agentleFS
WenWuZhiDaoWenWuZhiDao/mattpocock-skills-zh/skills/engineering/code-review/SKILL.md

code-review

Skill27 starsChanged 3 months agoMITView on GitHub

审查自某个固定基点(commit、分支、tag 或 merge-base)以来的改动,沿两条轴进行——标准(代码是否遵循本仓库记录的编码规范?)和规格(代码是否符合源头工单/规格的要求?)。两项审查在并行子 agent 中运行,并把结果并排报告。当用户想审查一个分支、一个 PR、进行中的改动,或要求「审查自 X 以来」时使用。

We split this skill into the rules it gives an agent

1 rule. 0 are common, 0 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 183 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    commit 消息中的工单引用(#123、Closes #45、GitLab !67 等)——通过 docs/agents/issue-tracker.md 中的工作流获取。

    line 29

“Common” is measured: kept by at least 6 in 10 of the 183 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

对 HEAD 与用户提供的某个固定基点之间的 diff 做双轴审查:

  • 标准 — 代码是否符合本仓库记录的编码规范?
  • 规格 — 代码是否忠实地实现了源头工单/规格?

两条轴都作为并行子 agent运行,这样它们不会污染彼此的上下文,然后本技能汇总它们的发现。

工单跟踪器应当已经提供给你——如果 docs/agents/issue-tracker.md 缺失,运行 /setup-matt-pocock-skills。

流程

1. 钉住固定基点

用户说的就是固定基点——一个 commit SHA、分支名、tag、main、HEAD~5 等等。如果他们没指定,就问。

把 diff 命令记下来一次:git diff <fixed-point>...HEAD(三点,这样比较是针对 merge-base)。同时通过 git log <fixed-point>..HEAD --oneline 记下 commit 列表。

在继续之前,确认固定基点能解析(git rev-parse <fixed-point>)且 diff 非空。坏的 ref 或空 diff 应该在这里失败——而不是在两个并行子 agent 内部失败。

2. 确定规格来源

按以下顺序寻找源头规格:

  1. commit 消息中的工单引用(#123、Closes #45、GitLab !67 等)——通过 docs/agents/issue-tracker.md 中的工作流获取。
  2. 用户作为参数传入的路径。
  3. docs/、specs/ 或 .scratch/ 下与分支名或功能匹配的规格文件。
  4. 如果什么都找不到,就问用户规格在哪里。如果他们说没有规格,规格子 agent 将跳过并报告「无可用规格」。

3. 确定标准来源

仓库里任何记录了代码应当如何编写的东西,比如 CODING_STANDARDS.md 或 CONTRIBUTING.md。

除了仓库记录的东西之外,标准轴始终携带下面这套坏味道基线——一组固定的 Fowler 代码坏味道(《重构》,第 3 章),即便一个仓库什么都没记录也适用。有两条规则约束它:

  • 仓库优先。 有记录的仓库标准始终胜出;当它认可某件基线本会标记的东西时,压制那条坏味道。
  • 始终是判断题。 每条坏味道都是一个带标签的启发式(「可能存在 Feature Envy」),从不是硬性违规——而且,和这里任何标准一样,跳过工具链已经强制执行的东西。

每条坏味道读作它是什么 → 如何修;把它对照 diff 来匹配:

  • Mysterious Name(神秘命名) — 一个函数、变量或类型的名字没有揭示它做什么或持有什么。→ 重命名它;如果找不到诚实的名字,说明设计本身就模糊。
  • Duplicated Code(重复代码) — 同样形状的逻辑出现在这次改动的多个 hunk 或文件中。→ 提取共享的形状,从两处调用它。
  • Feature Envy(依恋情结) — 一个方法访问另一个对象的数据多于访问自己的。→ 把该方法移到它所依恋的数据上。
  • Data Clumps(数据泥团) — 同样几个字段或参数总是一起出现(一个想要诞生的类型)。→ 把它们捆进一个类型,传那个。
  • Primitive Obsession(基本类型偏执) — 一个基本类型或字符串在替代一个理应拥有自己类型的领域概念。→ 给这个概念它自己的小类型。
  • Repeated Switches(重复的 switch) — 同样的 switch/if 级联针对同一类型在这次改动中反复出现。→ 用多态替换,或用两处共享的一个映射表。
  • Shotgun Surgery(霰弹式修改) — 一个逻辑改动逼得你在 diff 中的许多文件里做零散的编辑。→ 把一起变化的东西聚拢进一个模块。
  • Divergent Change(发散式变化) — 一个文件或模块因几个不相关的原因被编辑。→ 拆分,使每个模块只因一个原因而变化。
  • Speculative Generality(夸夸其谈的通用性) — 为规格并不具备的需求添加的抽象、参数或钩子。→ 删掉它;内联回去,直到真实需求出现。
  • Message Chains(过长的消息链) — 调用方不该依赖的长串 a.b().c().d() 导航。→ 把这段游走藏在第一个对象上的一个方法后面。
  • Middle Man(中间人) — 一个大多只是向下转发的类或函数。→ 砍掉它,直接调用真正的目标。
  • Refused Bequest(被拒绝的遗赠) — 一个子类或实现者忽略或覆盖了它继承来的大部分东西。→ 放弃继承,改用组合。

4. 并行派发两个子 agent

标准子 agent 提示词 — 需包含:

  • 完整的 diff 命令和 commit 列表。
  • 你在第 3 步找到的标准来源文件列表,外加第 3 步的坏味道基线全文粘贴进去——子 agent 没有其他途径获取它。
  • 简报:「逐文件/hunk(在相关处)报告——(a) diff 违反某条记录标准的每一处:引用该标准(文件 + 规则);(b) 你发现的任何基线坏味道:命名它并引用该 hunk。区分硬性违规和判断题——记录标准的违反可以是硬性的,但基线坏味道始终是判断题,而且有记录的仓库标准覆盖基线。跳过工具链强制执行的东西。400 字以内。」

规格子 agent 提示词 — 需包含:

  • diff 命令和 commit 列表。
  • 规格的路径或获取到的内容。
  • 简报:「报告:(a) 规格要求但缺失或部分实现的需求;(b) diff 中没有被要求的行为(范围蔓延);(c) 看似已实现但实现看起来有误的需求。为每个发现引用规格中的那一行。400 字以内。」

如果规格缺失,跳过规格子 agent,并在最终报告中注明这一点。

5. 汇总

把两份报告放在 ## Standards 和 ## Spec 标题下呈现,逐字或稍作清理。不要合并或重新排序发现——两条轴是有意分开的(见「为什么分两条轴」)。

以一行摘要收尾:每条轴的发现总数,以及每条轴内最严重的问题(若有)。不要跨轴挑出一个单一的赢家——那正是这种分离所要防止的重新排序。

为什么分两条轴

一个改动可以通过一条轴而在另一条上失败:

  • 遵循每条标准但实现了错误的东西的代码 → 标准通过,规格失败。
  • 完全按工单要求去做但破坏了项目约定的代码 → 规格通过,标准失败。

分开报告它们,可以阻止一条轴掩盖另一条。

Download now (ZIP)

  • Other versions193 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 193

    1. mattpocock/skills★ 309ksame name
    2. TheAlgorithms/Python★ 226ksame name
    3. microsoft/vscode★ 194ksame name
    4. github/spec-kit★ 145ksame name
    5. ggml-org/llama.cpp★ 133ksame name
    6. shareAI-lab/analysis_claude_code★ 80ksame name
    7. shareAI-lab/learn-claude-code★ 80ksame name
    8. vectorize-io/hindsight★ 57ksame name
    9. dbeaver/dbeaver★ 52ksame name
    10. roboflow/supervision★ 51ksame name

    183 more not listed

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • Used alongsideProjects with it also use add-new-model, azsdk-common-sdk-breaking-change and 9 more.

    Other files people use alongside this one.

    Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
    • PydanticSkill

      add-new-model

      Add support for a newly-released language or image generation model in pydantic-ai (e.g. openai:gpt-5.6, anthropic:claude-sonnet-5, openai:gpt-image-2). Use when a provider ships a new model id and you need to wire literals, profile flags, adapters, and tests to recognize it. Handles SDK-lag, gateway list conventions, capability probing, and direct image-model geometry.

      Also in 9 projects that use this

    • Microsoft AzureSkill

      azsdk-common-sdk-breaking-change

      Detect and mitigate SDK Breaking changes for an SDK package which is generated from TypeSpec. WHEN: "Detect SDK breaking changes for a service", "Detect SDK breaking changes for an SDK package", "Detect and mitigate SDK breaking changes for a service", "Detect and mitigate SDK breaking changes for an SDK package". INVOKES: skill: azsdk-common-generate-sdk-locally; MCP tools: azure-sdk-mcp:azsdk_customized_code_update, azure-sdk-mcp:azsdk_package_detect_breaking_change.

      Also in 4 projects that use this

    • ww-w-aiSkill

      bkend-auth

      bkend.ai authentication guide. Signup, login, JWT tokens, sessions, role-based access control, and password management with bkend.ai BaaS. Triggers: bkend auth, bkend login, bkend signup, JWT, session, RBAC, password, bkend 인증, 로그인, 회원가입, bkend認証, ログイン, 新規登録, bkend认证, 登录, 注册, autenticacion bkend, authentification bkend, bkend-Auth Do NOT use for: data operations (use $bkend-data), file storage (use $bkend-storage).

      Also in 4 projects that use this

    • ww-w-aiSkill

      bkend-cookbook

      bkend.ai cookbook with step-by-step tutorials and example projects. Build a todo app, blog, e-commerce store, and more with bkend.ai BaaS. Triggers: bkend cookbook, bkend tutorial, bkend example, todo app, blog app, bkend 쿡북, bkend 튜토리얼, 예제 프로젝트, bkendクックブック, チュートリアル, bkend教程, 示例项目, tutorial bkend, tutoriel bkend, bkend-Tutorial, ricettario Do NOT use for: initial setup (use $bkend-quickstart), specific features (use $bkend-data/auth/storage).

      Also in 4 projects that use this

    • dzhngSkill

      close-spec

      When a spec under specs/<feature>/ is done shipping (a write-spec build, or any planned task that produced a spec), archive it to specs/done/ and rewrite it from a build-plan into a durable rationale — the why, the principles, the invariants — pointing back to the real code for the how. Use when implementation has landed and the plan no longer matches what shipped, or the user says a feature/spec is finished. Pairs with [write-spec](../write-spec/SKILL.md) (the plan this closes) and [review](../review/SKILL.md) (run before closing).

      Also in 4 projects that use this

    • dzhngSkill

      design-with-images

      Explore UI and visual design with image generation, then iterate the real implementation against the user-selected concept. Use when brainstorming visual directions, offering mockup variants, or implementing an approved generated design; do not stop at the mockups or the first code approximation.

      Also in 4 projects that use this

    • +5 more from ww-w-ai
  • In this repository36 other files it gives its agents.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.