findscripter 何时使用
当你手上有多个彼此无关的问题（不同测试文件、不同子系统、不同 Bug），逐个串行排查纯属浪费时间。核心原则：一个独立问题域派一个子 Agent，让它们并发干活。
判定路径（源自原 SKILL 的决策图）：
- 有多处失败吗？→ 没有则单 Agent 处理。
- 它们彼此独立吗？→ 相关联（修一个可能连带修好其他）则让单 Agent 一起查。
- 能并行吗？→ 有共享状态（会改同一文件、抢同一资源）则改为串行 Agent；否则并行分派。
该用：
- 3+ 个测试文件因不同根因失败
- 多个子系统各自独立损坏
- 每个问题不依赖其他上下文即可理解
- 各排查之间无共享状态
不该用（负边界）：
- 失败相互关联——先合并排查，修一个可能修好一片
- 需要通览整个系统状态才能理解
- 探索性排障——你还不知道哪里坏了
- 共享状态——Agent 之间会互相干扰（编辑同一文件、争用同一资源）
步骤 / 指令
1. 划分独立问题域 按"坏了什么"对失败分组，例如：文件 A=工具审批流程、文件 B=批量完成行为、文件 C=中止功能。确认彼此独立——修工具审批不会影响中止测试。
2. 编写聚焦的 Agent 任务 每个子 Agent 必须拿到四件套：
- 明确范围：单个测试文件或子系统
- 清晰目标：让这些测试通过
- 约束：不要改动其他代码
- 预期产出：定位与修复的摘要
3. 并行分派（Claude Code / AI 环境）
Task("Fix agent-tool-abort.test.ts failures")
Task("Fix batch-completion-behavior.test.ts failures")
Task("Fix tool-approval-race-conditions.test.ts failures")
// 三者并发执行
4. 回收并整合
- 逐份阅读摘要
- 核验各修复是否冲突（是否动了同一段代码）
- 跑全量测试套件
- 抽查——子 Agent 可能犯系统性错误，确认无误后整合
示例
好的子 Agent prompt 应满足：聚焦（单一问题域）、自包含（含理解问题所需的全部上下文）、产出明确（说清要返回什么）。
修复 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. 修复方式：
- 用基于事件的等待替换任意 timeout
- 若发现中止实现有 Bug 则修掉
- 若被测行为已变更则调整测试期望
不要只是加大 timeout——找到真正的问题。
返回：你定位到什么、修了什么的摘要。
实战参考（6 个失败 / 3 个文件，重构后）：Agent1 用事件等待替换 timeout；Agent2 修了事件结构 Bug（threadId 放错位置）；Agent3 增加了对异步工具执行完成的等待。三处修复独立、零冲突、全量套件转绿。
注意事项
常见错误对照：
- 太宽泛：「修好所有测试」→ Agent 会迷失。应：「修 agent-tool-abort.test.ts」聚焦范围。
- 无上下文：「修那个竞态」→ Agent 不知道在哪。应：贴出报错信息与测试名。
- 无约束：Agent 可能大改重构。应：「不要改生产代码」或「只改测试」。
- 产出模糊：「修一下」→ 你不知道改了啥。应：「返回根因与改动摘要」。
收益：并行（多路排查同时进行）、聚焦（每个 Agent 范围窄、上下文少）、独立（互不干扰）、提速（3 个问题用 1 个的时间解决）。
风险与边界（保留源约束）：仅在任务明确落在上述范围内时使用；其产出不能替代环境特定的验证、测试或专家评审；若缺少必需输入、权限、安全边界或成功标准，停下并请求澄清。
互见
- 串行 Agent 编排（存在共享状态时的替代方案）
- 子 Agent prompt 写法 / 任务下发规范
采编自 sickn33/antigravity-awesome-skills（MIT）。