plan-and-delegate

Plan and Delegate

Big or fuzzy coding tasks fail in two predictable ways: you start coding before you understand the problem, or you burn an expensive reasoning model on mechanical work that a faster model would have nailed. This skill is a workflow that avoids both. You plan once, carefully, at high reasoning, then fan the implementation out to subagents, matching each piece of work to the cheapest model that can do it well.

You — the session running this skill — are the orchestrator. You stay in the loop end to end: you hold the plan, you write the briefs, you pick the models, you review what comes back, and you integrate. Subagents do scoped implementation work and report back; they don't own the architecture.

When to run the full workflow vs. just doing it

Don't bring out the whole apparatus for a one-line fix. Use judgment:

• One or two files, obvious change, low risk → just do it directly. The overhead of planning and delegation isn't worth it.
• Multiple files, new feature, a project from scratch, a refactor with ripple effects, or anything ambiguous → run the full workflow below.

If you're unsure, lean toward planning. The cost of a five-minute plan is small; the cost of building the wrong thing is large.

Phase 1 — Plan (high reasoning / Opus)

Planning is where the leverage is, so do it at the top of your reasoning ability. If a brainstorming or planning skill is available (e.g. superpowers:brainstorming, superpowers:writing-plans), use it here — this skill composes with them rather than replacing them.

Before writing any code, get clear on:

• Intent. What is the user actually trying to accomplish, and why? Restate it back to them if there's any ambiguity. Don't infer requirements you could cheaply confirm.
• Constraints. Language, framework, existing conventions, dependencies, deadlines, things that must not break. Read the surrounding code so the plan fits the codebase that exists, not a generic one.
• Approach. The shape of the solution and the main alternatives. Make a recommendation; don't just enumerate options.
• Decomposition. Break the work into discrete steps. For each step note its inputs, its outputs, and what it depends on. This decomposition is what makes delegation possible, so spend real effort here.

End Phase 1 with a written plan: a short prose summary plus an ordered (or dependency-annotated) list of steps. Confirm it with the user before you start spending tokens on implementation — a wrong plan caught here is nearly free.

Phase 2 — Write the implementation spec

A subagent starts cold. It does not share your context, your conversation, or your mental model — it sees only the brief you give it. So the spec you write is the single biggest determinant of whether delegation succeeds.

For each step you intend to delegate, write a brief that is self-contained:

• Goal — what this step must produce, in one or two sentences.
• Context — the files, paths, types, and conventions the agent needs. Point at real locations (src/auth/session.ts:42), don't describe vaguely.
• Exact deliverable — what files to create or edit, what the public surface (function signatures, routes, schema) should look like.
• Constraints — patterns to follow, things not to touch, the style of the surrounding code to match.
• Definition of done — how the agent verifies its own work (tests pass, builds clean, a specific command produces a specific output). Tell it to verify before reporting success, and to report failures honestly.

A good test: if you handed the brief to a competent engineer who has never seen the project, could they do the step without asking you a question? If not, add what's missing.

Phase 3 — Delegate, choosing the model per step

Dispatch each step to an implementation subagent via the Agent tool, setting the model parameter deliberately. The whole point is to spend reasoning where it pays off and move fast where it doesn't.

Model selection rubric

Use Sonnet (model: "sonnet") when the step is well-specified and the path is clear — the spec removed the ambiguity, so what's left is execution. Sonnet is faster and cheaper, and on a tight brief it's excellent. Good fits:

• Boilerplate, scaffolding, config, wiring things together
• CRUD endpoints, forms, and components that follow an established pattern
• Writing tests against a clear, already-decided interface
• Mechanical refactors and migrations that follow a stated rule
• High-volume repetitive edits across many files

Use Opus (model: "opus") when the step needs judgment that the spec can't fully pin down — getting it subtly wrong is expensive, so pay for the better reasoning. Good fits:

• Designing an API, schema, or architecture that other steps depend on
• Tricky algorithms, concurrency, security-sensitive code
• Debugging an unknown failure (the cause isn't yet understood)
• Cross-cutting changes where one wrong assumption breaks many things
• Anything still genuinely ambiguous after Phase 2

Rule of thumb: if the spec made the step unambiguous, Sonnet. If real judgment remains, Opus. When a step on Sonnet comes back wrong in a way that reveals hidden complexity, that's your signal to re-run it on Opus with a sharper brief — don't just keep retrying the same thing.

Sequencing and parallelism

• Independent steps run in parallel. Dispatch them in the same turn so they execute concurrently. (A parallel-dispatch skill like superpowers:dispatching-parallel-agents pairs well here.)
• Dependent steps run in order. A step that consumes another's output waits for it. Foundational steps that everything depends on (the schema, the core interface) usually go first, alone, often on Opus — get them right before fanning out the work built on top of them.

Phase 4 — Review and integrate

Subagent output is a draft, not a merge. You're accountable for what lands, so:

• Read what came back against the brief and the plan. Don't rubber-stamp.
• Verify for real — run the build, the tests, the actual command. Evidence before claims; if something fails, say so with the output.
• Integrate the pieces and check they fit together, not just individually.
• Re-delegate anything that missed, with a brief sharpened by what you learned — escalate to Opus if a Sonnet run revealed hidden depth.

Only call the work done once you've watched it pass, not because a subagent said it would.

The shape of a run

Plan (Opus, with the user)
  └─ write specs for each step
       ├─ Step 1: schema design        → Opus   (foundational, judgment-heavy)
       ├─ Step 2: CRUD endpoints        → Sonnet ┐
       ├─ Step 3: form components       → Sonnet ┤ parallel, depend on Step 1
       └─ Step 4: tests for endpoints   → Sonnet ┘
  └─ review every result, verify, integrate

Keep the orchestration visible to the user: say which step is going to which model and why, so the delegation is legible rather than a black box.