izittmarvin/agent-skills-zh/code-review

Code Review

审查默认只读。每项发现都应有明确位置、成立条件、影响和修复方向；审查请求不授权修复、提交或发布评论。

固定审查范围

先读取任务上下文和 git status --short，记录当前 HEAD。遵循用户指定范围；未指定时，优先本次任务的工作区改动，工作区干净时再确定分支基线。无法从上下文确定基线时才询问。

• 工作区：用 git diff HEAD -- <paths> 覆盖已暂存和未暂存改动；用 git ls-files --others --exclude-standard 找到未跟踪文件，读取属于本次范围的文件。用户只要求 staged 或 unstaged 时，分别用 git diff --cached 或 git diff。
• 分支或 PR：解析并固定 base/head 的提交 ID；分支新增改动用 git diff <base>...<head>，用户要求两个版本的直接差异时用两点比较。明确报告工作区改动是否在范围内。
• 混合范围：分别收集提交与工作区差异，按当前文件状态核实，避免重复报告或漏掉新文件。

没有提交的仓库以目标文件作为初始变更审查。空范围报告“没有可审查改动”，无效引用报告原因。与本次无关的用户改动不纳入、也不改动。结束前重查 HEAD 和状态；范围发生变化时重新核对受影响发现。

找到判断依据

• Standards：读取适用的 AGENTS、贡献规范和相关目录规则；沿变更的调用方、类型、状态归属和测试检查可达缺陷。命名、重复、透传层、散落状态等只作为调查线索，必须解释实际影响；项目规范优先。
• Spec：优先使用用户当前要求、明确给定的规格、验收条件和执行清单；必要时读取相关 Issue。没有正式文档不等于没有需求。无法获得需求时，说明不能验证的部分，继续其余审查。

用户明确要求深度、核弹级可维护性审查，或要求评估结构简化时，读取 references/maintainability.md。普通审查不额外执行整套架构探索。

独立检查与复核

平台允许且有子代理时，让两个只读子代理分别检查 Standards 和 Spec；给它们相同的固定范围、相关依据和文件路径，不传入另一份报告。缺少需求时，Spec 仅核查已知要求并标注缺口。

不能委派时，主代理分两遍完成并说明没有独立子代理复核。无论采用哪种方式，主代理都要回查每个发现的条件、源码与证据，剔除误报和重复项；不把子代理结论直接当作事实。

交付

分别列出 Standards 与 Spec 发现，每项附严重度、文件位置、触发条件、影响和建议。同一问题跨两个维度时只完整记录一次，并交叉引用。风格偏好与已证实缺陷分开，没有发现时如实说明。

最后说明实际审查范围、使用的需求与规范、验证证据，以及缺失的资料或未覆盖的运行路径。完成标准是范围内每项重要要求和变更都有着落；已定位但无法验证的风险仍作为不确定项保留。