---
name: repo-harness-sprint
description: Program-level sprint planning and execution entrypoint. Uses upper-layer PRDs from plans/prds/ when present, writes ordered sprint backlogs in plans/sprints/, then expands each row with $think before the existing plan, contract, and worktree flow.
when_to_use: "repo-harness-sprint, plan a sprint, create sprint backlog, from-prd, PRD to sprint, sprint from PRD, run next sprint task, sprint status"
---

# repo-harness-sprint

Use this command to plan a program-level Sprint from an upper-layer PRD or source spec and execute its tasks through the existing task-contract flow. Sub-routes: `plan`, `from-prd`, `run`, `status`.

## Protocol

1. Confirm the working repo with `git rev-parse --show-toplevel`; read `docs/spec.md`, `.ai/harness/policy.json`, and `bash scripts/sprint-backlog.sh status` when present.
2. Route `plan` (default when no sprint is active):
   - Discuss the product direction with the user from two named perspectives before writing anything: product (problem, users, success criteria, acceptance scenarios, non-goals) and architecture (capabilities touched, dependency order, risks, slice granularity).
   - Run `bash scripts/sprint-backlog.sh init --slug <slug> --title <title>`, then fill `## PRD`, `## Architecture Notes`, and the ordered `## Backlog` table from the upper-layer PRD or source spec; every row needs a concrete machine-checkable acceptance line and a mode (`contract` or `inline`).
   - Present the draft sprint to the user. Only after explicit approval set `> **Status**: Approved`; `check-task-workflow.sh --strict` rejects placeholder PRDs, placeholder acceptance lines, and duplicate backlog rows.
3. Route `from-prd` when the user gives `plans/prds/*.prd.md`:
   - Read the PRD `Problem`, `Users`, `Success Criteria`, `Acceptance Scenarios`, and `Non-goals`; summarize them into the Sprint `## PRD` section and set `> **Source PRD**:` to the PRD path.
   - Derive backlog rows from `Module Behaviors (P0)` and acceptance scenario groups. Preserve dependency order and make every acceptance line traceable to a PRD acceptance scenario.
   - Keep discussion focused on ordering, slice granularity, and mode selection; do not re-decide the product intent unless the PRD has blocking contradictions.
   - Use one row for one plan -> contract -> worktree cycle. Split larger work at stable integration boundaries.
   - Acceptance lines must be machine-checkable, such as a test command, file existence assertion, grep pattern, or numeric assertion. Avoid subjective wording such as "works well".
   - Default mode is `contract`; use `inline` only for small isolated documentation, configuration, or single-file changes.
4. Route `run` (incremental, one backlog task per invocation):
   - Run `bash scripts/sprint-backlog.sh next` to resolve the next pending row; when it exits 3, report the backlog as complete and recommend setting the sprint Status to Done after review.
   - Treat the row as a long-task waypoint, not a detailed implementation plan. Invoke `$think` with the sprint path, row task, mode, and acceptance line so the coding agent expands it into a decision-complete plan.
   - Capture the approved `$think` output with `bash scripts/capture-plan.sh --source waza-think --source-ref sprint:<sprint-file>#<task> --status Approved --execute` so the plan projects through the contract worktree flow.
   - `bash scripts/sprint-backlog.sh start-task` remains a compatibility helper for reserving a row and generating a thin plan seed; its generated plan must still run `$think` before code edits.
   - Execute the slice as usual (implement, `/check`, external acceptance, `bash scripts/contract-worktree.sh finish`); finish back-fills the backlog row warn-only.
5. Route `status`: report `bash scripts/sprint-backlog.sh status` plus the Active Sprint section of `tasks/current.md`; mutate nothing.
6. After each completed task, re-read the sprint file before starting the next one; user edits to the backlog override stale session memory.

## Failure Modes

- If no sprint file exists and the user asked for `run` or `status`, report that no sprint is active and route to `plan`.
- If the backlog table is malformed or `check-task-workflow.sh --strict` rejects the sprint, stop and fix the sprint file before starting any task.
- If `start-task` fails after the plan was captured, report the orphan plan path and stop instead of retrying blindly.
- If a task contract is already executing in this worktree, finish or archive it first; never stack a second backlog task on top of it.

## Boundaries

- Does not implement backlog tasks itself; execution always flows through the existing plan -> contract -> worktree -> verify gates.
- Does not set `> **Status**: Approved` without explicit user approval of the PRD and backlog.
- Never bypasses `/check`, external acceptance, or `verify-sprint.sh` to mark a backlog row complete.
- Goal mode (`run --goal`, autonomous continuation) is not part of this command yet; treat requests for it as future work and say so.
- Do not run two backlog tasks in parallel: concurrent contract rows merge-conflict on the sprint file's Updated and Execution Log lines; the backlog is an ordered queue.
- `tasks/todos.md` stays the deferred-goal ledger; never write the backlog there.
