| name | subagent-orchestration |
| description | Standard subagent flow for fleet-generator — when Woodstock spawns Snoopy for pre-flight, when to spawn Garfield for review, and when specialist reviewers (Dogbert, Cathy, Odie) get pulled in. Always-active doctrine. |
| when_to_use | Always active. Read at session start. Trigger phrases: spawn, subagent, Task tool, pre-flight, post-flight, review, who reviews this, when to call the reviewer, when to spawn the architect, standard flow, orchestrate, hand off. |
| status | active |
| tags | ["skill"] |
| updated | 2026-05-07T00:00:00.000Z |
Subagent Orchestration — Standard Flow
The fleet has multiple agents. They aren't decoration — they fire
naturally at standard checkpoints during a mission. The point of
this skill is so Woodstock (the main coder) and Hobbes (the
orchestrator) PULL IN the right specialists without waiting to be
told.
Who is on the team
- Hobbes — orchestrator (planner, mission author)
- Woodstock — code worker (main coder, this is YOU when you're
implementing)
- Snoopy — pre-flight scanner (read-only)
- Garfield — post-flight reviewer (read-only)
- Calvin — architect (design review, read-only)
- Dogbert — security reviewer (read-only)
- Cathy — accessibility reviewer (read-only)
- Odie — performance reviewer (read-only)
- Linus — doc writer
(Whichever of these is enabled in this fleet — others may be off.)
How spawning works
The main coder spawns subagents using the Task tool with
subagent_type=<lowercase-name>. Subagents are read-only by
default (except Woodstock and Linus, who write to specific lanes).
Spawn one subagent at a time unless the queries are independent. Read
their reports before continuing.
Worker's standard execution order
When Woodstock starts a mission, the flow is:
- Read the mission file end-to-end. Absorb every section.
- Read referenced skills. Particularly
pre-commit,
self-review, and (if touching existing code) blast-radius.
- Spawn Snoopy (pre-flight scan). "Scan files in 'Files to
Modify' and report risks." Snoopy returns GREEN/YELLOW/RED.
- Evaluate the brief. If RED, fix or escalate before coding.
- If touching existing code: run
blast-radius. Produce the
Blast Radius Report; commit it as the first commit of the work.
- Implement Part by Part. Each Part = one logical change = one
commit. Run the test runner after each step.
- Run
pre-commit before every commit.
- Run
self-review after the final commit.
- Spawn Garfield (post-flight review). "Review the diff against
the mission spec." Garfield returns categorized findings
(CRITICAL / WARNING / INFO).
- Address Garfield's findings. Fix CRITICALs; document
WARNINGs that won't be fixed; INFO is informational.
- Re-spawn Garfield until Garfield says PASS.
- For specialist concerns, spawn the matching reviewer:
- Security-touching change → Dogbert
- UI / accessibility change → Cathy
- Hot path / perf-sensitive change → Odie
- User-facing behavior change → Linus updates the docs
- Declare done.
Steps 3, 9, and 11 are NOT optional for non-trivial missions. They
happen automatically. The audit trail shows whether they ran.
Orchestrator's standard flow
When Hobbes drafts a mission:
- Investigate the codebase. Read relevant files; understand
the problem.
- For non-trivial design choices, spawn Calvin. "Review
the proposed approach for tradeoffs and second-order effects."
Calvin produces a written design review. Recommendations only —
the human decides.
- Address Calvin's findings in the mission's Design Notes
section.
- Author the mission file following the
mission-template
skill.
- Hand off to Woodstock with the mission file content.
Specialist triggers
Spawn a specialist as soon as the trigger fires. Don't batch them
to the end.
| Specialist | Spawn when |
|---|
| Snoopy | Mission spec arrives, BEFORE coding starts |
| Garfield | After the final commit of a mission |
| Calvin | Designing anything that touches shared primitives, cross-system boundaries, or sets a new pattern others will follow |
| Dogbert | Touching auth, user data, dependency upgrades, URL handlers, credentials, network |
| Cathy | Any UI mission |
| Odie | Touching hot paths, query layers, render paths, allocation-heavy code |
| Linus | User-visible behavior changed |
What the worker does NOT do
- Don't skip the pre-flight scan because "it's a small change."
Snoopy is fast; the audit trail wants the run.
- Don't skip the reviewer because "I checked my own work."
Self-review is required; reviewer is the second pair of eyes.
- Don't spawn three reviewers in parallel just because they're
available. Spawn the ones whose triggers actually fired.
- Don't ignore reviewer findings because they slow you down. The
reviewer flagged it for a reason; address or document.
What the orchestrator does NOT do
- Don't write code. Mission files only.
- Don't decide architecture unilaterally. Recommend; the human
decides.
- Don't skip Calvin because "I think I know the right answer."
If a real design choice exists, Calvin reviews it.
Why this exists
Without this doctrine, the worker tends to do everything alone. The
specialists exist for a reason — each one catches a class of
mistakes the worker is bad at catching. Standard flow makes sure
the right eyes look at the right code.
The audit-log hooks (log-subagent-start, log-subagent-stop)
make subagent spawns visible. If the audit log shows a mission
landed without the standard spawns, someone skipped a step.
