Riper Pace

---
name: riper-pace
effort: high
description: >
  任务分析和工作流调度。收到开发任务、需求分析、或不确定从哪开始时触发。
---

# 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 阶段

### 每阶段通用
1. 读 .ai_state/project.json 的 gotchas → 避开
2. 读 .ai_state/lessons.md → 参考历史教训
3. 完成后更新 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 阶段无代码, 不要用
**产出:**
1. design.md 最终版
2. .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+)

**目标:** 更新知识库, 为下次迭代积累
**产出:**
1. project.json: conventions + gotchas 更新
2. lessons.md: 追加本 Sprint 教训
3. project.json: stage="", sprint+1

---

## 阶段转换规则

1. 前进: 满足门控 → 更新 stage → 进入下一阶段
2. 后退: T-REWORK→E; T-FAIL→D
3. 跳过: Path A 只做 E→T
4. 中断恢复: 下次触发 skill 时 `!command` 注入状态, 从当前 stage 继续

## Gotchas

- ❌ 收到任务直接写代码 → ✅ 先 PACE 路由
- ❌ D 阶段用 /codex:adversarial-review → ✅ 该命令审查代码, D 阶段无代码
- ❌ E 完成一半就进 T → ✅ Sisyphus: 全部 Task 完成才能进 T
- ❌ T-CONCERNS 就交付 → ✅ 修复后重新评分