What ralplan is
ralplan is a planning workflow inside an open-source harness called oh-my-claudecode (OMC). A harness is not the model itself but the set of rules that decide in what order, in what role, and through what verification the model works. The same model produces different results under a different harness.
Usage is a single line. In the Claude Code terminal, type /oh-my-claudecode:ralplan "add retry logic for failed payments". The name is a short alias for /oh-my-claudecode:plan --consensus.
What happens next differs from an ordinary coding agent. Most agents open files and start writing code as soon as they get a request. ralplan writes no code. Instead, Planner, Architect, and Critic take turns on a single planning document until they reach consensus. Only then does it ask a human for approval, and only after approval does execution begin.
Why one agent cannot do all three jobs
You could ask the same model to plan and then to review its own plan three times over, but it falls into the same blind spot all three times. Refuting what you just wrote is hard for people too.
So ralplan gives each role different permissions and different obligations. The drafter is bound to a format, the challenger has its editing rights taken away, and the judge carries a duty to reject. The three agents run with different prompts and different tool permissions — they are not the same call under three names.
The next three sections describe what each role must produce.
Planner — at least two options on the table
Planner writes the draft plan, but not freely — it has to fill in a format called RALPLAN-DR. Three parts are mandatory: 3 to 5 principles the plan will hold to, the top 3 decision drivers, and at least two viable options, each with bounded pros and cons.
The last clause matters most. If only one option survives, Planner must write an invalidation rationale for the alternatives it discarded. That single requirement breaks the pattern where the first idea automatically becomes the answer. Because the rejected options stay in the document, the question "why did we build it this way?" still has an answer weeks later.
The output is not scattered through a conversation; it is saved as a markdown file under .omc/plans/. Plans run 3 to 6 actionable steps, each with acceptance criteria an executor can verify — neither 30 micro-steps nor two vague directives.
For high-risk work, --deliberate adds a three-scenario premortem (what could fail and how) and an expanded test plan covering unit, integration, e2e, and observability.
Architect — the counterargument survives because it cannot fix anything
Architect reads Planner's plan and pushes back on architectural grounds. Its definition carries disallowedTools: Write, Edit — the tools for writing and editing files are blocked outright, making it strictly read-only.
Removing the permission is the point. Anyone who can fix something reaches for the fix instead of the argument. When fixing is impossible, only one move remains. Architect is required to deliver the strongest steelman antithesis against the favored option, at least one real tradeoff tension, and where possible a synthesis that reconciles them.
Its evidence is constrained too. Every finding must cite a file:line reference, identify a root cause rather than a symptom, and avoid vague advice like "consider refactoring". In deliberate mode it must explicitly flag where the plan violates the principles Planner set.
To move the dissent to a different model entirely, pass --architect codex. If the Codex CLI is installed, that stage runs on Codex; if not, it quietly falls back to the default Architect. Use it when you want to remove the blind spot three instances of the same model would share.
Critic — its job is rejection, not approval
One premise in Critic's definition sets the character of the whole workflow: a false approval costs 10 to 100 times more than a false rejection. So Critic is designed as a final quality gate rather than a helpful reviewer, and the author is treated as someone presenting for approval.
It also looks from a different angle. A normal review evaluates what is present; Critic also evaluates what is absent, rotating through the executor, stakeholder, and skeptic perspectives to surface gaps. Its checklist: are principles and options consistent, were alternatives explored fairly, is risk mitigation concrete, are acceptance criteria actually testable, are verification steps written down.
And it carries a duty to reject. Shallow alternatives, contradictions between drivers, vague risks, and weak verification must be refused explicitly. In deliberate mode, a missing or thin premortem or expanded test plan is grounds for rejection on its own. The verdict is one of approve, iterate, or reject.
Three benefits that only appear when all three roles exist
First, the order is enforced. Critic is never called before Architect finishes. The rule is written in capitals in the documentation, down to the instruction not to issue both agent calls in the same parallel batch. Running them together means neither reads the other, producing two monologues instead of a consensus.
Second, rework is a closed loop. When Critic returns iterate or reject, the feedback from Architect and Critic goes back to Planner, and review restarts from Architect — not from the changed part only. The loop runs up to five times, and if approval never lands, the best version goes to the human along with a note that consensus was not reached.
Third, the code stays locked until approval. The plan is marked pending approval, and until then ralplan cannot edit files, commit, push, open PRs, or hand work to an execution skill. Once the planning stage touches code, the plan becomes a retroactive justification for what was already done.
Execution after approval is not this workflow's job either. Under --interactive, the final prompt asks how to proceed and hands off to team for parallel execution or ralph for sequential execution with verification. The separation between the one who plans and the one who builds holds to the end.
How to start
You need Claude Code installed first. Then add OMC: run /plugin install oh-my-claudecode, or install from the terminal with npm i -g oh-my-claude-sisyphus@latest. Either way, run /oh-my-claudecode:omc-setup once afterward and setup is done.
The basic call is /oh-my-claudecode:ralplan "task description". With no flags, the Planner to Architect to Critic loop runs automatically, marks the finished plan pending approval, prints it, and stops. It asks nothing in between and executes nothing.
Four flags come up often. --interactive prompts you at two points: draft review and final approval. --deliberate adds the three-scenario premortem and expanded test plan, though it also switches on by itself when the request carries clear risk signals such as auth, security, migrations, production incidents, or personal data. --architect codex and --critic codex move only the dissenter or only the judge to Codex.
The result lands as markdown under .omc/plans/, closing with an ADR section: decision, drivers, alternatives considered, why chosen, consequences, follow-ups. That file is both the execution brief and the record you revisit when someone asks why.
When to use it, and when not to
ralplan pays for itself most at the moment someone tries to jump straight to execution. OMC has a gate that intercepts vague execution requests like "ralph, improve the app" and routes them through ralplan. Spinning up multiple agents without a defined scope means they do scope discovery while executing, and the usual result is partial or misaligned work.
Conversely, it is overkill for a typo fix, a single function rename, or a one-line config change — work that is easy to reverse and has nothing to decide. The consensus loop is not free; it spends time and tokens.
Reduced to one rule: use ralplan whenever undoing the work would cost more than planning it. Data migrations, changes to authentication, edits to a public API, anything touching a payment flow. Critic's premise that a false approval costs 10 to 100 times more than a false rejection holds just as well for human teams.