Menu
当同时面对 2 个及以上相互独立、无共享状态且无顺序依赖的任务时必须使用本技能
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
在开展任何创造性工作之前必须使用：创建功能、构建组件、添加能力或修改行为。在动手实现前，先探索用户意图、需求并制定设计。
当需要在一个独立会话中执行已撰写的实现计划，并通过检查点进行复核时必须使用
当实现完成、所有测试通过且需要决定如何集成工作时必须使用——通过呈现结构化的本地合并、创建 PR 或清理工作树等选项，指导开发工作的收尾
当收到代码审查反馈、准备采纳建议前必须使用，尤其当反馈表述不清或技术上可疑时——要求技术严谨与验证，禁止表面附和或盲目执行
当完成任务、实现主要功能或在合并前需要验证工作是否符合要求时必须使用
当需要在当前会话内执行包含独立任务的实现计划，并为每个任务分派全新子代理时，必须使用此技能。
| name | dispatching-parallel-agents |
| description | 当同时面对 2 个及以上相互独立、无共享状态且无顺序依赖的任务时必须使用本技能 |
你将任务委派给拥有独立上下文的专用子智能体。通过精确构建它们的指令和上下文，确保它们保持专注并完成任务。它们绝不应继承你会话的上下文或历史记录——你要自行构建它们所需的全部信息。这样也能为你保留协调工作所需的上下文。
当你遇到多个互不相关的失败（不同的测试文件、不同的子系统、不同的缺陷）时，逐个排查会浪费时间。每次排查都是独立的，可以并行进行。
核心原则： 每个独立的问题域派一个智能体，让它们并发工作。
digraph when_to_use {
"Multiple failures?" [shape=diamond];
"Are they independent?" [shape=diamond];
"Single agent investigates all" [shape=box];
"One agent per problem domain" [shape=box];
"Can they work in parallel?" [shape=diamond];
"Sequential agents" [shape=box];
"Parallel dispatch" [shape=box];
"Multiple failures?" -> "Are they independent?" [label="yes"];
"Are they independent?" -> "Single agent investigates all" [label="no - related"];
"Are they independent?" -> "Can they work in parallel?" [label="yes"];
"Can they work in parallel?" -> "Parallel dispatch" [label="yes"];
"Can they work in parallel?" -> "Sequential agents" [label="no - shared state"];
}
使用时机：
不适用场景：
按照损坏的内容对失败进行分组：
每个域都是独立的——修复工具审批不会影响中止测试。
每个子智能体应获得：
在同一个回复中发出全部三个子智能体派发请求——它们会并行运行：
Subagent (general-purpose): "Fix agent-tool-abort.test.ts failures"
Subagent (general-purpose): "Fix batch-completion-behavior.test.ts failures"
Subagent (general-purpose): "Fix tool-approval-race-conditions.test.ts failures"
# All three run concurrently.
一次回复中的多个派发调用 = 并行执行。每次回复只发一个 = 顺序执行。
当子智能体返回时：
优秀的子智能体提示应具备：
修复 src/agents/agent-tool-abort.test.ts 中 3 个失败的测试：
1. "should abort tool with partial output capture" - 期望消息中包含 'interrupted at'
2. "should handle mixed completed and aborted tools" - 快速工具被中止而非完成
3. "should properly track pendingToolCount" - 期望得到 3 个结果，但实际为 0
这些都是时序/竞态条件问题。你的任务：
1. 阅读测试文件，理解每个测试验证的内容
2. 识别根因——是时序问题还是真实缺陷？
3. 通过以下方式修复：
- 将任意超时替换为基于事件的等待
- 如果发现中止实现存在缺陷，则修复
- 如果测试的是已变更的行为，则调整测试预期
不要只是增加超时时间——找到真正的问题。
返回：你发现了什么以及修复了什么的总结。
❌ 范围过大： "修复所有测试" - 子智能体会无从下手 ✅ 具体明确： "修复 agent-tool-abort.test.ts" - 范围聚焦
❌ 缺少上下文： "修复竞态条件" - 子智能体不知道位置 ✅ 提供上下文： 粘贴错误信息和测试名称
❌ 缺少约束： 子智能体可能会重构所有代码 ✅ 明确约束： "不要修改生产代码" 或 "仅修复测试"
❌ 输出模糊： "修复它" - 你不知道改了什么 ✅ 输出具体： "返回根因和变更总结"
相互关联的失败： 修复一个可能会连带修复其他 — 应先一起调查 需要完整上下文： 理解问题需要查看整个系统 探索性调试： 你还不知道哪里出了问题 共享状态： 智能体之间会互相干扰（编辑相同文件、使用相同资源）
场景： 大规模重构后，3 个文件共 6 个测试失败
失败：
决策： 各域相互独立——中止逻辑、批量完成和竞态条件彼此分离
派发：
Agent 1 → Fix agent-tool-abort.test.ts
Agent 2 → Fix batch-completion-behavior.test.ts
Agent 3 → Fix tool-approval-race-conditions.test.ts
结果：
整合： 所有修复相互独立，无冲突，完整套件全部通过
节省时间： 3 个问题并行解决，而非顺序解决
子智能体返回后：
来自调试会话（2025-10-03）：