findscripter 何时使用
当你手里已经有一份写好的、可读的实施计划（步骤被拆成小颗粒），且希望在一个独立会话里把它落地、并在批次之间停下来让人（架构师/搭档）审阅时使用。核心原则：分批执行 + 检查点审阅。
开工先声明：「我正在用『分批执行计划与检查点』技能来落地这份计划。」
不该用的边界：
- 还没有具体计划文本，只有模糊想法 → 先去写/补全计划，再回来执行。
- 任务很小、能一口气跑完且无需人工把关 → 直接做，分批只会增加来回开销。
- 需要的是重新设计方案或推翻整体思路，而非按既定计划执行 → 回到计划/评审阶段。
步骤
- 加载并批判性评审计划：读计划文件；带着质疑通读，找出疑问或顾虑。有顾虑 → 先和搭档对齐再动手；无顾虑 → 用
TodoWrite建任务清单后开工。 - 执行一批：默认前 3 个任务。逐个任务：标记
in_progress→ 严格按计划的小步骤做（计划已切成小颗粒，照做即可）→ 按计划跑验证 → 标记completed。 - 汇报：一批做完后，展示「实现了什么 + 验证输出」，然后说一句「Ready for feedback.」并停下等待。
- 继续：依据反馈——需要就改、执行下一批、循环直到全部完成。
- 收尾：所有任务完成并验证通过后，转入收尾流程（声明并按团队的「完成开发分支」流程：验证测试、给出选项、执行所选项）。
指令
何时必须停下来求助（命中任一立即停止执行，不要猜）：
- 批次中途撞墙：缺依赖、测试失败、指令含糊。
- 计划存在关键缺口，导致无法开始。
- 看不懂某条指令。
- 验证反复失败。
何时回到评审（第 1 步）：搭档据你的反馈更新了计划；或底层方法需要重新思考。别硬闯阻塞点——停下来问。
要点速记：先批判性评审计划；严格照计划步骤做；不跳过验证；计划引用到别的技能时就去用；批次之间只汇报、不擅自往下推进；卡住就停、不要靠猜糊弄。
示例
一份计划含 8 个任务。执行节奏：
评审计划 → 无顾虑 → TodoWrite 建 8 条任务
批次 1：任务 1/2/3（每个 in_progress → 按步骤做 → 跑验证 → completed）
汇报：「实现了 X/Y/Z；验证输出如下 …… Ready for feedback.」 ← 停下等反馈
（搭档：任务 2 的边界要改）→ 应用修改 → 批次 2：任务 4/5/6 → 汇报 → 停
批次 3：任务 7/8 → 汇报 → 全部完成并验证 → 转入收尾流程
撞墙示例：批次 2 中任务 5 的验证连续 3 次失败 → 立即停止，向搭档说明「任务 5 在 …… 处验证反复失败，疑似 ……，需要你确认 ……」，而不是继续往任务 6 推进。
注意事项
- 默认每批 3 个任务是为了控制审阅粒度；可按搭档偏好调整，但「批次间汇报并等待」这一约束不要省。
- 「批判性评审」发生在动手前，不是走形式：把疑问/顾虑在建 TodoWrite 之前提出来。
- 不要跳过计划里写明的验证步骤；验证输出是检查点能审阅的依据。
- 停下时给出可操作信息（哪里卡、疑似原因、需要什么决策），而非只说「卡住了」。
- 本技能只负责「按计划分批执行 + 检查点」；写计划、拆任务依赖、收尾合并分支等是相邻职责，按需组合。
互见
- related：
task-decomposition-planner—— 上游负责把复杂任务拆成可执行计划/子任务，本技能负责把计划落地执行。 - related：
premortem-plan-challenger—— 执行前若想先给计划「找茬」、暴露脆弱假设，可先用它。 - combines_with：与「收尾/完成开发分支」类流程组合，完成执行后做测试验证与合并收口。
采编自 sickn33/antigravity-awesome-skills（MIT 许可）。