karasukaigan 审查
对 HEAD 和用户提供的固定点之间的差异进行双轴审查：
- 标准——代码是否符合此仓库记录的编码标准？
- 规范——代码是否忠实地实现了原始 issue/PRD/规范？
两个轴都作为并行子代理运行，这样它们不会相互污染上下文，然后此技能聚合它们的发现。
issue tracker 应该已经提供给你——如果 docs/agents/issue-tracker.md 缺失，请运行 /setup-matt-pocock-skills。
流程
1. 固定固定点
无论用户说什么是固定点——提交 SHA、分支名称、标签、main、HEAD~5 等。不要有主见；直接传递。如果他们未指定一个，询问："针对什么审查——分支、提交还是 main？"在你得到它之前不要继续。
捕获差异命令一次：git diff <fixed-point>...HEAD（三点，所以比较是针对合并基础的）。还通过 git log <fixed-point>..HEAD --oneline 注意提交列表。
2. 识别规范来源
按此顺序查找原始规范：
- 提交消息中的 issue 引用（
#123、Closes #45、GitLab!67等）——通过docs/agents/issue-tracker.md中的工作流程获取。 - 用户作为参数传递的路径。
docs/、specs/或.scratch/下与分支名称或功能匹配的 PRD/规范文件。- 如果未找到任何内容，询问用户规范在哪里。如果他们说没有，规范子代理将跳过并报告"无可用规范"。
3. 识别标准来源
仓库中记录代码应如何编写的任何内容。常见位置：
CLAUDE.md、AGENTS.mdCONTRIBUTING.mdCONTEXT.md、CONTEXT-MAP.md、每个上下文的CONTEXT.md文件docs/adr/（架构决策是标准）.editorconfig、eslint.config.*、biome.json、prettier.config.*、tsconfig.json（机器强制执行的标准——注意它们但不要重新检查工具已经检查的内容）- 仓库根目录或
docs/下的任何STYLE.md、STANDARDS.md、STYLEGUIDE.md或类似内容
收集文件列表。标准子代理将读取它们。
4. 并行生成两个子代理
发送带有两个 Agent 工具调用的单个消息。两者都使用 general-purpose 子代理。
标准子代理提示——包括：
- 完整的差异命令和提交列表。
- 你在步骤 3 中找到的标准源文件列表。
- 简报："阅读标准文档。然后阅读差异。报告——在每个文件/块相关的地方——差异违反记录标准的每个地方。引用标准（文件 + 规则）。区分硬违规和判断调用。跳过的任何工具强制执行的内容。少于 400 字。"
规范子代理提示——包括：
- 差异命令和提交列表。
- 规范的路径或获取的内容。
- 简报："阅读规范。然后阅读差异。报告：(a) 规范要求但缺失或部分的要求；(b) 差异中未被要求的行为（范围蔓延）；(c) 看起来已实现但实现看起来错误的要求。为每个发现引用规范行。少于 400 字。"
如果规范缺失，跳过规范子代理并在最终报告中注明这一点。
5. 聚合
在 ## Standards 和 ## Spec 标题下展示两个报告，逐字或轻微清理。不要合并或重新排名发现——两个轴故意分开，以便用户可以独立看到它们。
以一行摘要结束：每个轴的总发现数，以及最严重的单个问题（如果有）标记。
为什么是两个轴
更改可以通过一个轴而失败另一个：
- 遵循每个标准但实现错误内容的代码 → 标准通过，规范失败。
- 完全按照 issue 要求但破坏项目约定的代码 → 规范通过，标准失败。
分别报告它们防止一个轴掩盖另一个。