Sprint Plan

You are the engineering-manager. Plan and set up a new sprint.

Move efficiently: run commands, show results, act. Don't narrate steps before doing them — do them, then summarize briefly.

Step 1: Gather state

Run all of these simultaneously (one pass — you won't need to re-read these files later):

•
gh api repos/{owner}/{repo}/milestones --jq '.[] | select(.state=="open")'
- •Open milestone found → warn: "Sprint N is still open. Continue anyway?" and wait for answer
•Read .claude/sprint/current.md (ignore if missing)
•Read .product/rice-scores.md
•Count .claude/sprint/archive/*.md → determines sprint number

Step 2: Priority health check

Run: gh issue list --state open --label agent-ready --limit 100 --json number,title,labels,createdAt

This step catches priority drift before you lock in a plan. A P0 stuck for two sprints shouldn't silently appear in a third — it needs a decision. Check for:

•P0 items open 2+ sprints → flag as stuck, recommend decision (descope or unblock)
•Items whose blockers are now closed → flag as newly unblocked, bump priority
•Launch blockers still at 0% → flag

Report in one line (e.g. "No major shifts" or "CD-XXX stuck 2 sprints — recommend descoping"). If significant: "Consider /reprioritize first."

Step 3: Select issues

Ask this before selecting anything:

"How many hours can you dedicate to review/testing this sprint?"

Use the answer to shape the capacity check below. Don't proceed past this question until you have the answer.

Then select top $ARGUMENTS issues (default: 5) from .product/rice-scores.md (already loaded in Step 1):

•P0 before P1; RICE as tiebreaker within priority
•Unblocked items first
•Start External items (F=4-5) regardless of other priorities — they have wait times that can't be recovered
•Capacity check: Agent (F=1-2) = 1-2h review each; Human (F=3) = direct user hours; External = calendar only

If selected items have dependencies on each other, note the chain explicitly and build a sequential schedule — don't list them as parallel.

If selected backlog items don't have open GitHub issues yet, note them — you'll create the issues in Step 6.

Step 4: Handle oversized items (if any)

If a selected item has Friction clearly higher than estimated or is too large to complete in one sprint:

•Spawn PO agent: define value boundaries for split
•Spawn Architect agent: validate technical feasibility
•Propose split — each part must deliver independent value, max 3 parts, naming: CD-XXXa, CD-XXXb
•Re-score RICE per part, create new GH issues on approval, update backlog

Step 5: Present plan

Keep it concise:

code

Sprint N (date – date)
Goal: [one sentence]

| # | Issue | Title | RICE | Type | Schedule |
|---|-------|-------|------|------|----------|

[Day-by-day schedule — parallel where independent, sequential where dependencies exist]

Ask: "Approve this plan?"

Step 6: Set up (on approval)

Work through this in order:

1. Create any missing GH issues for selected items that don't have them yet:

code

gh issue create --title "CD-XXX: Title" --body "..." \
  --label "agent-ready" --label "P1" --label "enhancement" \
  --milestone "Sprint N (date – date)"

2. Create milestone:

code

gh api repos/{owner}/{repo}/milestones \
  -f title="Sprint N (date – date)" \
  -f due_on="YYYY-MM-DDT23:59:59Z" \
  -f description="Goal: ..."

3. Assign issues to milestone (skip if already set during issue creation):

code

gh issue edit <number> --milestone "Sprint N (date – date)"

4. Label as planned:

code

gh issue edit <number> --add-label planned

5. Resolve worktree root: Check .claude/sprint/current.md for the path used last sprint. If no prior sprint exists, use ../cardo-worktrees/. If unclear, ask the user.

6. Create worktrees:

bash

git worktree add <worktree-root>/issue-<number> -b feature/<number>-<description> main

7. Write .claude/sprint/current.md:

markdown

# Sprint N
- **Milestone:** Sprint N (date – date)
- **Goal:** ...
- **Capacity:** X review hours
- **Issues:** #A, #B, #C
- **Started:** YYYY-MM-DD
- **Plan:**
  - Agent: #A, #B, #C (parallel / or sequential if dependencies)
  - Human: #D (requires ...)
  - External: #E (started day 1)

## Dependency Chain (if any)
#A → #B → #C

8. Print terminal launch commands (respect dependency order — note which to run after which):

code

Terminal 1:  cd <worktree-root>/issue-A && claude "/implement A"
Terminal 2:  cd <worktree-root>/issue-B && claude "/implement B"
             # Start after #A is merged
...

Step 7: Update dashboard

Run the /status flow to refresh the dashboard with sprint info.

Configuration

•Branch naming: feature/{issue-number}-{short-description}
•Sprint duration: 7 days default (adjust based on user input)