/plan

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

Ideator Opus

Explores solution space via brainstorming skill — one question at a time, multiple-choice where possible.
Architect Opus

File-level design decisions and implementation plans. Confirms skills and produces the technical plan.
Researcher Sonnet

Live documentation lookup and best practices — dispatched by architect when technical validation is needed.

optional
Author Haiku

Writes plan document and creates backlog task with full field mapping. Pushes to git.
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.

Ideator Opus

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 + Researcher (Sonnet, optional)

Design — Architect Plan

The architect agent 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.
The orchestrator infers which skills are relevant and asks the human to confirm. 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.
Author Haiku

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.
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.