SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场code-review-mastery

code-review-mastery

编程与开发

查看项目

更新于 10-26 16:19

技能介绍

用途

code-review-mastery 用于审查本地 Git 变更，包括已暂存（staged）和未暂存（unstaged）的 diff，适合在提交或推送前做一次质量检查。当用户提出“review my diff”“check my code”“code review before commit”“what's wrong with my changes”“anything I should fix before committing”等请求时触发。

该技能不适用于以下场景：审查远程 PR 或 GitHub 链接（应使用 PR 审查工具）；从零编写或重构代码；与具体变更无关的架构讨论；没有具体 diff 的一般性代码质量建议。

主要能力

  • 项目感知分析：读取项目根目录的 CLAUDE.md、AGENT.md、README.md，读取相关 lint 与格式配置（ESLint、Prettier、Ruff、tsconfig 等），并扫描变更文件同目录下的 2-3 个既有文件以识别命名、导入和错误处理约定。
  • 两级严重度：每个发现只标记为 [MAJOR]（必须修复，会阻塞专业代码审查中的 PR）或 [MINOR]（可改进但代码本身可用）。判断标准是“资深工程师是否会因此阻塞 PR”。存疑时降级为 [MINOR]。
  • 多轮分析：按安全、正确性、性能、设计、可读性、约定、测试等维度逐项检查，优先级为 安全 > 正确性 > 性能 > 设计 > 可读性 > 约定。
  • 结构化输出：按指定格式输出审查结果，[MAJOR] 在前、[MINOR] 在后，组内按文件路径与行号排序，每条为复选框形式，包含 file:line、分类标签、一句话描述与一句话建议。
  • 交互式修复：输出后询问用户是否修复，可指定条目或选择“fix all MAJOR”“fix all”。

使用方式

技能激活后，首次响应以 🧢 emoji 开头。审查按四个阶段依次进行：

  1. DETECT：运行 git diff --stat（未暂存）和 git diff --cached --stat（已暂存）确定变更范围。若两者都有变更，询问用户审查哪一组（或“both”）；若都没有，提示“No local changes to review.”并停止。从文件扩展名识别语言，统计文件数、新增与删除行数。若 diff 超过 500 行，警告用户并建议只关注 [MAJOR]。
  2. CONTEXT：收集项目上下文以校准审查，读取 CLAUDE.md、AGENT.md、README.md 及相关 lint/格式配置，抽样同目录既有文件，记录框架与语言。上下文仅用于内部校准，不输出给用户。
  3. ANALYZE：用 git diff 或 git diff --cached 获取完整 diff；超过 500 行时用 git diff -- <file> 逐文件处理。按安全、正确性、性能、设计、可读性、约定、测试等轮次分析，为每个发现分类 [MAJOR]/[MINOR]、标注类别与文件行号。
  4. REPORT：按输出格式规范呈现审查结果，并询问是否修复。

输出格式示例结构：

## Code Review: [staged|unstaged] changes

**Files changed**: N | **Insertions**: +X | **Deletions**: -Y

### [MAJOR] Issues (N)

- [ ] **file.ts:42** [Security] Description of the issue.
  Suggested fix or approach.

### [MINOR] Suggestions (N)

- [ ] **file.ts:15** [Readability] Description of the suggestion.
  Suggested improvement.

### Summary
N major issues to resolve, M minor suggestions to consider.
Would you like me to fix any of these? Tell me which items or say "fix all MAJOR" / "fix all".

若无 [MAJOR] 发现，明确说明“No major issues found.”；若完全无发现，说明“No issues found. Code looks good to commit.”。始终以修复询问结尾。

适用场景

  • 提交或推送前对本地改动做质量检查。
  • 用户想了解“我的改动有什么问题”或“提交前有什么需要修复”。
  • 对已暂存或未暂存 diff 做项目约定一致性检查。

限制与注意事项

  • 只审查 diff 中出现的行，不审查 diff 之外的文件，避免范围蔓延。
  • 不报告 linter 已能捕获的问题（若项目已配置 ESLint、Prettier、Ruff 且 CI 运行）。
  • 避免严重度膨胀：只有 bug、安全问题、明确规则违反、缺失测试才标 [MAJOR]。
  • 判断前必须收集上下文，避免把项目既有模式误判为问题。
  • 大 diff（>500 行）应警告用户并聚焦 [MAJOR]，可另行提供 [MINOR] 第二轮。
  • 二进制文件跳过并注明；生成/锁文件（package-lock.json、yarn.lock、pnpm-lock.yaml、.min.js、.generated.* 等）跳过并注明。
  • 混合暂存/未暂存时询问用户选择；合并冲突标记标为 [MAJOR] 并建议先解决；仅有删除时检查悬空引用、断裂导入、孤立测试等清理问题。
  • 参考文件：references/review-checklist.md（完整分类检查清单）、references/context-detection.md（项目上下文收集指南）。
  • 首次激活时检查配套技能是否安装：运行 ls ~/.claude/skills/ ~/.agent/skills/ ~/.agents/skills/ .claude/skills/ .agent/skills/ .agents/skills/ 2>/dev/null，与 frontmatter 中 recommended_skills 对比，缺失时提示一次并提供安装命令：npx skills add AbsolutelySkilled/AbsolutelySkilled --skill <name>。若 recommended_skills 为空或全部已安装则跳过。