wenjunduan RIPER-PACE 工作流引擎
收到任务后: PACE 选路径, RIPER 按路径执行。
当前项目状态
!cat .ai_state/project.json 2>/dev/null
待办任务
!cat .ai_state/tasks.md 2>/dev/null
前置检查
.ai_state/ 不存在? → 创建目录, 从本 skill 的 templates/ 复制模板文件:
mkdir -p .ai_state/reviews
cp ${CLAUDE_SKILL_DIR}/templates/project.json .ai_state/
cp ${CLAUDE_SKILL_DIR}/templates/tasks.md .ai_state/
cp ${CLAUDE_SKILL_DIR}/templates/design.md .ai_state/
cp ${CLAUDE_SKILL_DIR}/templates/lessons.md .ai_state/
有进行中的 stage? → 从当前 stage 继续, 不要重新路由。
PACE 路由
评估任务的 5 维度, 取最高匹配:
| 维度 | A (快速) | B (标准) | C (复杂) | D (系统) |
|---|---|---|---|---|
| 文件 | 1-3 | 4-10 | 10+ | 跨服务 |
| 时间 | <30min | 30min-4h | 4h-2d | >2d |
| 架构 | 无影响 | 局部 | 跨模块 | 系统级 |
| 测试 | 单元 | 单元+集成 | 含 E2E | 全链路 |
| 风险 | 低 | 中 | 高 | 极高 |
路径 → 阶段映射:
A: ───────── E → T
B: R₀→R→D→P→E→T→V
C: 同 B + /batch 并行 + 对抗审查
D: 同 C + 设计评审
路由完成 → 更新 .ai_state/project.json → 告知用户 → 进入首阶段。
RIPER 阶段
每阶段通用
- 读 .ai_state/project.json 的 gotchas → 避开
- 读 .ai_state/lessons.md → 参考历史教训
- 完成后更新 project.json 的 stage 字段
R₀ 需求精炼 (Path B+)
目标: 模糊需求 → 可验收 Spec
工具: superpowers brainstorming (自动激活) · ctx7 library + ctx7 docs (查库文档) · augment-context-engine (跨文件关联)
产出: .ai_state/design.md (MUST/SHOULD/COULD + 验收标准)
门控: cunzhi DESIGN_READY 检查点 (如可用) 或直接问用户确认 → stage="R"
详细指引: → plan/SKILL.md 阶段 R₀
R 技术调研 (Path B+)
目标: 验证技术方案可行, 排除风险
工具: Grep (搜项目代码) · ctx7 library + ctx7 docs (查库 API) · augment-context-engine (语义搜索) · Read (conventions/lessons)
产出: design.md 追加技术方案段 (接口/依赖/风险)
门控: 技术方案非空 → stage="D"
详细指引: → plan/SKILL.md 阶段 R
D 方案定稿 (Path B+)
目标: 锁定方案, 生成 Sprint Contract
工具: @evaluator (方案评审) · /review (快速审查)
约束: /codex:adversarial-review 只审查代码, D 阶段无代码, 不要用
产出:
- design.md 最终版
- .ai_state/tasks.md 填充 Task 清单 门控: cunzhi SPRINT_CONTRACT 检查点 (如可用) 或直接问用户确认 → stage="P" 详细指引: → plan/SKILL.md 阶段 D
P 计划排期 (Path B+)
目标: 确定 Task 执行顺序和依赖 工具: 主 Agent 分析 产出: tasks.md 补充依赖和执行顺序 约束: 用 VibeCoding 的 tasks.md 格式 (- [ ] F001/T001: 描述)。如果 superpowers writing-plans 自动激活, 以 VibeCoding 格式为准。 门控: tasks.md 非空 → stage="E" 详细指引: → plan/SKILL.md 阶段 P
E 执行 (所有 Path)
目标: 逐个完成 Task, 产出通过测试的代码 详细指引: → execute/SKILL.md 门控: tasks.md 所有 Task 完成 (Sisyphus) → stage="T"
T 审查 (所有 Path)
目标: 独立验证质量, 产出审查报告和评分 详细指引: → review/SKILL.md 门控:
- PASS (≥4.0) → stage="V"
- CONCERNS (3.0-3.9) → 修复后重新评分
- REWORK (2.0-2.9) → 回 E
- FAIL (<2.0) → 回 D
V 归档 (Path B+)
目标: 更新知识库, 为下次迭代积累 产出:
- project.json: conventions + gotchas 更新
- lessons.md: 追加本 Sprint 教训
- project.json: stage="", sprint+1
阶段转换规则
- 前进: 满足门控 → 更新 stage → 进入下一阶段
- 后退: T-REWORK→E; T-FAIL→D
- 跳过: Path A 只做 E→T
- 中断恢复: 下次触发 skill 时
!command注入状态, 从当前 stage 继续
Gotchas
- ❌ 收到任务直接写代码 → ✅ 先 PACE 路由
- ❌ D 阶段用 /codex:adversarial-review → ✅ 该命令审查代码, D 阶段无代码
- ❌ E 完成一半就进 T → ✅ Sisyphus: 全部 Task 完成才能进 T
- ❌ T-CONCERNS 就交付 → ✅ 修复后重新评分