Sprint Execute

You are the engineering-manager. Execute all pending sprint issues.

Each issue gets its own feature branch and its own PR. Sprint-execute is an orchestrator: verify state, determine dispatch order, call /implement N for each Agent-type issue. You don't implement anything directly — delegate to the appropriate engineer via subagent or terminal command.

Move efficiently: act, then summarize.

Pre-flight

Run simultaneously:

•Read .claude/sprint/current.md — sprint number, issue list, dependency chain, worktree root
•Check open milestone: gh api repos/mohammad-shaddad/cardo/milestones --jq '.[] | select(.state=="open")'

Stop conditions:

•current.md missing → "No active sprint. Run /sprint-plan first."
•No open milestone → "Sprint milestone is not open. Check GitHub milestones."
•--dry-run in $ARGUMENTS → print dispatch plan, do not execute

Classify Issues

For each issue in current.md, read it: gh issue view N --json title,body,labels

Condition	Classification	Action
Has `agent-ready` label	Agent	Dispatch
Already labeled `in-progress` or `status:awaiting-release`	Running/Done	Skip — already in flight
No `agent-ready` label	Human	Skip — note for user
Body has `F=4`/`F=5` with external dependency	External	Skip — note for user

Verify Worktrees

Sprint-plan creates a worktree per issue at <worktree-root>/issue-N. Before dispatching, confirm each Agent issue has one:

bash

git worktree list

If a worktree is missing, create it:

bash

git worktree add <worktree-root>/issue-N -b feature/N-<short-desc> main

Derive <short-desc> from the issue title (lowercase, hyphens).

Dispatch Order

Read the dependency chain from current.md. Issues with no dependencies on each other can be dispatched in parallel; chained issues must run sequentially.

Independent issues — dispatch in parallel. Spawn one background subagent per issue:

Task: "cd into <worktree-root>/issue-N and run /implement N" (run_in_background: true)

If subagents are not available, print the terminal commands and wait for the user to confirm they've been launched:

code

Terminal 1:  cd <worktree-root>/issue-A && claude "/implement A"
Terminal 2:  cd <worktree-root>/issue-B && claude "/implement B"

Chained issues (A → B) — dispatch A. Only dispatch B after A's PR merges into main:

bash

gh pr list --head feature/A-<desc> --json state --jq '.[].state'

If A is not yet merged, mark B as "waiting" and tell the user to re-run /sprint-execute after #A merges — or run /implement B manually in its worktree at that point.

Circuit Breaker

If the same issue fails twice, stop and escalate — don't retry. Report what failed and what needs human attention before proceeding.

Report

After all issues are dispatched or skipped:

code

Sprint N — Execution
====================
Dispatched:       #A (CD-XXX), #B (CD-YYY)
Skipped (Human):  #C — requires manual work
Waiting on deps:  #D — blocked until #A merges

PRs to review (as CI completes):
  PR #NNN — CD-XXX
  PR #NNN — CD-YYY

Next:
  Run /review <pr-number> for each PR as it's ready.
  Chained issues: re-run /sprint-execute after #A merges to dispatch #B.
  All PRs merged → run /sprint-close.

Resume

Re-running /sprint-execute mid-sprint is safe. Issues labeled in-progress or status:awaiting-release are skipped automatically — only planned issues are dispatched.