From superpowers-zh
Dispatches isolated parallel agents for 2+ independent tasks like fixing unrelated test failures across files or subsystems without shared state.
npx claudepluginhub jnmetacode/superpowers-zh --plugin superpowers-zhThis skill uses the workspace's default tool permissions.
你将任务委派给具有隔离上下文的专用智能体。通过精心设计它们的指令和上下文,确保它们专注并成功完成任务。它们不应继承你的会话上下文或历史记录——你要精确构造它们所需的一切。这样也能为你自己保留用于协调工作的上下文。
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
Guides TDD-style skill creation: pressure scenarios as tests, baseline agent failures, write docs to enforce compliance, verify with RED-GREEN-REFACTOR.
Guides idea refinement into designs: explores context, asks questions one-by-one, proposes approaches, presents sections for approval, writes/review specs before coding.
你将任务委派给具有隔离上下文的专用智能体。通过精心设计它们的指令和上下文,确保它们专注并成功完成任务。它们不应继承你的会话上下文或历史记录——你要精确构造它们所需的一切。这样也能为你自己保留用于协调工作的上下文。
当你遇到多个不相关的失败(不同的测试文件、不同的子系统、不同的 bug),逐一排查会浪费时间。每个排查都是独立的,可以并行进行。
核心原则: 每个独立问题域分派一个智能体,让它们并发工作。
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. 找到根因——是时序问题还是实际 bug?
3. 修复方式:
- 用基于事件的等待替换任意超时
- 如果发现中止实现中的 bug 则修复
- 如果测试的是已变更的行为则调整测试期望
不要只是增加超时时间——找到真正的问题。
返回:你发现了什么以及修复了什么的总结。
错误做法:太宽泛: "修复所有测试" - 智能体会迷失方向 正确做法:具体明确: "修复 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 个问题并行解决 vs 顺序解决
智能体返回后:
来自调试会话(2025-10-03):