delegate

name	delegate
description	Use when a task would flood the main context window — broad searches, verbose test/build output, 2+ independent parallel tasks, or an isolated large workstream. How to hand work to subagents well, and when not to.

Delegate

Part of the Build phase — see the workflow skill for tiers and sequencing.

Subagents exist to protect the main context window and exploit true parallelism — not to add process. Every dispatch costs a full agent spin-up: the agent re-reads context, explores, works, and reports. Spend that cost only when it buys something.

Triggers — delegate when (and only when)

1. Context-flooding search/read: answering requires sweeping many files but you only need the conclusion, not the file contents.
2. Verbose output: test suites, builds, long logs — where only the summary matters in the main session.
3. True parallelism: 2+ genuinely independent tasks with no shared state and no sequential dependency.
4. Isolated large workstream (T3): big enough that a fresh, focused context outperforms a crowded one.

When a trigger fires, stop and call AskUserQuestion: name the task, why it triggered, a suggested model tier, and delegate-or-inline as options. Never decide silently in either direction. This applies at the trigger point, whenever it fires — including in the middle of another skill's process. (Doesn't apply to the anti-triggers below.)

Anti-triggers — do it inline instead:

• Small, sequential, or interdependent work.
• A 30-line change never needs an agent round-trip.
• Never delegate "to follow process" — an implementer+reviewer pair per tiny task turns 15 minutes of work into 8 round-trips of ceremony.
• Exploratory debugging where you don't yet know what's broken — you need the full picture in one context.
• Related failures (fixing one might fix the others): investigate together first.

Writing the dispatch prompt

A subagent inherits none of your session. You construct exactly what it needs:

1. Focused scope — one clear problem domain. "Fix all the tests" loses the agent; "fix agent-tool-abort.test.ts" keeps it on target.
2. Self-contained context — paste the error messages, name the files, one line on where this fits in the project, interfaces/decisions it can't discover itself, and your resolution of any known ambiguity.
3. Constraints — "do NOT change production code", "fix tests only", "don't just increase timeouts — find the real issue."
4. Expected return — say exactly what to report back: "return a summary of root cause and changes", a structured result, a file path. The agent's final message is your only deliverable from it.
5. Exact values live in one place. If the work follows a plan, point the agent at its task text rather than paraphrasing requirements — paraphrase drift is how implementations diverge from spec.

Coordination rules

• One writer per file. Never let two concurrent agents edit the same files or share mutable state; parallel writers = merge conflicts.
• Parallel dispatches go in one message; one per message = sequential. Sequential dependencies mean you wanted one agent, not two.
• Match model to task when dispatching: mechanical single-file work → a fast cheap model; multi-file integration → standard; architecture/judgment → the most capable. Turn count beats token price — a too-weak model taking 3× the turns costs more than a stronger one.
• Handle agent status honestly: if an agent reports it's blocked or needs context, change something (context, model, task size) before re-dispatching — never force a retry of the same failure.

Integrating results

• Verify, don't trust. An agent's "success" report is a claim, not evidence — check the diff, run the affected tests yourself (see verify-done). Agents can make systematic errors.
• Read each summary; check for conflicts between concurrent agents' changes; run the full affected suite after integrating.
• One fixer for all findings, not one per finding. If review/verification surfaces multiple issues, dispatch a single fix agent with the complete list — per-finding fixers each rebuild context and re-run suites.

Checkpoint economics

A checkpoint is a human-in-the-loop decision point — a subagent reporting back to you, or you presenting a tier gate to the user. Two rules:

• Push right. Defer a checkpoint as late as it will go, so whoever waits is asked once, late, with maximum work already done. A subagent that comes back to ask what it could have discovered itself wasted its dispatch; a T3 approval gate should arrive with the plan complete, not in fragments.
• Arrive decision-ready. A checkpoint presents a synthesized decision, never raw output: what was produced, why, the recommendation, a pointer to the artifact. Demand this shape in the dispatch prompt's "expected return"; produce it yourself at the user's tier gates.

Checkpoint vocabulary adapted from a personal workflow-design skill (loop-me).

Review scaling

Independent review passes (a separate reviewer agent over the diff) are a T3 tool — worth it for money/auth/data/migration work. They are not a default. For T1/T2, mechanical verification (typecheck, tests, lint) plus your own read of the diff is the right-sized gate.

Adapted from superpowers (MIT, © 2025 Jesse Vincent); see ATTRIBUTION.md.