菜单
Decide whether to delegate work to subagents, set each one's isolation boundary, and verify their output with external evidence. Use when considering fanning work out to parallel agents, orchestrating multiple agents, or reviewing whether a multi-agent result can be trusted.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Design, create, and validate portable Agent Skills with effective triggers, concise instructions, and reusable scripts, references, or assets. Use when adding a new skill, substantially restructuring an existing skill, or validating a skill's structure, frontmatter, links, and bundled scripts.
Manage GitHub via CLI including pull requests, issues, workflows, actions, releases, and repositories. Use when working with GitHub, gh commands, GitHub Actions CI/CD, PRs, issues, releases, or repository management.
Check reasoning with a second mind — dispatch a reviewer whose prompt is built for the specific question, with a lens it can fail on and evidence required for every finding. Use before acting on a plan, decision, diagnosis, or rationale whose cost of being wrong is high and whose only support so far is your own reasoning.
Use tmux safely from an agent with explicit pane targeting, state inspection, verified input delivery, response polling, recovery, and multi-agent supervision. Use when an agent CLI, TUI, REPL, authentication flow, or other interactive command must retain terminal state across tool calls.
Confirm you have everything needed to finish a change before starting it — what to implement, how it will be tested, and which rules govern it. Use before non-trivial work, when reviewing a plan for completeness, or when preparing a PR that needs planning evidence.
Manage Linear issues, teams, and projects via the Linear CLI. Use when the tracker is Linear specifically — reading or filing Linear issues, Linear sprint workflows, creating a branch or PR from a Linear issue, or managing Linear teams and projects. Not for GitHub Issues or other trackers.
| name | dispatching-subagents |
| description | Decide whether to delegate work to subagents, set each one's isolation boundary, and verify their output with external evidence. Use when considering fanning work out to parallel agents, orchestrating multiple agents, or reviewing whether a multi-agent result can be trusted. |
Delegation is an orchestrator-workers decision, not a reflex. It costs roughly an order of magnitude more tokens than doing the work inline and it removes your ability to see what happened. Earn it.
Portability: dispatch mechanisms differ per harness and change often. This skill is the decision procedure, not the API. Use whatever mechanism the current harness provides; where none exists, execute the same plan sequentially in this context. The boundaries and verification rules below are unchanged either way.
Delegate only when at least one is true:
Do not delegate when: the subtasks are sequential and each needs the previous one's output; the task is small enough to read directly; you cannot state the success criterion for a worker in one paragraph; or you would be unable to check the result yourself.
If none of the three conditions holds, do the work inline and say so.
Before dispatching, state for each worker what it knows about the others. Default to nothing: a self-contained task description, the required output format, and a fresh context. Shared state between workers is a cost — justify each piece of it.
Write the boundary down in the plan. "Worker A does not see B's findings" is a design decision, not an omission.
Put reasoning-heavy planning, decomposition, and final review on the strongest model. Put well-specified execution on cheaper ones. A worker whose task cannot be specified tightly enough for a cheaper model is a sign the decomposition is not finished.
Agreement between workers is not verification. Several agents on the same model reading the same flawed context will agree with each other and be wrong together.
A result is verified only by evidence from outside the agents:
The maker never grades its own work. If a verifier is itself an agent, it must be given the artifact and the criterion, not the maker's reasoning.
State how many workers ran, what each was asked, what came back, and which claims are backed by external evidence versus by an agent's assertion. Unverified worker output is reported as unverified.
Stop and consolidate when: workers return contradictory results and no external evidence settles it; a worker fails twice on the same subtask; or the dispatch has cost more than doing the work inline would have. Contradiction is a finding to report, not noise to re-roll away.
