/ralph

name: ralph
description: Self-referential loop until task completion with configurable verification reviewer
argument-hint: "[--no-deslop] [--critic=architect|critic|codex] <task description>"
level: 4

[RALPH - ITERATION {{ITERATION}}/{{MAX}}]

Your previous attempt did not output the completion promise. Continue working on the task.

<Purpose> Ralph is a PRD-driven persistence loop that keeps working on a task until ALL user stories in prd.json have passes: true and are reviewer-verified. It combines session persistence, automatic retry on failure, structured story tracking, and mandatory verification before completion. </Purpose> <Precondition_Feedback_Gate> NON-NEGOTIABLE, runs before any story work and at every verification gate:

0. Resolve the CLI once per run. An `omc ralph afk` session exports `OMC_RALPH_AFK_FEEDBACK` and grants only the bare `Bash(omc ralph verify:*)` form, so use `omc` directly there — do not run a discovery probe, it is not granted and is denied in headless mode. Everywhere else use `omc` when it is on PATH; on a plugin-only install there is no `omc`, so use the plugin-shaped form `node "$CLAUDE_PLUGIN_ROOT"/bridge/cli.cjs` — the same prefix OMC's own skill renderer emits, and the same fallback `ultragoal` and `cancel` already document. Every `omc ralph verify` below means the resolved command. If neither form is available, STOP and report the failure — do not fall back to hand-rolled judgment.

1. FIRST ITERATION, before picking a story: run `omc ralph verify --write-baseline --session <sessionId>` (session id: read OMC_SESSION_ID if set — `omc ralph afk` exports it — else the one in the Ralph continuation context / active PRD path; use the SAME id for every call in this run). This records the feedback baseline. If the command is unavailable or denied, STOP and report the failure — do not fall back to hand-rolled judgment. 2. EVERY verification gate (story verification, post-deslop re-verification): run `omc ralph verify --session <sessionId>` and obey the exit code — 0 = pass (baseline-only failures are recorded warnings, never a story failure), 1 = new failures to fix. Two infrastructure causes also exit 1 and are printed on their own lines: `timed out` (the command exceeded its per-command budget; partial output is discarded) and `another verify is running` (runs for one session are serialized). Neither is a story failure: retry after the other run finishes, or raise the budget with `--timeout <seconds>` (or `OMC_RALPH_VERIFY_TIMEOUT_SECONDS`) when the suite legitimately needs more than 600 s. 3. NEVER hand-roll the feedback diff (running the suite yourself and eyeballing the output is exactly the failure mode this gate exists to prevent). 4. NEVER re-record the baseline to make a gate pass. A re-record turns every regression introduced since the previous one into baseline-only noise. If the gate cannot run for an infrastructure reason, report it as a blocker in the Step 8 closeout instead. </Precondition_Feedback_Gate>

<Use_When>

• Task requires guaranteed completion with verification (not just "do your best")
• User says "ralph", "don't stop", "must complete", "finish this", or "keep going until done"
• Work may span multiple iterations and needs persistence across retries
• Task benefits from structured PRD-driven execution with reviewer sign-off

</Use_When>

<Do_Not_Use_When>

• User wants a full autonomous pipeline from idea to code -- use `autopilot` instead
• User wants to explore or plan before committing -- use `plan` skill instead
• User wants a quick one-shot fix -- delegate directly to an executor agent
• User wants manual control over completion -- delegate directly to an executor agent
• User already has an active Claude Code `/goal` and only wants that native goal loop monitored -- adopt the existing `/goal` explicitly or use artifact-only Ultragoal notes instead of starting Ralph as a competing persistence loop

</Do_Not_Use_When>

<Why_This_Exists> Complex tasks often fail silently: partial implementations get declared "done", tests get skipped, edge cases get forgotten. Ralph prevents this by:

1. Structuring work into discrete user stories with testable acceptance criteria (prd.json) 2. Iterating story-by-story until each one passes 3. Tracking progress and learnings across iterations (progress.txt) 4. Requiring fresh reviewer verification against specific acceptance criteria before completion </Why_This_Exists>

<PRD_Mode> By default, ralph operates in PRD mode. A scaffold `prd.json` is auto-generated when ralph starts if none exists. Active transient PRD state is session-scoped at `.omc/state/sessions/{sessionId}/prd.json` when a session ID is available; legacy project-level `prd.json` / `.omc/prd.json` files are read as startup migration inputs.

**Startup gate:** Ralph always initializes and validates `prd.json` at startup. Legacy `--no-prd` text is sanitized from the prompt for backward compatibility, but it no longer bypasses PRD creation or validation.

**Deslop opt-out:** If `{{PROMPT}}` contains `--no-deslop`, skip the mandatory post-review deslop pass entirely. Use this only when the cleanup pass is intentionally out of scope for the run.

**Reviewer selection:** Pass `--critic=architect`, `--critic=critic`, or `--critic=codex` in the Ralph prompt to choose the completion reviewer for that run. `architect` remains the default.

**Stale-state detection & reconciliation (#3669):** If a PRD is left unfinished by an abnormal/non-Step 8 exit (crash, force-kill, cancel before `/oh-my-claudecode:cancel`, session end), Ralph surfaces an explicit `[STALE PRD WARNING]` at startup/resume, in the continuation context, and at session end — with unfinished counts, last-touched age, and stale-pointer signals (PRD `branchName` merged/gone). Completion is NEVER inferred from PR/branch/merge status alone; git state is a warning signal only. A story is auto-reconciled to `passes: true` ONLY when the PR