507 review

交付审查（review）

对一个明确的代码或文档变更范围检查：

1. Standards（项目规范）：项目规则、既有决策与文档约束；
2. Spec（需求符合度）：需求、验收标准、范围和行为；
3. Code Quality（代码质量）：真实的 bug、安全、错误处理、性能和可维护性风险。

本 skill 只读审查：只给发现、证据和路由，不修改文件。

确定审查范围

按顺序选择：

1. 用户明确给出的 commit（提交）、范围、branch（分支）、tag（标签）或路径；
2. 当前 staged（已暂存）、unstaged（未暂存）和相关 untracked（未跟踪）变更；
3. 当前分支相对默认主干的差异；
4. 已提交且工作区干净时，仍审当前分支相对主干的差异；
5. 没有可用基准时，临时审最近一个 commit 并明确说明；
6. 仍无法判断时，只询问一次范围并给出推荐基准。

工作区干净不等于没有可审内容。开始前说明范围、基准和选择原因。

审查依据

优先读取相关 AGENTS.md、根及目标目录 README.md、doc/README.md、术语表、决策档案、贡献/风格规范、测试与构建配置，以及用户提供的 issue（问题单）、PRD（需求文档）、spec（规格）或验收标准。

没有明确需求来源时，将 Spec 标为“无明确 spec”，仍检查范围蔓延、行为风险和可验证性。只把已有证据当作规范，不把个人偏好包装成 Standards。

审查重点

Standards

• 是否违反项目规范、既有决策、不做边界或稳定术语；
• 职责、入口、运行方式、配置或权限变化是否同步文档；
• 用户可见变化是否同步项目要求的变更记录和版本信息。

Spec

• 需求是否完整实现，有无漏做、误做或范围蔓延；
• 行为、文档、测试和验收标准是否一致；
• 验收是否可复验，入口 README、项目地图和发布产物是否完整。

Code Quality

只报告真实或有明确证据的风险：边界/空值/竞态/状态错误，注入/权限/泄密，静默失败，不必要重算或泄漏，以及复杂度、误导命名、死代码和重复逻辑。不要重复 formatter（格式器）或 linter（静态检查器）已经明确捕获的表面问题。

输出格式

## Review Scope
- 范围：...
- 基准：...
- 原因：...
- 依据：...

## Summary
- Standards：通过 / 有问题 N 个
- Spec：通过 / 有问题 N 个 / 无明确 spec
- Code Quality：通过 / 有问题 N 个
- 最严重问题：...

## Findings
### 🔴 严重 / 🟡 警告 / 🔵 信息
- `file:line`：问题
  - 依据：...
  - 影响：...
  - 建议：...

## Recommended Next Mode
- 默认下一步：...
- 路由理由：...

## Verification
- 已检查 / 已运行 / 未运行 / 建议验证：...

没有发现阻塞问题时明确写“未发现阻塞问题”，并说明范围和验证限制。

后续路由

• bug、逻辑或安全问题 → 507-fix；
• 测试缺口/失败 → 507-test；明确 test-first → 507-tdd；
• 行为不变内部简化 → 507-simplify；架构摩擦 → 507-inspect；
• 地图文档失真 → 507-map；完整项目初始化或规范巡检 → 507-setup；
• 漏做需求 → 507-prd 或 507-issue；
• 已完成且用户明确要求 Git 提交 → 507-commit。

红线

• 不直接修改、修复、重构、补测试或提交；
• 不把无证据风险断言为事实；
• 不因工作区干净跳过已提交差异；
• 不大段复述 diff（差异），只列有行动价值的问题。

完成与接力

• 完成信号：明确范围已按 Standards、Spec 与 Code Quality 审完，给出带证据的 findings（发现）和清晰 verdict（结论）。
• 产物：只读审查报告与问题路由，不直接修改。
• 候选出口：按发现进入 507-fix、507-test、507-simplify、507-map、507-setup、507-prd 或 507-issue；没有阻塞且用户明确要求提交时进入 507-commit；只需审查结论时直接结束。
• 回退条件：审查基线或目标规格不明确时先返回 507-explore 或 507-grill，不对猜测中的需求判通过/失败。