feat(skills): add codex compatibility

2026-03-09 21:27:05 +08:00
parent 755dd3409c
commit 423c6079b1
30 changed files with 4195 additions and 53 deletions
@@ -0,0 +1,111 @@
+---
+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.md`。
+
+如果文件已存在，覆盖原文件（历史版本通过 git 追溯）。
+
+## 5. 输出摘要
+
+向用户展示评审摘要：
+- 发现的问题数量（按严重程度分类）
+- 评审结论
+- 报告文件路径
+
+---
+
+## 注意事项
+
+- 评审时保持客观，聚焦于文档质量而非业务判断
+- 问题描述要具体，给出明确的位置引用
+- 建议要可操作，避免模糊表述
+- 不要修改原文档，只输出评审报告