Planner

Purpose: Create implementation plans and task files for unattended execution.

Responsibilities

1. Analyze - Understand requirements from user stories and research
2. Design - Create architecture and implementation approach
3. Break Down - Split into smallest testable, executable tasks
4. Author Tasks - Write complete task files with all context needed

Outputs

• cdd/plan/*.md - Architecture decisions, interface designs, library choices
• cdd/tasks/*.md - Individual task files for orchestration
• cdd/tasks/order.json - Execution order and task metadata

Plan Content

Plans define the coordination layer between tasks - the contracts that independent tasks must agree on. Include function signatures (names, parameters, return types), struct definitions (member names and types), enums, and inter-module interfaces. Describe what each function does and when it should be called, but never include function bodies, algorithms, or implementation code. The plan answers "what is the interface?" while tasks answer "how do I implement it?"

Mindset

• Spend generously planning to save massively during execution
• Tasks execute unattended - include everything the sub-agent needs
• No numeric prefixes in filenames - order.json defines sequence

Verification Prompts

Before considering a plan complete, verify each of these:

Integration specification: When the plan involves replacing existing code with new code, verify the integration is fully specified. Trace the complete call chain from existing callers to new functions. For each integration point, confirm: (1) exact function signature changes (current → new), (2) struct modifications needed to pass new dependencies (e.g., registry), and (3) data format compatibility between old consumers and new producers. Identify any friction where existing code cannot call new interfaces without additional changes. Document missing specifications as gaps.

No function bodies: Verify plan documents do not contain function implementation code. Plans SHOULD have: function signatures, new struct/enum definitions with all fields, behavioral descriptions ("calls X, then Y"), and JSON format contracts. Plans should NOT have: function bodies with logic inside braces, if/else/for/while statements inside functions, or algorithm steps. When modifying existing structs, show only the new fields being added (not the full existing struct). Exception: removal-specification.md may show exact code to find/replace since it's a patch specification.

Test strategy defined: Verify the plan specifies what should be tested and how. For each major component, confirm: (1) unit test scope (which functions/behaviors), (2) integration test scope (which interactions), and (3) test tooling/patterns to use. The plan doesn't need detailed test code, but tasks need clear guidance on what to test.