Back to Details

code-review-and-quality

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Code Review and Quality

代码审查与质量

Use this skill when

适用场景

Use this Skill before merging, handing off, or declaring a meaningful change complete. It is for reviewing a diff and its evidence, not for rewriting the task into a new project.
在合并、交接或宣告重要变更完成前使用本Skill。它用于审查diff及其相关证据，而非将任务重构成新项目。

Review order

审查顺序

  1. Confirm the requested behavior and non-goals.
  2. Check correctness and important edge cases.
  3. Check dependency direction and meaningful boundaries.
  4. Check error handling, state transitions, and compatibility.
  5. Check whether tests protect behavior rather than implementation details.
  6. Check maintainability and whether abstractions are purposeful.
  7. Check the verification evidence and remaining uncertainty.
  8. Report findings by severity with file and behavior context.
  1. 确认需求行为与非目标。
  2. 检查正确性及重要边缘情况。
  3. 检查依赖方向与合理边界。
  4. 检查错误处理、状态转换与兼容性。
  5. 检查测试是否针对行为而非实现细节提供保护。
  6. 检查可维护性及抽象是否具有明确目的。
  7. 检查验证证据及剩余不确定性。
  8. 按严重程度报告发现，并附上文件及行为上下文。

MUST

必须执行

  • Review the actual diff and relevant surrounding code.
  • Distinguish blocking defects from suggestions.
  • Explain why each finding matters.
  • Verify claims with tests, reproduction, or direct evidence.
  • Check that the change stays within scope.
  • 审查实际diff及相关周边代码。
  • 区分阻塞性缺陷与建议。
  • 解释每项发现的重要性。
  • 通过测试、复现或直接证据验证相关声明。
  • 检查变更是否在范围内。

SHOULD

建议执行

  • Review high-risk paths before stylistic details.
  • Look for missing regression tests.
  • Check public contracts and boundary ownership.
  • Prefer a small actionable finding over a speculative redesign.
  • State what was checked and what was not.
  • 在审查风格细节前先检查高风险路径。
  • 查找缺失的回归测试。
  • 检查公共契约与边界归属。
  • 优先提出具体可执行的发现，而非推测性的重新设计。
  • 说明已检查内容与未检查内容。

Do not

禁止操作

  • approve because tests are green without checking behavior;
  • reject a change only because it differs from personal taste;
  • request an interface or pattern without a concrete benefit;
  • mix unrelated cleanup into a required fix;
  • claim security or performance properties that were not evaluated.
Read review-rubric.md for finding quality and verification.md for evidence.
  • 仅因测试通过而不检查行为就批准变更；
  • 仅因不符合个人偏好就拒绝变更；
  • 在无具体收益的情况下要求采用特定接口或模式；
  • 在必要修复中混入无关的清理工作；
  • 声称未经过评估的安全性或性能特性。
阅读review-rubric.md了解发现质量相关内容，阅读verification.md了解证据相关内容。

Routing

路由指引

Route architecture findings to architecture-boundaries or ddd-lite. Route missing behavior tests to test-driven-development. Route an observed defect to systematic-debugging. Route merge and release concerns to git-workflow-and-versioning and ci-cd-and-automation.
将架构相关发现转至architecture-boundaries或ddd-lite。将缺失行为测试的问题转至test-driven-development。将已发现的缺陷转至systematic-debugging。将合并与发布相关问题转至git-workflow-and-versioning及ci-cd-and-automation。

Verification

验证标准

A review is complete when each finding has a severity, location, impact, recommendation, and evidence; the final summary states residual risk and checks performed.
当每项发现都包含严重程度、位置、影响、建议及证据，且最终总结说明了剩余风险与已执行的检查时，审查即完成。