code-review

Files (3)

• SKILL.md
• openai.yaml · agents/
• maintainability.md · references/

SKILL.md (first lines)

# 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](references/maintainability.md)。普通审查不额外执行整套架构探索。

## 独立检查与复核

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

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

## 交付

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

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

From iZiTTMarvin/agent-skills-zh, MIT.

More from iZiTTMarvin/agent-skills-zh