aif-review 是一个代码审查助手技能，专注于正确性、安全性、性能和可维护性，对暂存的更改或拉取请求执行审查。
用途
该技能用于对代码变更进行审查，检查缺陷、安全问题、性能问题和最佳实践。当用户发出“review…”等指令时触发。
主要能力
- 支持多种审查模式：无参数时审查暂存更改；传入 PR 编号或 URL 时审查拉取请求；传入 Git 引用时进入提交模式逐条审查。
- 支持 +check 标志，在审查产出后运行可选的发现验证器。
- 读取项目配置 .ai-factory/config.yaml，解析路径、语言和 Git 基础分支。
- 运行只读上下文门禁，检查架构、规则和路线图对齐情况。
- 输出人类可读的审查结果，并附加机器可读的 aif-gate-result JSON 块。
使用方式
无参数（审查暂存更改）
运行 git diff --cached 获取暂存更改；若无暂存内容，则运行 git diff 查看未暂存更改；分析每个文件的更改。
传入 PR 编号或 URL
使用 gh pr view <number> --json 获取 PR 详情；使用 gh pr diff <number> 获取差异；审查 PR 中的所有更改。
传入 Git 引用（提交模式）
参数路由链：空 → 暂存审查；数字或 #N → PR 模式；其他 → 通过 git rev-parse --verify 验证 → 提交模式或询问用户。
验证：git rev-parse --verify <argument> 2>/dev/null。有效引用则进入提交模式；无效引用不会静默回退到暂存审查，而是询问用户澄清。
提交模式步骤：获取引用与 HEAD 之间的提交列表（git log --oneline --reverse <ref>..HEAD）；若无提交则告知用户并停止；若提交数超过 20，询问用户如何处理；逐条审查提交（git show <commit-hash> --stat 和 git show <commit-hash>），检查提交信息是否与实际更改匹配、更改是否原子化、是否引入问题；提供包含每条提交注释的综合摘要。
参数标志
+check：在审查产出后运行可选的发现验证器。该令牌可出现在主参数之前或之后。若剩余参数字符串为空，则回退到空参数模式（暂存审查）。未知的 + 前缀令牌会作为主参数的一部分传递。
上下文门禁（只读）
在最终确定审查发现之前，运行只读上下文门禁：检查已解析的架构工件（若存在）的边界/依赖对齐问题；检查已解析的 RULES.md 工件（若存在）的显式约定违规；检查已解析的路线图工件（若存在）的里程碑对齐情况。人类门禁结果严重性：WARN 用于非阻塞不一致或缺失可选文件；ERROR 仅用于用户/审查策略要求的显式阻塞标准。
机器可读门禁结果
在人类可读审查之后附加一个最终的 aif-gate-result JSON 块。使用 "gate": "review"。"status": "pass|warn|fail" 取两个独立输入中更严重者：发现输入和上下文门禁输入。"blocking": true|false，仅当 "status" 为 fail 时为 true。"blockers" 仅包含已确立的合并阻塞发现。"affected_files" 为已审查或涉及的路径。"suggested_next.command" 遵循状态：fail → 默认 /aif-fix；warn/pass → /aif-commit。
门禁前解析标记
产生至少一个 (confidence: low) / (confidence: medium) 标记的审查会自动运行 +check 验证，即使未给出标志。自动分派受能力限制：仅在运行时强制该代理的只读工具允许列表（Read、Glob、Grep — Claude Code）时作为 review-validator 运行。若该代理不可用或其运行时无法强制允许列表，则自动运行不会分派，并报告整体分派失败及由此产生的 review-validation-failed 门禁。只有显式 +check 才可在较弱边界下运行。
每个标记的发现要么被确认（验证器返回时无标记，计为普通发现），要么被反驳并丢弃。门禁随后从验证后的发现计算，因此发布的块从不包含标记。
项目上下文
读取 .ai-factory/skill-context/aif-review/SKILL.md — 若文件存在则为强制。该文件包含由 /aif-evolve 从补丁、代码库约定和技术栈分析中积累的项目特定规则。应用方式：将其视为本技能通用指令的项目级覆盖；当技能上下文规则与 SKILL.md 中的通用规则冲突时，技能上下文规则优先；无冲突时两者都应用。技能上下文规则适用于本技能的所有输出，包括审查摘要格式和检查清单标准。生成任何输出工件后，对照所有技能上下文规则验证；若有违反，在呈现给用户前修复。
发现阶段：覆盖优先于过滤
在发现阶段，任务是覆盖而非过滤。报告发现的每个问题，包括不确定或判断为低严重性的问题。不确定的发现仍会浮出，在其影响所对应的部分中携带显式置信度标记。不要为了满足“仅高严重性”/“保守”框架而自我审查。保持 Critical 与 Suggestion 划分的诚实性。
发现分类与验证边界
审查输出中的每一项恰好属于一个类别。类别决定项目渲染位置以及 +check 是否验证它：可操作的代码发现（渲染在 Critical Issues 或 Suggestions，由 +check 验证）；上下文门禁发现（渲染在 Context Gates，不验证）；提交结构发现（内联在审查中，不验证）；非可操作观察（渲染在 Positive Notes，不验证）；真正开放的澄清（渲染在 Questions，不验证）。关键不变量：可操作的代码发现绝不在 Critical Issues 或 Suggestions 之外渲染，因此当设置 +check 时它总是进入验证路径。
置信度标记
置信度和严重性是独立维度：严重性选择部分（基于所引用行为的影响，假设发现为真）；置信度标记文本（不确定的发现以 (confidence: low) 或 (confidence: medium) 结尾）。高置信度为默认，不携带标记。标记绝不会存活到发布的门禁。
适用场景
适用于需要对代码变更进行审查的开发工作流，包括暂存更改审查、拉取请求审查和提交历史审查。
限制
/aif-review 默认对上下文工件只读。除非用户明确要求，不要修改上下文文件。若配置 .ai-factory/config.yaml 不存在，使用默认值：路径 .ai-factory/，语言 en（英语），基础分支 main。