القائمة
当同时面对 2 个及以上相互独立、无共享状态且无顺序依赖的任务时必须使用本技能
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Update Kimi Code CLI user documentation after meaningful code changes that affect product behavior or user experience.
Map systematic debugging onto Ganymede Code native Debug / 排障 surfaces (probes, user verification bar, TodoList).
Map KimiCodeBoost engineering workflows onto Ganymede Code native UI and host tools (AskUserQuestion, TodoList, Agent, Plans panel, GanymedeBrowser, Worktree, Review).
在开展任何创造性工作之前必须使用：创建功能、构建组件、添加能力或修改行为。在动手实现前，先探索用户意图、需求并制定设计。
当需要在一个独立会话中执行已撰写的实现计划，并通过检查点进行复核时必须使用
当实现完成、所有测试通过且需要决定如何集成工作时必须使用——通过呈现结构化的本地合并、创建 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"];
}
使用时机：
不适用场景：
按照损坏的内容对失败进行分组：
每个域都是独立的——修复工具审批不会影响中止测试。
每个子智能体应获得：
在同一个回复中发出全部三个子智能体派发请求——它们会并行运行：
Agent (subagent_type: "coder"): "Fix agent-tool-abort.test.ts failures"
Agent (subagent_type: "coder"): "Fix batch-completion-behavior.test.ts failures"
Agent (subagent_type: "coder"): "Fix tool-approval-race-conditions.test.ts failures"
# All three run concurrently.
一次回复中的多个派发调用 = 并行执行。每次回复只发一个 = 顺序执行。
当子智能体返回时：
在 Kimi Code CLI 中，并行的动作映射如下：
| 意图 | 动作 |
|---|---|
| 派遣一个实现者子代理 | 调用“派遣子代理”动作，类型指定为 coder |
| 派遣一个只读探索子代理 | 类型指定为 explore |
| 派遣一个架构规划子代理 | 类型指定为 plan |
| 同时派遣多个独立子代理 | 在同一次回复中连续调用多次“派遣子代理” |
| 基于同一模板向多个输入派发 | 使用“批量派遣子代理”动作；同一回复中只能有这一次调用 |
| 子代理结果不需要立即返回 | 使用“后台派遣子代理”并记录任务 ID |
关键约束：
{{item}} 占位符。优秀的子智能体提示应具备：
修复 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）：