用途：对 HEAD 与用户提供的固定点之间的变更做双轴代码审查。标准轴判断代码是否符合本仓库文档化的编码标准；规格轴判断代码是否忠实实现原始 issue/规格。两轴作为并行子代理运行，避免相互污染上下文，再由本技能汇总结果。
主要能力：固定点可为提交 SHA、分支名、标签、main、HEAD~5 等；若用户未指定则需询问。使用 git diff <fixed-point>...HEAD（三点，与 merge-base 比较）获取 diff，并用 git log <fixed-point>..HEAD --oneline 记录提交列表。继续前先用 git rev-parse <fixed-point> 确认固定点可解析且 diff 非空。规格来源按顺序查找：提交信息中的 issue 引用（#123、Closes #45、GitLab !67 等，经 docs/agents/issue-tracker.md 工作流获取）、用户作为参数传入的路径、docs/、specs/ 或 .scratch/ 下与分支名或功能匹配的规格文件；找不到则询问用户，若确无规格则跳过规格子代理并报告“no spec available”。标准来源包括仓库中记录代码写法的文件（如 CODING_STANDARDS.md、CONTRIBUTING.md），并始终附带 Fowler 代码坏味道基线（Refactoring 第 3 章），规则为：仓库文档标准优先于基线；每个坏味道都是带标签的启发式判断（如“possible Feature Envy”），不是硬性违规；工具已强制的内容跳过。
使用方式：需先提供 issue tracker；若 docs/agents/issue-tracker.md 缺失，提示用户运行 /setup-matt-pocock-skills。随后按固定点、规格来源、标准来源、并行子代理、汇总五步执行。标准子代理提示需包含完整 diff 命令与提交列表、标准来源文件列表及完整坏味道基线，要求按文件/hunk 报告违反文档标准之处（引用标准文件与规则）和发现的基线坏味道（命名并引用 hunk），区分硬性违规与判断性意见，400 词以内。规格子代理提示需包含 diff 命令、提交列表和规格路径或内容，报告规格要求缺失或部分实现、diff 中未被要求的行为（范围蔓延）、看似实现但实现有误的要求，并引用规格行，400 词以内。汇总时在 ## Standards 与 ## Spec 标题下分别呈现两份报告，不合并、不重排，最后给出一行总结：每轴发现总数及各自最严重问题，不跨轴选唯一赢家。
适用场景：需要同时检查代码规范符合度与规格实现忠实度的变更审查。
限制：固定点必须可解析且 diff 非空；规格缺失时规格轴跳过；基线坏味道始终为判断性意见；仓库文档标准可覆盖基线；工具已强制的内容不报告。具体安装方式、收费与平台信息暂未提供。