用途
Audit Decisions 面向的是「实现型智能体在任务未充分说明时自行做出的决策」，而不是代码差异本身。一个实现可以运行完美，却建立在用户从未做过的决策之上——数据形态、存储位置、依赖、API 契约、内存与速度的权衡——这些决策对未来工作都是承重的。用户需要知道它们，不是因为它们错了，而是因为用户从此要拥有它们。
该技能的核心主张是：审查数千行改动无法扩展，而且它检查的是执行过程（那部分很可能没问题）；可扩展的审计对象是决策——把实现者自行做出的每一个决策摆到台面上，评判这份清单，并记录判定。
主要能力
- 追溯决策：当实现者报告完成时，询问其「在完成这项工作时，你做了哪些自己不太有把握的决策？全部列出。」但把自我报告当作起点而非边界——智能体会少报。审计者需自行追溯会话步骤、子智能体报告、差异、提交，收集所有「在工作里但不在原始规格或提示里」的决策。
- 按证据分诊：对每个决策判断是被计划强制的，还是自行发明的。发明出来的决策接受审查：这是通用解法，还是为单个失败案例量身定做的修复？
- 三种判定：sound（合理）、unsound（不合理）、needs-user（需用户决定），并附带置信度（审计有多确定用户会做出同样的调用）。置信度用于对报告排序。
- 纠正决策而非打补丁：对每个 unsound 决策，条目要指出工作应从中重做的「纠正后的决策」——即一般意义上必须成立的性质——而不是在其上叠加的编辑。
- 决策台账：一个独立文件，在每次通过后依然存在（有规格时位于 specs/<feature>/decisions.md，否则位于计划旁的 decisions.md）。
使用方式
有两种入口，审计相同：
- 由工作流调用（每次通过或每个切片）：审计该次通过，将其条目追加到台账并返回；工作流在交回时呈现累积的台账。
- 由用户直接调用：审计眼前全部工作（会话、分支或指定变更）并立即呈现报告。只建议，不改变任何东西。
决策台账的条目格式
每个被审计的决策一条记录，包含：
- When：它落在哪次通过或提交中。
- The decision：一行标题，然后是 ELI5 场景——触发事件、工作今天做什么、未构建的替代方案会做什么，术语在首次使用时定义。
- The gap：计划中未说明、从而迫使该决策出现的地方。
- The reach：该决策约束或启用了哪些未来工作；用户为何需要知道它存在。
- Verdict：sound / unsound / needs-user，附一行理由。对 unsound：给出应从中重做的纠正决策。对 needs-user：给出推荐的临时调用及其回退方式。
- Confidence：审计有多确定用户会做出同样的调用（low / medium / high）。用于升序排列报告。
适用场景
- 实现型智能体报告完成、结果看起来干净时——声明成功正是风险最大的时刻。
- 工作流中途按通过或切片审计，累积台账。
- 用户直接对会话、分支或指定变更做整体审计。
- 需要把承重的合理决策提升进计划交接，让后续通过将其作为既定事实继承，而不是重新决策。
限制
- 该审计不修改代码、测试或构建状态。发现不合理决策是交付物，不是修复它的许可——记录纠正后的决策，让代码树与审计时完全一致。
- 证据收集是允许的：可以读任何东西、运行现有测试、写临时探针——但交回前必须移除每个探针。
- 「它能工作」不是对决策的判定。反复出现的坏味道是巧合性修复：调整过的缓冲区、调高的超时、恰好覆盖失败输入的特例，而底层原因仍在休眠。
- 在非平凡工作上得到空清单是危险信号，不是通过。
- 审计从不阻塞运行：每个条目是交给他人行动或审查的判断，而不是让运行停止的问题。
- 计划明确委托给实现者的决策属于自由裁量，不是审计项。
- 台账中已入账的决策即为既定事实，后续通过不再重新列出、不再重新决策。
- 条目必须默认以 ELI5 书写，且 ELI5 在每次重写后都要保留；合并、收尾重写时若把已入账条目压缩成标题，即视为失败。
完成标准
当该次通过中每个发明出来的决策都有带判定的台账条目、每个 unsound 条目都指出应从中重做的纠正决策、每个 needs-user 条目都带有可回退的临时调用，并且台账已呈现给下一个行动者（按判定分组、组内最不自信者优先、每个条目无需追问即可读懂），且代码树未被触碰时，审计即完成。交回时展示差异而非决策，或在审计期间应用了「修复」，都不算完成。