mcpField
C
code-review

code-review

github.com/buyoung测试与质量2146 次安装4 天前更新
代码仓库

关于 code-review

code-review 是用于审查代码变更的工作流,不修改文件,也不发布外部评审。它引导评审者确认范围、追踪行为、检查相关风险,并报告已确认的问题及审查限制。

主要功能

  1. 01确认审查目标与版本
  2. 02沿调用方追踪变更行为
  3. 03按变更选择实际检查项
  4. 04对照基线验证疑似问题
  5. 05报告发现与审查限制

适用场景

  1. 01审查暂存区或工作区变更
  2. 02检查指定提交或提交范围
  3. 03合并前评估缺陷与风险

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/buyoung/skills --skill code-review

安装后在 Claude Code 中输入/code-review确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

evals/
build_fixtures.py
evals.json
README.md
verify_git_examples.py
evals/results/
benchmark.json
README.md
review.html
evals/results/compatibility/old_skill/
grading.json
review.md
transcript.md
evals/results/compatibility/with_skill/
grading.json
review.md
transcript.md
evals/results/historical/old_skill/
grading.json
review.md
transcript.md
evals/results/historical/with_skill/
grading.json
review.md
transcript.md
evals/results/mixed/old_skill/
grading.json
review.md
transcript.md
evals/results/mixed/with_skill/
grading.json
review.md
transcript.md
references/
git_operations.md
impact_detection.md
output_format.md
review_checks.md

详细介绍

代码审查工作流

审查更改,但不要修改代码或发布外部审查。使用用户的语言回复。目标明确时,可立即开始审查;只有当歧义会实质影响范围或意图时才提问。

1. 确定目标和版本

获取差异前,请先阅读 Git 操作。记录请求的范围、已解析的提交 ID 或索引/工作树状态、比较基准,以及任何路径限制。

  • 未指定目标:包含已暂存、未暂存和未跟踪的更改。如果没有更改,询问要审查什么;不要改为审查 HEAD。
  • 明确要求审查已暂存内容:使用索引中的内容检查更改及其上下文调用方,包括未更改的文件。
  • 提交或范围:使用所选修订版检查上下文和使用方,绝不以当前工作树文件作为该修订版行为的证据。
  • 文件路径会将审查发现限制在这些路径内;为了解上下文,可检查边界外的必要使用方,并说明此边界。
  • 区分端点比较、合并基点比较和旧式包含式 start~end 表示法。不要为了让命令成功而擅自更改基准。

检查状态,确认是否存在未解决的冲突,并明确处理根提交和合并提交。保留用户的索引和工作树。

2. 梳理更改并说明预期行为

阅读所选版本中的需求、相关契约以及更改前后的代码。明确哪些输入应产生哪些可观察结果。提交说明可供参考,但不能证明正确性。

逐个跟踪更改文件,并标记为已审查、经说明原因后进行机械检查,或未审查。根据行为影响确定优先级,不要仅按文件数量抽样检查源代码。根据生成产物、锁文件、供应商代码和打包文件的实际部署或依赖影响进行检查;文件名不能证明其内容无关紧要。必要时同时检查生成器和输出。如果无法完成审查,请说明跳过的部分。

3. 沿使用方追踪行为

阅读影响检测。沿调用方 → 中间层/共享抽象 → 最终使用方追踪。检查参数、默认值、配置、返回值、错误和取消信号在转换和优先级规则中的传递情况。确认更改的值确实会影响运行时行为。

在可行时,检查公开导出、适配器、序列化数据、动态注册和外部使用方。搜索结果只能用于定位候选路径;得出结论前应检查这些路径。审查历史版本或索引内容时,请使用版本感知搜索或隔离快照。

4. 执行相关的实用检查

阅读审查检查项,并选择适用于本次更改范围的检查。视情况检查边界条件、授权、状态转换、并发、资源生命周期、重试/幂等性、兼容性、成本和测试断言。报告中不必将参考内容变成强制检查清单。

单独评估可维护性:指出当前存在的复杂性、重复策略或耦合,并说明局部改进能带来的具体好处。默认排除个人风格偏好和推测性的抽象。

5. 验证每一项疑似缺陷

报告前,确认存在可触发条件、执行路径、预期行为与实际行为、代码证据和影响。寻找反证:调用方校验、兼容层、明确的需求、清理/回退逻辑或运行时保证。

与基准版本比较:省略此次更改未引入或未加重的既有问题。即使多个文件或使用方都暴露了问题,也应合并根因相同的报告。静态证据无需实际复现也可以证实缺陷;请说明所依据的证据类型。如果缺失的信息可能推翻该结论,请在限制条件下提出待验证问题,而不要将其作为已确认的缺陷。

6. 分类并报告

阅读输出格式。根据实际影响和触发条件确定缺陷严重程度:严重安全、数据或可用性后果属于严重;导致实质性错误行为属于主要;影响有限且较低的缺陷属于次要。将不确定性单独说明;不要计算置信度分数,也不要因为缺少测试或使用者众多而提高严重程度。

默认顺序:目标、按重要性排序的缺陷、可维护性观察、验证和局限性。明确说明是否未发现已确认的缺陷。省略空的可选部分和礼节性赞扬。只有在用户要求给出结论时,才应用输出参考中的定性决策规则;绝不使用发现数量或加权分数。

工具和边界

使用 Git 和可用的代码库导航工具;在适用且可用时优先使用 codemap-search。搜索相关路径和文件类型。当前工作树的导航索引不能作为历史内容或暂存内容的证据;应使用 Git blob/搜索,或隔离的匹配快照。经授权且相关时,使用现有验证命令;报告准确的命令、执行位置和结果。仅提出审查请求并不代表授权修改源代码、新增测试或对外发布。

归档的字面示例

这些保留的代码块是历史示例,不是要执行的步骤。请使用当前工作流程。单提交 show 示例需要按上述方式处理根提交/合并提交;闭区间范围命令需要有效的父提交。合并基准命令仅适用于明确要求的共同祖先比较,绝不可作为备用方案。工作树 rg 示例不得提供历史或索引上下文。

git --no-pager show --stat <commit_hash>
# or for staged changes:
git --no-pager diff --cached --stat
# Single commit
git --no-pager show <commit_hash>

# Staged changes
git --no-pager diff --cached

# Commit range
git --no-pager diff <start_hash>^..<end_hash>

# File-scoped
git --no-pager show <commit_hash> -- <file_path>
# Find direct callers
rg -F "symbolName(" .
# Find broader references
rg "symbolName" .

评论

支持 Markdown