---
name: minimalist-sprint-execution
description: Use when implementing a selected sprint increment and the agent must preserve story scope, test behavior, record evidence, and keep unselected backlog work out of the change.
---

# Minimalist Sprint Execution

Resolve verification.md from <plugin-root>/templates/ and the execution
contracts from <plugin-root>/references/artifact-contracts.md.

Implement the planned increment. The active sprint plan, selected story IDs,
acceptance criteria, and Definition of Done are the execution boundary.

## Before editing

Read:

- the sprint record and plan;
- each selected story;
- relevant existing code and tests;
- explicit exclusions;
- project instructions and authorization constraints.

Confirm the Sprint Goal and list the selected story IDs in the execution record.
If the plan is missing, contradictory, or requires unselected work, stop at the
smallest blocking decision.

## Execution behavior

For each task:

1. state the story ID and expected evidence;
2. write or identify the behavior check before implementation when practical;
3. implement the smallest change that satisfies the task;
4. run the narrowest relevant check;
5. update task and story status from evidence;
6. continue only while the change serves the selected scope.

Use the project's existing architecture, contracts, authorization boundaries, and
test conventions. Preserve unrelated behavior. Do not add abstractions,
refactors, dependencies, or automation without a reason tied to the selected
story or an approved scope change.

## Scope protection

A request during execution is classified before code changes:

- clarification: acceptance meaning is unchanged;
- defect: selected behavior fails an agreed criterion;
- new backlog story: capability is outside selected scope;
- scope swap: decision-maker explicitly removes existing scope to add it.

Record the classification and decision in the sprint record. Do not silently
append a task or mark new work as part of the current sprint.

## Evidence states

Keep these separate:

- written: implementation exists;
- checked: a verification command ran;
- passing: expected result was observed;
- demonstrated: the increment was shown;
- accepted: the decision-maker approved the criteria.

A passing test is evidence of behavior, not automatic user acceptance.

## Blockers and incomplete work

Expose missing requirements, failing checks, environmental blockers, and scope
conflicts. Do not hide them behind a completed label. At the end of the timebox,
return incomplete stories as carried-over with remaining scope and evidence.

## Handoff

Produce or update verification.md and the selected story history. Pass the
increment and evidence to minimalist-sprint-review. The review, not the coding
agent, determines acceptance.