双维度代码审查
通过并行子代理，同时审查代码是否符合项目标准和原始需求，输出并排报告。
技能定义清晰，仅执行本地git命令和读取仓库文件，无网络外传或敏感数据处理。但未提供用户确认机制（如调用前确认），子代理可能自动运行，且依赖外部issue-tracker文档（setup脚本），存在一定不可控性。因此授予16分。
流程步骤明确，包含错误处理（如固定点解析失败及空diff检查）。但静态审查无法执行，且依赖外部issue-tracker文档的可用性，未提供测试或验证手段。授予6分。
技能的目的和范围清晰，能区分标准与规格审查，并对无规格情况有处理。但未明确声明非适用场景，且未考虑中国网络环境（依赖GitHub等海外服务）。授予10分。
有清晰的文档结构，包含过程、子代理提示、聚合步骤。但缺少安装/依赖说明，无版本历史或更改日志，维护责任未明确。授予12分。
核心任务（审查差异）有明确步骤，产出结构清晰（并行报告）。但静态审查无法验证实际输出质量，且依赖外部文档（issue-tracker.md）存在不确定性。授予6分。
技能本身没有测试或可验证的示例。README提供了仓库背景，但无具体审查案例。静态审查无法进行独立验证。授予3分。
- 该技能依赖外部issue-tracker文档（如GitHub、Linear），可能无法从中国大陆网络访问，影响实际使用。
- 技能未提供用户确认机制，子代理可能自动并行运行，建议在执行前进行确认。
- 静态审查无法验证实际输出质量，建议在实际环境中试用后再评估。
这个 Skill 能做什么，适合哪些场景？
此技能对自固定提交点起的代码变更进行双维度审查：标准维度检查代码是否符合仓库的编码规范及 Fowler 代码坏味道基线；规格维度检查代码是否忠实实现了原始 issue 或 spec。两个维度并行运行于独立子代理，避免上下文污染，最后汇总为分开的报告。它内置了 12 种 Fowler 坏味道基线，并优先遵循仓库文档规范。适用于分支、PR 或进行中的工作。
此技能会确定用户指定的固定提交点（commit SHA、分支、标签等），并运行 git diff <fixed-point>...HEAD 和 git log。它查找规格来源（issue 引用、用户参数、spec 文件），并识别标准来源文件。然后，它向两个并行子代理提供提示：一个检查标准违规和坏味道，另一个对照规格检查缺失、额外或不正确的实现。最后，它汇总两份报告并给出每轴的摘要。
- 当开发者想要在合并前审查一个 PR 或分支时，该技能会自动识别固定点（如 `main`）并启动双轴审查。
- 当用户要求“自 X 起审查更改”时，其中 X 是提交 SHA、标签或 `HEAD~5`。
- 当存在多个待审 PR，且需要快速并行评估标准和规格符合性时。
- 当产品经理希望验证实现是否符合 PRD，而工程负责人希望检查代码规范时。
这个 Skill 有哪些优点和局限？
- 并行子代理避免上下文污染，提高审查精度。
- 内置 Fowler 坏味道基线，即使在无文档的仓库也能提供有用的检查。
- 双轴分离防止标准合规掩盖需求偏差。
- 明确的流程：确认固定点，查找规格源，并清晰指示子代理。
- 需要用户指定的固定点；若不明确，必须提示，增加了初始交互。
- 若没有可用规格，规格轴将被跳过，可能偏离原始需求。
- 需要仓库中有 `docs/agents/issue-tracker.md` 才能获取 issue，缺失时需要先运行设置命令。
- 坏味道是启发式的判断，可能因主观性导致误报。
- 此技能是在一个更大的仓库中分发的，安装它需要整个收藏，而不只是这一个技能。
如何安装这个 Skill？
运行 npx skills@latest add mattpocock/skills 并从交互式选择中选择此技能（确保选择 /setup-matt-pocock-skills）。随后运行 /setup-matt-pocock-skills 以配置 issue tracker 等。
如何使用这个 Skill？
在已配置的仓库中，提示例如：“审查 feature/login 分支”或“自 HEAD~3 起审查更改”。如有需要，指明固定点（若不指定，技能会询问）。该技能需要访问 docs/agents/issue-tracker.md；若缺失，它会提示运行设置命令。