rpi

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

/rpi — Full RPI Lifecycle Orchestrator

/rpi — 完整RPI生命周期编排器

Quick Ref: One command, full lifecycle. Research → Plan → Pre-mortem → Crank → Vibe → Post-mortem. The session IS the lead. Sub-skills manage their own teams.

YOU MUST EXECUTE THIS WORKFLOW. Do not just describe it.

快速参考： 一条命令，覆盖全生命周期。研究→规划→事前复盘→实施→最终验证→事后复盘。会话为主导，子Skill自主管理各自团队。

你必须执行此工作流，而非仅进行描述。

Quick Start

快速开始

bash

/rpi "add user authentication"              # Full lifecycle, fully autonomous (default)
/rpi --interactive "add user authentication" # Human gates at research + plan
/rpi --from=plan "add auth"                 # Skip research, start from plan
/rpi --from=crank ag-23k                    # Skip to crank with existing epic
/rpi --from=vibe                            # Just run final validation + post-mortem
/rpi --loop --max-cycles=3 "add auth"       # Gate 4 loop: post-mortem FAIL -> spawn another /rpi cycle
/rpi --test-first "add auth"               # Spec-first TDD (contracts → tests → impl)

bash

/rpi "add user authentication"              # 全生命周期，完全自主执行（默认模式）
/rpi --interactive "add user authentication" # 在研究和规划阶段启用人工审核节点
/rpi --from=plan "add auth"                 # 跳过研究阶段，从规划阶段开始
/rpi --from=crank ag-23k                    # 跳过前期阶段，直接进入实施阶段（需传入现有epic ID）
/rpi --from=vibe                            # 仅运行最终验证+事后复盘
/rpi --loop --max-cycles=3 "add auth"       # 启用第4节点循环：事后复盘失败时，启动新的/rpi周期
/rpi --test-first "add auth"               # 采用先写测试的TDD模式（契约→测试→实现）

Architecture

架构

/rpi <goal | epic-id> [--from=<phase>] [--interactive]
  │  (session = the lead, no TeamCreate)
  │
  ├── Phase 1: /research ── auto (default) or human gate (--interactive)
  ├── Phase 2: /plan ────── auto (default) or human gate (--interactive)
  ├── Phase 3: /pre-mortem ── auto (FAIL → retry loop)
  ├── Phase 4: /crank ────── autonomous (manages own teams)
  ├── Phase 5: /vibe ──────── auto (FAIL → retry loop)
  └── Phase 6: /post-mortem ── auto (council + retro + flywheel)

Human gates (default): 0 — fully autonomous, all gates are retry loops Human gates (--interactive mode): 2 (research + plan approval, owned by those skills) Retry gates: pre-mortem FAIL → re-plan, vibe FAIL → re-crank, crank BLOCKED/PARTIAL → re-crank (max 3 attempts each) Gate 4 (optional): post-mortem FAIL → spawn another /rpi cycle (enabled via

--loop

)

Read

references/phase-data-contracts.md

for the full phase-to-phase data contract table.

/rpi <目标 | epic-id> [--from=<阶段>] [--interactive]
  │  (会话为主导，无需创建团队)
  │
  ├── 阶段1: /research ── 自动执行（默认）或人工审核节点（--interactive模式）
  ├── 阶段2: /plan ────── 自动执行（默认）或人工审核节点（--interactive模式）
  ├── 阶段3: /pre-mortem ── 自动执行（失败则进入重试循环）
  ├── 阶段4: /crank ────── 自主执行（自主管理团队）
  ├── 阶段5: /vibe ──────── 自动执行（失败则进入重试循环）
  └── 阶段6: /post-mortem ── 自动执行（评审+回顾+飞轮反馈）

人工审核节点（默认）： 0个——完全自主执行，所有节点为重试循环 人工审核节点（--interactive模式）： 2个（研究和规划阶段的审核，由对应Skill负责） 重试规则： 事前复盘失败→重新规划，最终验证失败→重新实施，实施阻塞/部分完成→重新实施（每个节点最多3次尝试） 可选第4节点： 事后复盘失败→启动新的/rpi周期（通过

--loop

参数启用）

查看

references/phase-data-contracts.md

获取完整的阶段间数据契约表。

Execution Steps

执行步骤

Given

/rpi <goal | epic-id> [--from=<phase>] [--interactive]

给定命令

/rpi <目标 | epic-id> [--from=<阶段>] [--interactive]

：

Step 0: Setup

步骤0：初始化

bash

mkdir -p .agents/rpi

Large-repo mode (recommended when context is tight):

If the repo is large (for example, >1500 tracked files), initialize deterministic context-window shards before Phase 1:

bash

scripts/rpi/context-window-contract.sh

Read

references/context-windowing.md

for shard generation, progress tracking, and bounded one-shard-at-a-time execution.

Determine the starting phase:

Default: Phase 1 (research)
```
--from=plan
```
: Start at Phase 2
```
--from=pre-mortem
```
: Start at Phase 3
```
--from=crank
```
: Start at Phase 4 (requires epic-id)
```
--from=vibe
```
: Start at Phase 5
```
--from=post-mortem
```
: Start at Phase 6

If input looks like an epic-id (matches

ag-*

or similar bead prefix pattern), treat it as an existing epic and skip to the appropriate phase (default: crank if no --from specified).

Check for harvested next-work from prior RPI cycles:

bash

if [ -f .agents/rpi/next-work.jsonl ]; then
  # Read unconsumed entries (consumed: false)
  # Schema: .agents/rpi/next-work.schema.md
fi

If unconsumed entries exist in

.agents/rpi/next-work.jsonl

In
```
--auto
```
mode: use the highest-severity item's title as the goal (no user prompt)
In
```
--interactive
```
mode: present items via AskUserQuestion and let user choose or provide custom goal
If goal was already provided by the user, ignore next-work.jsonl (explicit goal takes precedence)

Initialize state:

rpi_state = {
  goal: "<goal string>",
  epic_id: null,     # populated after Phase 2
  phase: "<starting phase>",
  auto: <true unless --interactive flag present>,
  test_first: <true if --test-first flag present>,
  fast_path: false,  # auto-detected after Phase 2, or forced via --fast-path
  cycle: 1,          # RPI iteration number (incremented on --spawn-next)
  parent_epic: null,  # epic ID from prior cycle (if spawned from next-work)
  verdicts: {}       # populated as phases complete
}

bash

mkdir -p .agents/rpi

大型仓库模式（上下文紧张时推荐）：

如果仓库规模较大（例如，跟踪文件超过1500个），在进入阶段1前初始化确定性上下文窗口分片：

bash

scripts/rpi/context-window-contract.sh

查看

references/context-windowing.md

了解分片生成、进度跟踪和单次单分片的受限执行方式。

确定起始阶段：

默认：阶段1（研究）
```
--from=plan
```
：从阶段2开始
```
--from=pre-mortem
```
：从阶段3开始
```
--from=crank
```
：从阶段4开始（需传入epic-id）
```
--from=vibe
```
：从阶段5开始
```
--from=post-mortem
```
：从阶段6开始

如果输入内容符合epic-id格式（匹配

ag-*

或类似前缀模式），则视为已有epic，直接跳转到对应阶段（默认：若无--from参数则进入实施阶段）。

检查之前RPI周期中收集的待办工作：

bash

if [ -f .agents/rpi/next-work.jsonl ]; then
  # 读取未处理的条目（状态：consumed: false）
  #  schema: .agents/rpi/next-work.schema.md
fi

如果

.agents/rpi/next-work.jsonl

中存在未处理条目：

在
```
--auto
```
模式下：将最高优先级条目标题作为执行目标（无需用户输入）
在
```
--interactive
```
模式下：通过AskUserQuestion展示条目，由用户选择或自定义目标
如果用户已提供明确目标，则忽略next-work.jsonl（明确目标优先级更高）

初始化状态：

rpi_state = {
  goal: "<目标字符串>",
  epic_id: null,     # 阶段2完成后填充
  phase: "<起始阶段>",
  auto: <true，除非传入--interactive参数>,
  test_first: <true，如果传入--test-first参数>,
  fast_path: false,  # 阶段2完成后自动检测，或通过--fast-path参数强制启用
  cycle: 1,          # RPI迭代次数（--spawn-next时递增）
  parent_epic: null,  # 上一周期的epic ID（如果从待办工作启动）
  verdicts: {}       # 阶段完成后填充结果
}

Phase 1: Research

阶段1：研究

Skip if:

--from

is set to a later phase.

Skill(skill="research", args="<goal> --auto")   # always --auto unless --interactive

By default, /research runs with

--auto

(skips human gate, proceeds automatically). With

--interactive

, the research skill shows its human gate (AskUserQuestion). /rpi trusts the outcome:

User approves → research complete, proceed
User abandons → /rpi stops with message: "Research abandoned by user."

After research completes:

Record: which research file was produced

Write phase summary (keep context lean):

Read the research output file.
Write a 500-token summary to .agents/rpi/phase-1-summary.md

Ratchet checkpoint:

bash

ao ratchet record research 2>/dev/null || true

跳过条件：

--from

参数指定了后续阶段。

Skill(skill="research", args="<目标> --auto")   # 始终为--auto，除非使用--interactive

默认情况下，/research以

--auto

模式运行（跳过人工审核节点，自动推进）。在

--interactive

模式下，研究Skill会触发人工审核节点（AskUserQuestion）。/rpi将信任审核结果：

用户批准→研究完成，进入下一阶段
用户放弃→/rpi终止并提示："研究已被用户放弃。"

研究完成后：

记录：生成了哪些研究文件

编写阶段摘要（精简上下文）：

读取研究输出文件。
撰写500词以内的摘要至.agents/rpi/phase-1-summary.md

记录检查点：

bash

ao ratchet record research 2>/dev/null || true

Phase 2: Plan

阶段2：规划

Skip if:

--from

is set to a later phase.

Skill(skill="plan", args="<goal> --auto")   # always --auto unless --interactive

By default, /plan runs with

--auto

(skips human gate, proceeds automatically). With

--interactive

, the plan skill shows its human gate. /rpi trusts the outcome.

After plan completes:

Extract epic-id:

bash

# Find most recent epic
EPIC_ID=$(bd list --type epic --status open 2>/dev/null | head -1 | grep -o 'ag-[a-z0-9]*')

Store in

rpi_state.epic_id

Detect micro-epic (fast-path):
bash
```
ISSUE_COUNT=$(bd children <epic-id> 2>/dev/null | wc -l | tr -d ' ')
BLOCKED_COUNT=$(bd children <epic-id> 2>/dev/null | grep -c 'blocked' || echo 0)
```
If
```
ISSUE_COUNT <= 2
```
AND
```
BLOCKED_COUNT == 0
```
(all issues in Wave 1), OR if
```
--fast-path
```
flag is set:
- Set
```
rpi_state.fast_path = true
```
- Log: "Micro-epic detected (N issues, 1 wave) — using fast path (--quick for gates)"
Fast path passes
```
--quick
```
to pre-mortem, vibe, and post-mortem, using inline review instead of spawning full council. This saves ~15 min on small epics with no loss of quality.
Write phase summary to
```
.agents/rpi/phase-2-summary.md
```

Ratchet checkpoint:

bash

ao ratchet record plan 2>/dev/null || true

跳过条件：

--from

参数指定了后续阶段。

Skill(skill="plan", args="<目标> --auto")   # 始终为--auto，除非使用--interactive

默认情况下，/plan以

--auto

模式运行（跳过人工审核节点，自动推进）。在

--interactive

模式下，规划Skill会触发人工审核节点。/rpi将信任审核结果。

规划完成后：

提取epic-id：

bash

# 查找最新的epic
EPIC_ID=$(bd list --type epic --status open 2>/dev/null | head -1 | grep -o 'ag-[a-z0-9]*')

将其存储至

rpi_state.epic_id

。

检测微epic（快速路径）：
bash
```
ISSUE_COUNT=$(bd children <epic-id> 2>/dev/null | wc -l | tr -d ' ')
BLOCKED_COUNT=$(bd children <epic-id> 2>/dev/null | grep -c 'blocked' || echo 0)
```
如果
```
ISSUE_COUNT <= 2
```
且
```
BLOCKED_COUNT == 0
```
（所有问题均在第1波），或传入了
```
--fast-path
```
参数：
- 设置
```
rpi_state.fast_path = true
```
- 日志："检测到微epic（N个问题，1波）——将使用快速路径（节点采用--quick模式）"
快速路径会在事前复盘、最终验证和事后复盘中传入
```
--quick
```
参数，使用内联评审而非完整评审团队，可在小型epic场景下节省约15分钟且不影响质量。
编写阶段摘要至
```
.agents/rpi/phase-2-summary.md
```

记录检查点：

bash

ao ratchet record plan 2>/dev/null || true

Phase 3: Pre-mortem

阶段3：事前复盘

Skip if:

--from

is set to a later phase.

Skill(skill="pre-mortem", args="--quick")   # if rpi_state.fast_path
Skill(skill="pre-mortem")                    # otherwise (full council)

Pre-mortem auto-discovers the most recent plan. No args needed.

After pre-mortem completes: Extract verdict (PASS/WARN/FAIL) from council report. Read

references/gate-retry-logic.md

for detailed Pre-mortem gate retry behavior.

PASS/WARN: auto-proceed
FAIL: re-plan with feedback, re-run pre-mortem (max 3 total attempts)

Store verdict in

rpi_state.verdicts.pre_mortem

. Write phase summary to

.agents/rpi/phase-3-summary.md

Ratchet checkpoint:

bash

ao ratchet record pre-mortem 2>/dev/null || true

跳过条件：

--from

参数指定了后续阶段。

Skill(skill="pre-mortem", args="--quick")   # 如果启用rpi_state.fast_path
Skill(skill="pre-mortem")                    # 否则（完整评审团队）

事前复盘会自动发现最新的规划，无需额外参数。

事前复盘完成后： 从评审报告中提取结果（通过/警告/失败）。查看

references/gate-retry-logic.md

获取事前复盘节点的详细重试逻辑。

通过/警告：自动推进
失败：结合反馈重新规划，并重试事前复盘（最多3次尝试）

将结果存储至

rpi_state.verdicts.pre_mortem

。编写阶段摘要至

.agents/rpi/phase-3-summary.md

。

记录检查点：

bash

ao ratchet record pre-mortem 2>/dev/null || true

Phase 4: Crank (Implementation)

阶段4：实施（Crank）

Requires:

rpi_state.epic_id

(from Phase 2 or --from=crank with epic-id argument)

Skill(skill="crank", args="<epic-id> --test-first")   # if --test-first set
Skill(skill="crank", args="<epic-id>")                 # otherwise

Crank manages its own waves, teams, and internal validation. /rpi waits for completion.

After crank completes: Check

<promise>

tags for completion status. Read

references/gate-retry-logic.md

for detailed Crank gate retry behavior.

DONE: proceed to Phase 5
BLOCKED/PARTIAL: re-crank with context (max 3 total attempts)

Write phase summary to

.agents/rpi/phase-4-summary.md

Ratchet checkpoint:

bash

ao ratchet record implement 2>/dev/null || true

前提条件：

rpi_state.epic_id

（来自阶段2，或通过--from=crank参数传入epic-id）

Skill(skill="crank", args="<epic-id> --test-first")   # 如果传入--test-first参数
Skill(skill="crank", args="<epic-id>")                 # 否则

Crank自主管理自身的迭代波次、团队和内部验证。/rpi将等待执行完成。

实施完成后： 检查

<promise>

标签获取完成状态。查看

references/gate-retry-logic.md

获取实施节点的详细重试逻辑。

完成：进入阶段5
阻塞/部分完成：结合上下文重新实施（最多3次尝试）

编写阶段摘要至

.agents/rpi/phase-4-summary.md

。

记录检查点：

bash

ao ratchet record implement 2>/dev/null || true

Phase 5: Final Vibe

阶段5：最终验证（Vibe）

Skill(skill="vibe", args="--quick recent")   # if rpi_state.fast_path
Skill(skill="vibe", args="recent")            # otherwise (full council)

Vibe runs a full council on recent changes (cross-wave consistency check).

After vibe completes: Extract verdict (PASS/WARN/FAIL) and apply gate logic. Read

references/gate-retry-logic.md

for detailed Vibe gate retry behavior.

PASS/WARN: auto-proceed
FAIL: re-crank with feedback, re-vibe (max 3 total attempts)

Store verdict in

rpi_state.verdicts.vibe

. Write phase summary to

.agents/rpi/phase-5-summary.md

Ratchet checkpoint:

bash

ao ratchet record vibe 2>/dev/null || true

Skill(skill="vibe", args="--quick recent")   # 如果启用rpi_state.fast_path
Skill(skill="vibe", args="recent")            # 否则（完整评审团队）

Vibe会对近期变更进行完整评审（跨波次一致性检查）。

最终验证完成后： 提取结果（通过/警告/失败）并应用节点逻辑。查看

references/gate-retry-logic.md

获取最终验证节点的详细重试逻辑。

通过/警告：自动推进
失败：结合反馈重新实施，并重试最终验证（最多3次尝试）

将结果存储至

rpi_state.verdicts.vibe

。编写阶段摘要至

.agents/rpi/phase-5-summary.md

。

记录检查点：

bash

ao ratchet record vibe 2>/dev/null || true

Phase 6: Post-mortem

阶段6：事后复盘

Skill(skill="post-mortem", args="--quick <epic-id>")   # if rpi_state.fast_path
Skill(skill="post-mortem", args="<epic-id>")            # otherwise (full council)

Post-mortem runs council + retro + flywheel feed. By default, /rpi ends after post-mortem (enable Gate 4 loop via

--loop

After post-mortem completes:

Ratchet checkpoint (with cycle lineage):

bash

ao ratchet record post-mortem --cycle=<rpi_state.cycle> --parent-epic=<rpi_state.parent_epic> 2>/dev/null || true

Read

references/gate4-loop-and-spawn.md

for Gate 4 loop (

--loop

) and spawn-next work details.

Skill(skill="post-mortem", args="--quick <epic-id>")   # 如果启用rpi_state.fast_path
Skill(skill="post-mortem", args="<epic-id>")            # 否则（完整评审团队）

事后复盘会执行评审+回顾+飞轮反馈。默认情况下，/rpi在事后复盘后终止（可通过

--loop

参数启用第4节点循环）。

事后复盘完成后：

记录检查点（包含周期 lineage）：

bash

ao ratchet record post-mortem --cycle=<rpi_state.cycle> --parent-epic=<rpi_state.parent_epic> 2>/dev/null || true

查看

references/gate4-loop-and-spawn.md

了解第4节点循环（

--loop

）和待办工作收集的详细信息。

Step Final: Report

最终步骤：报告

Read

references/report-template.md

for the full report and flywheel output templates.

Read

references/error-handling.md

for error handling details.

查看

references/report-template.md

获取完整的报告和飞轮输出模板。

查看

references/error-handling.md

获取错误处理详情。

Flags

命令参数

Flag	Default	Description
`--from=<phase>`	`research`	Start from this phase (research, plan, pre-mortem, crank, vibe, post-mortem)
`--interactive`	off	Enable human gates in /research and /plan. Without this flag, /rpi runs fully autonomous.
`--auto`	on	(Legacy, now default) Fully autonomous — zero human gates. Kept for backwards compatibility.
`--loop`	off	Enable Gate 4 loop: after /post-mortem, iterate only when post-mortem verdict is FAIL (spawns another /rpi cycle).
`--max-cycles=<n>`	`1`	Hard cap on total /rpi cycles when `--loop` is set (recommended: 3).
`--spawn-next`	off	After post-mortem, read harvested next-work items and report suggested next `/rpi` command. Marks consumed entries.
`--test-first`	off	Pass `--test-first` to `/crank` for spec-first TDD
`--fast-path`	auto	Force fast path (--quick for gates). Auto-detected when ≤2 issues and 1 wave.
`--dry-run`	off	With `--spawn-next` : report items without marking consumed. Useful for testing the consumption flow.

参数	默认值	说明
`--from=<phase>`	`research`	从指定阶段开始执行（可选值：research, plan, pre-mortem, crank, vibe, post-mortem）
`--interactive`	关闭	在/research和/plan阶段启用人工审核节点。无此参数时，/rpi完全自主执行。
`--auto`	开启	（遗留参数，现为默认值）完全自主执行——无人工审核节点。用于向后兼容。
`--loop`	关闭	启用第4节点循环：事后复盘失败时，启动新的/rpi周期。
`--max-cycles=<n>`	`1`	启用 `--loop` 时，限制/rpi的总迭代次数（推荐设置为3）。
`--spawn-next`	关闭	事后复盘完成后，读取收集的待办工作并推荐下一个/rpi命令。标记已处理的条目。
`--test-first`	关闭	向/crank传入 `--test-first` 参数，采用先写规范的TDD模式
`--fast-path`	自动	强制启用快速路径（节点采用--quick模式）。当问题数≤2且仅1波时自动检测启用。
`--dry-run`	关闭	配合 `--spawn-next` 使用：展示待办工作但不标记为已处理。适用于测试处理流程。

Examples

示例

Full Lifecycle from Scratch

从 scratch 启动全生命周期流程

User says:

/rpi "add user authentication"

What happens:

Phase 1: Research agent explores auth patterns in codebase
Phase 2: Plan creates epic
```
ag-5k2
```
with 5 issues in 2 waves
Phase 3: Pre-mortem validates plan — PASS
Phase 4: Crank spawns 5 workers across 2 waves, all complete
Phase 5: Vibe validates recent changes — PASS
Phase 6: Post-mortem extracts learnings, harvests 2 tech-debt items

Result: Auth system implemented end-to-end. Suggested next

/rpi

command for highest-priority tech-debt.

用户输入：

/rpi "add user authentication"

执行流程：

阶段1：研究Agent探索代码库中的认证模式
阶段2：规划创建epic
```
ag-5k2
```
，包含2波共5个任务
阶段3：事前复盘验证规划——通过
阶段4：Crank在2波中启动5个工作者，全部完成
阶段5：Vibe验证近期变更——通过
阶段6：事后复盘提取经验，收集2个技术债务项

结果： 认证系统已端到端实现。推荐针对最高优先级技术债务的下一个/rpi命令。

Resume from Crank

从实施阶段恢复执行

User says:

/rpi --from=crank ag-5k2

What happens:

Skips research, plan, pre-mortem (already done)
Phase 4: Crank resumes or restarts epic
```
ag-5k2
```
Phase 5: Vibe validates
Phase 6: Post-mortem wraps up

Result: Fast resumption for already-planned work.

用户输入：

/rpi --from=crank ag-5k2

执行流程：

跳过研究、规划、事前复盘（已完成）
阶段4：Crank恢复或重启epic
```
ag-5k2
```
阶段5：Vibe验证
阶段6：事后复盘收尾

结果： 快速恢复已规划工作的执行。

Interactive Mode

交互式模式

User says:

/rpi --interactive "refactor payment module"

What happens:

Phase 1: Research completes, asks for human approval
User approves research
Phase 2: Plan completes, asks for human approval
User approves plan with revisions
Phases 3-6: Fully autonomous (pre-mortem auto-retries on FAIL)

Result: Human-guided research and planning, autonomous execution.

用户输入：

/rpi --interactive "refactor payment module"

执行流程：

阶段1：研究完成，请求人工批准
用户批准研究结果
阶段2：规划完成，请求人工批准
用户批准规划并提出修订意见
阶段3-6：完全自主执行（事前复盘失败时自动重试）

结果： 人工引导研究和规划，后续阶段自主执行。

Troubleshooting

故障排除

Problem	Cause	Solution
Pre-mortem retry loop hits max attempts	Plan has fundamental issues that retry loop cannot fix	Review council findings, manually revise plan, re-run `/rpi --from=plan`
Vibe retry loop hits max attempts	Implementation has critical flaws that re-crank cannot fix	Review vibe findings, manually fix code, re-run `/rpi --from=vibe`
Crank blocks on missing dependency	Epic issue references unavailable blocker	Check `bd show <epic-id>` for dep graph, fix or remove blocker
Post-mortem harvests no next-work	Council found no tech debt or improvements	Flywheel stable — no follow-up needed
`--loop` causes infinite cycles	Gate 4 loop enabled but post-mortem always returns FAIL	Set `--max-cycles=3` to cap iterations, review why FAIL persists
Large repo context overflow	Repo has >1500 files and agents run out of context	Enable context-windowing via `scripts/rpi/context-window-contract.sh` before Phase 1

问题	原因	解决方案
事前复盘重试循环达到最大次数	规划存在根本性问题，重试循环无法修复	查看评审结果，手动修订规划，重新运行 `/rpi --from=plan`
最终验证重试循环达到最大次数	实现存在严重缺陷，重新实施无法修复	查看最终验证结果，手动修复代码，重新运行 `/rpi --from=vibe`
实施因依赖缺失而阻塞	epic任务引用了不可用的阻塞项	查看 `bd show <epic-id>` 的依赖图，修复或移除阻塞项
事后复盘未收集到待办工作	评审未发现技术债务或改进点	飞轮已稳定——无需后续操作
`--loop` 导致无限循环	启用了第4节点循环，但事后复盘始终返回失败	设置 `--max-cycles=3` 限制迭代次数，排查持续失败的原因
大型仓库上下文溢出	仓库文件超过1500个，Agent上下文不足	阶段1前通过 `scripts/rpi/context-window-contract.sh` 启用上下文窗口分片

rpi

Original

Translation

/rpi — Full RPI Lifecycle Orchestrator

/rpi — 完整RPI生命周期编排器

Quick Start

快速开始

Architecture

架构

Execution Steps

执行步骤

Step 0: Setup

步骤0：初始化

Phase 1: Research

阶段1：研究

Phase 2: Plan

阶段2：规划

Phase 3: Pre-mortem

阶段3：事前复盘

Phase 4: Crank (Implementation)

阶段4：实施（Crank）

Phase 5: Final Vibe

阶段5：最终验证（Vibe）

Phase 6: Post-mortem

阶段6：事后复盘

Step Final: Report

最终步骤：报告

Flags

命令参数

Examples

示例

Full Lifecycle from Scratch

从 scratch 启动全生命周期流程

Resume from Crank

从实施阶段恢复执行

Interactive Mode

交互式模式

Troubleshooting

故障排除

See Also

相关文档