---
name: rr
description: 评审 RequirementsDoc.md，检查需求文档的完整性、清晰度和可执行性，输出结构化评审报告。
---

# Review RequirementsDoc

当用户调用 `/rr` 时，执行以下步骤：

## 1. 读取目标文档

读取 `doc/RequirementsDoc.md` 文件。

如果文件不存在，提示用户：
> RequirementsDoc.md 不存在，请先创建需求文档。

## 2. 评审维度

RequirementsDoc 是文档链的源头，没有上游依赖。重点检查以下维度：

### 2.1 完整性
- [ ] 产品概述是否清晰（定位、目标用户、核心价值）
- [ ] 功能需求是否完整列出
- [ ] 非功能需求是否涵盖（性能、安全、兼容性）
- [ ] 数据规范是否明确（输入输出格式、字段定义）
- [ ] 边界条件和异常情况是否考虑

### 2.2 清晰度
- [ ] 术语定义是否一致，无歧义
- [ ] 用例描述是否具体可理解
- [ ] 优先级是否明确标注
- [ ] 是否有模糊表述（"等"、"可能"、"应该"等）

### 2.3 可执行性
- [ ] 需求是否可被验证（有明确的验收标准）
- [ ] 技术约束是否合理
- [ ] 依赖项是否明确

### 2.4 结构规范
- [ ] 文档结构是否清晰（章节划分合理）
- [ ] 格式是否统一（表格、列表、标题层级）

## 3. 生成评审报告

按以下格式输出评审报告：

```markdown
# RequirementsDoc 评审报告

## 概要

| 项目 | 内容 |
|------|------|
| 评审时间 | {YYYY-MM-DD HH:mm} |
| 目标文档 | doc/RequirementsDoc.md |
| 问题统计 | {critical} 个严重 / {major} 个一般 / {minor} 个建议 |

## 问题清单

### 严重问题 (Critical)

> 必须修复，否则影响后续文档生成

1. **[位置: 第X节/第Y行]** 问题描述
   - 现状：...
   - 建议：...

### 一般问题 (Major)

> 建议修复，可提升文档质量

1. **[位置]** 问题描述
   - 建议：...

### 改进建议 (Minor)

> 可选优化项

1. **[位置]** 建议内容

## 评审结论

{通过 / 需修改后通过 / 不通过}

### 下一步行动

- [ ] 行动项1
- [ ] 行动项2
```

## 4. 保存报告

将评审报告保存到 `doc/review-RequirementsDoc-claude.md`。

如果文件已存在，覆盖原文件（历史版本通过 git 追溯）。

## 5. 输出摘要

向用户展示评审摘要：
- 发现的问题数量（按严重程度分类）
- 评审结论
- 报告文件路径

---

## 注意事项

- 评审时保持客观，聚焦于文档质量而非业务判断
- 问题描述要具体，给出明确的位置引用
- 建议要可操作，避免模糊表述
- 不要修改原文档，只输出评审报告