Back to Details

code-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
<!-- markdownlint-disable MD013 -->
<!-- markdownlint-disable MD013 -->

Code Review

代码审查

Three-axis review of the diff between 
HEAD
and a fixed point the user supplies:
  • Standards — does the code conform to this repo's documented coding standards?
  • Spec — does the code faithfully implement the originating issue / PRD / spec?
A third, lighter axis applies when the change is non-trivial: Stability — does the diff ship the property-based tests named in the spec? The Spec agent additionally verifies that each named invariant/property test exists and fails loud on a broken invariant, not just example coverage.
Both axes run as parallel sub-agents (
delegate_task
) so they don't pollute each other's context; this skill aggregates their findings side by side. The issue tracker comes from 
docs/agents/issue-tracker.md
.
针对用户指定的
HEAD
与固定版本之间差异的三维度审查：
  • 标准 — 代码是否符合本仓库已归档的编码标准？
  • 需求规范 — 代码是否忠实地实现了源问题/PRD/需求规范？
当变更较为复杂时，会启用第三个轻量化维度：稳定性 — 差异代码是否交付了需求规范中指定的基于属性的测试？Spec Agent还会验证每个指定的不变量/属性测试是否存在，且在不变量被破坏时能明确报错，而非仅覆盖示例场景。
所有维度均以并行子Agent（
delegate_task
）的形式运行，避免互相干扰上下文；本Skill会将它们的审查结果汇总展示。问题追踪器来源为
docs/agents/issue-tracker.md
。

Process

流程

1. Pin the fixed point

1. 锁定固定版本

Whatever the user said — a commit SHA, bookmark, tag, 
main
, 
@~5
. If unspecified, ask. Capture once (prefer 
jj
, fall back to 
git
): 
jj diff -r <fixed>..@
/ 
git diff <fixed>...HEAD
(three-dot, merge-base), and 
jj log -r <fixed>..@
/ 
git log <fixed>..HEAD --oneline
. Confirm the ref resolves (
jj log -r <rev>
/ 
git rev-parse
) and the diff is non-empty before spawning sub-agents — a bad ref or empty diff fails here, not inside two children.
用户指定的任意标识——提交SHA、书签、标签、
main
、
@~5
均可。若用户未指定，则询问用户。一次性获取差异信息（优先使用
jj
， fallback到
git
）：
jj diff -r <fixed>..@
/ 
git diff <fixed>...HEAD
（三点表示基于合并基准），以及
jj log -r <fixed>..@
/ 
git log <fixed>..HEAD --oneline
。在启动子Agent前，需确认引用可解析（通过
jj log -r <rev>
/ 
git rev-parse
）且差异非空——若引用无效或差异为空，将在此阶段终止，而非在子Agent中失败。

2. Identify the spec source

2. 确定需求规范来源

In order: issue references in commit messages (
#123
, 
Closes #45
) fetched per 
docs/agents/issue-tracker.md
; a path the user passed; a spec under 
docs/
, 
specs/
, or 
.scratch/
matching the branch. If none, ask; if the user says there isn't one, the Spec sub-agent reports "no spec available".
优先级顺序：提交消息中的问题引用（如
#123
、
Closes #45
，根据
docs/agents/issue-tracker.md
获取）；用户提供的路径；与分支匹配的
docs/
、
specs/
或
.scratch/
目录下的规范文件。若以上均不存在，则询问用户；若用户表示无相关规范，Spec子Agent将报告“无可用规范”。

3. Identify the standards sources

3. 确定标准来源

CODING_STANDARDS.md
, 
CONTRIBUTING.md
, 
AGENTS.md
, 
.cursorrules
, etc. On top of whatever the repo documents, the Standards axis always carries a smell baseline — Fowler's code smells (long method, large class, feature envy, primitive obsession, shotgun surgery, ...) — so review has teeth even when the repo documents nothing.
CODING_STANDARDS.md
、
CONTRIBUTING.md
、
AGENTS.md
、
.cursorrules
等文件。除仓库中已归档的标准外，标准维度始终包含代码异味基线——Fowler提出的代码异味（长方法、大类、特性依恋、原始类型痴迷、霰弹式修改等）——因此即便仓库未归档任何标准，审查仍具备有效性。

4. Run both axes in parallel

4. 并行运行各维度审查

Spawn two sub-agents with 
delegate_task
:
  • Standards agent — the diff + the standards sources + smell baseline.
  • Spec agent — the diff + the spec. Reports each user story / acceptance criterion as met / partial / missing.
通过
delegate_task
启动两个子Agent：
  • 标准Agent — 输入内容为差异代码 + 标准来源 + 代码异味基线。
  • 需求规范Agent — 输入内容为差异代码 + 需求规范。会将每个用户故事/验收标准标记为已满足/部分满足/未满足。

5. Aggregate

5. 汇总结果

Report the two axes side by side. Per finding: location (
path:line
), the issue, and the fix. End with a verdict per axis (pass / changes requested) and the single most important change.
将两个维度的审查结果并列展示。每条审查结果需包含：位置（
path:line
）、问题描述及修复建议。结尾需给出各维度的结论（通过/需修改），以及最重要的一项修改建议。

Boundaries

边界说明

This review is the agent's pre-flight; the gating approving review is human. After it passes, hand the PR to a human (label 
ready-for-human
) — never treat this review as the merge gate. Reviews; does not apply fixes. The over-engineering pass is folded into the workflow as the minimalism over-engineering audit (see 
docs/agents/workflow.md
— 
delete:
/ 
stdlib:
/ 
native:
/ 
yagni:
/ 
shrink:
tags, ending in 
net: -<N> lines possible
); run it from 
implement
before this review. For deeper correctness/security, escalate to a dedicated review pass.
本次审查是Agent执行的预检查；最终的批准审查由人工完成。审查通过后，需将PR移交至人工（标记
ready-for-human
）——绝不能将本次审查作为合并的准入条件。本Skill仅执行审查，不自动应用修复。过度设计检查已整合到工作流中，作为极简主义过度设计审计（详见
docs/agents/workflow.md
——包含
delete:
/
stdlib:
/
native:
/
yagni:
/
shrink:
标签，最终输出
net: -<N> lines possible
）；需在本次审查前，从
implement
阶段启动该审计。若需更深入的正确性/安全性审查，需升级至专门的审查流程。