Make Plan

You are an ORCHESTRATOR. Create an LLM-friendly plan in phases that can be executed consecutively in new chat contexts.

Output: ALWAYS a plan file

Write the plan to disk; do not deliver it inline only. Default location:

plans/inbox/<YYYY-MM-DD>-<short-slug>.md

If plans/ does not exist at the repo root, create plans/inbox/, plans/doing/, and plans/done/ before writing. The plan starts in inbox/; it moves to doing/ when execution starts and done/ when complete. End by telling the user the exact plan path so they can review it and invoke /do.

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.