mcpField
C
code-review

code-review

github.com/carvalab测试与质量38 次安装
代码仓库

关于 code-review

面向开发者自查或同伴审查的代码审查 Skill，强调结合上下文追踪问题、修复已验证的问题，并通过针对语言的质量门禁验证更改。

主要功能

  1. 01审查差异与变更文件
  2. 02检查架构、正确性和安全性
  3. 03遵循项目专属规则
  4. 04修复并验证已确认的问题
  5. 05运行 lint、构建和测试门禁
  6. 06生成结构化审查报告

适用场景

  1. 01合并前审查变更
  2. 02自查已完成的功能
  3. 03检查复杂错误修复
  4. 04重构前检查代码

MCP 相关

该 Skill 建议在审查时使用 `kavak-platform/platform_docs_search` MCP 工具核实 Kavak 的实践规范。

安装

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

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

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

包含的文件

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

references/
checklist.md
common-issues-go.md
common-issues.md
feedback-guide.md
logging-metrics-review.md
security-owasp.md
self-review-workflow.md
severity-guide.md

详细介绍

代码审查

对近期变更进行全面的高级代码审查。将人工审查重点放在复杂逻辑、架构和边缘情况上。将风格检查交给自动化工具。

相关技能：

  • kavak-documentation - 查询 Kavak 专属模式、日志/指标标准和 GitLab CI 模板
  • 审查时使用 kavak-platform/platform_docs_search MCP 工具核验 Kavak 最佳实践

快速开始

# 1. Get review range
BASE_SHA=$(git rev-parse HEAD~1)  # or: git merge-base main HEAD
HEAD_SHA=$(git rev-parse HEAD)

# 2. See what changed
git diff --stat $BASE_SHA..$HEAD_SHA
git diff --name-only $BASE_SHA..$HEAD_SHA --diff-filter=ACMR

# 3. After review, run quality gates (detect project type)

各语言的质量门禁命令：

语言Lint构建测试
Gogolangci-lint rungo build ./...go test ./...
Node/TSnpm run lintnpm run buildnpm test
Pythonruff check .python -m py_compilepytest
Java./mvnw checkstyle:check./mvnw compile./mvnw test

何时审查

此工作流适用于自我审查和同行审查。

必须执行： 完成任务后、实现功能后、合并前。

值得执行： 遇到困难时（换个角度思考）、重构前（建立基线）、修复复杂 Bug 后。

审查思路

  • 全面而不仓促 - 得出结论前，先阅读所有相关代码
  • 基于证据 - 跟踪执行路径，不要臆断存在 Bug
  • 修复，而非只指出 - 找出问题并解决
  • 控制范围 - 每次审查少于 400 行，以确保有效性

工作流

1. 确定差异范围

识别所有已更改的文件：

git diff --name-only HEAD~1 --diff-filter=ACMR

对于列表中的每个文件，如果没有实际的差异区块，则跳过。

2. 理解意图和要求

审查代码前，先了解它应实现的功能：

  • 原始任务/问题：提出了什么需求？
  • 产品影响：这能为用户带来什么？
  • 验收标准：什么情况才算“完成”？

请自问：“实现是否满足了需求？”

3. 审查每个文件

针对每个已更改的文件和每个差异区块，结合现有代码库进行评估。

必须执行：指出严重/主要问题前，端到端跟踪完整的执行路径。确认没有防御性代码能够阻止问题发生。考虑错误路径、取消操作和边缘情况。

4. 审查类别

重点关注：架构（是否符合模式、是否避免耦合）、正确性（边缘情况、错误处理）、安全性（输入验证、密钥、OWASP）、性能（N+1 查询、内存）、日志/指标（基数激增）。将风格检查交给 Linter。

包含全部 11 个类别的完整检查清单：references/checklist.md 日志和指标标准：references/logging-metrics-review.md

5. 检查项目规则

必须执行：检查并遵守以下规则：

  • .claude/CLAUDE.md 或 CLAUDE.md（根目录）
  • .cursor/rules/ 文件夹
  • AGENTS.md
  • 遵循其中定义的所有模式和约定
6. 报告并修复问题

对于每个已确认的问题：

  • 文件：<path>:<line-range>
  • 问题：一句话概述
  • 修复：简洁的修改建议

严重级别：

  • 严重（P0）：安全漏洞、数据丢失、崩溃
  • 主要（P1）：重大 Bug、性能问题、架构违规
  • 次要（P2）：代码风格、小幅改进
  • 增强（P3）：锦上添花的改进

必须执行：发现问题后立即修复所有问题。

  1. 从最高优先级开始（严重 → 主要 → 次要）
  2. 对每个问题：
    • 修复代码
    • 验证修复不会造成问题
    • 检查点提交：git add -A && git commit -m "fix: brief description"
  3. 持续处理，直到所有问题均已解决
7. 运行质量门禁

修复所有问题后，按照项目类型运行 lint → 构建 → 测试（参见“快速开始”表格）。

如果任何门禁失败，立即修复并提交修复。

8. 最终报告

提供结构化输出：

### Strengths

[What's well done - be specific with file:line references]

### Issues Found & Fixed

- **Critical**: [count] - [brief list]
- **Major**: [count] - [brief list]
- **Minor**: [count] - [brief list]

### Quality Gates

- Lint: ✓/✗
- Typecheck: ✓/✗
- Build: ✓/✗
- Tests: ✓/✗

### Assessment

**Ready to proceed?** [Yes / Yes with notes / No - needs fixes]
**Reasoning:** [1-2 sentence technical assessment]

如果没有问题：“代码审查已完成。未发现问题。所有质量门禁均已通过。可以继续。”

参考资料

参考资料用途
references/checklist.md详细的审查清单
references/severity-guide.md如何对问题严重程度进行分类
references/common-issues.md常见问题（TypeScript/Node）
references/common-issues-go.md常见问题（Go）
references/security-owasp.mdOWASP Top 10 安全清单
references/feedback-guide.md如何提供有建设性的反馈
references/logging-metrics-review.md日志格式和指标基数标准
references/self-review-workflow.md开发期间的自动化自我审查工作流

最佳实践

  1. 不做假设 - 标记问题前，阅读所有相关代码
  2. 立即修复 - 不要只报告问题，要修复并提交
  3. 检查点提交 - 分别提交每项修复，以便轻松回滚
  4. 先验证 - 追踪执行路径后，再断言存在错误
  5. 优先遵循项目规则 - 始终检查 .cursor/rules/ 和 AGENTS.md
  6. 及时处理 - 尽快审查，避免阻塞队友
  7. 限制范围 - 每次审查少于 400 行，以提高效率

原则：审查 → 修复 → 验证 → 提交。只发现问题而不修复的审查是不完整的。

评论

支持 Markdown