ultra-review

Ultra Review

生成一份超详细、有证据支持的代码审查报告。默认范围为当前 Git 变更。如果用户指定了路径、模块、功能、包或关注点，则改为审查该目标。

除非用户明确要求应用修复，否则此技能为只读。

不可妥协的准备工作

在撰写审查结果前，必须完成以下步骤。跳过任何一步都意味着审查未通过。

1. 确定范围

Git 差异模式（默认）：用户未指定目标时使用：

1. 检查状态、已暂存差异、未暂存差异，以及（适用时）相对于跟踪基分支领先的提交。
2. 优先审查与请求相关的整个脏工作树；如果不清楚用户是否只希望审查已暂存或未暂存内容，请说明假设并继续。
3. 仅当用户明确排除无关的脏文件，或这些文件显然属于噪声（生成的锁文件变更、本地环境等）时，才忽略它们——并说明排除项。

定向模式：用户指定代码时使用：

1. 全面审查指定路径／模块／功能／包。
2. 仅在判断正确性所需时，追踪导入、调用方、测试、配置和契约——不要擅自扩展为全仓库审查。

深入审查前，先用一个简短段落说明确定的审查范围。

2. 加载所有相关的可用技能

在评判代码之前：

1. 清点当前会话／运行环境中可用的 Agent 技能（技能列表、技能目录或运行环境提供的其他发现方式）。
2. 根据清单，阅读并遵循所有描述或领域与审查范围相符的技能——包括语言、框架、库、UI 系统、数据／验证、身份验证、测试、构建工具、样式、电子邮件、队列、可观测性、架构约束等。
3. 宁可多纳入：如果某项技能可能适用于范围内的任何文件或关注点，就加载它。
4. 不要虚构不存在的技能，也不要提及或依赖缺失的技能。
5. 加载后，将这些技能的标准作为对应代码的审查准则。

如果运行环境无法列出或加载技能，只需说明一次，然后继续参考仓库指南并进行研究。

详情见：skill-loading.md。

3. 在必要时进行研究

如果当前一手资料可用，不要仅凭记忆审查库、API、协议、安全或“正确做法”相关问题。

以下任一情况都必须进行研究：

• 代码使用或配置了库、框架、SDK、API、CLI 或云服务。
• 正确性取决于特定版本的行为、默认值或迁移说明。
• 涉及安全、隐私、身份验证、密码学、支付或合规模式。
• 变更声称遵循既定实践、RFC、无障碍标准或供应商指南。
• 不确定某个 API、选项或模式是否仍然有效或受推荐。

研究方式：

1. 优先使用可用的已配置文档／研究工具（例如库文档解析器；用于一般实践的网络／研究工具）。
2. 优先参考官方文档、变更日志、RFC 和一手标准，而不是博客或记忆。
3. 记录影响审查结果的版本和来源链接／路径。
4. 如果无法进行研究，请将相关审查结果标记为较低置信度，并说明无法核实的内容。

详情见：external-research.md。

4. 阅读本地依据

还应根据需要加载：

• 仓库 Agent 指令和所有权文档
• 附近的测试、类型、模式、配置和公开导出
• 同级模块中的现有模式（一致性标准）

Review 深度

检查 review-dimensions.md 中所有适用的维度。对于适用于审查范围的每个维度，要么：

• 提出有具体证据的发现，或
• 仅当不作说明会让人以为跳过了该维度时，明确注明“已检查，无问题”

不要用推测性的细枝末节凑数。优先提出少量高价值发现，而不是凑评论数量。同时，要全面覆盖所有维度——“全面”指覆盖到位，而不是凭空找问题。

发现标准

每项可执行的发现都必须包含：

1. 严重性：blocker | high | medium | low | nit
2. 位置：可用时提供路径和符号、行号或代码块引用
3. 证据：代码的具体行为（准确引用或简要转述）
4. 影响：具体的故障、风险或维护成本
5. 建议：明确的修复方向
6. 依据：已加载的技能规则、本地约定、测试/契约，或外部来源（附链接/版本）

区分以下类型：

• 缺陷（错误、不安全或破坏契约）
• 风险（可能的故障模式、缺少防护）
• 设计（API/所有权/抽象问题）
• 问题（需要产品或负责人的判断）

不要将问题当作缺陷来呈现。

工作流

- [ ] Resolve scope (git diff vs target)
- [ ] Inventory and load all relevant available skills
- [ ] Map stack, libraries, and risk areas in scope
- [ ] Run external research for triggered topics
- [ ] Read local instructions, tests, and sibling patterns
- [ ] Deep-read the code under review (not only the diff hunk)
- [ ] Score every applicable review dimension
- [ ] Cross-check findings against skills + sources
- [ ] Produce the review report

当执行环境支持并且范围较大或涉及多个方面时，使用并行审查 Agent；由一名总协调者负责最终整合的审查结果。如果无法使用并行 Agent，则在聊天中依次完成相同的审查步骤。

报告格式

## Scope
[diff | path] — files/areas included; exclusions

## Preparation
- Skills loaded: [names of skills actually loaded from this harness]
- Research: [sources/versions consulted, or none with reason]
- Local context: [key docs/tests/patterns read]

## Verdict
[ship | revise | blocked] — one sentence

## Findings
### Blockers
…

### High
…

### Medium
…

### Low / Nits
…

## Questions / Assumptions
…

## What looked solid
[short; only real strengths worth preserving]

## Residual risk
[what was out of scope, unverified, or research-blocked]

优先列出阻断级和高严重性问题。简要说明“表现良好的部分”，避免冲淡审查结果。

完成规则

• 如果跳过了技能加载或必需的研究，绝不要声称审查结果干净，且不作说明。
• 除非用户要求修复，否则不要在审查时顺手修复。
• 保留与审查范围无关的用户工作：不要要求顺带清理范围外的内容。
• 如果没有发现问题，说明检查了哪些内容，以及为何对此有较高把握。