receive-review

Files (1)

• SKILL.md

SKILL.md (first lines)

# receive-review

接收审查反馈并按严重度分类处理。禁止表演性同意——用代码修改证明你收到了反馈。

## 何时使用

- 收到其他猫的审查反馈时
- 审查（code-review）后审查者返回了结论

## 不使用的情况

- 审查结论是 ✅ 可以合并 / 💬 仅评论（非阻断、无需处理）
- 自己是审查者（用 code-review 返回结果，不是 receive）

## 执行步骤

### 步骤 1：分类审查发现

将审查者的每一条发现归入严重度等级（参照 `skills/refs/review-standards.md`）：

- **P1 阻断**：安全漏洞、数据丢失、功能崩溃
- **P2 必须修**：逻辑错误、性能问题、资源泄漏、架构违规
- **P3 可选修**：命名、注释、代码风格

### 双轴处理（code-review 方法论）

审查发现来自两条独立轴，分开处理、分开验证：

- **Standards 发现**（违反文档化规范）→ 对照 CODING_STANDARDS 核实；文档规范明说是硬违规，坏味道是判断标签
- **Spec 发现**（需求缺失/范围蔓延/实现错误）→ 对照发起它的 spec/issue 逐条核实

**一条轴通过不豁免另一条轴**——Standards 全过但 Spec 缺需求仍需修。区分硬违规与判断标签：文档化规范优先于坏味道基线，工具已强制的跳过。

### 步骤 2：VERIFY 三道门（每条发现都要过）

在接受任何审查发现之前：

**门 1 — Spec Gate**：这个修改建议是否与现有需求冲突？
**门 2 — Mechanism Gate**：审查者是否有具体的失败证据，还是仅仅"不够优雅"？
**门 3 — Feature Gate**：采纳这个建议后，核心用户路径是否仍然正常？

三道门通过 → 接受并修复
任何一道门不通过 → 标记为"讨论"，说明理由后回复审查者

### 步骤 3：FAILURE-MODE SWEEP（失败模式扫描）

如果 2+ 个 P1/P2 发现属于同一失败模式（同一类 bug 的变体），**在修复任何一条之前**：

1. 扫描整个 diff，查找同一模式的全部出现位置
2. 一次性修复所有同类问题
3. 在修复确认中标注 "sweep: {模式名}, 扫描 N 处, 修复 N 处"

### 步骤 4：逐项修复

按 P1 → P2 → P3 顺序修复：

1. 先修所有 P1
2. 再修所有 P2
3. P3：现场修或明确放弃（写进结论）
4. 每修完一类，运行 `pnpm test` 确认无回归

### 步骤 5：3 轮升级规则

如果同一个有状态对象（同一个文件/模块/函数）连续 3 轮审查都有发现：

- 停止代码级别的修补
- 回到设计层面，重新评估方案
- 可能需要对问题模块做整体重构

### 步骤 6：生成修复确认

```
## 修复确认

| # | 级别 | 发现 | 状态 | 修复 |
|---|------|------|------|------|
| P1-1 | P1 | {描述} | ✅ done | {文件}: {修改说明} |
| P2-1 | P2 | {描述} | ✅ done | {文件}: {修改说明} |
| P3-1 | P3 | {描述} | ❌ dropped | 理由: {为什么不修} |

测试: pnpm test → N passed, 0 failed

@审查者 修复完成，请确认
```

## 禁止的行为

| 禁止                      | 正确做法             |
| ------------------------- | -------------------- |
| "你说得对！" / "好主意！" | 直接用代码修改证明   |
| 盲目接受所有建议          | 每条过 VERIFY 三道门 |
| P3 写 BACKLOG             | P3 现场处理或放弃    |
| 只修一条忽略同类          | Failure-mode sweep   |
| 3 轮后继续修补同一文件    | 升级到设计层面       |

## 衔接

- 修复完成 → 通知审查者确认
- 审查者确认 ✅ → 可以合并
- 审查者仍不满意 → 回到步骤 1（新一轮）
- 3 轮未收敛 → 升级到设计重新评估

## Common Mistakes

| 错误                                 | 正确做法                                                                     |
| ------------------------------------ | ---------------------------------------------------------------------------- |
| 回「你说得对！好主意！」             | 直接用代码修改证明收到了反馈——表演性同意是禁区                               |
| 盲信审查结论不核实                   | 每条发现过 VERIFY 三道门（Spec / Mechanism / Feature），不通过就标记「讨论」 |
| 只修审查者点名的第一条，同类问题漏掉 | 2+ 条同类发现 → failure-mode sweep，扫描全 diff 一次修完                     |
| P3 写进 BACKLOG 攒着                 | P3 现场修或明确放弃，理由写进结论                                            |
| Standards/Spec 两轴混在一起处理      | 分开核实：一条轴过了不代表另一条也过，硬违规与判断标签分开报                 |

## 与其他 skill 区别

| skill        | 区别                                                                         |
| ------------ | ---------------------------------------------------------------------------- |
| code review  | code-review 产生审查结论，receive-review 接收并处理反馈                      |
| quality-gate | quality-gate 是作者自查（提交前）；receive-review 是收到他人审查后的处理流程 |
| code-review  | code-review 是执行双轴审查产出结论；receive-review 是结论的接收方            |

From JianHun101/catStudio, MIT.

More from JianHun101/catStudio