메뉴
教 mainagent 何时 / 如何把任务分发给 subagent 来控制主线程上下文预算，并判断哪些独立任务适合并行、如何回收和验证结果。当任务命中「读超过 5 个文件 / 包含搜索 / 输出超过 500 行 / 主线程已 30+ tool call / 用户说调研/分析/扫一遍/梳理」任一条时启动。触发词：分发任务、上下文预算、主线程上下文、要不要 dispatch、subagent 分发、长任务、调研、扫一遍、避免上下文爆炸、context budget、控制上下文、mainagent context、上下文要爆了。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use before implementation when a request is ambiguous, has materially different solution paths, changes architecture or public behavior, or involves costly or irreversible decisions. Skip for small well-scoped fixes, mechanical edits, and execution of an already approved plan.
Use when code review feedback has been received and needs to be assessed, answered, or implemented. Verify each suggestion against the actual code and requirements before changing anything.
Use when diagnosing a bug, test or build failure, performance issue, or unexpected technical behavior. Gather evidence and confirm a root-cause hypothesis before implementing a fix.
Use immediately before claiming work is complete, fixed, correct, or passing, and before publishing changes. Requires fresh, claim-specific evidence and accurate reporting of what was and was not verified.
| name | mainagent-context-budget |
| description | 教 mainagent 何时 / 如何把任务分发给 subagent 来控制主线程上下文预算，并判断哪些独立任务适合并行、如何回收和验证结果。当任务命中「读超过 5 个文件 / 包含搜索 / 输出超过 500 行 / 主线程已 30+ tool call / 用户说调研/分析/扫一遍/梳理」任一条时启动。触发词：分发任务、上下文预算、主线程上下文、要不要 dispatch、subagent 分发、长任务、调研、扫一遍、避免上下文爆炸、context budget、控制上下文、mainagent context、上下文要爆了。 |
主线程是协调者，不是执行者。这个 skill 教 mainagent 何时把任务分发给 subagent，以及怎么把任务分发清楚。
主线程上下文是有限资源。一旦被原始数据淹没——读 50 个文件、跑 30 次 grep、看 1000 行报告——主线程会：
正确分工：
下面任一条命中就 dispatch：
| 信号 | 判断标准 | 处理 |
|---|---|---|
| 多文件读取 | 需要读 >5 个文件 | dispatch |
| 包含搜索 | grep / find / glob 等 | dispatch |
| 长输出 | 预计 >500 行 / >5k token | dispatch + 要求 subagent 摘要返回 |
| 主线程已重 | 已做 30+ tool call | 后续非聚合任务都 dispatch |
| 用户用了关键词 | "调研"、"分析"、"扫一遍"、"全面看一下"、"梳理"、"统计" | dispatch |
| 重复执行 | 同样的操作要做 N 次（如改 N 个仓库） | 并行 dispatch N 个 |
| 场景 | 为什么不 dispatch |
|---|---|
| 单文件 read + 单文件 edit | dispatch 成本 > 收益 |
| 1-2 个简单 bash 命令 | 同上 |
| 需要跟用户对齐的判断 | subagent 不能问用户 |
| 最终聚合 / 总结 | 这就是主线程的职责 |
| 反思 / 回顾当前对话 | subagent 看不到对话 |
| 写最终给用户的回复 | 主线程负责输出 |
subagent 没有当前对话上下文。每个 prompt 都要自包含。
会修改文件的任务还要明确：允许改哪些路径、禁止碰哪些路径、能否与其他 agent 共享资源，以及「禁止执行 git add / commit / push / reset」。排障任务应附上准确错误、复现方式和已知证据，别只写「修一下」。
只有同时满足下面条件，才并行 dispatch：
如果多个失败可能来自同一个根因，先按问题域合并调查，别机械地按文件一人一个。探索性排障尚未划清边界时，也先由一个 agent 建立全局事实，再决定是否拆分。
并行示例：
subagent 必须按下面格式回报，主线程才能高效消费：
## 关键发现
- 3-5 条 bullet，每条不超过 1 行
## 量化数据
- markdown 表格或关键计数
## 不确定的点
- 等主线程决定的 1-3 条
## 引用证据
- 文件路径 + 行号 / URL，最多 5 条
严禁让 subagent 把全部读到的内容堆给主线程。如果产物是大文件（>200 行），让 subagent 写到磁盘，回报路径就行。
agent 返回后，主线程不能直接转述“已完成”：
验证强度要与风险匹配：只读任务抽查关键证据，局部修改检查 diff 并跑针对性验证；只有多个结果共享接口、状态或组合行为时，才追加组合验证。不要默认运行与改动无关的全量测试。
git diff 和工作区状态；对只读任务抽查关键证据。| 用户说 | 是否 dispatch | 为什么 |
|---|---|---|
| "查下 README 在哪" | ❌ | 主线程一个 glob 就够 |
| "读一下这个文件" | ❌ | 单文件 |
| "把所有 service 类找出来" | ✅ | 搜索 |
| "分析最近三个月的代码变化" | ✅ | 大量数据 |
| "看一下这个 PR 怎么改的" | ❌ | 单 PR |
| "对比这 5 个 PR 的风格" | ✅ | 多文件 + 分析 |
| "扫一下仓库找 TODO" | ✅ | 全仓库搜索 |
| "把对话总结一下" | ❌ | subagent 看不到对话 |
| "给我每个仓库 build 一遍" | ✅ 并行 | 独立 + 重复 |
| "梳理一下这块代码的依赖关系" | ✅ | 用户说"梳理"+ 多文件 |
如果你（主线程）出现以下信号，要更激进地分发，所有剩余非聚合任务都 dispatch：
这时不要再贪心"我顺手做完吧"，立即 dispatch。
superpowers:subagent-driven-development —— 关注执行实现计划时怎么用 subagent。本 skill 关注任何任务的上下文预算。systematic-debugging —— 多个失败是否独立尚不清楚时，先建立根因证据，再决定按问题域并行。verification-before-completion —— agent 自报完成不算证据；主线程集成后仍需 fresh verification。handoff —— 当上下文已经爆了想"换一份干净的主线程"，走 handoff；本 skill 是预防handoff 被触发。subagent-verify hook 做这件事）git commit 两个仓库、还把已 force-push 删掉的 commit 推回 origin，主线程花了很多轮 git -C 排查 + reset --mixed 合并才收敛。改文件的 agent 一律加「禁止 git 操作」约束，提交由主线程统一做