Ralplan 共识规划工具：AI 驱动的迭代规划与决策制定 | 自动化开发工作流

ralplan by yeachan-heo/oh-my-claudecode

202 周安装量

24,900 GitHub Stars

GitHub

安装命令

npx skills add https://github.com/yeachan-heo/oh-my-claudecode --skill ralplan

软件工程项目管理自动化

🇨🇳中文介绍

Ralplan（共识规划别名）

Ralplan 是 /oh-my-claudecode:omc-plan --consensus 的简写别名。它会触发 Planner、Architect 和 Critic 代理的迭代规划，直到达成共识，并采用 RALPLAN-DR 结构化审议（默认为简短模式，高风险工作则使用审议模式）。

用法

/oh-my-claudecode:ralplan "任务描述"

标志

--interactive：在关键决策点（步骤 2 的草案审查和步骤 6 的最终批准）启用用户提示。如果没有此标志，工作流将完全自动化运行——Planner → Architect → Critic 循环——并在不请求确认的情况下输出最终计划。
--deliberate：强制对高风险工作使用审议模式。增加事前分析（3 种场景）和扩展的测试规划（单元/集成/端到端/可观测性）。如果没有此标志，当请求明确表明高风险（身份验证/安全、迁移、破坏性更改、生产事件、合规性/PII、公共 API 破坏）时，审议模式仍可自动启用。
--architect codex：当 Codex CLI 可用时，在 Architect 阶段使用 Codex。否则，简要说明回退情况并保持默认的 Claude Architect 审查。
--critic codex：当 Codex CLI 可用时，在 Critic 阶段使用 Codex。否则，简要说明回退情况并保持默认的 Claude Critic 审查。

使用交互模式

广告位招租

在这里展示您的产品或服务

触达数万 AI 开发者，精准高效

联系我们

相关 Skills

FlyClaw：零登录航班聚合查询工具，Python实现多源航班信息与价格搜索

4,000,000 周安装

Azure RBAC 权限管理工具：查找最小角色、创建自定义角色与自动化分配

142,000 周安装

GitHub Actions 官方文档查询助手 - 精准解答 CI/CD 工作流问题

47,200 周安装

通过 LiteLLM 代理让 Claude Code 对接 GitHub Copilot 运行 | 高级变通方案指南

46,900 周安装

/oh-my-claudecode:ralplan --interactive "任务描述"

此技能以共识模式调用 Plan 技能：

/oh-my-claudecode:omc-plan --consensus <参数>

Planner 创建初始计划，并在审查前生成一份简洁的 RALPLAN-DR 摘要：
- 原则（3-5 条）
- 决策驱动因素（前 3 项）
- 可行选项（>=2 个）及其有限的优缺点
- 如果只剩下一个可行选项，需明确说明替代方案无效的理由
- 仅审议模式：事前分析（3 种场景）+ 扩展测试计划（单元/集成/端到端/可观测性）
用户反馈（仅限 --interactive）：如果设置了 --interactive，则在审查前使用 AskUserQuestion 展示草案计划以及原则/驱动因素/选项摘要（继续审查 / 请求更改 / 跳过审查）。否则，自动继续审查。
Architect 审查架构合理性，必须提供最强有力的反方观点，至少一个真实的权衡矛盾点，以及（如果可能）综合方案——在步骤 4 之前等待完成。在审议模式下，Architect 应明确标记违反原则的情况。
Critic 根据质量标准进行评估——仅在步骤 3 完成后运行。Critic 必须强制执行原则与选项的一致性、公平的替代方案、清晰的风险缓解措施、可测试的验收标准和具体的验证步骤。在审议模式下，Critic 必须拒绝缺失或薄弱的事前分析或扩展测试计划。
重新审查循环（最多 5 次迭代）：任何非 APPROVE 的 Critic 裁决（ITERATE 或 REJECT）必须运行相同的完整闭环：a. 收集 Architect + Critic 反馈 b. 使用 Planner 修订计划 c. 返回 Architect 审查 d. 返回 Critic 评估 e. 重复此循环，直到 Critic 返回 APPROVE 或达到 5 次迭代 f. 如果达到 5 次迭代仍未获得 APPROVE，则向用户呈现最佳版本
Critic 批准后（仅限 --interactive）：如果设置了 --interactive，则使用 AskUserQuestion 展示计划并提供批准选项（批准并通过团队实施（推荐）/ 批准并通过 ralph 执行 / 清除上下文并实施 / 请求更改 / 拒绝）。最终计划必须包含 ADR（决策、驱动因素、考虑的替代方案、选择原因、后果、后续工作）。否则，输出最终计划并停止。
（仅限 --interactive）用户选择：批准（团队或 ralph）、请求更改或拒绝
（仅限 --interactive）批准后：调用 Skill("oh-my-claudecode:team") 进行并行团队执行（推荐）或调用 Skill("oh-my-claudecode:ralph") 进行顺序执行——切勿直接实施

重要提示： 步骤 3 和 4 必须顺序运行。不要在同一并行批次中发出两个代理的 Task 调用。在发出 Critic Task 之前，始终等待 Architect 的结果。

有关共识模式的详细信息，请遵循 Plan 技能的完整文档。

关卡存在的原因

执行模式（ralph、autopilot、team、ultrawork、ultrapilot）会启动繁重的多代理编排。当针对模糊的请求（如 "ralph improve the app"）启动时，代理没有明确的目标——它们浪费周期在范围发现上，而这本应在规划阶段完成，通常导致交付不完整或错位的工作，需要返工。

ralplan-first 关卡会拦截未明确指定的执行请求，并将其重定向到 ralplan 共识规划工作流。这确保了：

明确的范围：PRD 明确定义将要构建的内容
测试规范：在编写代码之前，验收标准是可测试的
共识：Planner、Architect 和 Critic 就方法达成一致
无浪费的执行：代理从一个清晰、有界的任务开始

良好提示与不良提示

通过关卡（足够具体，可直接执行）：

ralph fix the null check in src/hooks/bridge.ts:326
autopilot implement issue #42
team add validation to function processKeywordDetector
ralph do:\n1. Add input validation\n2. Write tests\n3. Update README
ultrawork add the user model in src/models/user.ts

被拦截——重定向到 ralplan（需要先确定范围）：

ralph fix this
autopilot build the app
team improve performance
ralph add authentication
ultrawork make it better

绕过关卡（当您知道想要什么时）：

force: ralph refactor the auth module
! autopilot optimize everything

关卡何时不会触发

当检测到任何具体信号时，关卡会自动通过。您不需要全部信号——一个就足够了：

信号类型	示例提示	通过原因
文件路径	`ralph fix src/hooks/bridge.ts`	引用了特定文件
Issue/PR 编号	`ralph implement #42`	有具体的工作项
camelCase 符号	`ralph fix processKeywordDetector`	命名了特定函数
PascalCase 符号	`ralph update UserModel`	命名了特定类
snake_case 符号	`team fix user_model`	命名了特定标识符
测试运行器	`ralph npm test && fix failures`	有明确的测试目标
编号步骤	`ralph do:\n1. Add X\n2. Test Y`	结构化的交付成果
验收标准	`ralph add login - acceptance criteria: ...`	明确的成功定义
错误引用	`ralph fix TypeError in auth`	要解决的具体错误
代码块	`ralph add: ```ts ... ````	提供了具体代码
转义前缀	`force: ralph do it` 或 `! ralph do it`	明确的用户覆盖

端到端流程示例

用户输入：ralph add user authentication
关卡检测到：执行关键词（ralph）+ 未明确指定的提示（无文件、函数或测试规范）
关卡重定向到 ralplan，并附带解释重定向原因的消息
Ralplan 共识运行：
- Planner 创建初始计划（哪些文件、何种身份验证方法、哪些测试）
- Architect 审查合理性
- Critic 验证质量和可测试性
达成共识批准后，用户选择执行路径：
- team：并行协调的代理（推荐）
- ralph：带验证的顺序执行
执行开始，基于一个清晰、有界的计划

问题	解决方案
关卡在明确指定的提示上触发	添加文件引用、函数名或 issue 编号来锚定请求
想绕过关卡	使用 `force:` 或 `!` 作为前缀（例如，`force: ralph fix it`）
关卡未在模糊提示上触发	关卡仅捕获有效单词数 <=15 且无具体锚点的提示；添加更多细节或显式使用 `/ralplan`
被重定向到 ralplan 但想跳过规划	在 ralplan 工作流中，说 "just do it" 或 "skip planning" 以直接过渡到执行

2026 年 1 月 22 日

🇺🇸English

Ralplan (Consensus Planning Alias)

Ralplan is a shorthand alias for /oh-my-claudecode:omc-plan --consensus. It triggers iterative planning with Planner, Architect, and Critic agents until consensus is reached, with RALPLAN-DR structured deliberation (short mode by default, deliberate mode for high-risk work).

Usage

/oh-my-claudecode:ralplan "task description"

Flags

--interactive: Enables user prompts at key decision points (draft review in step 2 and final approval in step 6). Without this flag the workflow runs fully automated — Planner → Architect → Critic loop — and outputs the final plan without asking for confirmation.
--deliberate: Forces deliberate mode for high-risk work. Adds pre-mortem (3 scenarios) and expanded test planning (unit/integration/e2e/observability). Without this flag, deliberate mode can still auto-enable when the request explicitly signals high risk (auth/security, migrations, destructive changes, production incidents, compliance/PII, public API breakage).
--architect codex: Use Codex for the Architect pass when Codex CLI is available. Otherwise, briefly note the fallback and keep the default Claude Architect review.
--critic codex: Use Codex for the Critic pass when Codex CLI is available. Otherwise, briefly note the fallback and keep the default Claude Critic review.

Usage with interactive mode

/oh-my-claudecode:ralplan --interactive "task description"

Behavior

This skill invokes the Plan skill in consensus mode:

/oh-my-claudecode:omc-plan --consensus <arguments>

The consensus workflow:

Planner creates initial plan and a compact RALPLAN-DR summary before review:
- Principles (3-5)
- Decision Drivers (top 3)
- Viable Options (>=2) with bounded pros/cons
- If only one viable option remains, explicit invalidation rationale for alternatives
- Deliberate mode only: pre-mortem (3 scenarios) + expanded test plan (unit/integration/e2e/observability)
User feedback (--interactive only) : If --interactive is set, use AskUserQuestion to present the draft plan plus the Principles / Drivers / Options summary before review (Proceed to review / Request changes / Skip review). Otherwise, automatically proceed to review.
Architect reviews for architectural soundness and must provide the strongest steelman antithesis, at least one real tradeoff tension, and (when possible) synthesis — await completion before step 4. In deliberate mode, Architect should explicitly flag principle violations.
Critic evaluates against quality criteria — run only after step 3 completes. Critic must enforce principle-option consistency, fair alternatives, risk mitigation clarity, testable acceptance criteria, and concrete verification steps. In deliberate mode, Critic must reject missing/weak pre-mortem or expanded test plan.
Re-review loop (max 5 iterations): Any non-APPROVE Critic verdict (ITERATE or ) MUST run the same full closed loop: a. Collect Architect + Critic feedback b. Revise the plan with Planner c. Return to Architect review d. Return to Critic evaluation e. Repeat this loop until Critic returns or 5 iterations are reached f. If 5 iterations are reached without , present the best version to the user

Important: Steps 3 and 4 MUST run sequentially. Do NOT issue both agent Task calls in the same parallel batch. Always await the Architect result before issuing the Critic Task.

Follow the Plan skill's full documentation for consensus mode details.

Pre-Execution Gate

Why the Gate Exists

Execution modes (ralph, autopilot, team, ultrawork, ultrapilot) spin up heavy multi-agent orchestration. When launched on a vague request like "ralph improve the app", agents have no clear target — they waste cycles on scope discovery that should happen during planning, often delivering partial or misaligned work that requires rework.

The ralplan-first gate intercepts underspecified execution requests and redirects them through the ralplan consensus planning workflow. This ensures:

Explicit scope : A PRD defines exactly what will be built
Test specification : Acceptance criteria are testable before code is written
Consensus : Planner, Architect, and Critic agree on the approach
No wasted execution : Agents start with a clear, bounded task

Good vs Bad Prompts

Passes the gate (specific enough for direct execution):

ralph fix the null check in src/hooks/bridge.ts:326
autopilot implement issue #42
team add validation to function processKeywordDetector
ralph do:\n1. Add input validation\n2. Write tests\n3. Update README
ultrawork add the user model in src/models/user.ts

Gated — redirected to ralplan (needs scoping first):

ralph fix this
autopilot build the app
team improve performance
ralph add authentication
ultrawork make it better

Bypass the gate (when you know what you want):

force: ralph refactor the auth module
! autopilot optimize everything

When the Gate Does NOT Trigger

The gate auto-passes when it detects any concrete signal. You do not need all of them — one is enough:

Signal Type	Example prompt	Why it passes
File path	`ralph fix src/hooks/bridge.ts`	References a specific file
Issue/PR number	`ralph implement #42`	Has a concrete work item
camelCase symbol	`ralph fix processKeywordDetector`	Names a specific function
PascalCase symbol	`ralph update UserModel`	Names a specific class
snake_case symbol	`team fix user_model`

End-to-End Flow Example

User types: ralph add user authentication
Gate detects: execution keyword (ralph) + underspecified prompt (no files, functions, or test spec)
Gate redirects to ralplan with message explaining the redirect
Ralplan consensus runs:
- Planner creates initial plan (which files, what auth method, what tests)
- Architect reviews for soundness
- Critic validates quality and testability
On consensus approval, user chooses execution path:
- team : parallel coordinated agents (recommended)
- ralph : sequential execution with verification
Execution begins with a clear, bounded plan

Troubleshooting

Issue	Solution
Gate fires on a well-specified prompt	Add a file reference, function name, or issue number to anchor the request
Want to bypass the gate	Prefix with `force:` or `!` (e.g., `force: ralph fix it`)
Gate does not fire on a vague prompt	The gate only catches prompts with <=15 effective words and no concrete anchors; add more detail or use `/ralplan` explicitly
Redirected to ralplan but want to skip planning	In the ralplan workflow, say "just do it" or "skip planning" to transition directly to execution

Weekly Installs

134

Repository

yeachan-heo/oh-…audecode

GitHub Stars

11.3K

First Seen

Jan 22, 2026

Security Audits

Gen Agent Trust HubPass SocketPass SnykPass

Installed on

claude-code124

opencode124

gemini-cli119

codex117

cursor117

github-copilot109

开源项目教练指南 - 诊断问题、制定行动计划、优化开源项目运营

46,800 周安装

On Critic approval (--interactive only) : If --interactive is set, use AskUserQuestion to present the plan with approval options (Approve and implement via team (Recommended) / Approve and execute via ralph / Clear context and implement / Request changes / Reject). Final plan must include ADR (Decision, Drivers, Alternatives considered, Why chosen, Consequences, Follow-ups). Otherwise, output the final plan and stop.

(--interactive only) User chooses: Approve (team or ralph), Request changes, or Reject

(--interactive only) On approval: invoke Skill("oh-my-claudecode:team") for parallel team execution (recommended) or Skill("oh-my-claudecode:ralph") for sequential execution -- never implement directly