review

审查

输出语言： 用用户自己的语言回答并撰写产物（与用户的消息保持一致，而非仓库历史中的语言）。

概述

在开始下一个任务或进行 commit-and-push 之前，对照约定检查工作成果。可审查的对象不总是代码差异：规范（write-spec）、计划（write-plan）或结构决策（solid）都应分别审查，并使用各自的证伪方法。

核心原则：审查产物，而不是你记忆中的意图。

宣布：“正在使用 review 审查 <spec|plan|solid|code>……”

适用时机

• 每个计划任务完成后（执行 write-plan 时）
• 主要功能切片完成后
• 创建或更新 PR/MR 之前
• 规范 / 计划 / 结构决策完成后，且你希望在下游工作以此为依据之前对其进行严格检查
• 遇到阻碍时（重新检查假设）

**不适用时机：**差异为空；用户明确免除审查。

铁律

1. Critical and Important findings BLOCK progress until fixed or explicitly deferred by the human with reason. The **transition gate** at each skill's Hand-off is where that deferral happens — review surfaces findings, the human decides proceed / fix / adjust at the gate.
2. EVERY review carries a claim→case table — the design-level analog of a test suite. No claim→case table, no LGTM.
3. EVERY review checks the artifact against its DIRECT upstream (child must faithfully narrow the parent).
4. NEVER claim "LGTM" without reading the actual artifact (diff, tests, spec text, plan tasks, boundary decisions).
5. Findings are written in the user's conversational language, plain words, no metaphor-for-decoration; each finding says the scene, what someone hits, and where in the artifact.

分派

确定审查对象，打开其参考文档，并且只执行对应的审查准则。

审查对象	时机	参考文档	claim→case 表格基于
code	差异 / 实现切片	references/code.md	差异中的声明（行为 + 测试预期）
spec	设计/规范文档（write-spec 的输出）	references/spec.md	规范中的声明（场景、In/Out、机制、验收标准）
plan	实施计划（write-plan 的输出）	references/plan.md	计划中的声明（每项任务的可测试性、可追溯性）
solid	结构/边界决策	references/solid.md	结构性声明（单元用途、依赖方向、避免形式主义）

混合对象（例如包含规范及其首个实现版本的 PR）？对每个对象分别使用对应参考文档，每个对象各建一份 claim→case 表格，并生成一份报告。

工作流

1. 收集上下文（而非会话中的直觉）：
   • 确定对象类型 → 打开匹配的参考文档
   • 产物本身及其直接上游（审查计划时看规范，审查代码时看计划，审查规范时看讨论决策，审查 solid 时看规范边界）
   • 对于代码：git diff / BASE...HEAD
2. 执行参考文档中的审查准则——claim→case 表格必须作为输出（见下文）。如果可用，优先使用新的子 Agent / 审查者；否则按照相同准则自行审查。
3. 按严重程度报告：Critical / Important / Minor——每项发现都应使用通俗语言，并包含三个部分（场景 → 用户会遇到的问题 → 产物中的位置）。
4. 采取行动：修复 Critical + Important；记录 Minor；如发现有误，提供证据并提出异议。
5. 重新验证——若已实施修复，重新运行 claim→case 表格的相关部分；对于代码，重新运行测试（debug 验证关卡 / tdd）。
6. 交接：准备发布时交由 commit-and-push 处理。

主张→场景表（必需）

未经证伪的主张，就不算经过审查。 与测试套件一样，主张→场景表会将产物中的每个可证伪主张列为一行，注入各种场景，并给出判定。

对于每一行：

• 主张： 产物中的一项可证伪断言（规格验收项、计划任务中的“测试验证 Z”、明确的“领域不依赖 IO”，或代码行为）。
• 注入的场景（至少两个；继续添加，直到这一行不再让你感到意外）：
  • 正常路径
  • 至少一个边界情况（空、零、最大值、刚刚超出范围、首个／最后一个元素、截止时间、配额……）
  • 至少一个极端情况（负载增加 100 倍、上游缺失、权限被拒、网络中断、输入损坏、用户愤怒、午夜跨日……）
  • 如果有，添加一个真实案例——过去的事故、用户投诉、已经发生的回归问题。原文注入真实案例；产物必须经得住考验。
• 判定： PASS / WATCH / BLOCK。
  • PASS — 在注入的场景下均成立。
  • WATCH — 在正常路径下成立，但某个边界／极端／真实场景尚未处理、未说明或存在歧义。
  • BLOCK — 某个场景直接与产物矛盾（悄然增加范围、任务无法追溯、没有人负责边界情况、验收无法演示）。

输出格式 — 每份报告都必须包含的固定部分：

### claim→case table
| Claim | Scenarios injected | Verdict |
|-------|--------------------|---------|
| …     | happy; boundary; extreme; real case   | PASS/WATCH/BLOCK |

对于小型产物，提供完整表格；对于大型产物，写出所有 WATCH／BLOCK 行，并附上一行“其余行均已检查，未发现异常”——不得遗漏任何一行，除非明确注明已全面检查。

真实案例注入： 如果存在真实案例（你有事故文本、失败复现步骤或用户的原话），它优先于虚构场景——必须先用它检查产物。

报告格式

## Review
**Object:** spec | plan | solid | code (BASE...HEAD or paths)
**Upstream checked:** <path or "none — WATCH noted">
**Verdict:** proceed | blocked

### Strengths
- …

### Critical
- …

### Important
- …

### Minor
- …

### claim→case table
| Claim | Scenarios injected | Verdict |
|-------|--------------------|---------|

合理化借口表

借口	事实
“这是个小改动”	小改动也会导致线上故障。照样运行评审规则。
“测试通过了＝没问题”	测试可能只是做做样子。检查主张→场景表是否覆盖了这些主张。
“这只是计划／规格，无需测试”	计划／规格也包含可证伪的主张——这正是主张→场景表的用途。
“用户懂技术，无需使用通俗语言”	发现的问题必须让没参与过讨论的后来者也能读懂。通俗表述是为他们准备的。
“我稍后会在 PR 界面里评审”	现在发现问题；拖到以后只会让问题累积。
“评审者错了，所以忽略”	用证据提出异议——不要对 Critical 置之不理。

危险信号

• 未打开产物便发布（差异、规格文本、计划任务、边界决策）
• 没有通过主张→场景表检查就说“LGTM”
• 存在未解决的 Critical／Important 仍继续推进
• 只评审对象本身，从不检查其直接上游
• 发现的问题只用行话描述，没有具体场景，也没有说明“谁会受到影响”

检查清单

• 已识别对象；已打开匹配的参考资料
• 已取得产物及其直接上游（缺少上游 → 标记为 WATCH）
• 已填写主张→场景表；每项主张均已证伪或检查完毕
• 发现的问题用通俗语言分三部分描述（场景 → 某人遇到的问题 → 位置）；不使用装饰性比喻
• 已分配严重级别；阻塞项已修复或由人工豁免
• 修复落实后已重新运行验证
• 发布时已准备好提交并推送

交接

转换关卡 — 评审报告已完成；发布前询问用户（调用一次 AskUserQuestion；存在未解决的阻塞项时，绝不自动发布报告）：

A) Recommended: Proceed → commit-and-push (clean, or Critical/Important fixed or waived with reason)
B) Fix open Critical/Important first — back to debug / tdd, then return to this gate
C) Adjust — re-review a narrower object / different slice, then return to this gate
D) Something else (I will type it)

• 代码问题 → debug / tdd
• 结构问题 → solid
• 规格／计划中的产品歧义需重新审视 → grill
• 发布 → commit-and-push