---
name: make-a-plan
description: The front door for any coding task, on any tool. Interview the user first, confirm a short brief BEFORE any code exists, then draft a plan, get it approved, and delegate execution across workstreams to smaller-model subagents. Use this for ANY request to build, create, fix, scaffold, redesign, or change software — UI work, scripts, components, pages, integrations — even when the user doesn't say "plan" or "agents". "Build X", "make me a Y", "fix these", "clean this up" all qualify. Skip only for trivial one-line edits.
---

# Make a plan

The front door for any coding task. Three phases: **Brief** (interview → confirmed brief, before any code exists), **Plan & execute** (decompose → approved plan → delegate to subagents → verify), then **Wrap up** (plain-language summary of what shipped).

Why this exists: it controls prompt quality at the source. A two-minute interview surfaces the states, edge cases, and audience the request left implicit — and over time it teaches the requester to write better prompts. And the top-level session (the most capable model) is worth more as planner and reviewer than as the hands; execution goes to smaller, parallel subagents.

The requester may not be a developer — a designer or writer describing an idea in loose terms is expected, and the early phases exist to help them figure out what they actually want, not to fill the gaps with your own assumptions. Keep all user-facing communication plain-language and jargon-free unless the user demonstrates technical fluency first.

## Phase 1 — Brief

**Restate the goal in one or two sentences of your own words before doing anything else.** This shows the user what you heard, and mishearings surface immediately instead of three phases later.

If the request involves existing files, a codebase, or prior work, look before you ask — questions grounded in what actually exists are far more useful than generic ones. **Never ask something you could answer yourself by reading the files.**

Then interview the user before writing anything — but **every question must earn its place**. A question is worth asking only if the answer changes what you'd build; before asking, be able to name the decision it unblocks. Filler questions are worse than no questions: they train the user to ignore the interview. **Zero questions is a legitimate interview** — when the request plus available context (the repo, the conversation, project docs) already answer everything, skip straight to the brief and let the user correct it there.

Depth is a ceiling, not a target: at most 2–3 questions for small tasks, deeper intake only when the work is genuinely large or ambiguous. Use AskUserQuestion where available (batch in one call); propose defaults for everything you don't ask about — the brief confirmation is the user's chance to override them.

Prompts for what *might* be missing — not checklists to run through:

- **UI / front end:** states (empty, loading, error, success), breakpoints, which existing components/design system to use, audience, light/dark
- **Scripts / CLI / automation:** inputs and their formats, outputs and where they land, edge cases and failure behavior, run environment
- **Data work:** source of truth, expected volume, what "done" looks like, who consumes the result
- **Integrations / APIs:** auth, rate limits, failure/retry behavior, sandbox vs. production

Then write a **short brief** — a few lines, not a spec:

```
## Brief
**Goal:** what we're building, in one sentence
**Scope:** what's in / what's explicitly out
**Key decisions:** the answers that shape the build (states, formats, components…)
**Done means:** how we'll verify it works
```

**The user confirms the brief before any code exists.** This is the point of the skill — don't start implementing on an unconfirmed brief. If the user has clearly pre-answered everything or says "just go", note the brief and proceed.

## Phase 2 — Plan & execute

For non-trivial work, draft a plan from the brief, break it into workstreams, and delegate.

**Get the plan approved before execution starts.** The brief said *what* we're building; the plan says *how* — show the user the workstreams, which agent and model each one goes to, the order, and how the result will be verified, then wait for sign-off before spawning any agents. Approval must be explicit — "yes", "go ahead", "looks good". **Silence, a topic change, or a lukewarm "I guess" is not approval;** if the response is ambiguous, ask plainly: "Should I go ahead and execute this?" Use the harness's plan mode where it exists (EnterPlanMode/ExitPlanMode in Claude Code) so approval is a real gate, not a courtesy heads-up. For small tasks, fold this into the brief confirmation — one approval covering both; don't make the user click through two gates for a one-agent job.

**The split:** the top-level session does architecture, decomposition, writing subagent prompts, resolving conflicts, reviewing results, and talking to the user. Subagents do everything mechanical or self-contained — file edits, component builds, scaffolding from a reference, test runs, QA sweeps, Figma pushes, browser verification, migrations.

Pick the model per task (Agent tool `model` parameter):

- `haiku` — repetitive, well-specified work: scaffolding from an approved reference, mechanical refactors, running tests and reporting output
- `sonnet` — standard implementation and QA: building a component to spec, fixing a described bug, verification passes
- `opus` — hard subtasks that deserve deep reasoning but not the orchestrator's seat: cross-system refactors, ambiguous debugging, gnarly performance work
- Omit (inherit the top model — Fable/whatever runs the session) — rare; only when a subtask genuinely needs the orchestrator's own judgment tier

Also match the *agent type* to the job, not just the model: use specialized agents where they exist (e.g. Explore for codebase search, a code-review agent for review passes) instead of general-purpose for everything — a tuned agent with the right toolset beats a generic one at the same model size.

**Delegation rules:**

1. **Self-contained prompts.** Each agent starts blank: give exact file paths, the reference pattern to follow, the relevant lines of the brief, acceptance criteria, and what to return.
2. **Batch independent agents in one message** so they run concurrently — serial spawning throws away the point.
3. **Verify with a different agent than the one that implemented** (or review the diff at top level). Never trust the implementer's self-report alone.
4. **Route follow-ups to the agent that owns the file** via SendMessage rather than spawning a competitor or editing inline.

**Progress and problems:** as workstreams complete, give the user a one-line, plain-language progress note per step. If a step fails or produces something that contradicts the plan, pause and tell the user rather than improvising around it.

**Graceful degradation:** on tools without subagents (claude.ai, other surfaces), keep the same discipline — confirmed brief, written plan with the same workstream breakdown — and execute sequentially yourself, checking in at workstream boundaries.

## Phase 3 — Wrap up

When all workstreams are done, summarize in plain language: what was produced, where it lives (file paths, links), and anything that was skipped or came out differently than planned. Offer next steps only if there are natural ones — don't invent follow-up work.

## When to skip

Trivial one-liners and config tweaks: skip the interview, just do them. But if you catch yourself three files deep in mechanical edits with no brief and no agents, stop — this skill should have fired.