Menü
当面临2个或更多可独立执行的、无共享状态或顺序依赖的任务时使用
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
桌面/网关运行时内置的计划创建技能，用于生成可落盘、可调度、可批次执行的结构化计划包。
桌面/网关运行时内置的计划执行技能，用于按批次执行结构化计划包中的单个任务文件。
Use when demonstrating or verifying VibeWindow local plugin packaging, including plugin skills, MCP servers, hook declarations, and interface metadata.
当需要在编码前创建或更新实施计划时使用，尤其适用于多步骤功能开发、重构、包含多个活动部件的缺陷修复，或需要拆分为可独立执行并跟踪进度的任务文件的请求。
当你有书面实现计划需要在单独会话中执行，并带有审查检查点时使用
通过 `rustcodegraph` 命令行界面使用 RustCodeGraph 理解、导航或脚本化操作已索引代码库。当用户要求使用 RustCodeGraph、需要高性能搜索检索代码、需要符号/源码/调用流上下文、调用方/被调用方/影响分析或受影响测试选择时使用。
| name | dispatching-parallel-agents |
| description | 当面临2个或更多可独立执行的、无共享状态或顺序依赖的任务时使用 |
你将任务委派给具有隔离上下文的专业代理。通过精心构建它们的指令和上下文，确保它们保持专注并成功完成任务。它们不应继承你当前会话的上下文或历史——你只需精确构建它们所需的内容。这也为你自己的协调工作保留了上下文空间。
当你遇到多个不相关的故障（不同的测试文件、不同的子系统、不同的缺陷）时，逐一排查是在浪费时间。每个排查任务是独立的，可以并行进行。
核心原则： 每个独立的问题域派遣一个代理。让它们并发工作。
digraph when_to_use {
"多个故障？" [shape=diamond];
"它们是否独立？" [shape=diamond];
"单代理排查所有问题" [shape=box];
"每个问题域一个代理" [shape=box];
"它们能否并行工作？" [shape=diamond];
"顺序代理" [shape=box];
"并行调度" [shape=box];
"多个故障？" -> "它们是否独立？" [label="是"];
"它们是否独立？" -> "单代理排查所有问题" [label="否 - 相关联"];
"它们是否独立？" -> "它们能否并行工作？" [label="是"];
"它们能否并行工作？" -> "并行调度" [label="是"];
"它们能否并行工作？" -> "顺序代理" [label="否 - 共享状态"];
}
适用场景：
不适用场景：
按故障点分组：
每个问题域是独立的——修复工具审批不影响中止测试。
每个代理获得：
// 在 Claude Code / AI 环境中
Task("修复 agent-tool-abort.test.ts 的故障")
Task("修复 batch-completion-behavior.test.ts 的故障")
Task("修复 tool-approval-race-conditions.test.ts 的故障")
// 三个任务并发运行
代理返回后：
好的代理提示词应具备：
修复 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 个测试失败
失败情况：
决策： 独立的问题域 - 中止逻辑与批量完成与竞态条件各自独立
调度：
代理 1 → 修复 agent-tool-abort.test.ts
代理 2 → 修复 batch-completion-behavior.test.ts
代理 3 → 修复 tool-approval-race-conditions.test.ts
结果：
集成： 所有修复相互独立，无冲突，完整测试套件全部通过
节省时间： 3 个问题并行解决，而非串行
代理返回后：
来自调试会话（2025-10-03）：