Choose the agent definition for $ARGUMENTS. If it is empty, ask what the task is and what its issue's complexity: label says.

What this run must produce

One name from .claude/agents/, and one sentence saying why. Not a paragraph weighing the options — the caller is about to dispatch and wants a decision.

If the task does not fit any definition, say so and default to implementer. Defaulting up is cheap and recoverable; defaulting down produces a subagent that quietly does a worse job and reports success.

The rubric

Match on what the task demands, never on how large the diff will be. A one-line fix to a race condition is not mechanical work.

Each definition's model and effort live in the model: and effort: lines of its file under .claude/agents/. Read the file of the one you choose rather than assuming either, and name both in your sentence.

Where the issue carries a confirmed complexity: label, use it — it was set before work started, which is exactly why it is worth something:

A task that changes how a screen looks goes to one of the two design agents at any rating, never to mechanic, which does not load the design system. Which one turns on the same question as implementer against mechanic: does the surface's DESIGN.md already hold the answer? A one-line change to a colour the system names is design-mechanic; a one-line change that adds a colour the system lacks is a design decision, and designer.

Ignore a rating carrying complexity:unconfirmed. That label means an agent rated the issue and no human signed off. The session-metrics tooling leaves unconfirmed ratings out so its charts cannot be circular (tools/metrics/src/shape.ts:134) — and a dispatch is the most consequential thing anyone acts on. Treat an unconfirmed rating as no rating, and say you chose from the task text alone.

Never general-purpose for work a definition covers

general-purpose runs on its parent's model at its parent's effort. A review sent from an implementer therefore runs at the implementer's settings because of who sent it, not because anyone chose them, and it carries none of the definition's rules — reviewer's ban on changing the checkout, for one.

Review, plan-attack and whole-task work always go to their definition. Over September and October 2026, about half of all dispatches in this repository went to general-purpose, most of them prep-pr reviews, with plan attacks and whole-task hand-offs making up most of the rest; analyse-sessions gives the current split. general-purpose is right only for one-off research, a probe of the harness, or a skill's own eval run — work no definition describes.

A plugin skill's dispatch template is not a licence either. superpowers:subagent-driven-development hard-codes general-purpose and picks a model per task. Send an implementer prompt it would put on its cheapest tier — the plan holds the complete code — to mechanic, every other implementer prompt to implementer, and its final whole-branch review to reviewer, none with a model. Its per-task reviews and re-reviews are the one exception: they keep the plugin's own general-purpose dispatch and model choice, because routing each of them to reviewer would run every small review at high.

A session older than the definition

The Agent tool reads .claude/agents/ when a session starts. A session started before a definition existed rejects its name. Dispatch the definition on the same tier instead — implementer for designer, mechanic for design-mechanic — with everything below the chosen definition's frontmatter pasted into the brief. It carries the rules but runs at the stand-in's settings; say so in your sentence.

Pass no model and no effort

A dispatch to one of these definitions passes neither. A model on the Agent call overrides the definition's model:, and the transcripts show it happening — attacker sent with another model, mechanic sent with opus — each one a silent departure from the setting the definition records. The Agent tool also takes effort, and a value there is the same kind of override, with one exception the owner has set: a double review passes effort: xhigh on its second reviewer pass (prep-pr Step 6, Agent 2). Every other dispatch passes neither, and a change to the level goes in the definition.

Frontmatter effort overrides the session's effort level, but not the CLAUDE_CODE_EFFORT_LEVEL environment variable (code.claude.com/docs/en/sub-agents).

How much the effort levels are worth here is not measured

Session cards now record dispatches at every level from low to xhigh, so the data to compare them exists. Nobody has yet compared outcome against effort on this codebase, so the levels in the definitions are reasoned defaults, not measured optima. Two consequences:

• Say when you are guessing. A caller that knows the recommendation is a prior treats it differently from one that thinks it is a measurement.
• Let the data argue. Every card records spend.effort and spend.by_model. Run analyse-sessions before changing a definition, and let it argue with what is written here.

A card whose spend.effort map is empty is missing the field, not running at zero effort.

Four traps

A small change is not a mechanical change. The mechanic definition exists for work where the answer is already decided. A major version bump produces two changed lines and needs every breaking change read and applied deliberately — that is an implementer. Most of the dependency pull requests in this repository's history contained a major bump, and the cheap ones were cheap because they were isolated, not because they were mechanical.

Check the semver delta before you choose, do not infer it. Read the manifest and the target version rather than trusting the issue's framing:

grep -n '"<package>"' <workspace>/package.json    # what is declared now

A jump in the leading number sends it to implementer whatever the label says. Breadth is its own kind of hard: a wide patch and minor advisory sweep has cost more than several isolated majors together, so a wide sweep is not automatically mechanic either.

Never choose by cost. The question is what the task needs, not what it would be nice to pay. A cheaper agent that does the job worse costs more, because the work comes back.

One code-writing agent per worktree. Two agents writing code in the same worktree corrupt each other's branches. Only reviewer agents share a worktree: their tool grant has no Edit, their definition tells them never to change the checkout, and they build only when the brief says they are alone in it.

What consumes this

orchestrate asks this skill for every task hand-off and re-dispatch (Step 3) and for each fix subagent after the reviews (Step 4), and writes the answer on the task's agent: line in ORCHESTRATE.md. With unconfirmed ratings ignored, the rubric table above is what sends a fixed-answer task to mechanic. The other dispatch sites are fixed by role and name their definition directly:

new-feat keeps the built-in Plan: it is read-only and runs on the planner's own model, which is the model whose plan it is.