Execute Task

Execute Task — 执行编排 Skill（workflow 层）

你的任务

把一份已确认的任务清单（理想情况下来自 split-task），编排成实现 + 测试 + 提交， 并经验收确认"真的做完了"。你不亲手定义怎么写测试、怎么审代码——那些交给 composable 层； 你钉死的是编排层的四件事：

1. 按依赖 / wave 调度 —— 用 split-task 的依赖与并行视图排执行顺序，可并行的并行、高风险的先做， 并为每个任务备齐约定的 seam。
2. 每任务一个可核对的闭环 —— 干净基线 → 调用 tdd 走红 → 绿 → 过闸门一（核证据）→ checkbox 与代码一起原子提交。判据是落盘的红 → 绿证据 + 验证全绿 + 范围没漂，不绿不算完成。
3. 进度可恢复 —— checkbox 回写 + 轻量账本，中断 / 上下文压缩后能续上，不重复执行。
4. 整体验收对回上游 —— 调用 review-changes 做 whole-branch 审查 + 自己做覆盖核对回扫， 确认每个设计点都落地、不落空；这是全链路唯一的审查与修复轮。

这是本链唯一真正写代码的 skill：前面 refine-idea / write-spec / make-design / split-task 都止于文档， 到 execute-task 才落地实现。但守层不变：不拆任务（那是 split-task）、不定技术决策（make-design）、 不定行为（write-spec）；发现上游有重大错误，退回上游修，不在执行里硬改。

一句话：把"拆好、可验收的任务清单"，按依赖顺序逐个编排成通过验收的代码—— 每个任务调 tdd 走一个红 → 绿闭环并凭证据过门，进度记在可恢复账本里， 最后调 review-changes 做一次整体审查并逐条对回 design / spec。

分层与调用

本 skill 是 workflow 层的最后一棒。workflow 层是 refine-idea → write-spec → make-design → split-task → execute-task 这条链，各守一道闸门、 把产物交给下一棒。执行期需要的具体能力一律调用 composable 层：

三条跨层约定：

• 调用即交出该层的判据定义权：不在本 skill 里重述 tdd 的循环规则、也不重述 review-changes 的审查判据—— 需要细节时读那个 skill，别在这里维护第二份。
• 调用 tdd 不是派 subagent：阶段 2 由主 agent 自己加载 tdd 的执行纪律走完闭环，任务内不派任何 subagent。 全流程唯一的 subagent 派发点是阶段 3（review 与 fix），fresh 上下文正是那道门的价值。
• 被调 skill 不可用时，闸门判据不变：主 agent 按闸门一 / 闸门二的判据自己完整走一遍 （红 → 绿证据齐、六关逐项判定），并说明降级原因——降级的是谁来做，不是做不做。

核心理念

执行是这条链的最后一棒，也是唯一产出代码的一棒。前四道闸门把"做什么 / 怎么实现 / 拆成哪些任务" 都钉死了，但"代码写完了"不等于"做完了"。execute-task 把"做完"变成有客观判据的事： 每任务凭红 → 绿证据过门才提交、整体过验收门才收尾、进度有账本可恢复。 判据是机制自带的（先红后绿、命令实跑、范围不漂），不是再加一层"另一个 agent 看过了"的主观确认。

何时用 / 何时不用

适用：

• 任务清单已确认（或手上有 split-task 的 tasks），准备落地编码。
• 要把一组拆好的开发任务推进到"实现 + 测试 + 提交 + 整体验收"。
• 需要可恢复、可追溯的执行过程（中断后能续、每步有 commit、最后能整体验收）。

不适用（别硬套）：

• 任务还没拆 / 没确认 → 先 split-task。执行必须站在确认过的任务清单上。
• 技术方案没定 → 先 make-design；行为没钉死 → 先 write-spec；想法还模糊 → 先 refine-idea。
• 只是一个改动要走红 → 绿 → 直接用 tdd，不必起整套编排。
• 只是要审一遍改动 → 直接用 review-changes。
• 单纯定位某个已知 bug、纯代码评审 → 用对应方法，不必起整套执行编排。

⚠️ 加载约束：execute-task 会真写代码、跑测试、提交——没有前四个 skill 那种"止于文档"约束。但有硬线：

• 提交也必须先授权：阶段 0 在任何代码修改前，说明当前分支、tasks 范围和预计提交批次，获得用户明确授权； 拒绝或语义含糊就停止，不降级成"先改代码、以后再说"。超出授权范围的提交必须重新确认。 若要用并行任务分支，还要单独说明并取得对具体集成 merge 的授权。
• 其他破坏性 / 对外操作必须用户确认：合并到主干、提 PR、push、删文件 / 目录——遵循当前仓库 CLAUDE.md / AGENTS.md 与平台审批策略，不自动做。
• 重大上游错误退回，不硬改：执行中发现 design / spec / tasks 有重大错误，停下退回对应上游 skill， 不在执行里绕过。
• 可在自治 / 批处理场景执行任务，但合并 / 对外操作仍要 gate——遇到该合并时，正确做法是停下交用户拍板。

招牌机制：调度编排 + 可恢复账本 + 双验收闸门 ⭐

编排类的招牌不是"探针覆盖"，而是执行纪律。两个核心 + 两道闸门：

核心一：每任务一个干净闭环（调用 tdd，任务内不派 subagent）

干净基线 → 备简报与 seam → 调用 tdd 走红 → 绿 → 过闸门一（核证据） → atomic commit

• seam 事先约定：seam 由 make-design / split-task 指定；没指明的任务，开工前把 seam 写下来 与用户确认，再写进任务简报交给 tdd——不让 tdd 自己挑地方测。测错地方比测得少更糟， 任务内没有 reviewer 会发现。
• 一次只做一个任务：手上同时只推进一个任务的闭环。混着做会让"范围没漂"这条判据失效，也拆不出原子提交。
• 记录落文件，不只留在上下文：任务简报与 tdd 的执行记录都写进自忽略的 .execute-task/—— 上下文一旦被压缩，留在对话里的证据就没了，落盘的还在；safe-resume 也靠它。
• 重构不夹带：tdd 交回的「疑虑」记进账本，留给阶段 3 的 architecture 关，不在任务内顺手改。
• atomic commit：过闸门一后先回写 checkbox，再把代码、测试和 checkbox 一起提交； 一个任务一个原子提交，提交信息可追溯到任务。提交必须落在阶段 0 的明确授权内。

质量靠 TDD 本身承担：红 → 绿是自带判据的机制，任务内不再套一层主观审查； 架构级审查集中到阶段 3 做一次。

核心二：可恢复账本

每任务完成后记账，让执行可中断、可恢复：

• checkbox 回写：把 split-task 的 tasks.md 对应任务从 - [ ] 改成 - [x]， 与该任务代码 / 测试进入同一个 commit（状态即进度）。
• 轻量 ledger：在自忽略的 .execute-task/ 内记起点 commit、已完成任务 + 对应 commit + tdd 交回的结构疑虑（交阶段 3），提交成功后才写。
• safe-resume：重跑时读账本跳过已完成任务，绝不重复执行（防上下文压缩后从头再来）。

闸门一：每任务证据门（跑命令与比对，不是代码审查）

任务「验收标准」逐条对上，外加核三样：

1. 红 → 绿证据齐：tdd 交回的执行记录里每个行为都有实现前的失败输出（含"为何预期失败"）+ 实现后的通过输出，且都是当场记下的。
2. 验证方式收尾实跑绿：提交前完整跑一次任务的验证命令（加 typecheck / 相关测试文件）， 告警噪音也要看见——不拿红绿循环中途某一次的输出顶替。
3. 范围没漂：HEAD 仍是 task-baseline.sh 记录的基线，改动落在任务涉及文件内。

不齐不 commit、不算完成，也不许标 [x]。记录只有绿没有红 → 这个任务没走成 TDD： 把缺的行为交回 tdd 重做一遍红 → 绿，做不到就记录在案并告知用户，别事后补一段测试冒充红证据。

闸门二：整体验收门（全链路唯一的审查与修复轮）

全部任务完成后做 whole-branch 验收：

• 调用 review-changes：派 fresh subagent（固定最强档）加载它，对 BASE..HEAD 做六关审查 （五轴 + 测试质量），把各任务疑虑一并交给它。
• 覆盖核对回扫（本 skill 自己做）：对回 split-task 的覆盖核对表、spec 的成功标准—— design 每个组件 / spec 每条 MUST / MUST NOT 都已实现且被测试覆盖，不落空。
• 全绿：全套测试 / 构建 / typecheck 通过。
• 审出的 Critical / Important 派独立 fix subagent 修复 → 复审（按轮次计，默认 3 轮， 超限停下交用户），Minor 记录不阻塞。

流程：确认提交授权 → 调度排序（依赖 / wave + seam 清单）→ 逐任务闭环（干净基线 + 调用 tdd + 闸门一 + 原子提交）→ ignored ledger → 整体验收（闸门二）→ 收尾。

工作流程（阶段 0 + 四个工作阶段）

阶段 0 · 定位与上下文

1. 接上游：读 tasks（docs/tasks/* 或用户指明位置）作为主输入，读 design / spec 取验收口径。 无 tasks → 视为前置缺失：执行必须站在确认过的任务清单上；没有就建议先 split-task， 不要自己临场拆任务。
2. 扫代码库：技术栈、测试怎么跑、构建怎么跑、typecheck 怎么跑——这决定每任务的验证怎么做， 也是交给 tdd 的「验证方式」。
3. 建 / 读进度账本：首次执行建账本并记起点 commit（git rev-parse HEAD——阶段 3 的 BASE）； 续跑读账本，确定从哪个任务接着做。
4. 确认分支策略：在哪个分支执行（默认当前工作分支；若在主干，按仓库习惯决定是否先开分支）。
5. 提交授权闸门（代码修改前）：向用户明确说明当前分支、要执行的 tasks 范围，以及本批次将产生的 任务提交和必要验收修复提交；等待"确认 / 继续 / 是"等明确授权。未授权、拒绝或范围不清 → 停止 execute-task，不开工、不修改代码。后续提交若超出该范围，重新确认。默认串行执行； 若计划用并行任务分支，还必须同时说明 expected base、集成顺序与将执行的 merge，并取得明确授权。

阶段 1 · 调度规划

1. 排执行顺序：按 split-task 的依赖与并行视图做拓扑排序。
2. 列 seam 清单：逐任务从 design / tasks 取出该任务的可测接缝；有任务没指明 seam → 现在就与用户确认， 确认后写进该任务简报。没有确认过 seam 的任务不开工——测试写在哪决定这个闭环能验住什么。
3. 定并行与隔离：默认串行执行。同 wave 只有在每个任务使用独立 worktree、共享同一个 expected base、 能证明改动与 tasks checkbox 的集成不会冲突，且阶段 0 已授权具体 merge 时才并行。 建立隔离时调用 setup-worktree。
4. 高风险前置：split-task 标了高风险 / 高不确定性的任务先做，早暴露问题。
5. 打印执行计划：列出顺序、每个任务测在哪个 seam、哪些并行、checkpoint 在哪——让执行过程可见。

阶段 2 · 逐任务执行闭环

1. 运行 scripts/task-baseline.sh <任务编号>：真实工作区必须干净，并记录当前 HEAD； 失败就停下处理，不能带着上个任务或用户的改动开工。
2. 备好任务简报（scripts/task-brief.sh 抽取 + 追加 design/spec 片段与约定的 seam）。
3. 调用 tdd，按其调用契约传入：简报路径、seam、验证方式、记录参数（名称 task-N、 输出目录 .execute-task/）。任务内不派任何 subagent——主 agent 自己走完这个闭环。
4. 收 tdd 交回的证据齐否 / 改动文件 / 疑虑 / 记录路径，过「闸门一」（三样证据 + 验收标准逐条对上）； 不齐 → 交回 tdd 把缺的行为重做红 → 绿，或交用户判断，不往下走。
5. 过门后先回写 checkbox，确认提交仍在阶段 0 授权范围内，再把代码 + 测试 + checkbox一起 atomic commit；提交成功后写 ignored ledger（含本任务的疑虑），并用 git status --porcelain=v1 --untracked-files=all 校验真实工作区干净。未干净就停下排查，不开始下一任务。
6. 同 wave 默认仍串行；只有满足阶段 1 的四项条件才并行。并行时按预先声明的确定顺序集成并逐次验证； wave 间串行。
7. 每 2~3 个任务到 checkpoint 跑一次相关测试 / 构建，确认到这里是稳的。

阶段 3 · 整体验收

1. 先扫本次开发 diff 中的临时日志、调试打印、断点与临时开关；发现残留就精准清理、跑覆盖测试， 并在阶段 0 授权范围内提交。工作区恢复干净后再进入验收。
2. 过「闸门二」：派独立 subagent 加载 review-changes（固定最强档），传 BASE 起点 commit、 tasks / design / spec 路径、各任务疑虑；它自己生成审查包并回六关 findings。 同时跑全套测试 / 构建 / typecheck 绿，并自己做覆盖核对回扫。
3. 不绿 / 有落空 / 有 Critical 或 Important → 派独立 fix subagent 修复（或回阶段 2 补任务）， 涉及行为的修复仍先补失败测试再修到绿；修完 commit 再复审（按轮次计，超限交用户）。

阶段 4 · 收尾

1. 调用 finish-branch 做收尾：先清理本次开发的调试残留并重跑最终测试，再检测 repo/worktree 状态， 给出合并到主干 / 本地保留 / 创建 PR / 丢弃选项。提交、合并、push、删除和移除 worktree 分别由用户授权， 不把一种选择扩张成其他动作的许可。
2. execute-task 到"整体验收通过 + 收尾决策交付"为止，不擅自合并、不自动往下。

进度跟踪与恢复

• 状态存在 tasks.md 的 checkbox：- [x] = 已完成、已提交、已过闸门一；checkbox 必须在对应任务 commit 内。
• ledger 位于自忽略的 .execute-task/，记起点 commit、每个完成任务对应的 commit 与 tdd 交回的结构疑虑， 便于追溯、safe-resume 和阶段 3 整体验收。
• 中断恢复：重新执行时，先读账本与 checkbox，已完成的跳过；只接着做未完成的，绝不重复执行。
• 不引入 GSD 那套 STATE / ROADMAP 全套状态文件——checkbox + 轻 ledger 足够，别把进度跟踪做成负担。

上游纠错与守层

执行中发现 design / spec / tasks 有误时，分级处理：

• 小问题（笔误、明显的小遗漏、不影响结构的偏差）→ 就地修正 + 回写 artifact + 告知用户，继续执行。
• 重大问题（技术决策错、需求缺失、任务依赖一段不存在的设计）→ 停下退回 make-design / split-task 修订， 不在执行里硬改绕过——否则代码会偏离已 review 的契约。

检验：「这个修正会不会改变已 review 的行为契约 / 技术决策 / 任务边界？」会 → 它是重大问题，退回上游，别就地改。

产物与收尾

• 产物是代码（实现 + 测试 + 一串原子提交 + 回写的 tasks.md），不是文档。
• 收尾交 finish-branch：执行完调用 finish-branch 决定合并 / 本地保留 / PR / 丢弃，破坏性操作由用户拍板。
• brownfield：执行只动 tasks 涉及的范围；迁移 / 回滚任务按 tasks 里标的来做。

核心原则（不要违反）

1. 每任务走可核对的闭环 —— 干净基线 → 调用 tdd 红 → 绿 → 三样证据核对 → checkbox + 代码原子提交 → ignored ledger → clean 校验；证据不齐不算完成、不 commit。
2. 测在约定的 seam 上 —— seam 来自 design / tasks，缺就先与用户确认后写进简报再交给 tdd。
3. 先站在 tasks + design/spec 上再动手 —— 执行依据是确认过的任务清单与验收口径，不临场发挥。
4. 能力交给 composable 层 —— 红绿闭环调 tdd、整体审查调 review-changes、隔离调 setup-worktree、 收尾调 finish-branch；不在本 skill 里维护第二份判据。
5. 任务内主 agent 自己做，不派 subagent —— 调用 tdd 是加载纪律；subagent 只在阶段 3 出现。
6. 进度记可恢复账本 —— checkbox 回写 + ledger，safe-resume 不重复执行。
7. 审查集中在整体验收一次 —— review-changes 六关 + 本 skill 的覆盖核对回扫，design / spec 每条都落地 且被测试覆盖，不落空；任务内不开审查轮。
8. 守层 —— 不拆任务 / 不定决策 / 不定行为；重大上游错误退回，不硬改。
9. 提交与危险操作用户拍板 —— commit 必须先在阶段 0 获得明确批次授权；任务分支集成 merge 也需在阶段 0 明确授权；合并 / PR / push / 删文件不自动做。
10. 自包含 —— 不依赖外部插件，只调用本工具集内的 composable skill；被调 skill 或 subagent 不可用时，由主 agent 按同一套判据自己走完（阶段 3 以 fresh 视角走六关），不删掉那道门。

终止条件（可检验）

• 达标即停：全部任务过闸门一、整体过闸门二（六关 + 覆盖回扫 + 全绿）、收尾决策交付给用户—— 执行就完成了，别为"再优化一下"无限改。
• 兜底①：执行中发现任务依赖的 design 决策缺失 / 错误（重大）→ 停下退回 make-design / split-task， 别用代码替设计补窟窿。
• 兜底②：某任务反复实现不过 / 卡死（tdd 交回 BLOCKED）、红 → 绿证据补不出来， 或 阶段 3 的 fix loop 超轮次上限仍有 Critical / Important → 停下把判断告诉用户—— 继续修、接受现状还是退回上游，由用户拍板，别在原地空转或硬猜。

自检清单（执行与收尾时过一遍）

• 在任何代码修改前，已向用户说明分支 / tasks / 提交批次并获得明确提交授权？每个实际 commit 都在授权范围内？
• 每任务开工前 task-baseline.sh 都确认了真实工作区干净并记录 HEAD？
• 每个任务的 seam 都是约定过的（来自 design / tasks，或已与用户确认并写进简报）？没有让 tdd 自己挑地方测？
• 每任务都过了闸门一的三样证据（红 → 绿齐、收尾完整跑一次验证命令绿、HEAD 未漂移且范围没越界）才标 [x]、才 commit？
• 记录只有绿没有红时把那个行为交回 tdd 重做了红 → 绿，没把事后补的测试当 TDD 证据？
• 每任务 commit 都包含代码 + 测试 + checkbox，随后才写 ignored ledger，并确认工作区干净？
• 任务内一个 subagent 都没派（调用 tdd 是加载纪律，不是派发）？
• tdd 的执行记录落在 .execute-task/task-N-record.md，不是只留在对话上下文里？
• 阶段 3 的 review / fix 派发显式指定了模型档位，整体验收用了最强档？
• 调度按 tasks 的依赖 / wave，无环、顺序可执行？默认串行；若并行，是否每任务独立 worktree、 expected base 相同、集成无冲突且 merge 已获授权？
• 整体验收调用了 review-changes（独立 subagent、最强档），并把各任务疑虑交给了它？ 审出的 Critical / Important 派 fix 修了、按轮次计？
• 覆盖核对回扫——design 组件 / spec MUST / MUST NOT 都已实现且被测试覆盖、不落空？
• 全套测试 / 构建 / typecheck 绿？
• 生成审查包前工作区无非忽略改动、BASE 是 HEAD 的祖先？
• 中断恢复读了账本、没重复执行已完成任务？
• 发现上游错误：小修就地 + 回写 + 告知，重大退回上游？
• 破坏性 / 对外操作（合并 / PR / push）都停下问了用户，没自动做？
• 收尾调用了 finish-branch，给了用户合并 / PR / 留分支的决策，没擅自合并？

一次完整示范（照着这个节奏走）

接 split-task 那份"实验清单"任务清单（T1 建表 → T2 list_experiments() → T3 路由 + 模板 → T4 MUST NOT 收口），看它怎么被执行掉。

阶段 0 · 定位与上下文

读 tasks（4 个任务，线性依赖 T1→T2→T3→T4）+ design / spec（验收口径）。扫项目：测试 pytest、 无构建步骤、无 typecheck（小 Python 项目）。首次执行，建进度账本并记起点 commit a1b2c3d。 分支：在当前 feature 分支执行。 向用户说明"本批次会产生 T1~T4 四个任务提交，以及整体验收发现问题时的必要修复提交"，获得明确授权后才继续。

阶段 1 · 调度规划

依赖链线性、split-task 已标"无并行"，无需 worktree（不调 setup-worktree）。执行计划：T1 → T2 → T3 → T4， checkpoint 设在 T2 后（数据层绿）、T3 后（开页面）。无高风险任务。 seam 清单：T1 建表脚本 / migration 的幂等接口、T2 list_experiments() 纯函数、T3 路由响应， T4 三条 MUST NOT 各自的检查点——design 已指明 T1~T3，T4 的 seam design 没写， 与用户确认为"在 list_experiments() 与路由两层各加拒绝用例"后写进 T4 简报。

阶段 2 · 逐任务执行闭环（以 T2 为例）

1. task-baseline.sh T2 确认 T1 提交后工作区干净，记录 HEAD；task-brief.sh 抽 T2 简报， 追加 design 片段与 seam（list_experiments() 纯函数）。
2. 调用 tdd：传简报路径、seam、验证方式 pytest tests/test_models.py、记录参数 （task-2 + .execute-task/）。tdd 逐个行为走红 → 绿——test_empty → 红（NameError，行为缺失）→ 最小实现 → 绿；test_invalid_status → 红 → 校验 → 绿；test_stable_sort → 红 → 稳定排序 → 绿； test_owner_none → 红 → 绿。收尾完整跑一次 pytest tests/test_models.py → 4 passed。 交回：证据齐、改动 models.py + tests/test_models.py、疑虑一条（"取数可拆两个 helper，按规则没动"）、 记录路径 .execute-task/task-2-record.md。
3. 过闸门一核三样：记录里四个行为红 → 绿证据齐、都是当场写的 ✓；收尾验证完整跑绿、无告警 ✓； git rev-parse HEAD 仍是基线、改动只在那两个文件 ✓；验收标准四条逐条对上 ✓。
4. 过门 → tasks.md 的 T2 改 - [x]；确认仍在阶段 0 授权内，把实现、测试和 checkbox 一起 git commit -m "feat: list_experiments 查询+校验+稳定排序"（atomic）。
5. 回写账本：提交成功后 ledger 记 commit + 那条疑虑（留阶段 3）；确认工作区干净，再开始 T3。

〔T1 / T3 / T4 同构。T3 后到 checkpoint：开页面看列表 + 空态 + owner 空。〕

阶段 3 · 整体验收

先扫 diff 无调试残留，工作区干净。过闸门二：

• 全套 pytest 绿；无构建 / typecheck 步骤。
• 调用 review-changes（派独立 subagent，最强档）：传 BASE a1b2c3d、tasks/design/spec 路径、 两条结构疑虑。它生成审查包后回六关判定：correctness（验收全过）/ readability（纯函数清晰）/ architecture（"取数拆 helper"判为 Minor，不阻塞）/ security（只读、无注入面）/ performance（数据量小）/ 测试质量（四个用例都走公共函数、期望值是字面量，无同义反复）——无 Critical / Important。
• 覆盖核对回扫（自己做）：对回 split-task 覆盖核对表——experiments 表(T1) / list_experiments(T2) / 路由+模板(T3) / 三条 MUST NOT(T4) 全部实现且有测试或检查覆盖，不落空。

阶段 4 · 收尾

调用 finish-branch。它给出收尾选项：

「实验清单 4 个任务全部完成、整体验收通过（pytest 全绿 + 六关无阻塞项 + 覆盖核对无落空）。 收尾你想怎么走？A 合并到 main　B 提 PR　C 留在分支。合并 / PR 我不会自动做，等你定。」

反例（不要这样做）

❌ 在本 skill 里重写一遍红绿循环规则或五轴审查判据 —— 那是 tdd / review-changes 的事，维护两份必然漂移。 ❌ 跳过 tdd 直接自己糊实现再补测试 —— 红没发生过，闸门一的证据造不出来。 ❌ 不给 tdd 传 seam，让它自己挑地方测 —— seam 缺就先与用户确认。 ❌ 一个任务没过闸门一（三样证据缺一样）就 commit / 标 [x] —— 证据门形同虚设。 ❌ tdd 交回"只有绿没有红"，事后补一段测试冒充红证据。 ❌ 在任务内派执行 / 审查 / 修复 subagent —— 任务内只有主 agent 加载 tdd 自己走，subagent 只在阶段 3 出现。 ❌ 阶段 3 派发 review / fix 不写模型，任其继承主 agent 当前档位 —— 该显式定档，整体验收固定最强档。 ❌ 阶段 3 的 fix loop 不设轮次上限无限修，或超限后不问用户硬冲；反过来把 Minor 问题也当阻塞项修个没完。 ❌ 中断后不读账本，从头重跑、重复执行已完成任务。 ❌ 跳过整体验收，"测试绿就算完" —— 任务内已经没有审查轮，跳过闸门二等于全程没被审过。 ❌ 只调 review-changes 就算验收完 —— 覆盖核对回扫是本 skill 自己的活，它不做。 ❌ 发现 design 设计错了，在执行里硬改绕过，不退回 make-design。 ❌ 自动合并到 main / 自动提 PR / 自动 push —— 没让用户拍板（危险操作）。 ❌ tasks 还没确认就开始执行 —— 该先 split-task。 ❌ 没有阶段 0 的明确提交授权就改代码或 commit；或把含糊的"看看吧"当授权。 ❌ 上一任务留下 dirty 工作区仍开下一任务，或不核 HEAD 就提交。 ❌ 先 commit 代码、之后再单独改 tasks checkbox / ledger —— checkbox 会留脏或与任务提交失去原子性。 ❌ 越界回去拆任务 / 改技术决策 / 改行为契约 —— 那是上游的事。 ❌ 运行时去调用 / 依赖外部插件 —— 本工具集自包含；阶段 3 无 subagent 可用时主 agent 以 fresh 视角 自己走一遍 review-changes 的六关，不是删掉那道门。

相关参考

调用的 composable skill（tdd / review-changes / setup-worktree / finish-branch）见上文「分层与调用」表—— 它们的判据住在各自的 SKILL.md，需要细节直接读那一份。以下是本 skill 自己的参考：

• references/orchestration.md —— 调度与编排：依赖 / wave 排序、 并行与 worktree 隔离、任务工作文件、进度账本与 safe-resume。
• references/acceptance.md —— 双验收闸门：闸门一证据核对、 闸门二编排与 fix 循环、覆盖核对回扫、上游纠错守层、收尾。
• references/handoff-templates.md —— 任务简报的准备， 以及阶段 3 review / fix 派发 prompt（照抄填空）与派发前自查。
• references/model-selection.md —— 阶段 3 派发的档位判据 （standard / most-capable），以及为什么任务内不再有定档动作。
• references/platform-agents.md —— Claude Code 与 Codex 在阶段 3 的 subagent 派发、权限继承、模型参数和并行工作目录；派发前按当前平台读取。