1
0

feat(prompts): 添加 proposal-review 和 apply-review 审查提示词

This commit is contained in:
2026-04-22 19:12:03 +08:00
parent f5e45d032e
commit 669cbb8c51
3 changed files with 129 additions and 0 deletions

View File

@@ -12,6 +12,8 @@
| ---- | ---- |
| [prompt-smart-merge.md](prompt-smart-merge.md) | 批量合并 dev 分支到主干,含依赖分析、冲突处理、安全回退 |
| [prompt-spec-review.md](prompt-spec-review.md) | 审查和重构 openspec/specs/ 下的规范文件 |
| [prompt-proposal-review.md](prompt-proposal-review.md) | 审查 openspec 变更文档与讨论内容的一致性 |
| [prompt-apply-review.md](prompt-apply-review.md) | 审查代码实现与 openspec 变更文档的一致性 |
## 书写原则

View File

@@ -0,0 +1,71 @@
审查 openspec apply 完成后的实现是否与变更文档一致,按以下流程执行。
## 约束
- 仅审查代码和文档,不修改源码
- 每批修改建议执行前用提问工具获得用户确认
- 涉及删除/重写操作前必须备份原文件
## 1. 收集
并行读取:
- 本次变更涉及的所有文档proposal.md、design.md、tasks.md、specs/*.md
- 实际变更的源码文件
- 测试文件和测试结果
- openspec/config.yaml
## 2. 分析
根据上下文判断 apply 后是否有手动改动,将实现与文档双向对照:
| 维度 | 检查点 |
| ---- | ------ |
| 目标覆盖 | 代码实现是否覆盖 proposal 中的所有目标;是否有遗漏的功能点 |
| 方案一致性 | 实现是否与 design 中的技术方案一致;是否有偏离设计的地方 |
| 规范遵循 | 代码是否遵循 specs 中的规范要求;是否有违反 SHALL 约束的地方 |
| 任务完成度 | tasks 中每项任务是否真正完成;是否有未完成但标记完成的任务 |
| 测试完整性 | 测试是否覆盖所有场景;是否有跳过、取消、降低难度的测试;测试是否真正验证了功能 |
| 代码质量 | 是否有明显的代码问题(重复、复杂度过高、命名不清等);是否有可优化的地方 |
重点识别:
- 文档要求但未实现的功能 → 需补充代码
- 实现与文档描述不一致的地方 → 根据上下文判断apply 后手动改动则更新文档,否则确认修正方向
- 实现了但文档未提及的功能 → 根据上下文判断apply 后手动改动则补充文档,否则标记为未讨论的新增
- 标记完成但实际未完成的任务
- 掩盖错误的测试skip、only、降低断言强度等
输出审查结果:
1. **问题总览表**:问题类型 × 涉及文件数
2. **逐项分析**:每个问题文件,说明问题、影响和建议
3. **未覆盖清单**:哪些文档要求未在代码中实现(需补充代码)
4. **不一致清单**:哪些实现与文档描述不一致(需确认修正方向)
5. **需补充文档清单**:哪些代码改动未在文档中体现(需补充文档)
6. **任务问题清单**:哪些任务未真正完成或标记错误
7. **测试问题清单**:哪些测试存在问题或掩盖了错误
8. **优化建议清单**:哪些代码可以优化
若所有清单均为空,输出"审查通过,未发现问题",跳至步骤 5。
## 3. 计划(用户确认)
针对发现的问题,分类提出修复方案:
**需补充代码**:文档要求但未实现的功能,建议补充实现。
**需补充文档**:代码已实现但文档未记录,且上下文确认为 apply 后手动改动,建议更新 proposal/design/tasks/specs。
**需确认修正方向**:实现与文档不一致,且上下文无法判断:
- 若为 apply 后手动改动 → 更新文档
- 否则用提问工具确认以文档还是代码为准
**任务和测试问题**:逐项说明未完成原因、测试掩盖错误的风险,提出修复方案。
用提问工具展示完整修复方案,获得用户确认后执行。
## 4. 执行
逐项执行修复方案。
## 5. 收尾
列出所有修改的文件和变更摘要。

View File

@@ -0,0 +1,56 @@
审查 openspec 变更文档proposal、design、tasks、specs是否完整准确地记录技术方案按以下流程执行。
## 约束
- 仅审查文档内容,不修改源码
- 每批修改建议执行前用提问工具获得用户确认
- 涉及删除/重写操作前必须备份原文件
## 1. 收集
并行读取:
- 本次变更涉及的所有文档proposal.md、design.md、tasks.md、specs/*.md
- 之前上下文中讨论的内容
- openspec/config.yaml
- 与变更规范有依赖关系的其他规范
## 2. 分析
将文档与讨论内容逐项对照,检查:
| 文档 | 检查点 |
| ---- | ------ |
| proposal.md | 是否完整记录讨论确定的目标、范围、影响;是否遗漏决策点 |
| design.md | 是否覆盖讨论中所有技术方案;边界条件和异常处理是否与讨论一致 |
| tasks.md | 是否覆盖 design 中所有方案;任务划分是否合理;依赖关系是否明确 |
| specs/*.md | 是否严格遵循 OpenSpec 格式;术语是否一致;依赖声明是否完整;无实现细节混入 |
重点识别:
- 讨论中确定但文档未记录的内容
- 文档描述与讨论不一致的地方
- 文档新增但未在讨论中提及的内容
输出审查结果:
1. **问题总览表**:问题类型 × 涉及文档数
2. **逐项分析**:每个问题文档,说明问题、影响和建议
3. **缺失清单**:哪些技术方案/需求未在文档中体现
4. **冲突清单**:哪些描述与其他文档或讨论结果不一致
5. **待澄清清单**:哪些事项描述不明确,需要进一步确认
若所有清单均为空,输出"审查通过,未发现问题",跳至步骤 5。
## 3. 计划(用户确认)
针对发现的问题,提出修复方案(补充遗漏、修正冲突、优化表述)。
针对待澄清清单,用提问工具逐项向用户确认,根据反馈更新文档。
用提问工具展示完整修复方案,获得用户确认后执行。
## 4. 执行
逐项执行修复方案。
## 5. 收尾
列出所有修改的文件和变更摘要。