settled-reach/.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", "sprint planning", or invokes /sprint-plan. Gathers current sprint status, scans the backlog, proposes ticket selection, and writes briefing files per team to docs/sprints/sprint-N/.	true	Task, Read, Grep, Glob

Plan Sprint

Delegate this entire skill to SI (Project Manager agent, subagent_type: si).

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

Task(
  subagent_type: "si",
  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 SI's output to the user when done. Do NOT run the workflow yourself.

---

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

Generate sprint briefing files for each active team (e.g. server.md, client.md, copy.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

Team	Branch	Default Agents	Focus
server	server	Dudley (dev), Tyre (arch), Hoshe (QA)	Rust/bevy_ecs simulation, ECS systems, knowledge graph, perception
client	client	Stig (dev), Tyre (arch), Hoshe (QA)	Godot 4 client, rendering, UI, HUD, input handling
copy	copy	Mellanie (author), Paula (narrative), Gestalt (systems)	Dialogue, monologue, UI text, knowledge vocabulary, lore
audio	audio	Inigo (sound design)	Soundscapes, ambient layers, diegetic cues, audio propagation
visual	visual	Araminta (art direction)	Art assets, sprites, visual consistency, style guides
ci	ci	Justine (build/deploy)	Build pipelines, CI/CD, tooling, packaging
planning	planning	Purpose-assembled (see below)	Design discussions, decision resolution, workshop-style tickets

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

Planning Team Tickets

Some tickets need design discussion before implementation can begin — tagged "NEEDS DESIGN DISCUSSION" or blocking multiple downstream tickets with open questions. These run on the planning branch as structured discussions with the user and a purpose-assembled agent panel.

When to create a planning ticket:

• Ticket description says "NEEDS DESIGN" or "NEEDS DESIGN DISCUSSION"
• Ticket blocks 2+ downstream tickets across different teams
• Open Q-NNN items that block sprint candidates
• Architectural decisions that need multi-domain input before implementation

Planning briefing format (differs from implementation briefings):

• Agents line: List agents by domain relevance, not fixed team roster. Pick from: Gestalt (systems), Miri (worldbuilding), Araminta (visual/spatial), Tyre (technical), Paula (narrative), Ozzie (player experience), Gore (themes), Nigel (replayability). Typically 4-6 domain agents, plus Qatux (documenter — records decisions, updates domain files) and SI (project manager — creates follow-up tickets, updates sprint assignments).
• Discussion rounds: Structure the conversation into 2-3 rounds (inventory → proposals → convergence)
• Context section: List all existing design docs, decisions, and related tickets that participants must read before the discussion
• Output specification: What the discussion must produce — typically a D-record in decisions/, possibly a design doc in docs/design/
• Decision questions: Specific questions the discussion must answer, not open-ended exploration

Workflow

1. Run sprint prepare

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

tooling/db/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:

tooling/db/ticket children <epic_id>

Use tooling/db/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:

# Server modules
ls server/src/ server/src/*/

# Client scripts
ls client/scripts/ client/scripts/*/

Read key files that sprint tickets will build on (bridge types, existing renderers, etc.) 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 (Sprint 1 was "Run", Sprint 2 was "See")
• Sprint goal — one sentence shared across all teams
• Server tickets — stories from server-side epics
• Client tickets — stories from client-side 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)
• Respect D-030 test priority phases (sprint 1-2: infra, sprint 3-4: integration)
• 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.

IMPORTANT — worktree-relative paths: This project uses git worktrees. Each team branch is checked out in its own worktree, and each worktree contains the full repo (server/, client/, docs/, etc.). All file paths in briefings must be relative to the worktree/git root. Example: server/src/bridge/types.rs, not /absolute/path/to/server/src/... or paths that navigate outside the git root (../sibling-worktree/...). Agents must stay within the git root they are running in.

Key requirements per file:

• server.md: Carry-overs, new tickets, dependency chain, key decisions, notes referencing existing Rust modules by path from worktree root (e.g. server/src/simulation/movement.rs)
• client.md: Same structure, notes referencing existing GDScript files by path from worktree root (e.g. client/scripts/rendering/fog.gd)
• copy.md: In-game text tasks — dialogue, UI copy, tooltips, flavor text, lore
• audio.md: Sound design, music, audio integration tasks
• visual.md: Art direction, asset creation, visual consistency tasks
• ci.md: Build pipeline, CI/CD, tooling, infrastructure tasks
• joint.md: 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
tooling/db/sqlite-exec "UPDATE sprints SET name='Sprint N: Theme', goal='goal' WHERE id=N"

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

The sprint stays in planning status until explicitly activated via tooling/db/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