forge-reviewlisted
Install: claude install-skill gldu/dev-forge
# forge-review — 3+1 轮审查
## Goal
作为 Reviewer，只产报告 + 修复任务，不直接改代码。
## Workflow
使用 `references/REVIEW.md` 模板分三轮审查（后端/lib 项目跳过第三轮）。
### 第一轮 · Spec 合规审查
逐条对照 REQUIREMENT.md 的 AC：
- [ ] 每条 AC 是否被实现
- [ ] 每条 AC 是否被测试覆盖（链接到 TEST.md）
- [ ] 是否引入了 `out of scope` 里明令排除的内容
- [ ] 是否新增了 REQUIREMENT.md 里没有的功能（范围蔓延）
- [ ] 是否触动了 DESIGN.md 之外的架构
### 第二轮 · 代码质量审查（书本驱动 6 维衰退风险）
#### 2.0 TEST.md 5 轮金字塔完整性
打开 TEST.md，检查"本次测试范围声明"段：
- 5 轮状态都明确（无未填）
- 跳过的轮次都有理由
- 第 1 轮每条 AC 有覆盖
- 第 2~5 轮按需达标
任意一项不达 → 标 🔴 Critical，先回 5-test 补完。
#### 2.1 代码质量诊断 · 6 维衰退风险
| 编号 | 衰退风险 | 诊断问题 | 主要源头 |
|---|---|---|---|
| R1 | Cognitive Overload | 理解这段代码要多少心智？ | Code Complete / Refactoring / DDD |
| R2 | Change Propagation | 改一���会坏多少不相干的地方？ | Clean Architecture / Pragmatic |
| R3 | Knowledge Duplication | 同一个决定被表达在多处？ | Pragmatic / Refactoring / DDD |
| R4 | Accidental Complexity | 代码是否比问题本身更复杂？ | Brooks / Philosophy of SD |
| R5 | Dependency Disorder | 依赖流是否一致方向？ | Clean Architecture / SE@Google |
| R6 | Domain Model Distortion | 代码是否忠实反映业务领域？ | DDD / Refactoring |
路径 A（装了 brooks-lint）：`/brooks-review`，输出必须含 4 要素（Symptom / Source / Consequence / Remedy）+ 书本引用，原样贴入 REVIEW.md。
路径 B（未装）：AI 自己逐个维度诊断，输出同样 4 要素格式。每条都要标 R1~R6 编号、具体 `<file>:<line>`、至少一本书作为 Source。
#### 2.2 架构依赖检查（大型 change 触发）
触发条件：新增/重命名顶级模块 / 危险 import / 引入新中间件 / 跨 >= 5 模块重构。
1. **图谱查询**（工具支持时）：检测循环依赖
```
MATCH (a:Class)-[:CodeRelation {type: 'IMPORTS'}]->(b:Class)-[:CodeRelation {type: 'IMPORTS'}]->(a) RETURN a.name, a.filePath, b.name