| name | arkweb-spec-review |
| description | ArkWeb Spec 文档评审。可作为独立 subagent 运行。检查文档完整性、一致性、可行性。触发词：评审设计文档、Spec review、检查设计文档、需求评审。 |
ArkWeb Spec 文档评审
Announce at start: "我正在使用 arkweb-spec-review skill 评审设计文档。"
运行模式
模式 A：Subagent 模式（推荐）
作为独立 subagent 被 arkweb-architect 调用时，设计文档和代码分析结果路径已在 task 描述中提供，直接执行评审。
输入格式（从 task 描述中解析）：
## 待评审文档
{DOCS_REPO}/docs/{date}-{feature}-requirement.md
## 代码分析结果（用于交叉验证）
{DOCS_REPO}/analysis/{date}-{feature}-analysis.md
## 参考资料（按需读取）
- ACE Engine 索引：{DOCS_REPO}/analysis/arkweb-ace-engine-analysis.md
- WebWebView 分析：{DOCS_REPO}/analysis/web-webview-analysis.md
输出： 评审报告 → 保存到指定路径 → 回复评审结果摘要
模式 B：交互模式
在主 session 中直接调用，评审完成后呈现给用户，用户决定是否修改。
模式 C：最小化检视流程（独立检视 + 修改闭环）
适用于已有设计文档，只需检视和修改的场景，跳过 brainstorm/code-analysis/design-doc 全链路。
触发词： 检视设计文档、review checklist、快速检视
流程：检视 → 修改 → 复审 → 提 PR
Step 1: 读取设计文档 + Checklist 模版
Step 2: 执行 Checklist 33 项检视（输出结果表）
Step 3: 有阻塞项？
├─ 否 → 输出"通过"，流程结束
└─ 是 → 逐组修改设计文档
├─ 每组修改提交一个 PR
├─ 老板审批合并
├─ 合并后重新检视该组修改项
└─ 全部通过 → 流程结束
与模式 A/B 的区别：
- 不执行完整评审维度检查（5 维度 31 项），仅做 Checklist 33 项检视
- 不依赖代码分析结果交叉验证
- 检视不通过时直接修改文档（而非打回 design-doc skill）
- 每组修改独立提 PR，合并后复审该组，不重跑全量检视
概述
对已生成的 ArkWeb 设计文档进行系统评审，确保完整性、一致性和技术可行性。
评审维度
1. 完整性检查（10 项）
2. 一致性检查（6 项）
3. 技术可行性检查（5 项）
4. DFX 完整性（6 项）
5. 文档规范（4 项）
6. 接口设计规范（7 项 — 历史纠正项固化）
⚠️ 以下为多轮评审反复出现的问题，已固化为强制检查项：
需求检视 Checklist
评审流程中嵌入结构化检视环节，使用通用 Checklist 模版（assets/templates/requirement-design-review-checklist.md）逐项检查设计文档质量。
Checklist 为设计文档评审的质量门禁：检视不通过时，要求 design-doc 修改后重新评审。
Checklist 分类
- 必选（27 项）： 大部分设计文档需要满足，少量不涉及的可填写不涉及
- 可选（6 项）： 设计文档中写明不涉及即通过，如涉及则需评审满足度
检视时机
在 Step 2 逐项检查完成后、Step 3 输出报告前执行。
检视不通过的处理
- 🔴 必选项不满足 → 打回 design-doc 修改，修改后重新走 spec-review
- ⚠️ 可选项涉及但不满足 → 建议修改，不阻塞
- ❌ 必选项不涉及 → 需在说明列给出不涉及理由
Checklist 模版路径
assets/templates/requirement-design-review-checklist.md
8 大类 33 项：需求分析(5) / 需求规格(3) / KPI&KQI(4) / 模块(3) / 接口(2) / 设计(8) / 可测试性(3) / 安全(5)
流程
Step 1: 读取文档
读取待评审文档 + 代码分析结果（用于交叉验证类名、接口签名、文件路径）。
Step 2: 逐项检查
按上述 5 个维度逐项检查，记录问题。
交叉验证要点：
- 设计文档中的类名是否在 ace_engine 分析中存在
- 接口签名是否与 web_webview 分析中的定义一致
- 文件路径是否正确
Step 2.5: Checklist 结构化检视
基于 assets/templates/requirement-design-review-checklist.md 逐项检查，输出 Checklist 结果表：
## Checklist 检视结果
| # | 检查项 | 必/可选 | 状态 | 说明 |
|---|--------|---------|------|------|
| 1 | ... | 必选 | ✅/⚠️/❌ | ... |
| ... | ... | ... | ... | ... |
### 检视统计
- 必选满足：N / 27
- 必选不满足：N（阻塞项）
- 必选不涉及：N
- 可选涉及：N / 6
- 可选不涉及：N
### 检视结论
✅ 通过 / ❌ 不通过（N 项必选阻塞）
判定规则：
- 必选无"不满足"项 → ✅ 通过，进入 Step 3
- 必选有"不满足"项 → ❌ 不通过，输出评审报告后打回 design-doc 修改
Step 3: 输出评审报告
# {文档名} 评审报告
## 评审结果：{通过 / 需修改 / 不通过}
## Checklist 检视结果
| # | 检查项 | 必/可选 | 状态 | 说明 |
|---|--------|---------|------|------|
| 1 | ... | 必选 | ✅/⚠️/❌ | ... |
### 检视统计
- 必选满足：N / 27 | 必选不满足：N | 必选不涉及：N
- 可选涉及：N / 6 | 可选不涉及：N
- 检视结论：✅ 通过 / ❌ 不通过
## 问题清单
### 🔴 必须修改（含 Checklist 必选不满足项）
1. [描述] - 位置：{章节} - 来源：Checklist #N
### 🟡 建议修改
1. [描述] - 位置：{章节}
### 🟢 优秀实践
1. [描述]
## 统计
- Checklist 总检查项：33（必选 27 / 可选 6）
- Checklist 满足：N | 不满足：N | 不涉及：N
- 评审维度检查项：N
- 通过：N
- 🔴 必须修改：N 项
- 🟡 建议修改：N 项
- 🟢 优秀实践：N 项
Step 4: 闭环处理
Checklist 不通过时（必选有阻塞项）
- 输出评审报告，明确列出 Checklist 不满足项
- 打回
arkweb-design-doc 修改
- 修改后重新走 spec-review 流程
Checklist 通过但评审维度有问题时
- 🔴 必须修改项：打回 design-doc 修改
- 🟡 建议修改项：不阻塞，记录在评审报告中
全部通过时
Step 5: 输出
Subagent 模式
保存评审报告并回复结果摘要。不执行修改（由主 session 的决策 3 处理）。
交互模式
呈现评审结果，用户决定是否修改。修改后可重新评审。
产出物
- 路径：
{DOCS_REPO}/docs/YYYY-MM-DD-{feature-name}-review.md
Subagent 回复格式
✅ spec-review 完成
📄 报告：{file_path}
📊 评审结果：{通过 / 需修改 / 不通过}
📋 Checklist 检视：满足 N/33 | 不满足 N | 不涉及 N（必选阻塞 N）
- 总检查项：{N}，通过：{N}
- 🔴 必须修改：{N} 项
- 🟡 建议修改：{N} 项
- 🟢 优秀实践：{N} 项
