subagent-dispatch
Skill1 starsChanged 27 days agoMITView on GitHub
Conductor-only. How to dispatch one role and decide whether to accept its result — dispatch mode (native subagent, handoff file, or fast), briefing, baseline checks, proving and committing a developer case (focused Green, architecture, Red), closing the case loop (full suite, push), sending back, resuming, or changing a role's model/effort. Use for every dispatch a /project:* command makes.
- Commits and pushes
2 other projects use a version of this.
Adopted by
Most recently taken up by
- s977043/PlanGatetheir own version, first seen Nov 2, 2026
- rakaadi/agent-kittheir own version, first seen Aug 29, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- s977043/PlanGate★ 3same name
- rakaadi/agent-kit★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository20 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- adversarial-reviewSkill
- clean-architectureSkill
- decision-recordingSkill
- design-system-checkSkill
- dispatch-handoffSkill
- feature-branchingSkill
- finding-dispositionSkill
- git-recoverySkill
- gotcha-recordingSkill
- human-checkpointSkill
- plan-reviewSkill
- plan-writingSkill
- pr-createSkill
- simplicity-ladderSkill
- spec-writingSkill
- subagent-contractSkill
- tdd-loopSkill
- update-toolkitSkill
- wiki-updateSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 1 is distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 29
Handoff: write the brief per dispatch-handoff.
- Distinctive: line 40
One writer at a time: Read-only roles may run in parallel.
- Very specific: line 45
Do nothing to the checkout until the subagent notification arrives (or the human marks a handoff done per dispatch-handoff step 5).
- Very specific: line 51
Verify report: Check required fields (Checked: line for reviewers, test/implementation paths for developer).
- Very specific: line 69
Rejected before commit (Green or architecture check failed): No commit was created yet — do not run git reset HEAD~1.
- Very specific: line 93
Send back once: Use SendMessage to the same agent with the deciding output tail (or handoff step 6).
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Subagent Dispatch
One procedure for every dispatch. The command decides which role gets what brief; this skill decides how it runs and whether its result is accepted.
Before the cycle's first dispatch
- Role exists: The Agent tool lists every role in
.claude/agents/. If one is missing, ask the human to restart the session (subagents load at session start). - Commands allowlisted: Read-only roles,
planner,researcher, andwiki-maintainerrun indontAskmode (unlisted commands are denied without prompting). Ensure the test command, the focused test command (its words before<paths>), and the architecture check fromdocs/wiki/commands.mdare in.claude/settings.jsonin both exact and prefix forms (Bash(<command>),Bash(<command> *),PowerShell(<command>),PowerShell(<command> *)) so roles can run both the full suite and single test files. If missing, add them and commit.claude/settings.jsonalone perlog-and-commit.md(chore(workflow): allowlist <command> for the roles).
Dispatch mode
A dispatch runs native (via the Agent tool) or as a handoff (a file the human runs in another harness per dispatch-handoff). The command's leading argument word sets the mode for the run (stripped before reading the rest):
- Neither → native for every dispatch, without asking. Native is the default; never switch mode unless the human asks. Checkpoints still stop for the human.
handoff→ handoff file for every dispatch.fast→ native for every dispatch, and no waiting on the human. Loadhuman-checkpointnow; its§ Fast modeanswers every checkpoint in the run.
The human can hand one role off without a mode word (hand off the adversary, in the argument or mid-run): that dispatch alone runs as a handoff, and the run keeps its mode.
Brief
- Native: dispatch with
Agentandsubagent_type: <role>. Never use a fork orgeneral-purpose(rule 10). - Handoff: write the brief per
dispatch-handoff. Format (the subagent sees none of this conversation):
Task: <one line — "Implement B3 of entities/auth"> Inputs: <entity slug, case IDs, branch, test command, plan path or brief refinements, commit range> Scope: <paths it may create or edit> | read-only Return: <the role's report format, plus any dispatch-specific additions>Include no conductor reasoning, opinions, or expected answers. Pass files by path, never pasted.
- One writer at a time: Read-only roles may run in parallel; write roles run alone from a clean tree.
- Baseline: Record
git rev-parse HEADandgit status --porcelainbefore every dispatch.
Wait, then check what it touched
Do nothing to the checkout until the subagent notification arrives (or the human marks a handoff done per dispatch-handoff step 5).
- Partial result (
maxTurnshit): Continue once viaSendMessageto the same agent (or ask the human to continue the handoff session). Partial again →human-checkpoint. - Compare with baseline:
- Read-only role:
HEADand all tracked files must be unchanged (else report, account for paths per rule 21, restore, and re-dispatch). Untracked residue from a test run needs a.gitignoretodo, never a commit. - Write role:
HEADmust be unchanged (if it committed, reject) and edits must stay withinScope:(read any out-of-scope file before deciding; never widen scope retroactively).
- Read-only role:
- Verify report: Check required fields (
Checked:line for reviewers, test/implementation paths fordeveloper). Self-reported success is not evidence.
Prove and commit a developer case
The case's test paths are the tests, fixtures, and helpers the developer reported (prefer the test directory so new helpers stay with the test); everything else changed is the implementation (wiki page included). Focused means the focused test command from docs/wiki/commands.md § Test (focused) over the case's test paths plus any existing test files the developer reported as covering the code it changed; while that section is <TBD>, every focused run is the full test command. Run suites with an explicit timeout.
<focused test command> # 1. Green: the case's tests and the tests it touches pass
<architecture command> # 2. Architecture check passes (if defined in commands.md)
git add -- <every path the case changed> # plus Follow-ups appended to queues
git commit -m "<the case's commit message>" # docs/wiki/git-conventions.md; pushed at loop close
git restore --source=HEAD~1 --staged --worktree -- . ':(exclude)<test path>' … # set implementation aside
<focused test command over the case's test paths> # 3. Red: must FAIL on the case's assertion or missing symbol
git restore --source=HEAD --staged --worktree -- . # restore implementation (including moves/deletions)
git status --porcelain # must be empty- Read the Red output: A broken fixture, syntax error, or import of a pre-existing module is not Red.
- Rejected before commit (Green or architecture check failed): No commit was created yet — do not run
git reset HEAD~1. Leave the developer's edits in the working tree and send the developer back with the failing output (or discard only the attempt's paths below). - Rejected after commit (Red refuted — tests still pass with implementation set aside): Run
git restore --source=HEAD --staged --worktree -- . && git reset HEAD~1to restore the implementation and uncommit the case back into the working tree without losing edits, then send the developer back with the deciding output. - Interrupted mid-check: Account for every modified path (rule 21), then run
git restore --source=HEAD --staged --worktree -- .. - Inline tests (e.g. Rust
#[cfg(test)]): Brief the test into a separate file, or accept via ahuman-checkpointnaming the layout. - Unverified by developer (needs GUI/hardware/credentials only the conductor has): Run the real check yourself before committing; if you cannot run it either, leave the case
[~]and say so.
Close the case loop
Once the cycle's last case is committed (and before any adversary dispatch, log entry, or PR), run the full suite once and push the cases together:
<test command> # the full suite, over every case the loop committed
git push -u origin "$(git branch --show-current)"- Full suite fails: a case broke a test outside its focused run. Find the first failing commit over the loop's range (
git bisect start HEAD <sha-before-cases> && git bisect run <test command>, thengit bisect reset), and dispatchdeveloperwith the failing output, that case's ID and its paths. The failing existing test is the Red, and the fix never edits it (rule 3; a test that encodes the wrong behavior is ahuman-checkpoint). Prove the fix with the full suite Green and the architecture check, commit it alone asfix(<slug>): B<N> keep <test> passing(with aWiki-Update: none (restores <test>)footer unless the entity page changes), and close the loop again. A second failure on the same mechanism → rule 5. - Pausing or ending the run mid-loop (an interruption, a
fast-mode stop, a checkpoint the human will answer later): push the committed cases first, unproven against the full suite. A pushed feature branch survives a container recycle; the loop's close still runs before the PR.
Integrate any other write role
Stage the exact paths it reported (including reported deletions) plus any Follow-ups: lines appended to todos.md/wiki-todos.md, commit with the command's message, and push.
Send back, reject, two strikes
- Send back once: Use
SendMessageto the same agent with the deciding output tail (or handoff step 6). If the agent session is gone, re-dispatch with notes and"these files are the previous attempt"inInputs:. - Never re-send an unchanged brief: Fix the cause (scope, missing input, unrunnable command) first.
- Discarding an attempt: Restore only the tracked paths it changed (
git restore --source=HEAD --staged --worktree -- <paths>) and delete only the untracked files it created (rule 21). - Two strikes: Two failures on one mechanism or two rejections for one cause → rule 5.
Resuming after an interruption
Account for every path in the working tree first (rule 21). Uncommitted developer files are the case in flight (re-dispatch with "these files are a previous attempt" or discard as above). Push any committed-but-unpushed case before continuing; the loop's close still runs the full suite before the PR.
Changing a role's model or effort
Edit model/effort in .claude/agents/<role>.md and restart the session. Cite cycle evidence (refuted Reds/send-backs for developer, findings acted on in git log --grep="adversary round" for reviewers) in the commit's log entry.
Anti-patterns
- Accepting on self-report without running Green/architecture/Red.
- Leaking conductor context into a brief.
- Two writers in one checkout, or dispatching onto a dirty tree.
- Running
git reset HEAD~1when no commit was made (destroys the previous committed case). - Pushing before Red is proven, or opening a PR before the loop's full-suite close.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

