sprint-plan skill

!bash "${CLAUDESKILLDIR}/../../hooks/yaml-helper.sh" resolveconfig --keys reviewmode,automation,story_granularity,workflow

Resolved above — use as-is; --review overrides review_mode. No block → defaults in .claude/docs/config-resolution.md.

Existing Sprints

!ls production/sprints/ 2>/dev/null || echo "(no production/sprints/ directory yet)"

Resolved before this skill runs — use it to identify the previous sprint in Phase 1 rather than re-globbing.

Phase 0: Parse Arguments

Extract the mode argument (new, update, or status).

See .claude/docs/director-gates.md for the full check pattern. Individual gate definitions live in .claude/docs/director-gates/[gate-id].md — the spawned agent reads its own gate file; do not read it in the parent session.

Every AskUserQuestion call follows .claude/docs/automation-modes.md (collaborative asks always · guided major-only · autonomous logs and proceeds; automationalwaysask categories always prompt).

storygranularity — it sets how many stories to allocate per sprint, scaled by velocity: 2–4 at coarse, 6–10 at balanced (default), 15–25** at fine.

Review mode check (before gates run):

flag, no modes.reviewmode in project.yaml, no production/review-mode.txt) and** this is a new sprint, do not silently take the step-4 lean default — instead use AskUserQuestion:

• The review mode was already resolved in steps 1–4 above — do not re-resolve it.
• Special case: if steps 1–3 all found nothing configured (no --review

sprint with nothing configured, that is the lean default).

• Prompt: "No review mode is set. Which review depth would you like for this sprint?"
• Options:
• [A] full — spawn all director and lead gates
• [B] lean — skip non-phase-gate director reviews (recommended for most sprints)
• [C] solo — skip all gate spawning
• After selection: dual-write the chosen mode — set modes.review_mode in project.yaml (primary; add the modes: block if absent) AND write production/review-mode.txt (legacy fallback). Say: "Review mode set to [mode] and saved to project.yaml (and production/review-mode.txt)."
• In every other case the value resolved in steps 1–4 stands (for a non-new

Do not write until Phase 1 confirms the sprint can be planned. This write

lands in Phase 0, before the Phase 1 backlog check that aborts the run —

observed live: the run correctly BLOCKED on "No stories found under

production/epics/" and project.yaml had already gained

review_mode: lean. A skill that decides it cannot run must not have edited

config on the way to deciding. Hold the selection in memory, complete Phase 1,

and write only if planning proceeds.

Confirm the destination before writing. The question above asks for review

depth "for this sprint"; the write is permanent project config on a

rigor-fronted knob. Ask explicitly: "Set modes.review_mode: [mode] in

project.yaml (persists beyond this sprint), or use it for this sprint only?"

Phase 1: Gather Context

No skill writes this directory — it is authored by hand from .claude/docs/templates/milestone-definition.md. On the majority of projects it is absent, which is the normal state, not a gap: note "no milestone defined — planning against the story backlog alone" and continue. Never block sprint planning on it, and never infer a milestone from the sprint files.

1. Read the current milestone from production/milestones/ if it exists.

understand velocity and carryover.

1. Read the previous sprint (if any) from production/sprints/ to

input this phase cannot do without:

1. Find the stories to plan — this is the actual backlog, and it is the one

Glob production/epics/**/story-*.md
   Grep pattern="^> \*\*Status\*\*" glob="production/epics/**/story-*.md" output_mode="content"

Stories live at production/epics/[epic-slug]/story-NNN-[slug].md — that is where /create-stories writes them and where /dev-story looks for them. Plan from the ones marked Ready. Use the grep rather than reading each story: at this stage you need status and title, not the body.

If the glob returns nothing: "No stories found under production/epics/. Run /create-stories first (at standard/full, /create-epics before it)." Do not proceed to invent work items — a sprint plan that references stories which do not exist cannot be implemented.

features those stories implement. At workflow: minimal there are no per-system GDDs — use design/game-brief.md instead, and do not treat the absent GDDs as missing work. (Note: /sprint-plan is optional at minimal — the brief's Build order already is the plan.)

1. Scan design documents in design/gdd/ for additional context on the

Like the milestone above, no skill writes it — entries are authored by hand from .claude/docs/templates/risk-register-entry.md. If the directory is absent, say so once ("no risk register — risks assessed from the sprint contents only") rather than skipping risk assessment silently.

1. Check the risk register at production/risk-register/ if it exists.

Phase 2: Generate Output

For new:

Generate a sprint plan following this format and present it to the user. Do NOT ask to write yet — the gate phases run first and may require revisions before the file is written: the producer feasibility gate (Phase 4, spawned only in full review mode — skipped in lean/solo) and the QA plan check (Phase 5, all modes).

# Sprint [N] — [Start Date] to [End Date]

## Sprint Goal
[One sentence describing what this sprint achieves toward the milestone]

## Capacity
- Total days: [X]
- Buffer (20%): [Y days reserved for unplanned work]
- Available: [Z days]

## Tasks

### Must Have (Critical Path)
| ID | Task | Agent/Owner | Est. Days | Dependencies | Acceptance Criteria |
|----|------|-------------|-----------|-------------|-------------------|

### Should Have
| ID | Task | Agent/Owner | Est. Days | Dependencies | Acceptance Criteria |
|----|------|-------------|-----------|-------------|-------------------|

### Nice to Have
| ID | Task | Agent/Owner | Est. Days | Dependencies | Acceptance Criteria |
|----|------|-------------|-----------|-------------|-------------------|

## Carryover from Previous Sprint
| Task | Reason | New Estimate |
|------|--------|-------------|

## Risks
| Risk | Probability | Impact | Mitigation |
|------|------------|--------|------------|

## Dependencies on External Factors
- [List any external dependencies]

## Definition of Done for this Sprint
- [ ] All Must Have tasks completed
- [ ] All tasks pass acceptance criteria
- [ ] QA plan exists (`production/qa/qa-plan-sp

For update:

Update an existing sprint plan:

1. Read the most recent sprint plan from production/sprints/.
2. Present the current story list with their current statuses from production/sprint-status.yaml.
3. Ask the user what to change: stories to add, remove, reprioritize, or re-estimate. Use AskUserQuestion to gather changes.
4. Apply the changes and re-present the full revised plan for review.
5. Re-run the producer feasibility gate (Phase 4) on the revised plan.
6. Write the updated markdown plan and yaml together (same approval as new mode).

Note: update mode does not reset story statuses. Stories already marked in-progress or done keep their status. Only backlog and ready-for-dev stories can be removed or reprioritized freely.

For status:

Generate a status report:

# Sprint [N] Status -- [Date]

## Progress: [X/Y tasks complete] ([Z%])

### Completed
| Task | Completed By | Notes |
|------|-------------|-------|

### In Progress
| Task | Owner | % Done | Blockers |
|------|-------|--------|----------|

### Not Started
| Task | Owner | At Risk? | Notes |
|------|-------|----------|-------|

### Blocked
| Task | Blocker | Owner of Blocker | ETA |
|------|---------|-----------------|-----|

## Burndown Assessment
[On track / Behind / Ahead]
[If behind: What is being cut or deferred]

## Emerging Risks
- [Any new risks identified this sprint]

Phase 3: Prepare Sprint Status File

After generating a new sprint plan, also prepare the production/sprint-status.yaml content. This is the machine-readable source of truth for story status — read by /sprint-status, /story-done, and /help without markdown parsing.

Do not write the yaml yet — hold it in context. The producer feasibility gate (Phase 4, full review mode only) may revise the story list; the QA plan check (Phase 5) runs in every mode. Both files are written together after Phase 5 in a single write approval.

Format:

# Auto-generated by /sprint-plan. Updated by /story-done and /dev-story.
# DO NOT edit manually — use /story-done to update story status.
#
# Status value mapping (yaml ↔ story file Status field):
#   backlog        ↔  Not Started
#   ready-for-dev  ↔  Ready
#   in-progress    ↔  In Progress
#   review         ↔  In Review
#   done           ↔  Complete
#   blocked        ↔  Blocked

sprint: [N]
goal: "[sprint goal]"
start: "[YYYY-MM-DD]"
end: "[YYYY-MM-DD]"
generated: "[YYYY-MM-DD]"
updated: "[YYYY-MM-DD]"

stories:
  - id: "[epic-story, e.g. 1-1]"
    name: "[story name]"
    file: "[production/epics/[epic-slug]/story-NNN-[slug].md]"   # the real path, verbatim from the Glob above
    priority: must-have        # must-have | should-have | nice-to-have
    status: ready-for-dev      # backlog | ready-for-dev | in-progress | review | done | blocked
    owner: ""
    estimate_days: 0
    blocker: ""
    completed: ""

Initialize each story from the sprint plan's task tables:

• Must Have tasks → priority: must-have, status: ready-for-dev
• Should Have tasks → priority: should-have, status: backlog
• Nice to Have tasks → priority: nice-to-have, status: backlog

For update: read the existing sprint-status.yaml, carry over statuses for stories that haven't changed, add new stories, remove dropped ones.

Phase 4: Producer Feasibility Gate