by 运行时依赖
安装命令
点击复制技能文档
Taku 审核 - 交付门槛审核决定变更是否可以交付。它不是长篇批评，也不是瑕疵收集器。规则标签：[IRON LAW] 表示不可商量的正确性约束。[GUIDANCE] 表示强烈的默认值，可以在上下文合理时进行调整。[IRON LAW] 硬性阻塞优先于顾虑。不要将阻塞交付失败埋在样式评论中。
审阅合同：阅读当前 diff 与基准分支的比较，或者当没有远程 diff 时，阅读本地 dirty diff。然后输出三个部分： HARD STOPS - [无 | 阻塞性发现列表] CONCERNS - [无 | 非阻塞风险值得修复或注意] SUMMARY - 更改文件：[...] - 验证证据：[...] - 范围/规格状态：clean | drift | 缺少要求 | 未知 - 残余风险：无 | [...] - 状态：DONE | BLOCKED | DONE_WITH_CONCERNS 使用 BLOCKED 时，存在硬性阻塞。仅当剩余问题为非阻塞且明确列出时，使用 DONE_WITH_CONCERNS。
步骤 1：检测基准和 diff 运行仓库适用的等效命令：git remote get-url origin 2>/dev/null git branch --show-current git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's|refs/remotes/origin/||' git status --short git diff --stat 如果在基准分支上且没有本地 diff，则停止：HARD STOPS - 无 CONCERNS - 无 SUMMARY - 更改文件：[] - 验证证据：不适用；无 diff - 范围/规格状态：clean - 残余风险：无 - 状态：DONE 不要在没有代码更改时编造发现。
步骤 2：重构意图 阅读最强的意图源：构建日志从 /taku-build PLAN.md 批准 快速小设计 DESIGN.md 用户请求在当前会话中 提交消息 然后比较意图与交付的更改。硬性阻塞：范围漂移：无关文件、行为或重构未批准。 缺少要求：批准的行为在 diff 中缺失。 未批准的偏差：构建记录了未批准的偏差。 批准的偏差不是硬性阻塞，但必须在 SUMMARY 中列出。
步骤 3：检查验证证据 审阅观察到的证据，而不是信心声明。硬性阻塞：实现声称完成，但没有测试/构建/lint/手动命令证据可见。 验证输出过时或来自相关代码更改之前。 缺少 TDD 锚点或复制检查。 如果证据不可用，因为仓库没有测试框架，则说明使用了什么替代方法。 不要声称测试通过，除非输出或显式用户证据显示通过。
步骤 4：关键模式通过 阅读完整的 diff，然后评论。搜索生产风险模式： SQL/查询注入来自字符串构建的用户输入 提示注入或未验证的 LLM 输出跨越信任边界 缺少身份验证检查或过于宽泛的权限 条件副作用隐藏在三元运算、短路或可选链中 竞争条件、共享可变状态或非原子读/写 资源泄漏可能耗尽连接、文件、流或监听器 高置信度的关键/安全漏洞是硬性阻塞。 仅当正确的更改从本地上下文中清楚时，才直接应用修复。否则，提供最小的安全推荐并保持 BLOCKED 状态。
步骤 5：顾虑通过 仅处理完硬性阻塞后，列出非阻塞风险： 错误路径会降低行为但不会阻塞交付 弱类型/空处理，具有有限的爆炸半径 缺少清理，影响有限 可维护性问题，使后续处理风险增加 跳过琐碎的评论。如果样式模式很重要，则只提及一次。
自动修复策略：当修复方法明确且可以在本地验证时，自动修复关键和重要的发现。自动修复后，运行最小相关的验证。不要提交、推送或打开 PR。不要将审阅与广泛的重构混淆。
输出规则：HARD STOPS 必须首先出现。每个硬性阻塞需要文件/行或工件引用，当可用时。SUMMARY 必须包括更改文件、验证证据、残余风险和状态。如果审阅发现范围漂移、缺少要求或缺少验证，则状态为 BLOCKED，直到修复或用户明确批准。
已知陷阱：琐碎的评论隐藏了真正的问题。审阅产生了 40 个样式评论和一个 SQL 注入发现。开发人员修复了简单的评论并错过了安全漏洞。 预防方法：硬性阻塞优先；顾虑其次；样式注释仅在它们改变交付风险时。 审阅接受构建摘要作为证据。摘要说“测试通过”，但没有命令输出可见。 预防方法：完成声明需要观察到的命令输出、diff 证据或显式用户提供的证据。 范围漂移看起来像清理。任务批准了 --json 输出，但 diff 也重写了命令发现。 预防方法：在代码质量审阅之前重构意图。范围外的良好代码仍然是交付失败。