用途：审查自某个固定点以来的代码变更，从两个独立维度评估：Standards（是否符合本仓库文档化的编码规范）与 Spec（是否忠实实现来源 issue/规格）。两轴由并行子代理运行，避免互相污染上下文，再由本技能汇总结果。
主要能力：
- 固定点定位：用户给出的固定点可为提交 SHA、分支名、标签、main、HEAD~5 等；未指定则询问。使用 git diff <fixed-point>...HEAD（三点，与 merge-base 比较），并用 git log <fixed-point>..HEAD --oneline 记录提交列表。继续前先用 git rev-parse <fixed-point> 确认引用可解析且 diff 非空。
- 识别规格来源：按顺序查找提交信息中的 issue 引用（#123、Closes #45、GitLab !67 等，经 docs/agents/issue-tracker.md 工作流获取）、用户传入的路径、Obsidian 跟踪器中的 <vault>/engineering/<project>/workplans/<feature>/spec.md（<vault> 取自 $OBSIDIAN_AI_VAULT，用绝对路径本地读取）、docs/、specs/ 或 .scratch/ 下匹配分支名或特性的规格文件。找不到则询问；若用户说没有，Spec 子代理跳过并报告“no spec available”。
- 识别规范来源：仓库中记录代码写法的文件（如 CODING_STANDARDS.md、CONTRIBUTING.md）。此外 Standards 轴始终携带 Fowler 代码坏味道基线（Refactoring 第 3 章），即使仓库未记录任何规范也适用。两条约束：仓库规范优先，文档化标准覆盖基线；基线始终是判断性提示（如“possible Feature Envy”），非硬性违规，且跳过工具已强制的内容。
- 并行子代理：Standards 子代理接收 diff 命令、提交列表、规范来源文件及完整坏味道基线，报告违反文档化标准之处（引用文件与规则）及基线坏味道（命名并引用代码块），区分硬违规与判断性提示，400 词以内。Spec 子代理接收 diff 命令、提交列表与规格路径或内容，报告缺失或部分实现的需求、未要求的范围蔓延、实现有误的需求，每条引用规格原文，400 词以内。
- 汇总：在 ## Standards 与 ## Spec 标题下分别呈现两份报告，不合并、不重排。结尾给出一行摘要：各轴发现总数及各自最严重问题，不跨轴选唯一赢家。
使用方式：需先由 /ai-setup-skills 提供 issue 跟踪器；若 docs/agents/issue-tracker.md 缺失，提示用户运行该命令。
适用场景：需要同时检查代码规范符合度与需求实现忠实度的代码审查。
限制：两轴刻意分离，不合并或重排发现；基线坏味道仅为判断性提示；规格缺失时 Spec 轴跳过；具体安装与调用命令资料未提供。