settled-reach/whatsinagame/templates/.claude/skills/sprint-plan/SKILL.md

name, description, user-invocable, allowed-tools

name	description	user-invocable	allowed-tools
sprint-plan	Plan the next sprint and generate team briefing files. Use when the user says "plan sprint", "prep sprint briefing", "plan next sprint", or invokes /sprint-plan.	true	Task, Read, Grep, Glob

Plan Sprint

Delegate this entire skill to the Project Manager agent (subagent_type: project-manager or your project's PM agent — see .claude/agents/ for the correct type).

When this skill is invoked, spawn the PM using the Task tool:

Task(
  subagent_type: "project-manager",
  prompt: "Run /sprint-plan for Sprint N. Read the skill at
    .claude/skills/sprint-plan/SKILL.md for the full workflow,
    then execute it. Use the arguments provided: {args}",
  description: "Plan sprint N"
)

Pass through any arguments the user provided (e.g. sprint number). Present the PM's output to the user when done. Do NOT run the workflow yourself.

---

The remainder of this file is the PM's reference for executing the workflow.

Generate sprint briefing files for each active team (e.g. server.md, client.md, content.md, joint.md) for the next sprint based on current project state. Only generate briefings for teams that have tickets in the sprint.

Teams and Default Agents

Define your teams in CLAUDE.md. Example structure:

Team	Branch	Default Agents	Focus
backend	server	Backend Dev, Architect, QA Engineer	Server-side systems, APIs, data layer
frontend	client	Frontend Dev, Architect, QA Engineer	Client UI, rendering, input handling
content	content	Content Author, Narrative Designer, Domain Expert	Dialogue, UI text, lore, flavor text
audio	audio	Audio Designer	Soundscapes, ambient layers, audio effects
visual	visual	Visual Designer	Art assets, visual consistency, style guides
ci	ci	DevOps Engineer	Build pipelines, CI/CD, tooling, packaging

When writing briefings, name the assigned agents in the Agents line of each file so the team knows who to spawn.

Workflow

1. Run sprint prepare

Get carry-overs, backlog candidates, and decision gaps in one shot:

db/connectors/sprint prepare

This auto-detects the next sprint number (max ID + 1), creates the sprint record in planning status if needed, and outputs:

• Previous sprint status and carry-over candidates
• Backlog candidates grouped by team
• Decision coverage gaps
• Already-assigned tickets (if any)

2. Deepen the scan

For critical epics, check their children for granular candidates:

db/connectors/ticket children <epic_id>

Use db/connectors/ticket show --brief <id> [<id>...] to quickly scan multiple tickets.

3. Read existing code state

Scan what's already built to write accurate "what exists" notes:

# List project modules/directories
ls <project-dirs>

Read key files that sprint tickets will build on to reference specific integration points in the briefing.

4. Select tickets — propose to user

Based on the backlog scan, propose a sprint with:

• Sprint theme — a short name (e.g., Sprint 1 "Foundation", Sprint 2 "Visibility")
• Sprint goal — one sentence shared across all teams
• Team tickets — stories from each team's epics
• Joint tasks — integration proofs, pre-sprint decisions, schema work

Present the proposal using AskUserQuestion for the user to approve or adjust.

Selection heuristics:

• Follow dependency chains (don't pick a ticket if its blocker isn't in scope)
• Mix carry-overs with new work
• Aim for 3-6 tickets per team, with parallel tracks where possible
• Check decisions/questions.md for open Q-NNN items that block candidates

5. Read relevant decisions

For the selected tickets, identify which decisions/*.md files are relevant. Read them to provide accurate cross-references in the briefing.

6. Write briefing files

Create docs/sprints/sprint-N/ and write one file per team.

Read the template at references/briefing-template.md in this skill directory for the exact file structure.

Key requirements per file:

• Team briefings: Carry-overs, new tickets, dependency chain, key decisions, notes referencing existing modules by path from project root
• Joint briefing: Pre-sprint decisions table, integration tickets, sprint completion proof (concrete observable criteria), test plan alignment

Only generate briefing files for teams that have tickets assigned in the sprint. Not every sprint will have work for every team.

7. Assign tickets to sprint in DB

After the user approves, assign all selected tickets. The sprint record was already created by sprint prepare in step 1 (status: planning). Update it with the theme and goal, then assign tickets:

# Update the sprint with theme and goal
db/connectors/sqlite-exec "UPDATE sprints SET name='Sprint N: Theme', goal='goal' WHERE id=N"

# Assign tickets
db/connectors/ticket sprint assign <ticket_id> <sprint_id>

The sprint stays in planning status until explicitly activated via db/connectors/sprint start. This prevents starting an unplanned sprint.

8. Present summary

Output:

• Sprint number, theme, and goal
• Ticket count per team
• Carry-over count
• Open questions that need early resolution
• Files written