/plan

Guide a collaborative planning session to refine an idea into a structured build plan.

Explorer Haiku

Context — Explore the Codebase

Explorer maps all relevant codebase areas. A 2–3 line summary of what exists and what will be affected is presented before any refinement begins.

Brainstorming via brainstorming skill

Refinement — Socratic Dialogue

The brainstorming skill drives a Socratic dialogue with the human — one question at a time, multiple choice where possible, exploring 2–3 approaches before settling.

commands/plan.md
Continue until the brainstorming skill reaches a fully-formed
design with clear answers to:
- What must it do?
- What must it NOT do or break?
- What does "done" look like (specific, testable)?
The three-question framework ensures every plan covers requirements, constraints, and testable acceptance criteria before any code is written.
commands/plan.md
### Skill collision rules
- brainstorming: dialogue and design only — skip its
  built-in spec doc save, spec review loop, and
  writing-plans invocation; /plan owns those steps
/plan overrides brainstorming's built-in save and review behavior. The brainstorming skill handles dialogue only — /plan owns the plan file creation and backlog task lifecycle.
Architect Opus skill · + Researcher (Sonnet, optional)

Design — Architect Plan

The architect skill produces a design plan. If skills were confirmed during refinement, the architect includes a Skills directive in the plan.

commands/plan.md
Scan the available skills list and infer any skills
relevant to the deliverable type. Present your
suggestions with a one-line rationale each:
> "Based on what we're building, I'd suggest:
> - `frontend-design` — polished HTML/CSS output
> - `brand-guidelines` — Anthropic brand styling
> Confirm all, drop any, or add others?"
Collect the confirmed set as confirmed_skills.
Relevant skills are inferred and confirmed with the human. These flow through to the architect's plan as a Skills: directive, and from there into /build — so builder agents automatically load the right skills before starting work.
Plan External Review if EXTERNAL_REVIEW_API_KEY configured

External Review — Plan Quality Check

An external LLM reviews the plan document for gaps, contradictions, unverifiable acceptance criteria, and missing edge cases. Findings are appended to the plan before the Author saves it.

commands/plan.md
After architect produces the plan, run external
plan review if EXTERNAL_REVIEW_API_KEY is set:
- Check for internal contradictions
- Flag unverifiable acceptance criteria
- Surface missing edge cases
- Append findings to plan before save
External review runs silently if not configured — it never blocks the pipeline. When configured, PASS verdicts confirm plan quality; FAIL findings are appended to the plan document for the human to review before /build begins.
Author Haiku skill

Save — Plan & Backlog Task

The plan is saved as a structured markdown file that becomes the /build plan, then a backlog task is created with full field mapping.

Plan file format
# Feature: [Title]

## What it must do
[Functional requirements from the refinement session]

## What it must NOT do
[Constraints and non-goals]

## Acceptance criteria
[Specific, testable outcomes]

## Technical approach
[From architect — chosen approach, files to change,
 dependencies, risks, execution order]
**Skills:** [comma-separated list, or omit if none]

## Edge cases
[Known edge cases to handle]
This file IS the /build plan. Every section maps directly to a backlog task field. A builder reading only the task has identical information to one reading the plan file.
Backlog field mapping from plan file sections
Plan section Task field Rule
# Feature: <title> title Extracted heading
## What it must do + ## What it must NOT do -d Both sections verbatim
Each - [ ] item in Acceptance criteria --ac One flag per item
## Technical approach --plan Full section verbatim
## Edge cases --notes Prefix with "Edge Cases:"
**Skills:** line append to --notes If present
Verbatim, not summarised. Each acceptance criterion gets its own --ac flag — never combine multiple items into a single string.
commands/plan.md
Completeness audit: Re-read the plan file and audit
it against the full conversation. Check for: decisions
made but not captured, field-level detail missing,
constraints discussed but not written down.
The completeness audit enforces "complete dehydration" — a builder reading only the task must have identical information to one reading the plan file. No implicit knowledge allowed.
Hand off Presented to the human

Hand off — Choose Next Step

Three options are presented to the human after the plan and task are saved.

Build it now

Run /build immediately using the saved plan. Proceeds without pausing for individual confirmations.

Save and stop

Keep the plan for later. The exact /build command and task ID are shown for reference when you're ready.

Something else

Type a custom instruction. The plan and task are already saved — branch off in any direction.