Sprint Planner
Decompose complex implementation plans into focused, autonomous agent sprints. Each sprint is self-contained, has measurable acceptance criteria, and can execute without human intervention.
When invoked with arguments, decompose: $ARGUMENTS
When to Use
| Plan Characteristics | Action | |----------------------|--------| | >15 discrete steps or >8K tokens | Decompose into sprints | | Cross-domain work (multiple categories, services, or layers) | Decompose into sprints | | Long-running work requiring checkpoints | Decompose into sprints | | <10 steps, single domain, clear scope | Execute directly — decomposition adds overhead | | Exploratory or research work | Execute directly — fluid reasoning needs cross-domain context |
When uncertain, decompose. The cost of unnecessary decomposition is low; the cost of context collapse mid-execution is high.
Workflow
- Load the plan — Read the plan from the argument path or user input. If the input is a description rather than a file, ask for the full plan or spec location.
- Inventory work items — List every discrete deliverable (endpoints, migrations, features, integrations). Categorize each by complexity: setup, simple, stub, complex, integration.
- Identify dependencies — Map which items depend on others. Group independent items for parallel execution.
- Batch into sprints — Apply the Batching Strategy table below. Each sprint gets 2-6 items maximum.
- Write sprint definitions — Define each sprint using the Sprint Structure fields. Write acceptance criteria using the Acceptance Criteria Format.
- Build dependency chain — Express the full chain as:
1 → 2, 3 → 4 → 5 - Output the plan — Write the sprint plan using
assets/sprint-template.yaml. Append the Execution Protocol and Rollback sections fromreferences/execution-protocol.md.
Sprint Requirements
Every sprint MUST satisfy:
| Requirement | Constraint | |-------------|------------| | Duration | 2-4 hours | | Scope | 2-6 discrete items maximum | | Acceptance criteria | 3-5 verifiable checks with measurable outcomes | | Dependencies | Explicitly listed by sprint ID | | Autonomy | Executable without human intervention | | Token budget | Sprint definition fits in <2K input tokens (scope + criteria + constraints + references) |
Sprint Structure
Every sprint defines these fields:
| Field | Requirement |
|-------|-------------|
| sprint_id | Sequential integer |
| title | Format: "Category: Description" (e.g., "Setup: Create Feature Structure") |
| duration_hours | 1-4 hours |
| dependencies | List of sprint IDs that must complete first. Empty list if none |
| input_state | Exact filesystem/database state before sprint |
| output_state | Exact filesystem/database state after sprint |
| scope | Bulleted list of discrete work items |
| acceptance_criteria | 3-5 verifiable checks (see format below) |
| constraints | Explicit prohibitions — what NOT to do |
| reference_material | File path + line range or section name. Never paste full source |
| style_anchor | Path to shared conventions doc (naming, patterns, structure). All sprints reference the same anchor to prevent drift |
Acceptance Criteria Format
Use measurable, deterministic checks. Never use "code looks good", "follows conventions", or "works correctly".
| Criterion Type | Format | Example | |----------------|--------|---------| | Artifact exists | "Files exist: [paths]" | "Files exist: FundEndpoints.cs, AccountEndpoints.cs" | | Code pattern present | "[File] contains [pattern]" | "InvestorApiEndpoints.cs registers 5 handler methods" | | Build/test success | "[command] succeeds with [result]" | "dotnet build --configuration Release succeeds with 0 errors" | | Verification output | "[endpoint/command] returns [expected]" | "GET /api/v1/investors returns 200 with JSON array" | | Integration checkpoint | "Manual review: [action]" | "Manual review: Run smoke test and verify UI loads" |
Batching Strategy
| Sprint Type | Duration | Items | Use For | |-------------|----------|-------|---------| | Setup | 1h | 1 complex setup | Folder structure, service registration, scaffolding | | Simple CRUD bulk | 2-3h | 5-10 endpoints | Straightforward GET/POST handler migrations | | Stub migration | 2h | 8-12 stubs | Replace hardcoded data with database queries | | Complex work | 3-4h | 1-2 items | PDF generation, calculations, email, file processing | | Integration | 2h | 1 task | Route registration, config updates, OpenAPI verification |
Batching rules:
- Separate infrastructure setup from implementation
- Group by feature or category to reduce context switching
- Isolate complex work into dedicated sprints
- Never mix setup and implementation in the same sprint
- Design each sprint to be independently re-executable from its
input_state— if a sprint fails, it can be re-run without repeating prior sprints
Context Minimization
LLM performance degrades 30-40% when sprint context exceeds ~2K tokens, and information placed mid-context is used 30-60% less effectively than information at the start or end. Minimize each sprint definition to only what execution requires.
Rules:
- Reference the full plan by file path — do not paste content inline
- Order fields so acceptance criteria and constraints appear before reference material — critical information must not be buried at the end
- Target <2K tokens per sprint definition (scope + criteria + constraints + references combined)
# Correct
reference_material: "docs/plan.md lines 45-67"
# Wrong
reference_material: "[full source code pasted here]"
Dependency Ordering
Mark dependencies explicitly. Independent sprints can execute in parallel.
sprint_id: 4
dependencies: [1, 3] # Must complete sprints 1 and 3 first
Express the full chain in the plan header:
dependency_chain: "1 → 2, 3, 4 → 5 → 7"
Where commas indicate parallel sprints and arrows indicate sequential dependencies.
Output
Write the sprint plan as YAML using assets/sprint-template.yaml.
After the sprint definitions, append:
- Execution Protocol from
references/execution-protocol.md - Verification Gate from
references/execution-protocol.md - Rollback Procedures from
references/execution-protocol.md
See references/example.md for a complete 43-endpoint migration decomposed into 7 sprints.
Validation Checklist
- [ ] Every sprint has 3-5 measurable acceptance criteria
- [ ] No criterion uses subjective language
- [ ] All dependencies are explicitly declared
- [ ] No sprint exceeds 4 hours or 6 items
- [ ] Each sprint definition fits within ~2K input tokens
- [ ] Reference materials use file paths, not inline content
- [ ] Acceptance criteria and constraints appear before reference material in each sprint
- [ ] Dependency chain accounts for all sprints
- [ ] Independent sprints are marked for parallel execution
- [ ] Constraints specify what NOT to do, not just what to do
- [ ] Input and output states are concrete and verifiable
- [ ] Each sprint is independently re-executable from its
input_state - [ ] A
style_anchoris defined when the plan spans multiple sprints with shared conventions