make-plan

# Make Plan You are an ORCHESTRATOR. Create an LLM-friendly plan in phases that can be executed consecutively in new chat contexts. ## Delegation Model Use subagents for *fact gathering and extraction* (docs, examples, signatures, grep results). Keep *synthesis and plan authoring* with the orchestrator (phase boundaries, task framing, final wording). If a subagent report is incomplete or lacks evidence, re-check with targeted reads/greps before finalizing. ### Subagent Reporting Contract (MANDATORY) Each subagent response must include: 1. Sources consulted (files/URLs) and what was read 2. Concrete findings (exact API names/signatures; exact file paths/locations) 3. Copy-ready snippet locations (example files/sections to copy) 4. "Confidence" note + known gaps (what might still be missing) Reject and redeploy the subagent if it reports conclusions without sources. ## Plan Structure ### Phase 0: Documentation Discovery (ALWAYS FIRST) Before planning implementation, deploy "Documentation Discovery" subagents to: 1. Search for and read relevant documentation, examples, and existing patterns 2. Identify the actual APIs, methods, and signatures available (not assumed) 3. Create a brief "Allowed APIs" list citing specific documentation sources 4. Note any anti-patterns to avoid (methods that DON'T exist, deprecated parameters) The orchestrator consolidates findings into a single Phase 0 output. ### Each Implementation Phase Must Include 1. **What to implement** — Frame tasks to COPY from docs, not transform existing code - Good: "Copy the V2 session pattern from docs/examples.ts:45-60" - Bad: "Migrate the existing code to V2" 2. **Documentation references** — Cite specific files/lines for patterns to follow 3. **Verification checklist** — How to prove this phase worked (tests, grep checks) 4. **Anti-pattern guards** — What NOT to do (invented APIs, undocumented params) ### Final Phase: Verification 1. Verify all implementations match documentation 2. Check for anti-patterns (grep for known bad patterns) 3. Run tests to confirm functionality ## Key Principles - Documentation Availability ≠ Usage: Explicitly require reading docs - Task Framing Matters: Direct agents to docs, not just outcomes - Verify > Assume: Require proof, not assumptions about APIs - Session Boundaries: Each phase should be self-contained with its own doc references ## Anti-Patterns to Prevent - Inventing API methods that "should" exist - Adding parameters not in documentation - Skipping verification steps - Assuming structure without checking examples ## See Also - `oh-my-issues` — the issue-side sibling. When the plan you're being asked to make is rooted in a bug or feature backlog rather than a fresh idea, route through `oh-my-issues` first to cluster issues by root cause into plan masters and `plans/0X-*.md` design docs. `make-plan` then operates on the design doc for one plan slice.