Code reviewer

Skill findscripter/everything-skills/02-engineering/code-reviewer

类书式 AI Agent 技能大典 · 精选/中文化/互见成网的 500+ 开源技能，可作为 Claude Code 插件市场一键安装。A curated, cross-referenced encyclopedia of 500+ open-source agent skills.

Install

npx -y skills add findscripter/everything-skills --skill code-reviewer

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

当需要审查代码改动找正确性 bug、复用/简化机会与可读性问题、给出可执行修改建议时使用；触发词：代码审查、review、找 bug、重构建议、code review。

The file declares its own license as CC-BY-SA-4.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

5.0 KB, as published. Nobody here has run it

何时使用

有明确代码改动（diff、PR、补丁、粘贴的代码片段）需要审查时使用。
目标是找：正确性 bug（逻辑、边界、并发、错误处理、空值）、复用/简化机会、可读性问题，并给出可落地的修改建议。
触发词：代码审查、review、找 bug、重构建议、code review。

不该用的边界：

纯依赖/许可证/CVE 体检 → 用 dependency-auditor。
没有具体改动、只是问"怎么写"或要从零生成代码 → 不属于审查，直接写代码。
跑测试、构建、性能压测、部署验证 → 本技能只做静态审阅，不执行代码。
大段无关旧代码：只审查改动及其直接影响面，不重写整个文件。

步骤 / 指令

1. 取改动范围
   - 优先 git diff（未提交：`git diff`；已提交：`git diff <base>...<head>` 或 `git show <sha>`）。
   - 无 git 时，仅审查用户提供的片段，并读其上下文（被改函数、调用方、相关类型定义）。

2. 建立上下文（仅读必要文件）
   - 读被改函数/方法的完整体，而非只看 diff 行。
   - 读改动涉及的接口/类型、关键调用方，确认契约未被破坏。

3. 按维度逐项扫描（按优先级）
   a. 正确性：逻辑错误、off-by-one、边界/空集合、null/undefined、类型不符、
      错误的运算符/比较、异常未处理或吞掉、资源未释放、并发/竞态、
      用户输入未校验、回退分支缺失、注释与实现不一致。
   b. 复用/简化：重复逻辑可抽取、已有工具函数未用、可删的死代码、
      过度抽象或可内联、复杂条件可化简。
   c. 可读性：命名、魔法值、函数过长/嵌套过深、缺失关键注释（仅 why 类）。

4. 每条发现给出结构化条目：
   - [严重度] 文件:行号 — 问题一句话
   - 原因：为什么是问题（触发条件/后果）
   - 建议：可直接采用的修改（给出替换代码或精确改法）

5. 严重度分级
   - Blocker：会导致错误结果/崩溃/数据损坏/安全问题，必须改。
   - Major：边界/隐患/明显坏味道，建议改。
   - Minor：可读性/风格，可选。

6. 汇总输出
   - 先列 Blocker 与 Major，再列 Minor。
   - 无问题则明确说"未发现正确性问题"，不要编造。
   - 不确定的发现标注"待确认"并说明假设，不冒充事实。

规则：

单一职责：只审查，不顺手提交、不擅自改文件（除非用户要求 --fix 类操作）。
每条发现必须可定位（文件:行号）且可执行（带具体改法）。
优先 Blocker/Major；Minor 适度，避免噪声淹没要点。
不评论用户未改动的代码，除非改动直接破坏了它。

示例

最小审查提示词：

审查以下 diff，按 正确性 / 复用简化 / 可读性 三类输出。
每条：[严重度] 文件:行号 — 问题；原因；可执行建议（给替换代码）。
先 Blocker/Major 后 Minor；无正确性问题请明说，勿编造。
<贴入 git diff 内容>

取改动：

git diff                      # 未提交改动
git diff main...HEAD          # 分支相对 main 的改动
git show <sha>                # 某次提交

输出条目样例：

[Blocker] src/auth.py:42 — `if token == None` 用 == 比较 None
原因：自定义对象可能重载 __eq__，导致误判；空 token 会绕过校验。
建议：改为 `if token is None:`

[Major] src/list.js:88 — 循环内重复调用 fetchUser(id)，N+1 请求
原因：每次迭代发一次网络请求，列表大时显著变慢。
建议：循环前批量 `fetchUsers(ids)`，再用 Map 取值。

[Minor] src/list.js:12 — 变量 `d` 含义不明
建议：重命名为 `deadline`。

注意事项

不执行/不测试代码：只做静态推理；需要跑起来验证行为时，交给执行类技能或提示用户。
不臆造行号与文件名；定位以实际 diff/文件为准。
区分"确定 bug"与"风格偏好"，别把主观风格标成 Blocker。
安全相关（注入、鉴权、密钥硬编码、反序列化）一律按 Blocker 处理并显式指出。
改动很大时分批审，先核心逻辑文件，避免一次性产出过长且失焦。
给建议要可直接采用：提供替换代码或精确改法，不要只说"建议优化"。

互见

requires：无。
related：dependency-auditor（依赖/许可证/已知漏洞专项体检；本技能聚焦改动代码本身的正确性与质量，依赖层面的风险转交它）。
combines_with：无。