菜单
Produces a dispatch plan — isolation model, agent count, sequencing, and model assignments — for multi-agent parallel work. Use when: "dispatch agents in parallel", "run multiple tracks simultaneously", "plan parallel agent strategy", "should this be foreground or background".
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/DojoGenesis/gateway --skill agent-dispatch-playbook命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
| name | agent-dispatch-playbook |
| model | sonnet |
| description | Produces a dispatch plan — isolation model, agent count, sequencing, and model assignments — for multi-agent parallel work. Use when: "dispatch agents in parallel", "run multiple tracks simultaneously", "plan parallel agent strategy", "should this be foreground or background". |
| triggers | ["dispatch agents in parallel","orchestrate parallel work across repos","plan agent delegation strategy"] |
| metadata | {"version":"1.0","created":"2026-04-07","author":"Tres Pies Design","tool_dependencies":["meta_skill","bash","file_system"],"portable":true,"tier":1,"agents":["agent-orchestration"]} |
| category | agent-orchestration |
| tier | 1 |
| agents | ["primary"] |
| inputs | [{"name":"work_description","type":"string","description":"Description of the multi-agent parallel work to plan","required":true},{"name":"track_count","type":"number","description":"Target number of parallel tracks (default auto-selected)","required":false}] |
| outputs | [{"name":"dispatch_plan","type":"string","description":"Dispatch plan with isolation model, agent count, sequencing, and model assignments"}] |
Agent orchestration is not about launching as many agents as possible — it's about matching the isolation model to the dependency graph. Today's session (Apr 7, 2026) dispatched 15 agents across 7 repos, completing in hours what would take days sequentially. The patterns below are extracted from that lived experience, not theory.
The core insight: the main thread is for strategy, agents are for heavy lifting. The main thread reads results, makes judgment calls, resolves conflicts, and sequences dependent work. Agents do the grunt work in parallel.
When: Multiple code changes in the SAME repo that touch DIFFERENT packages/directories.
How:
isolation: "worktree".claude/worktrees/Example from today: Gateway Track 2 (workflow/executor.go, channel/nats_bus.go) and Track 3 (server/handle_websocket.go) ran in parallel worktrees — different packages, clean merge.
Gotcha: Worktree changes are uncommitted by default. You must copy files to main and manually apply shared-file changes (server.go, router.go) if both tracks modify them.
Agent(isolation="worktree", prompt="Track A: modify workflow/ and channel/")
Agent(isolation="worktree", prompt="Track B: modify server/ only")
# After both complete:
# 1. Copy new files from worktrees to main
# 2. Cherry-pick shared-file edits manually
# 3. Verify: go build ./... && go test ./...
When: Changes in DIFFERENT repos with zero dependencies between them.
How:
run_in_background: trueExample from today: HTMLCraft integration (TypeScript) ran alongside Gateway workflow wiring (Go) — completely independent repos.
Agent(prompt="Fix tests in repo A", run_in_background=true)
Agent(prompt="Fix tests in repo B", run_in_background=true)
Agent(prompt="Add feature in repo C", run_in_background=true)
# Main thread: update documentation or plan while waiting
When: Gathering information across multiple repos without making changes.
How:
Example from today: 3 health audit agents (Gateway, 4 smaller repos, HTMLCraft) ran simultaneously. Each produced findings; main thread compiled the unified scorecard.
Scaling rule: 3 concurrent audit agents is the sweet spot. More than 4 starts hitting diminishing returns from context overhead.
Agent(subagent_type="health-auditor", prompt="Audit repo A", run_in_background=true)
Agent(subagent_type="health-auditor", prompt="Audit repo B+C+D", run_in_background=true)
Agent(subagent_type="health-auditor", prompt="Audit repo E", run_in_background=true)
# Wait for all 3, then compile unified report
When: Fixing issues that were discovered by an audit, where fixes have dependencies.
How:
Example from today: After audit found 19 SKILL.md files missing triggers, a single fix agent updated all 19 + verified go test ./tests/skills/... passed.
Key principle: Fix agents get specific instructions, not open-ended research tasks. The audit already did the research — the fix agent just executes.
# BAD: "Find and fix test failures" (too open-ended)
# GOOD: "Update loader_test.go line 163: change 15 to 31. Update line 357: change 'debugging' to 'debugging-troubleshooting'. Verify: go test ./internal/skills/..."
When: Some work must complete before parallel work can begin.
How:
Example from today:
go build && go test (foreground)# Phase A — foreground, blocks everything
fix_build_errors()
verify_build()
# Phase B — parallel, independent
Agent("Track 2: workflow", isolation="worktree", run_in_background=true)
Agent("Track 3: websocket", isolation="worktree", run_in_background=true)
Agent("Track 4: htmlcraft", run_in_background=true)
# Phase C — after all Phase B agents complete
merge_worktrees()
verify_combined_build()
# Phase D — depends on Phase C
push_to_remotes()
run_health_audits()
| Situation | Pattern | Isolation | Background? |
|---|---|---|---|
| 2+ changes in same repo, different dirs | Worktree Tracks | worktree | Yes |
| Changes across different repos | Cross-Repo Parallel | none | Yes |
| Read-only audits across repos | Audit Swarm | none | Yes |
| Fixing specific known issues | Sequential Fix | none | No (foreground) |
| Mix of blocking + parallel work | Phased Pipeline | mixed | Mixed |
go test ./..., npm test, etc.)Every SKILL.md MUST declare model: sonnet or model: opus in YAML frontmatter. This is the authoritative routing signal — when the Dojo Gateway or a dispatch agent invokes a skill, it reads this field to select the model. Skills without a model: field default to the parent session's model, which wastes Opus tokens on mechanical work.
| Task Type | Model | Why |
|---|---|---|
| Planning, judgment, architecture | Opus | Needs reasoning depth |
| Strategy, synthesis, pattern recognition | Opus | Ambiguity requires judgment |
| Parsing, sed, template application | Sonnet | Fast, mechanical work |
| Fix agents with exact instructions | Sonnet | Instructions are complete, just execute |
| Normalization, auditing, bulk edits | Sonnet | Deterministic operations |
| Health audits, code exploration | Sonnet | Read-heavy, report-focused |
| Deep research, retrospectives | Opus | Synthesis across sources |
The cost-optimal ratio for a solo operator running 200+ Agent calls per session. When in doubt, default to Sonnet — most agent work is mechanical once the main thread has made the judgment call.
model: field is required in YAML frontmatter. Skill audit flags missing fields.model: "sonnet" or model: "opus" explicitly. Do not rely on parent session default.model: is a quality defect.Rule of thumb: If the prompt contains all file paths and exact changes, use Sonnet. If the agent needs to make judgment calls, use Opus.
sed command or one file edit, just do it in the main thread.server.go, don't use worktrees. Do one track, then the other, or split the file changes.| Metric | Value |
|---|---|
| Total agents dispatched | 15 |
| Max concurrent agents | 3 |
| Execution tracks (worktree) | 2 |
| Cross-repo parallel agents | 4 |
| Audit swarm agents | 3 |
| Fix agents | 4 |
| Documentation agents | 4 |
| Repos touched | 7 |
| Files modified | 500+ |
| New tests added | 78 |
| Time saved (estimated) | 3-4x vs sequential |
Scenario 1: "Run health audits across 5 repos while I continue coding" → Audit Swarm pattern; 3 background agents (repos grouped by size), each writing findings to /tmp/audit-<repo>.md; main thread continues foreground work and compiles unified report on completion.
Scenario 2: "Wire the workflow executor and the WebSocket hub in the same repo" → Phased Pipeline; Phase A fixes any build errors foreground; Phase B launches two worktree agents (workflow/ and server/) in parallel; Phase C merges worktrees and runs go build && go test; shared file edits (router.go) applied manually after merge.
server.go): do not use worktrees; run one track foreground, then the second, applying shared-file changes sequentiallysed command or one-file edit — main thread is faster基于 SOC 职业分类
