unity-code-review

对当前 Git 索引（已暂存更改）进行双轴审查：

• 规范：代码是否符合此仓库中记录的编码规范？
• 规格：代码是否忠实实现了原始任务／规格？

两个维度由并行子 Agent分别审查，避免彼此的上下文互相干扰；随后，此技能会汇总各自的发现。

流程

1. 确定已暂存的审查范围

检查 git status --short，并使用 git diff --cached 获取审查差异，其中包括已暂存的新增、修改、删除和重命名。使用 git diff --cached --name-status 记录已暂存文件列表。

如果没有已暂存的更改，准确报告 No staged changes to review.，并停止，不要启动子 Agent。

已暂存差异是审查边界。使用 git show :<path> 读取已暂存文件内容，确保审查的是索引中的文件状态，而非工作树中的状态。仅将相关文件作为上下文读取；未暂存和未跟踪的更改不在审查范围内。

2. 确定规格来源

按以下顺序查找原始规格：

1. 用户作为参数传入的路径。
2. docs/、specs/ 或 .scratch/ 下与分支名称或功能匹配的规格文件。
3. 如果未找到任何文件，询问用户规格位于何处。如果用户表示没有规格，则 规格子 Agent 会跳过审查，并报告“没有可用规格”。

3. 确定标准来源

• 将 docs/coding-standards.md、.agents/skills/unity-tdd/tests.md、任务／规范约定的测试接缝，以及负责验收归属的相关 ADR，列入 Standards 子代理的来源。
• 根据断言声明的契约进行判断：有意锁定已批准内容的测试，不同于通用行为测试。由人工负责的启动／视觉验收不代表缺少自动化测试。机械规则由仓库检查器负责；对于测试质量，应在其文档说明的检测范围之外进行评审，而不是重复这些诊断。

除仓库文档所述内容外，Standards 维度始终包含以下 代码异味基线：一组固定的 Fowler 代码异味（重构，第 3 章），即使仓库没有任何相关文档，也适用。以下两条规则具有约束力：

• 以仓库标准为准。 有文档记录的仓库标准始终优先；若其认可了基线会标记的做法，则忽略该异味。
• 始终是判断性意见。 每种异味都是带标签的启发式判断（“可能存在 Feature Envy”），绝非硬性违规。与此处的其他标准一样，跳过工具已强制执行的内容。

每种异味按 它是什么 → 如何修复 来说明；请对照差异进行检查：

• 晦涩命名（Mysterious Name）：函数、变量或类型的名称无法说明其作用或所持有的数据。→ 重命名；如果找不到恰当的名称，说明设计含糊不清。
• 重复代码（Duplicated Code）：更改中的多个代码块或文件出现相同的逻辑结构。→ 提取共有结构，并在两处调用。
• Feature Envy：某个方法访问其他对象的数据，比访问自身数据还多。→ 将该方法移到它所依赖的数据所属对象上。
• 数据泥团（Data Clumps）：相同的几个字段或参数总是一起传递（这表明它们应该成为一种类型）。→ 将它们封装到一个类型中，并传递该类型。
• 基本类型偏执（Primitive Obsession）：使用基本类型或字符串表示本应拥有独立类型的领域概念。→ 为该概念创建一个简单的独立类型。
• 重复的 Switch（Repeated Switches）：更改中多处重复出现针对相同类型的 switch／if 级联判断。→ 改用多态，或让两处共用一张映射表。
• 霰弹式修改（Shotgun Surgery）：一项逻辑上的更改迫使差异中的多个文件分散修改。→ 将需要一起更改的内容归入一个模块。
• 发散式修改（Divergent Change）：同一个文件或模块因多个互不相关的原因而被修改。→ 拆分模块，让每个模块只因一种原因而更改。
• 投机式通用性（Speculative Generality）：添加了规范并未要求的抽象、参数或钩子。→ 删除它；将其内联，直到出现真实需求。
• 消息链（Message Chains）：出现调用方不应依赖的冗长 a.b().c().d() 导航链。→ 在第一个对象上添加一个方法，将这段访问链隐藏起来。
• 中间人（Middle Man）：某个类或函数大多只负责转发调用。→ 移除它，直接调用真正的目标。
• 被拒绝的继承（Refused Bequest）：子类或实现类忽略或重写了继承的大部分内容。→ 移除继承，改用组合。

4. 并行启动两个审核子 Agent

在前台同时发起两个审核子 Agent 调用，并汇总它们返回的报告。

标准子 Agent 提示词应包括：

• 第 1 步中的暂存差异命令和文件列表，以及审核范围和索引读取说明。
• 第 3 步中找到的标准来源文件列表，以及第 3 步的异味基线全文（子 Agent 无法通过其他方式访问）。
• 任务说明：“按文件／代码块（如适用）报告：(a) 差异中每一处违反已记录标准的地方：引用标准（文件 + 规则）；(b) 发现的任何基线异味：指出异味名称并引用代码块。区分硬性违规和主观判断：违反已记录标准的情况可能属于硬性违规，但基线异味始终属于主观判断，且已记录的仓库标准优先于基线。跳过由工具强制执行的内容。少于 400 词。”

规格子 Agent 提示词应包括：

• 第 1 步中的暂存差异命令和文件列表，以及审核范围和索引读取说明。
• 规格文件的路径或已获取的内容。
• 任务说明：“报告：(a) 规格要求中缺失或仅部分实现的内容；(b) 差异中未被要求的行为（范围蔓延）；(c) 看似已实现但实现有误的要求。每条发现都引用对应的规格原文。少于 400 词。”

如果规格文件缺失，则跳过规格子 Agent，并在最终报告中说明。

5. 汇总

在 ## Standards 和 ## Spec 标题下分别呈现两份报告，原样保留或仅做轻微润色。不要合并或重新排列发现，因为这两个维度是刻意分开的（见 为什么要分成两个维度）。

最后用一行总结：各维度的发现总数，以及各维度中最严重的问题（如有）。不要在两个维度之间选出唯一赢家：这正是区分两个维度要避免的重新排序。

为什么要分成两个维度

一项改动可能通过一个维度，却未通过另一个维度：

• 遵循所有标准的代码，却实现了错误的功能 → 标准通过，规格未通过。
• 完全按任务要求实现，却违反了项目约定 → 规格通过，标准未通过。

分别报告可以避免一个维度掩盖另一个维度。