用途
review 用于对代码变更做双轴审查。它比较 HEAD 与用户提供的固定点（commit SHA、分支名、标签、main、HEAD~5 等）之间的 diff，从两个独立维度评估变更：
- Standards：代码是否符合本仓库文档化的编码规范。
- Spec：代码是否忠实实现了来源 issue / PRD / 规格。
两个轴作为并行子智能体运行，避免彼此污染上下文，随后由该技能汇总两者的发现。
主要能力
- 固定点解析与 diff 捕获：使用 git diff <fixed-point>...HEAD（三点，与 merge-base 比较），并通过 git log <fixed-point>..HEAD --oneline 记录提交列表。
- 规格来源识别：按顺序查找用户传入的路径、.scratch/、docs/ 或 specs/ 下与分支名或功能匹配的 PRD/规格文件（本地 markdown 规格的默认位置）、提交信息中的 issue 引用（#123、Closes #45、GitLab !67 等，仅在配置了远程跟踪器时通过 docs/agents/issue-tracker.md 的工作流获取）。
- 规范来源识别：查找仓库中记录代码应如何编写的文件，如 CODING_STANDARDS.md 或 CONTRIBUTING.md。
- 并行子智能体：在单条消息中发起两个 Agent 工具调用，均使用 general-purpose 子智能体。
- 汇总报告：在 ## Standards 和 ## Spec 标题下分别呈现两份报告，不合并、不重新排序，最后给出一行总结（每个轴的发现总数，以及各轴内最严重的问题）。
使用方式
- 固定固定点：用户所说的即为固定点。若未指定，需询问。在继续前确认固定点可解析（git rev-parse <fixed-point>）且 diff 非空；错误的 ref 或空 diff 应在此处失败，而不是在两个并行子智能体内部失败。
- 识别规格来源（见上）。若未找到，询问用户规格位置；若用户表示没有，Spec 子智能体将跳过并报告“no spec available”。
- 识别规范来源（见上）。
- 并行启动两个子智能体：
- Standards 子智能体提示词包含：完整的 diff 命令与提交列表；第 3 步找到的规范来源文件列表；任务说明：“按文件/hunk 报告 diff 中每一处违反文档化规范的地方。引用规范（文件 + 规则）。区分硬性违规与主观判断。跳过工具已强制的内容。400 字以内。”
- Spec 子智能体提示词包含：diff 命令与提交列表；规格的路径或获取到的内容；任务说明：“报告：(a) 规格要求但缺失或部分实现的需求；(b) diff 中未被要求的行为（范围蔓延）；(c) 看似已实现但实现有误的需求。每条发现引用规格原文。400 字以内。”
- 若规格缺失，跳过 Spec 子智能体并在最终报告中注明。
- 汇总：在 ## Standards 和 ## Spec 标题下分别呈现两份报告，可逐字或轻度清理。不要合并或重新排序发现——两个轴刻意保持分离。最后给出一行总结：每个轴的发现总数，以及各轴内最严重的问题（如有）。不要跨轴选出单一赢家。
适用场景
- 需要同时检查代码规范符合度与需求实现忠实度的代码审查。
- 变更可能通过一个轴而失败于另一个轴的情况：
- 代码遵循所有规范但实现了错误的东西 → Standards 通过，Spec 失败。
- 代码完全按 issue 要求实现但破坏了项目约定 → Spec 通过，Standards 失败。
- 分开报告可防止一个轴掩盖另一个轴。
限制
- 规格默认使用本地 markdown；仅当规格位于远程跟踪器（GitHub/GitLab）时才需要 docs/agents/issue-tracker.md，并需运行 /setup-skills 配置。
- 若未找到规格且用户表示没有，Spec 轴将跳过并报告“no spec available”。
- 固定点必须由用户提供或经询问确定；错误的 ref 或空 diff 会导致流程在早期失败。
- 两个子智能体报告均限制在 400 字以内。
- 不合并或重新排序两个轴的发现，也不跨轴选出单一赢家。