用途：对一段代码变更做双轴 review——Standards（代码是否符合本仓库文档化的编码规范）与 Spec（代码是否忠实实现原始 issue／spec）。两轴由并行子智能体分别运行，避免互相污染上下文，最后由本技能汇总结果。
主要能力
- 固定基准点：以用户指定的固定点（commit SHA、分支名、标签、main、HEAD~5 等）为准；未指定则先询问。使用 git diff <fixed-point>...HEAD 三点比较 merge-base，并用 git log <fixed-point>..HEAD --oneline 记录提交列表。开始前用 git rev-parse 确认引用可解析、diff 非空。
- 定位 spec 来源：优先看提交信息中的 issue 引用（#123、Closes #45、GitLab !67 等），通过 docs/agents/issue-tracker.md 的工作流获取；其次是用户传入的路径参数；再找 docs/、specs/、.scratch/ 下与分支名或功能匹配的 spec 文件。都没有则询问用户，若确认没有，Spec 轴跳过并报告 no spec available。若 docs/agents/issue-tracker.md 缺失，提示用户运行 /setup-matt-pocock-skills。
- 定位标准来源：仓库中描述代码应如何编写的文件（如 CODING_STANDARDS.md、CONTRIBUTING.md）。此外 Standards 轴始终携带一套 Fowler 代码坏味道基线（Refactoring 第 3 章），即使仓库未文档化也适用。两条约束：仓库文档标准优先，若仓库认可某做法则抑制对应的坏味道；坏味道始终是判断性提示（如 possible Feature Envy），不是硬性违规，且工具已强制的内容跳过。
基线坏味道（读作 什么 → 如何修）：Mysterious Name（命名不表意→重命名）、Duplicated Code（同一逻辑形状出现在多个 hunk／文件→抽取共享形状）、Feature Envy（方法过度访问他对象数据→把方法移到被羡慕的数据上）、Data Clumps（同几个字段／参数总一起出现→打包成类型）、Primitive Obsession（原始类型／字符串代替领域概念→建小类型）、Repeated Switches（同一类型的 switch／if 级联反复出现→多态或共享映射）、Shotgun Surgery（一次逻辑改动散落多文件→聚到一个模块）、Divergent Change（一个文件因多种无关原因被改→按单一原因拆分）、Speculative Generality（为 spec 不需要的需求加抽象→删除并内联）、Message Chains（长 a.b().c().d() 导航→藏到一个方法后）、Middle Man（类／函数主要只是转发→去掉直接调用目标）、Refused Bequest（子类忽略或覆盖大部分继承→改用组合）。
-
并行生成两个子智能体：Standards 子智能体获得完整 diff 命令与提交列表、第 3 步找到的标准源文件清单、完整粘贴的坏味道基线，并要求按文件／hunk 报告违反文档标准之处（引用标准文件与规则）及发现的基线坏味道（命名并引用 hunk），区分硬性违规与判断性提示，跳过工具已强制的内容，400 词内。Spec 子智能体获得 diff 命令与提交列表、spec 路径或已获取内容，报告 spec 要求但缺失或未完成的部分、diff 中未被要求的行为（范围蔓延）、看似实现但实现有误的要求，每条引用 spec 原文，400 词内。spec 缺失则跳过 Spec 子智能体并在最终报告注明。
-
汇总：以 ## Standards 与 ## Spec 两个标题分别呈现两轴报告（原文或轻度清理），不合并、不重新排序发现项。结尾给一行摘要：各轴发现总数及各轴最严重问题（若有）；不跨轴挑选单一胜者。
适用场景：审查从某个固定点以来的一批改动，同时需要验证“实现对不对”和“写法合不合规范”，且希望两个维度互不遮蔽。
限制：需要用户提供固定点；spec 缺失时无法做 Spec 审查；基线坏味道均为判断性提示而非硬性判定；未提供仓库文档标准时会以坏味道基线为主；未提及收费、价格或平台支持信息。