code-review

代码审查

用于审查和提升代码质量的一项技能。根据意图选择一种模式（或传入显式的 mode: 参数）；每种模式都是 references/ 中一个完整、独立的工作流。只加载所需的 模式，以节省 Agent 的上下文预算。

模式

模式	用户希望……时使用	读取 / 写入	输出	工作流
review（默认）	在差异或 PR 中查找 Bug、安全漏洞和质量问题	只读	按优先级排列的问题报告	references/review-mode.md
perf	提升代码速度——查找瓶颈、泄漏和算法浪费	只读	性能问题报告	references/perf-mode.md
clean	根据 bbv Clean Code 速查表审查可读性和规范	只读	CLEAN_CODE_AUDIT.md	references/clean-mode.md
cleanup	实际重构，清除 AI 赘余、死代码、重复代码和冗余内容	写入代码	修改后的源文件	references/cleanup-mode.md

选择模式

1. 显式指定优先。 如果请求包含 mode:review|perf|clean|cleanup（或 --mode <name>），就使用指定的模式。
2. 否则根据请求推断。 如果某个匹配短语包含在更长的匹配短语中，则只计算较长的短语；因此，“clean code review” 只算 clean 短语，不同时算作 review 短语。彼此不重叠的短语都算，无论长度如何（见第 3 步）。
   • “review”、“find bugs”、“security”、“is this correct”、“look for vulnerabilities” → review
   • “slow”、“faster”、“optimize”、“bottleneck”、“memory leak”、“performance” → perf
   • “clean code audit”（或 “clean-code audit”）、“clean code review”、“check this against clean code” → clean （仅限用户明确提出；单独提出“readability”或“audit against standards”含义不明确：使用第 3 步）
   • “remove slop”、“clean up the codebase”、“refactor out cruft / dead code / duplication” → cleanup
3. 没有匹配项，或匹配到多个模式的短语？ 询问用户要使用哪种模式，并列出四个选项。 例如，“review and optimize”同时匹配 review 和 perf，因此应询问用户。只有当请求包含审查短语、且不包含其他模式的短语时，才无需询问而直接使用 review。

安全：cleanup 会写入代码，其余三种不会

review、perf 和 clean 都是只读源代码：只进行分析和报告，不触碰源文件。Review 和 perf 只能写入各自模式指定的报告文件（review 对应 CODE_REVIEW.md；perf 在响应中返回报告）。分析 review/perf 时，不得以其他方式修改索引、引用、暂存区、分支、工作树或远程状态。 clean 遵循其自身的报告写入和同步约定。cleanup 会修改文件。因此：

• 切勿根据较弱的推断进入 cleanup。 只有用户明确要求重构 / 清理代码库（或传入 mode:cleanup）时才运行。普通的“审查我的代码”请求绝不能改写文件——应保持在只读模式。
• Review 和 perf 分析要记录 git rev-parse HEAD、git status 以及本地跟踪状态的观察结果，但不得声称远程状态是最新的。它们不得执行 fetch、stash、pull、rebase、checkout/switch、创建或删除分支/工作树，也不得应用源代码修复。单独获批的修改工作流负责处理自身的状态更新和先暂存再同步约定。
• 在 cleanup 中首次写入前，必须先确认，并遵循该模式自身的准入条件。

编辑前同步仓库（强制）

仅适用于 clean（写入 CLEAN_CODE_AUDIT.md）和 cleanup（写入源代码）。review 和 perf 不会同步（参见“安全”部分）。在这两种模式下首次写入前：

branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin && git pull --rebase origin "$branch"

• 如果在 clean 模式下工作树有未提交的更改，先暂存，再同步，然后恢复暂存内容。
• 如果在 cleanup 模式下工作树有未提交的更改，停止并请用户先提交或暂存。
• 如果缺少 origin，或拉取或恢复暂存内容时发生冲突，停止并询问用户。不要写入任何文件。
• 如果目标不是 git 仓库，clean 会跳过同步，并在报告中注明。

完整步骤及恢复命令见 references/clean-mode.md 和 references/cleanup-mode.md。

执行所选模式的工作流

阅读所选模式的参考文件，并严格执行其中的步骤。各模式使用的支持文件（已放在此技能目录下）：

• review → references/review-mode.md — Agent：agents/reviewer.md、agents/file-reviewer.md、agents/report-assembler.md；参考文件：references/subagent-architecture.md、references/code-smells.md
• perf → references/perf-mode.md — 参考文件：references/language-checks.md
• clean → references/clean-mode.md — 参考文件：references/clean-code-checklist.md、references/tdd-checklist.md、references/html-report-guide.md、references/report-template.html
• cleanup → references/cleanup-mode.md — agents/ 中的 8 个清理 Agent（deduplicator.md、type-consolidator.md、unused-code-killer.md、circular-dep-untangler.md、weak-type-strengthener.md、defensive-programming-remover.md、legacy-code-remover.md、slop-comment-cleaner.md）

环境检查

如果 Agent 工具可用，使用子 Agent 的模式（review、cleanup）会按各自的工作流启动子 Agent，以进行新上下文验证和并行工作。如果该工具不可用（例如 Claude.ai），则在当前上下文中按阶段执行各模式（严谨性较低，但仍可正常工作）。

串联模式

模式可以组合：常见流程是先运行 clean（审计 → CLEAN_CODE_AUDIT.md），再运行 cleanup（应用重构）；也可以先运行 review/perf 查找问题，再进行修复。一次只运行一种模式；切换到会写入代码的 cleanup 模式前，先向用户确认。

前置条件

• 如果未指定目标差异、PR、文件集或仓库，请先询问范围，再开始。
• 如果所选模式列出的参考文件或 Agent 文件缺失，请停止并指出缺失路径。
• 对于 clean 或 cleanup，请按顺序遵循该模式的同步、备份、试运行、确认和回滚步骤。如果同步或安全检查失败，请在首次写入前停止。

验收标准

根据所选模式自身的验收标准验证每次运行，然后断言满足以下所有路由标准：

• 仅选择了一种模式，并从头到尾遵循了其参考工作流。
• 只读模式未更改任何源文件；在适用时，使用限定路径的 git diff 进行验证。
• 每项发现都引用了具体证据，并且已生成预期的输出产物或报告。
• 所选模式要求的测试或验证命令均已完成，并得到预期结果。
• 已披露边缘情况、限制、跳过的文件以及子 Agent 覆盖范围下降的情况。

另请检查读者能否使用最终回复：

• 结果易于查找：Mode: 后的第一行说明结果，并标注 PASS、PARTIAL 或 FAIL。
• **事实与假设分开：**经过验证的主张注明运行过的检查；推断、跳过的范围和未经测试的行为均标注在 Uncertainty 下。
• **主张可追溯：**每项发现都指向 file:line、命令输出或报告章节。中间步骤通过不代表整个运行通过。
• 下一步决策明确：Decision 写明所需的批准（例如，启动 cleanup），或写明“No approval needed”，并列出任何尚待用户执行的操作。

Agent 检查无法确认人类是否理解了输出。如果没有人类反馈，应报告人类是否理解尚未确认；这不算失败，也不算通过。

预期输出

每种模式的最终回复都应按以下顺序包含这五项内容。每项控制在一至两行；详细内容放在模式的报告产物中。

Mode: review
Result: PARTIAL — 1 critical, 2 major, 0 minor findings; reviewer pass incomplete for 3 files
Evidence: CODE_REVIEW.md written; reviewer agent validated 41/44 files; `git diff --stat -- src/` empty
Uncertainty: 3 generated files skipped (listed in CODE_REVIEW.md); no tests were run
Decision: No approval needed. To apply fixes, ask for a separate `cleanup` run.

步骤完成报告

完成路由和所选工作流后，输出一份简明报告：

◆ Code Review ([mode])
  Mode selection:      √ pass
  Workflow criteria:   √ pass
  Output verified:     √ pass
  Safety boundary:     √ pass
  Result:              PASS | FAIL | PARTIAL

任何未通过的检查都使用 × fail — reason。如果所选模式的验收标准、预期输出、必需测试或安全防护措施仍有未解决项，绝不能报告 PASS。

边缘情况

• 未知的 mode: 值 → 拒绝该值，并列出四种有效模式。
• 不同模式的意图混杂 → 询问要先运行哪种模式；绝不隐式合并工作流。
• 缺少目标或无法访问文件 → 停止并请求明确的范围，而不是猜测。
• Agent 工具不可用 → 使用所选参考流程中的内联备用方案，并披露覆盖范围有所减少。
• 只读模式在运行中请求编辑 → 完成报告，然后要求获得明确批准，再开始单独的 cleanup 运行。