📝 docs(templates): refine superpowers prompt boundaries
This commit is contained in:
@@ -1,38 +1,56 @@
|
||||
# 变更验证模板
|
||||
|
||||
<!--
|
||||
用途:在声明“完成 / 修复 / 可交付”前,明确验证范围与证据
|
||||
触发:代码修改、配置修改、模板修改、规则修改后
|
||||
用途:在声明“完成 / 修复 / 可交付”前,用 fresh run 证明改动成立。
|
||||
触发:代码、配置、模板、规则修改后;准备交付结果前。
|
||||
-->
|
||||
|
||||
## 验证目标
|
||||
|
||||
- 这次改动要证明什么?
|
||||
- 哪些行为必须通过?
|
||||
- 哪些验证本轮不做?
|
||||
- 这次改动要证明什么
|
||||
- 哪些行为必须通过
|
||||
- 哪些验证本轮不做
|
||||
|
||||
## 先读
|
||||
|
||||
- `AGENT_RULES.md`
|
||||
- `memory-bank/progress.md`
|
||||
- 如存在:`docs/prompts/custom/verify.md`
|
||||
|
||||
## 规则
|
||||
|
||||
- 没有证据,不宣称完成
|
||||
- 验证命令必须 fresh run
|
||||
- 局部修改优先局部验证
|
||||
- 不能运行的验证必须写明原因
|
||||
- 不手工改写 `workflow-state` 或 `plan-status` 状态块
|
||||
|
||||
## 验证步骤
|
||||
|
||||
### 1. 语法 / 结构检查
|
||||
1. 做语法或结构检查,确认改动文件可读、可解析
|
||||
2. 运行与本次改动直接相关的验证命令
|
||||
3. 记录命令、结果和关键输出
|
||||
4. 复核 diff 是否只包含预期修改
|
||||
5. 复核 `workflow-state.phase`、`plan-status` 与当前声明一致
|
||||
6. 汇总未覆盖项和剩余风险
|
||||
|
||||
- 确认修改文件可读、可解析、无明显结构错误
|
||||
## 输出协议
|
||||
|
||||
### 2. 定向验证
|
||||
```markdown
|
||||
## Validated
|
||||
- ...
|
||||
|
||||
- 只跑与本次改动直接相关的验证命令
|
||||
- 记录命令、结果和关键输出
|
||||
- 如仓库存在项目私有验证提示词(例如 `docs/prompts/custom/verify.md`),先读取并执行其中的附加约束
|
||||
## Evidence
|
||||
- ...
|
||||
|
||||
```bash
|
||||
{{VERIFY_CMD}}
|
||||
## Not Validated
|
||||
- ...
|
||||
|
||||
## Risks
|
||||
- ...
|
||||
```
|
||||
|
||||
### 3. 差异复核
|
||||
|
||||
- 核对 diff 是否只包含预期修改
|
||||
- 确认没有误删、误改、命名漂移或路径漂移
|
||||
|
||||
### 4. 状态留痕复核
|
||||
## 状态留痕复核
|
||||
|
||||
- `workflow-state.phase` 是否与当前声明一致
|
||||
- `plan-status` 是否已经通过 `main_loop.py finish` 写回
|
||||
@@ -40,29 +58,10 @@
|
||||
`executor=executing-plans`
|
||||
`constraints=karpathy-guidelines,.agents,AGENT_RULES`
|
||||
|
||||
### 5. 剩余风险
|
||||
## 停止条件
|
||||
|
||||
- 本轮未覆盖的验证
|
||||
- 环境限制
|
||||
- 需要人工确认的点
|
||||
|
||||
## 输出格式
|
||||
|
||||
```markdown
|
||||
## 验证结果
|
||||
|
||||
- 已验证:...
|
||||
- 证据:...
|
||||
- 未验证:...
|
||||
- 风险:...
|
||||
```
|
||||
|
||||
## 原则
|
||||
|
||||
- 没有证据,不宣称完成
|
||||
- 局部修改优先局部验证
|
||||
- 不能运行的验证要明确写原因
|
||||
- 不手工改写 `workflow-state` 或 `plan-status` 状态块
|
||||
- 关键验证失败时停止并汇报
|
||||
- 证据不足以支持“完成”结论时停止并汇报
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user