tidy

Tidy

先审查差异，再按需修复。一轮即可生成报告；在应用模式下，同一轮还会落实修复，并完成干净的差异仍会掩盖的简化。

• 是： 审查本地差异、分支差异、PR 或指定的安全范围，并返回按严重程度分级、附有 file:line 证据的发现；在应用模式下，为这些发现提供最小且完整的修复，并进行差异范围内的简化。
• 不是： 创建 PR（pr-creator）、处理 CI 失败和审查讨论串（pr-babysitter）、面向用户的 UX、无障碍或渲染质量（ui-design 审计模式）、库或 CLI 的易用性（dx-audit）、架构简报和全仓库防护措施（codebase-architecture）、审查计划（planning），或将整个测试套件精简至经过衡量的目标（test-audit）。

报告或应用

报告是默认模式：用户说“审查我的更改”“代码审查”、下方的某个模式短语，或提供 PR 编号时使用。完成时，报告须采用“输出”部分规定的格式，包含审查范围、每条基线命令的最后一行，以及已阅读的参考资料。工作树保持原样。报告模式下不要编辑文件，即便只需修复一个字符也不例外；工作树一旦发生变化，用户要的只读报告就不复存在。

用户说“tidy”“简化”“修复”“应用这些发现”或要求进行更改时，使用应用模式。完成时，工作树中应包含已确认的发现和有依据的简化；受影响的检查须通过，或证明其失败属于基线问题；并总结更改内容、保留内容及原因，以及检查结果。应用模式会编辑差异涉及的任何文件，或修复所需的文件，并会直接运行仓库文档中指定的 lint、类型检查和测试命令：这些命令会在本地针对工作树运行，而落实更改正是用户所要求的。应用模式不会提交、推送、创建 PR、添加或升级依赖项、运行迁移，也不会在工作树之外写入文件。本会话先前生成的报告只是输入，并非依据：应用当前证据支持的内容，并说明未应用任何内容的原因。

Harness 优先级

Claude Code 内置了 /code-review（正确性加清理，带有 --fix）和 /security-review。手动输入的斜杠命令会运行内置技能；本技能会在用户点名时或匹配模式短语时运行，并额外提供 Structural 和 Deslop 模式、全仓库 Security 审计、内置命令会过滤掉的合理严重程度等级、REVIEW.md 支持，以及在任何具备 git 和文件工具的 harness 上生成相同的报告。本会话中已运行的内置审查所产生的发现，会作为候选项进入结论步骤，而不会重新推导。

模式分派

根据用户的措辞选择一个视角。每种模式都会加载 references/severity-rubric.md；表格中的附加项会加载该模式专属的评审标准。

模式	触发词	附加内容	范围
标准（默认）	/tidy、“review my changes”、“code review”、“tidy this”	无	本地或分支差异
结构性	“structural review”、“thermo-nuclear review”、“deep code quality audit”、“harsh maintainability review”、“code judo”	references/structural-quality-rubric.md	本地或分支差异
去除冗余	“deslop this”、“clean up AI code”、“remove slop”、“review for AI patterns”	references/ai-slop-patterns.md	本地或分支差异
安全审计	“security audit”、“find vulnerabilities”、“deepsec”、“threat model”、“audit for security”	references/security-checklist.md	指定子系统或整个仓库，无论是否存在差异

任何模式下都可能按条件加载：

• 当差异由 Agent 编写，或新增、修改、移除模块、系统边界、防护措施或回退机制时，加载 references/context-errors.md。
• 对于身份验证、输入处理、外部 API、上传、依赖项或锁文件变更，或环境配置，加载 references/security-checklist.md。
• 对于获取、渲染、图像、依赖项或影响包体积的导入，加载 references/performance-checklist.md。
• 当差异新增或修改测试时，加载 references/test-gate.md。没有测试变更的差异不会在此额外加载内容。
• 仅在第 3 步执行可选的第二意见检查时加载 agents/openai.yaml。其他情况下，它是供外部运行器使用的启动器元数据，不会加载。

工作流

1. 发现目标。 先检查暂存和未暂存的更改（git diff --stat、git diff --staged --stat）；如果工作区干净，则检查当前分支与 git merge-base HEAD origin/<default> 的差异。对于 PR，在已检出对应分支的情况下运行 gh pr diff <n>。记录差异范围或引用对；报告中要注明。

2. 收集上下文。 使用文件工具打开模式参考资料和条件加载项。此技能中的文件名只是指针，不代表内容已加载；如果必需的读取失败，应报告覆盖范围缺口，而不是声称已应用审核标准。从用户的原话、提交消息和 PR 描述中了解意图。加载适用范围内的 AGENTS.md / CLAUDE.md，以及根目录下存在的 REVIEW.md：若两者与此技能的默认规则冲突，则以它们为准，因此它们要求的模式不属于问题。复用已针对当前修订运行的检查；如果候选问题需要执行才能确认，则运行文档中记载的命令并保留其退出状态。

3. 审核。 应用已加载的审核标准和高信号标准；大型差异应分块处理。执行五轮检查，因为每轮都能发现其他轮次无法发现的问题：

   • 声明。 将描述或提交消息中的每项声明对应到一个代码块，再将每个代码块对应到一项声明。没有对应代码块的声明属于问题。没有对应声明的代码块应列入就绪情况摘要，作为未说明的更改。
   • 新增行。 阅读每个代码块，然后阅读其所在的完整函数。被修改函数中未修改行上的错误也属于范围内：此差异再次暴露了该错误。
   • 删除行。 对每一行删除或替换的代码，指出它原本维护的不变量，然后查找新代码中重新建立该不变量的位置。如果找不到，这就是问题：被移除的保护、丢弃的错误处理路径、缩小的验证范围，或删除的、原本覆盖真实场景的测试。
   • 调用点。 对每个已更改函数，搜索其调用方，检查是否出现新的前置条件、返回值形态变化、新异常或顺序依赖；然后检查其被调用方。
   • 差异之外。 对每个新模块、保护逻辑或回退逻辑，打开差异未涉及的内容：目录现有的导出项、同级实现，以及所有会写入受保护值的代码。重新实现的辅助函数、归错系统的更改，以及针对无任何代码会产生的状态添加的回退逻辑，看起来都像是干净的代码，除非你去查看差异没有打开的文件。references/context-errors.md 记录了所需的搜索和每个问题所需的证据。

   如果本次会话编写了该差异，代码中未体现的意图由你自己补足。将范围和用户请求原文交给全新的子 Agent，让其执行这些检查，而不是告诉它你对更改内容的概述，然后在步骤 4 中裁定其候选问题。

   可选：如果安装了不同模型的 CLI（codex exec、droid exec 或等效工具），可使用 agents/openai.yaml 中的 default_prompt，以只读方式运行，然后像裁定自己的发现一样裁定其发现。它的意见一致不构成佐证；两个实例读取的是同一份差异，也缺少相同的上下文。

4. 裁定。 每个候选问题都应判定为已确认（能指出触发输入或状态及错误输出，并引用相关行）、可能（机制确实存在，但触发条件不确定；说明如何确认）或已证伪（事实错误或已有保护；引用能证明这一点的行）。默认归为可能：并发竞态、罕见但可达路径上的 nil、把零值误判为缺失、未排除边界上的差一错误，以及失去锚点的正则表达式，都是真实可能发生的问题。只有代码能证明问题不存在时才予以证伪。删除重复项、错误归因，以及任何已修改函数范围之外的既存问题。将 references/test-gate.md 中的问题归入同样的两个层级，不要单独设一节。

5. 报告或应用。 按 Output 的要求报告，并将结构性阻碍列入 Must fix before push，标记可能的问题。若处于应用模式，则继续执行下文。

应用

按根本原因合并发现。先修正正确性问题，再修复所有权问题，最后简化剩余部分。除已确认的发现外，还要从以下五个角度审查差异：

角度	问题	支持修改的证据
复用	这段代码是否有必要存在，还是仓库中的辅助工具、标准库、平台功能或已安装的依赖已经涵盖了它？	现有契约及调用位置，包括它处理的边界情况
质量	这是否增加了第二个状态所有者、未使用的扩展点或不必要的兼容性？	实际使用方和状态所有权，而非代码行数
效率	这是否会在实际的热路径上增加重复工作？	调用频率、重复读取、无界保留
所有权	调用方的补丁是否在弥补共享机制的问题，或被放在了拥有此行为的子系统之外？	写入方、调用方和相邻实现；更深层的修复必须比特例更小
测试价值	测试失败时，是否能指出值得采取行动的原因？	有明确名称的回归问题、可达分支或公开契约；逐字镜像差异和模拟回声都没有价值

约束：

• 删除防护措施必须有系统证据。 移除回退、重试、锁或验证之前，先确定写入方、可达状态、允许的陈旧程度和恢复责任方。如果无法排除其状态，保留它并报告不确定性。
• 不得回滚与改动无关的整个文件。 限定格式化工具的作用范围；git restore <path> 会丢弃用户在同一文件中此前所做的修改。
• 不设抽象配额。 行数更少不代表更好，尤其是在它掩盖不同生命周期或丢失行为时。现有的所属子系统优先于偏好的通用模式。
• 测试应与风险相称。 当编辑会改变可能独立回归的行为时，添加或更新回归检查；对于文案、字面配置变更，或其他地方已覆盖的框架行为，则无需添加。
• 已确认的测试门禁问题必须删除或改写。 新增或修改的测试若在 references/test-gate.md 中达到已确认等级，就不能保留在差异中；应将其删除，或在门禁指定的边界上改写。合理但未确认的门禁问题应予以报告，不要自动删除。
• 以证据为准，及时停止。 受影响的检查通过后，只针对新改动或尚未解决的疑虑重复检查。如果第二轮仍不断在同一位置添加防护措施，说明问题出在机制本身，而非防护措施：应将更简单的方案交给系统负责人。

运行受改动影响的检查和仓库要求的门禁，保留退出码并区分基线失败，然后撰写「报告」或「应用」中所述的摘要。

高信号标准

凡是符合以下任一条件的内容都应报告，并由判定步骤决定；不要按置信度预先筛选，否则过滤会运行两次，第二轮就看不到第一轮丢弃的内容。

• 编译、类型、导入或语法错误；调用已安装的依赖版本未导出的符号（检查 node_modules/<pkg> 或锁文件所对应版本的文档）。
• 捕获到错误却将其丢弃：空的 catch；记录日志后却继续走成功路径的 catch；或对失败会改变调用方应采取行为的 Promise 使用 .catch(() => {})。
• 具体的漏洞利用路径，包含漏洞类别和受影响的 file:line。
• 缺少必要测试：对交互行为只做渲染检查，或修复 Bug 却没有在失败接缝处提供失败复现测试。
• 脚手架的使用方不存在或不可达，需列明搜索结果为空，并在使用方可能由生成流程创建、按约定访问或位于此代码库之外时标记为可能问题。搜索结果为空并不能证明问题不存在：动态导入、文件名约定、生成代码和其他代码库都可能访问任何静态搜索都找不到的代码。
• 防护、回退、重试或新鲜度机制覆盖了部署环境中永远不会出现的状态；仅在列明写入方集合、调用方的容错能力或重启策略时报告。
• 相对于基线新增的 lint、类型检查或测试失败。
• 违反作用域内指令文件或 REVIEW.md，并引用相关规则。
• 重试写入或至少一次写入却没有幂等键；数据库提交加外部发布却没有 outbox；未验证原始字节上的签名就信任 webhook；用浮点数表示金额；将时间戳存为非结构化字符串；多步骤流程包含不可逆操作却没有补偿路径；敏感变更没有审计记录。

所有模式（包括 Standard）都会触发结构性检查：修复放在了不该放的层级（在服务所有调用方的代码中，针对单个调用方添加特殊情况；或在单个调用点添加防护，而被调用方本可以为所有调用方返回正确形态）；没有当前需求支撑的推测性抽象；文件超过约 1000 行，且新增行为有明确的局部边界（配置了 max-lines 时以其为准）；在共享路径中添加特定于功能的条件分支；编写重复规范工具或重新实现标准库的专用辅助函数；为已安装的功能添加新依赖；逻辑位于错误的层级。references/structural-quality-rubric.md 对每项结构性检查作了更深入的说明，适用于 Structural 模式。

不要报告风格偏好、无关的既有问题、没有复现或利用路径的风险、超出差异预期的大规模重写、仅由 linter 触发的噪声，或已明确静默处理的违规。

输出

每条发现都必须包含 file:line、一行影响说明，以及可直接提交的修复方案。可能的问题需添加 Plausible: <可用于确认的信息>。依赖差异之外内容的发现需添加 Context:，注明相关制品。无法直接实施的 Fix:（例如“考虑重构”）不合格；请写明要做出的改动。长度由发现数量决定：没有问题的差异应输出两次 None.，并附上就绪状态区块。

## Local review

### Must fix before push
- [<severity>] `path/to/file.ts:line` <short factual title>
  Why: <concrete impact>
  Fix: <committable fix>

### Should fix soon
- [<severity>] `path/to/file.ts:line` <short factual title>
  Why: <concrete impact>
  Fix: <committable fix>
  Plausible: <what would confirm it>

### Ready for handoff
- Reviewed: <range or ref pair>, <N> files
- Baseline: `<command>` -> <last line>
- Mode: <selected mode>
- Reference evidence: `<path opened>` -> "<short excerpt>"
- Missing reference coverage: <failed reads, or None>
- Unstated changes: <hunks no claim covers, or None>
- <readiness verdict>

通过 pr-babysitter 或 gh 发布 PR 交接时，请在 ## PR handoff summary 下采用相同的发现格式，并在 minor 项目前加上 Nit:。在 apply 模式下，报告后还应说明已应用的改动、未处理的内容及原因，以及检查结果。

注意事项

• 在新建分支上，git diff @{u} 会报错“未配置上游”；而在过时的检出版本上与 main 比较差异，则会包含其他人的提交。请与 git merge-base HEAD origin/<default> 比较，并说明比较范围。
• 根据 git diff 块头计算出的行号会因块偏移而出错。请从 grep -n 或文件中获取行号；审查者若找不到引用的行，就会忽略报告的其余内容。
• 跳过基线检查会让已有故障看起来像回归问题，而每轮都运行完整的 pnpm test 会重复输出数百行内容。请运行静默形式，并引用最后一行。
• 同一个故障辅助函数在每个调用点各报告一次，会被当成三个问题并收到三次修复，而辅助函数本身仍然有问题。请只报告一次，并在其下列出调用点。
• REVIEW.md 中的 @path 行对 Claude Code Review 来说只是原样文本，它不会在此处展开导入。请以相同方式阅读该文件，否则两份报告会互相矛盾，作者也不会信任任何一份。

相关技能

• pr-creator：审查后创建或更新 PR；提交和创建 PR 都由它负责。
• pr-babysitter：监控 CI 和收到的审查评论，并发布 PR 交接格式。
• ui-design 审计模式：检查 UI 层面的粗糙之处、布局和渲染质量；此处的 Deslop 模式仅涵盖代码层面的粗糙之处。
• test-audit：在整个代码库范围内精简测试套件，以达到经过衡量的覆盖率目标。此技能只针对差异新增或修改的测试进行门控；“精简测试套件”或“削减 20% 的测试”则应转到该技能处理。

仅用于维护：evals/evals.json 存放回归场景和路由提示词，供修改此技能的人员使用；用户任务期间不会加载它。