Files
Claude-Code-Game-Studios/.claude/skills/sprint-plan/SKILL.md
Donchitos 70fbf670fc Gap closure: feedback loops, traceability, and new /content-audit skill
- NEW /content-audit skill: GDD-specified content vs implemented content gap
  report with COMPLETE/IN PROGRESS/EARLY/NOT STARTED per system
- balance-check: Fix & Verify Cycle phase (fix → re-verify → propagate-design-change)
- perf-profile: Scope & Timeline Decision phase for M/L effort optimizations
- playtest-report: Action Routing phase categorizes findings → design/balance/bugs/polish
- review-all-gdds: Phase 4 Cross-System Scenario Walkthrough (multi-system sequences)
- story-done: Test-Criterion Traceability (each AC mapped to a test, BLOCKING if >50% untested)
- code-review: ADR Compliance Check (ARCHITECTURAL VIOLATION / ADR DRIFT / MINOR DEVIATION)
- setup-engine: upgrade subcommand (pre-upgrade API scan, migration plan, VERSION.md update)
- story-readiness: Asset References Check (verifies referenced asset paths exist)
- validate-assets.sh: invalid JSON now exits 1 (blocking); naming issues exit 0 (warning)
- workflow-catalog.yaml + sprint-plan: /scope-check wired into production phase

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-03-12 11:18:43 +11:00

158 lines
4.7 KiB
Markdown

---
name: sprint-plan
description: "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."
argument-hint: "[new|update|status]"
user-invocable: true
allowed-tools: Read, Glob, Grep, Write, Edit
context: |
!ls production/sprints/ 2>/dev/null
---
When this skill is invoked:
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/`.
For `new`:
5. **Generate a sprint plan** following this format:
```markdown
# 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`:
5. **Generate a status report**:
```markdown
# 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]
```
### 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:
```yaml
# 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.
### Scope Reminder
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 (step 3 above), 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."
### Agent Consultation
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