Claude-Code-Game-Studios/.claude/skills/sprint-plan/SKILL.md

name, description, argument-hint, user-invocable, allowed-tools, context

name	description	argument-hint	user-invocable	allowed-tools	context
sprint-plan	Generates a new sprint plan or updates an existing one based on the current milestone, completed work, and available capacity. Pulls context from production documents and design backlogs.	[new|update|status]	true	Read, Glob, Grep, Write, Edit	!ls production/sprints/ 2>/dev/null

Phase 1: Gather Context

1. Read the current milestone from production/milestones/.

2. Read the previous sprint (if any) from production/sprints/ to understand velocity and carryover.

3. Scan design documents in design/gdd/ for features tagged as ready for implementation.

4. Check the risk register at production/risk-register/.

---

Phase 2: Generate Output

For new:

Generate a sprint plan following this format and present it to the user. Ask: "May I write this sprint plan to production/sprints/sprint-[N].md?" If yes, write the file, creating the directory if needed. Verdict: COMPLETE — sprint plan created. If no: Verdict: BLOCKED — user declined write.

# 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
- [ ] No S1 or S2 bugs in delivered features
- [ ] Design documents updated for any deviations
- [ ] Code reviewed and merged

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: Write Sprint Status File

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

Ask: "May I also write production/sprint-status.yaml to track story status?"

Format:

# Auto-generated by /sprint-plan. Updated by /story-done.
# DO NOT edit manually — use /story-done to update story status.

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/stories/path.md]"
    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: Scope and Risk Check

After presenting the sprint plan, add:

Scope check: If this sprint includes stories added beyond the original epic scope, run /scope-check [epic] to detect scope creep before implementation begins.

When reviewing stories during selection, note any stories that appear outside the original epic goals. If any are uncertain, flag them inline: "Are these stories within the original epic scope? If unsure, /scope-check can verify."

For comprehensive sprint planning, consider consulting:

• producer agent for capacity planning, risk assessment, and cross-department coordination
• game-designer agent for feature prioritization and design readiness assessment

---

Phase 5: Next Steps

After the sprint plan is written, recommend:

• /sprint-status — check progress mid-sprint
• /scope-check [epic] — verify no scope creep before implementation begins
• /dev-story [story-file] — begin implementing the first story
• /story-readiness [story-file] — validate a story is ready before starting it