[OMX] Self-referential loop until task completion with architect verification

AGPL-3.0Auto-check passed

Install Ralph

skills CLI
$ npx skills add yangyuan-zhen/PolyWeather --skill ralph -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install yangyuan-zhen/PolyWeather ralph --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/yangyuan-zhen/PolyWeather.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.codex/skills/ralph .claude/skills/ralph && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
ralph
GitHub stars
316
Token cost
~5.7k tokens
SKILL.md length
2,685 words
Files
1
Skills in repo
26
Repo updated
First seen
Licence
AGPL-3.0

At a glance

[OMX] Self-referential loop until task completion with architect verification

  • Works in 8 steps: Pre-context intake (required before… → Review progress: Check TODO list and any… → Continue from where you left off: Pick… → …
  • SKILL.md covers Goal Mode Integration, State Management, Scenario Examples and PRD Mode (Optional), plus 1 more section
  • Calls make

What it does

Ralph is an agent skill from yangyuan-zhen/PolyWeather. [OMX] Self-referential loop until task completion with architect verification

Its SKILL.md is about 5.7k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

The repository describes itself as: polymarket Intelligent Weather Quant Analysis Bot. The licence is AGPL-3.0.

Example prompts

  • “/ralph”

Workflow steps

8 steps, taken from the first numbered list in SKILL.md.

  1. Pre-context intake (required before planning/execution loop starts)
  2. Review progress: Check TODO list and any prior iteration state
  3. Continue from where you left off: Pick up incomplete tasks
  4. Delegate in parallel: Route tasks to specialist native agents with explicit agent_type and appropriate reasoning_effort
  5. Run long operations in background: Builds, installs, test suites use run_in_background: true
  6. Visual task gate (when screenshot/reference images are present)
  7. Verify completion with fresh evidence
  8. Architect verification (native role)

What it can do on your machine

Read from SKILL.md and the folder at commit 43e658b. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • make

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Ralph loads about 5.7k tokens when it runs. Until then it costs about 21 tokens; SKILL.md has 2,685 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~21
When it runs · the whole SKILL.md, loaded when a task matches
~5.7k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from yangyuan-zhen/PolyWeather at commit 43e658b, republished under its AGPL-3.0 licence (© yangyuan-zhen). 2,685 words, ~5,727 tokens.

Download SKILL.mdSave it as .claude/skills/ralph/SKILL.md (or your agent's skills folder).
name
ralph
description
[OMX] Self-referential loop until task completion with architect verification

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

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

<Purpose>
Ralph is a persistence loop that keeps working on a task until it is fully complete and architect-verified. It wraps ultrawork's parallel execution with session persistence, automatic retry on failure, and mandatory verification before completion.
</Purpose>

<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 parallel execution with architect sign-off at the end </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 -- use ultrawork directly </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 looping until work is genuinely complete, requiring fresh verification evidence before allowing completion, and using explicit architect native-subagent verification to confirm quality. </Why_This_Exists>

<Execution_Policy>

  • Fire independent agent calls simultaneously -- never wait sequentially for independent work
  • Use run_in_background: true for long operations (installs, builds, test suites)
  • The documented-leader preflight is not a general native-session gate. Run omx ralplan preflight --json only when native role routing reports role_routing_unavailable and Ralph attempts adapted Ralplan Planner, Architect, or Critic authority, adapted role-intent, or adapted consensus authority. On unsupported_documented_leader_proof, stop before that adapted authority and use a Codex surface with documented root proof or a reviewed alternative workflow. Do not infer root authority from session_id, undocumented thread_id, session/pointer/transcript/cwd state, absent child data, or prompt labels. Ordinary native planning, lifecycle, state, status, health, HUD, runtime, setup, install, sync, and unrelated delegation remain outside this preflight boundary and under their existing controls.
  • When the native surface exposes agent_type role routing, set agent_type to an installed OMX role and never omit it for OMX work; use reasoning_effort for per-dispatch intensity when needed.
  • OMX adapted role-pass protocol: when native routing is role_routing_unavailable, do not fabricate agent_type. On the exact reviewed Codex releases 0.144.5, 0.145.0, 0.146.1, and 0.148.0-alpha.5, only an attempted adapted Ralplan Planner, Architect, Critic, role-intent, or consensus authority path requires omx ralplan preflight --json and fails closed on unsupported_documented_leader_proof; every other version remains unknown and fails closed. Do not use prompt labels, task-name carriers, pending intents, markers, or omx ralplan role-intent write as substitutes.
  • Preserve legacy Ralph tier intent through native reasoning effort: LOW -> low, STANDARD -> medium, THOROUGH -> xhigh
  • Deliver the full implementation: no scope reduction, no partial completion, no deleting tests to make them pass
  • Apply the shared workflow guidance pattern: outcome-first framing, concise visible updates for multi-step execution, local overrides for the active workflow branch, validation proportional to risk, explicit stop rules, and automatic continuation for safe reversible steps. Ask only for material, destructive, credentialed, external-production, or preference-dependent branches.
  • Integrate with Codex goal mode when goal tools are available: inspect the active thread goal with get_goal, preserve it as the top-level stop condition, and only call update_goal({status: "complete"}) after a Ralph completion audit proves the objective is actually achieved. </Execution_Policy>
<Steps>
0. **Pre-context intake (required before planning/execution loop starts)**:
   - Assemble or load a context snapshot at `.omx/context/{task-slug}-{timestamp}.md` (UTC `YYYYMMDDTHHMMSSZ`).
   - Minimum snapshot fields:
     - task statement
     - desired outcome
     - known facts/evidence
     - constraints
     - unknowns/open questions
     - likely codebase touchpoints
   - If an existing relevant snapshot is available, reuse it and record the path in Ralph state.
   - If request ambiguity is high, gather brownfield facts first. `omx explore` is deprecated; use normal repository inspection tools/subagents for simple read-only repository lookups and `omx sparkshell` only for explicit shell-native read-only evidence. Then run `$deep-interview --quick <task>` to close critical gaps.
   - Do not begin Ralph execution work (delegation, implementation, or verification loops) until snapshot grounding exists. If forced to proceed quickly, note explicit risk tradeoffs.
   - A Ralplan-originated handoff alone does not require preflight. Before intake, run `omx ralplan preflight --json` only when native role routing is unavailable and the handoff attempts adapted Ralplan Planner, Architect, Critic, role-intent, or consensus authority. On `unsupported_documented_leader_proof`, record the reason in Execution Policy and stop before that authority; otherwise follow the existing intake controls.
1. **Review progress**: Check TODO list and any prior iteration state
2. **Continue from where you left off**: Pick up incomplete tasks
3. **Delegate in parallel**: Route tasks to specialist native agents with explicit `agent_type` and appropriate `reasoning_effort`
   - Simple lookups: `reasoning_effort="low"` -- "What does this function return?"
   - Standard work: `reasoning_effort="medium"` -- "Add error handling to this module"
   - Complex analysis: `reasoning_effort="xhigh"` -- "Debug this race condition"
   - When Ralph is entered as a ralplan follow-up, start from the approved **available-agent-types roster** and make the delegation plan explicit: implementation lane, evidence/regression lane, and final sign-off lane using only known agent types
4. **Run long operations in background**: Builds, installs, test suites use `run_in_background: true`
5. **Visual task gate (when screenshot/reference images are present)**:
   - Run the Visual Ralph verdict step **before every next edit**.
   - Require structured JSON output: `score`, `verdict`, `category_match`, `differences[]`, `suggestions[]`, `reasoning`.
   - Persist verdict to `.omx/state/{scope}/ralph-progress.json` including numeric + qualitative feedback.
   - Default pass threshold: `score >= 90`.
   - **URL-based visual cloning tasks**: When the task description contains a target URL (e.g., "clone https://example.com"), route the work through `$visual-ralph`. `$web-clone` is hard-deprecated; Visual Ralph owns the migrated live-URL visual implementation use case and uses its built-in visual verdict step for measured visual scoring.
6. **Verify completion with fresh evidence**:
   - If Codex goal mode is available, call `get_goal` before final verification to restate the active objective and include it in the evidence checklist.
   a. Identify what command proves the task is complete
   b. Run verification (test, build, lint)
   c. Read the output -- confirm it actually passed
   d. Check: zero pending/in_progress TODO items
7. **Architect verification** (native role):
   - <5 files, <100 lines with full tests: `task(agent_type="architect", reasoning_effort="medium", prompt="...")` minimum
   - Standard changes: `task(agent_type="architect", reasoning_effort="medium", prompt="...")`
   - >20 files or security/architectural changes: `task(agent_type="architect", reasoning_effort="xhigh", prompt="...")`
   - Ralph floor: always run an explicit `architect` native subagent, even for small changes
   - On `role_routing_unavailable`, do not invoke `omx ralplan role-intent write` or manufacture an Architect identity. Run the documented-leader preflight only if Architect verification would attempt adapted Ralplan Architect authority; on the exact reviewed Codex releases 0.144.5, 0.145.0, 0.146.1, and 0.148.0-alpha.5 that adapted path is unavailable, while every other version remains unknown and fails closed. Surface the leader-proof diagnostic and the supported-surface recovery guidance, then stop before that authority. Ordinary Ralph delegation remains under its existing controls. Use an adapted route only after its documented positive root proof has been reviewed and implemented.
7.5 **Mandatory Deslop Pass**:
   - After Step 7 passes, run `oh-my-codex:ai-slop-cleaner` on **all files changed during the Ralph session**.
   - Scope the cleaner to **changed files only**; do not widen the pass beyond Ralph-owned edits.
   - Run the cleaner in **standard mode** (not `--review`).
   - If the prompt contains `--no-deslop`, skip Step 7.5 entirely and proceed with the most recent successful verification evidence.
7.6 **Regression Re-verification**:
   - After the deslop pass, re-run all tests/build/lint and read the output to confirm they still pass.
   - If post-deslop regression fails, roll back cleaner changes or fix and retry. Then rerun Step 7.5 and Step 7.6 until the regression is green.
   - Do not proceed to completion until post-deslop regression is green (unless `--no-deslop` explicitly skipped the deslop pass).
8. **On approval**: If Codex goal mode is active, call `update_goal({status: "complete"})` before `/cancel`; report final elapsed time and token-budget usage when the tool returns it. Then run `/cancel` to cleanly exit and clean up all state files.
9. **On rejection**: Fix the issues raised, then re-verify with the same `agent_type` and `reasoning_effort` profile
</Steps>

<Tool_Usage>

  • Use ask_codex with agent_role: "architect" for verification cross-checks when changes are security-sensitive, architectural, or involve complex multi-system integration
  • Skip Codex consultation for simple feature additions, well-tested changes, or time-critical verification
  • If MCP compatibility tools are unavailable, proceed with CLI/agent verification alone -- never block on external tools
  • Use omx state write/read --input '<json>' --json for ralph mode state persistence between iterations
  • Use Codex goal tools when present: get_goal to discover or re-check the active objective, create_goal only when the user/system explicitly requested a new goal and no active goal exists, and update_goal only after the audited objective is fully achieved.
  • Persist context snapshot path in Ralph mode state so later phases and agents share the same grounding context
  • Prefer CLI state commands. If an explicit MCP compatibility omx_state call reports that its stdio transport is unavailable/closed, do not retry the same MCP call. Retry once through the supported CLI parity surface with the same payload, preserving workingDirectory and session_id: omx state write --input '<json>' --json, omx state read --input '<json>' --json, or omx state clear --input '<json>' --json. If the CLI path also fails, continue with .omx/context / .omx/plans file-backed artifacts and report the state persistence blocker. </Tool_Usage>

Goal Mode Integration

Codex goal mode is the thread-level completion contract for long-running Ralph work. Ralph state tracks workflow mechanics; goal mode tracks whether the user objective is truly done. When the goal tools are available:

  1. Call get_goal during intake or before the first execution loop when the prompt/hook says an active thread goal exists.
  2. If no goal exists, call create_goal only when the user or system explicitly asked for goal tracking; otherwise continue with Ralph state alone.
  3. Treat goal.objective as binding acceptance scope. Newer user updates can refine the current branch, but do not silently narrow the goal.
  4. Before completion, perform a prompt-to-artifact checklist and completion audit against real evidence:
    • restate the objective as deliverables/success criteria
    • map every prompt requirement, named workflow ($ralplan, $ralph), file, command, test, gate, and deliverable to evidence
    • inspect the actual files, command output, state, and tests behind each checklist item
    • identify missing, weakly verified, or uncovered requirements and continue if any remain
  5. Call update_goal({status: "complete"}) only when the audit shows no required work remains. Do not use passing tests, Ralph state, or architect approval as proxy proof unless they cover the whole goal.
  6. If goal tools are unavailable, keep working through Ralph state and mention the missing goal-mode evidence in the final report.
Show full SKILL.md (1,081 more words)Show less

State Management

Use the CLI-first state surface for Ralph lifecycle state (omx state write/read/clear --input '<json>' --json). Explicit MCP compatibility tools (state_write, state_read, state_clear) remain acceptable only when already enabled.

  • On start: omx state write --input '{"mode":"ralph","active":true,"iteration":1,"max_iterations":10,"current_phase":"executing","started_at":"<now>","state":{"context_snapshot_path":"<snapshot-path>"}}' --json
  • On each iteration: omx state write --input '{"mode":"ralph","iteration":<current>,"current_phase":"executing"}' --json
  • On verification/fix transition: omx state write --input '{"mode":"ralph","current_phase":"verifying"}' --json or omx state write --input '{"mode":"ralph","current_phase":"fixing"}' --json
  • On completion (only after the completion audit passes with real evidence): omx state write --input '{"mode":"ralph","active":false,"current_phase":"complete","completed_at":"<now>","completion_audit":{"passed":true,"prompt_to_artifact_checklist":["<requirement mapped to artifact/evidence>"],"verification_evidence":["<fresh test/build/lint command and result>"]}}' --json
  • Before the final answer:
    1. Run fresh verification and read the output.
    2. Build prompt_to_artifact_checklist entries that map every user requirement, workflow gate, named file, command, PR/delivery requirement, and stop condition to a concrete artifact or evidence item.
    3. Build verification_evidence entries with concrete commands, exit status, files inspected, PR URLs, or other machine-checkable evidence.
    4. Write the Ralph completion state with a top-level completion_audit field on the Ralph state object. Do not write bare top-level prompt_to_artifact_checklist or verification_evidence fields by themselves; the Stop gate will reject them.
    5. Read the state back with omx state read --input '{"mode":"ralph"}' --json and verify completion_audit.passed === true, a non-empty checklist, and non-empty verification evidence before producing the final answer.
    6. If Codex goal mode is active, call update_goal({status:"complete"}) only after this Ralph audit read-back succeeds.
  • On cancellation/cleanup: run $cancel (which should call omx state clear --input '{"mode":"ralph"}' --json)

Scenario Examples

Good: The user says continue after the workflow already has a clear next step. Continue the current branch of work instead of restarting or re-asking the same question.

Good: The user changes only the output shape or downstream delivery step (for example make a PR). Preserve earlier non-conflicting workflow constraints and apply the update locally.

Bad: The user says continue, and the workflow restarts discovery or stops before the missing verification/evidence is gathered.

<Examples>
<Good>
Correct parallel delegation:
```
task(agent_type="executor", reasoning_effort="low", prompt="Add type export for UserConfig")
task(agent_type="executor", reasoning_effort="medium", prompt="Implement the caching layer for API responses")
task(agent_type="executor", reasoning_effort="xhigh", prompt="Refactor auth module to support OAuth2 flow")
```
Why good: Three independent tasks fired simultaneously while explicitly selecting the installed `executor` native role, so the UI/tracker does not show default subagents; legacy tier intent is preserved through native reasoning effort (`LOW` -> `low`, `STANDARD` -> `medium`, `THOROUGH` -> `xhigh`).
</Good>
<Good>
Correct verification before completion:
```
1. Run: npm test           → Output: "42 passed, 0 failed"
2. Run: npm run build      → Output: "Build succeeded"
3. Run: lsp_diagnostics    → Output: 0 errors
4. task(agent_type="architect", reasoning_effort="medium", prompt="verify completion") → Verdict: "APPROVED"
5. Run /cancel
```
Why good: Fresh evidence at each step, architect verification, then clean exit.
</Good>
<Bad>
Claiming completion without verification:
"All the changes look good, the implementation should work correctly. Task complete."
Why bad: Uses "should" and "look good" -- no fresh test/build output, no architect verification.
</Bad>
<Bad>
Sequential execution of independent tasks:
```
task(agent_type="executor", reasoning_effort="low", prompt="Add type export") → wait →
task(agent_type="executor", reasoning_effort="medium", prompt="Implement caching") → wait →
task(agent_type="executor", reasoning_effort="xhigh", prompt="Refactor auth")
```
Why bad: These are independent tasks that should run in parallel, not sequentially.
</Bad>
</Examples>

<Escalation_And_Stop_Conditions>

  • Stop and report when a fundamental blocker requires user input (missing credentials, unclear requirements, external service down)
  • Stop when the user says "stop", "cancel", or "abort" -- run /cancel
  • Continue working when the hook system sends "The boulder never stops" -- this means the iteration continues
  • If architect rejects verification, fix the issues and re-verify (do not stop)
  • If the same issue recurs across 3+ iterations, report it as a potential fundamental problem </Escalation_And_Stop_Conditions>

<Final_Checklist>

  • All requirements from the original task are met (no scope reduction)
  • Zero pending or in_progress TODO items
  • Fresh test run output shows all tests pass
  • Fresh build output shows success
  • lsp_diagnostics shows 0 errors on affected files
  • Architect verification passed: on a routing-capable surface via explicit task(agent_type="architect", reasoning_effort="medium"...) minimum. On the exact reviewed Codex releases 0.144.5, 0.145.0, 0.146.1, and 0.148.0-alpha.5 when role routing is unavailable, no adapted Ralplan Architect pass is valid; every other version remains unknown and fails closed. When adapted authority is attempted, preflight must have stopped with the leader-proof diagnostic. Ordinary Ralph work remains subject to its existing controls.
  • Codex goal-mode completion audit passed, and update_goal({status: "complete"}) was called when an active goal exists
  • ai-slop-cleaner pass completed on changed files (or --no-deslop specified)
  • Post-deslop regression tests pass
  • /cancel run for clean state cleanup </Final_Checklist>
<Advanced>
## PRD Mode (Optional)

When the user provides the --prd flag, initialize a Product Requirements Document before starting the ralph loop.

Detecting PRD Mode

Check if {{PROMPT}} contains --prd or --PRD.

Prompt-side $ralph workflow activation is lighter-weight than omx ralph --prd .... It seeds Ralph workflow state and guidance, but it does not implicitly launch the CLI entrypoint or apply the PRD startup gate. Treat omx ralph --prd ... as the explicit PRD-gated path.

Detecting --no-deslop

Check if {{PROMPT}} contains --no-deslop. If --no-deslop is present, skip the deslop pass entirely after Step 7 and continue using the latest successful pre-deslop verification evidence.

Visual Reference Flags (Optional)

Ralph execution supports visual reference flags for screenshot tasks:

  • Repeatable image inputs: -i <image-path> (can be used multiple times)
  • Image directory input: --images-dir <directory>

Example: ralph -i refs/hn.png -i refs/hn-item.png --images-dir ./screenshots "match HackerNews layout"

PRD Workflow
  1. Run deep-interview in quick mode before creating PRD artifacts:
    • Execute: $deep-interview --quick <task>
    • Complete a compact requirements pass (context, goals, scope, constraints, validation)
    • Persist interview output to .omx/interviews/{slug}-{timestamp}.md
  2. Create canonical PRD/progress artifacts:
    • PRD: .omx/plans/prd-{slug}.md
    • Progress ledger: .omx/state/{scope}/ralph-progress.json (session scope when available, else root scope)
  3. Parse the task (everything after --prd flag)
  4. Break down into user stories:
json
{
  "project": "[Project Name]",
  "branchName": "ralph/[feature-name]",
  "description": "[Feature description]",
  "userStories": [
    {
      "id": "US-001",
      "title": "[Short title]",
      "description": "As a [user], I want to [action] so that [benefit].",
      "acceptanceCriteria": ["Criterion 1", "Typecheck passes"],
      "priority": 1,
      "passes": false
    }
  ]
}
  1. Initialize canonical progress ledger at .omx/state/{scope}/ralph-progress.json
  2. Guidelines: right-sized stories (one session each), verifiable criteria, independent stories, priority order (foundational work first)
  3. Proceed to normal ralph loop using user stories as the task list
Example

User input: --prd build a todo app with React and TypeScript Workflow: Detect flag, extract task, create .omx/plans/prd-{slug}.md, create .omx/state/{scope}/ralph-progress.json, begin ralph loop.

Legacy compatibility
  • During the compatibility window, Ralph --prd startup still validates machine-readable story state from .omx/prd.json.
  • .omx/plans/prd-{slug}.md remains the canonical storage/documentation artifact, but it is not yet the startup validation source.
  • If .omx/prd.json exists and canonical PRD is absent, migrate one-way into .omx/plans/prd-{slug}.md.
  • If .omx/progress.txt exists and canonical progress ledger is absent, import one-way into .omx/state/{scope}/ralph-progress.json.
  • Keep legacy files unchanged for one release cycle.

Background Execution Rules

Run in background (run_in_background: true):

  • Package installation (npm install, pip install, cargo build)
  • Build processes (make, project build commands)
  • Test suites
  • Docker operations (docker build, docker pull)

Run blocking (foreground):

  • Quick status checks (git status, ls, pwd)
  • File reads and edits
  • Simple commands
    </Advanced>

Original task: {{PROMPT}}

© yangyuan-zhen, AGPL-3.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .codex/skills/ralph of yangyuan-zhen/PolyWeather.

Open the folder on GitHubat commit 43e658b

Compare with similar skills

Ralph next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Ralph compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Ralph this skillyangyuan-zhen/PolyWeather316—~5.7kAutomated safety check: PassAGPL-3.0
RalphYeachan-Heo/oh-my-claudecode40k—~7.5kAutomated safety check: PassMIT
Agent Repo Architectruvnet/ruflo74k2 repos~3kAutomated safety check: PassMIT
Hindsight Architectvectorize-io/hindsight48k—~10kAutomated safety check: NotesMIT
Ralphzereight/gitlab-mcp2k1 repos~711Automated safety check: PassMIT
Ralph Loopcursor/plugins11k—~469Automated safety check: PassNone

Similar skills

  • Ralph

    Yeachan-Heo/oh-my-claudecode

    Self-referential loop until task completion with configurable verification reviewer

    40k GitHub stars~7.5k tokensUpdated 2 days ago
    Product & Project ManagementAuto-check passed
  • Agent skill for repo-architect - invoke with $agent-repo-architect

    74k GitHub starsUsed in 2 repos~3k tokens
    Auto-check passed
  • Hindsight Architect

    vectorize-io/hindsight

    Expert memory architect. An agent skill from vectorize-io/hindsight.

    48k GitHub stars~10k tokensUpdated today
    Agent WorkflowsAuto-check: notes
  • Ralph

    zereight/gitlab-mcp

    PRD-driven persistence loop until task completion with verification.

    2k GitHub starsUsed in 1 repo~711 tokens
    Product & Project ManagementAuto-check passed
  • Ralph Loop

    cursor/plugins

    Official

    Start a Ralph Loop for iterative self-referential development.

    11k GitHub stars~469 tokensUpdated today
    Agent WorkflowsAuto-check passed
  • Agent skill for v3-integration-architect - invoke with $agent-v3-integration-architect

    74k GitHub starsUsed in 2 repos~2.7k tokens
    Agent WorkflowsAuto-check passed

More from yangyuan-zhen/PolyWeather

All 26 skills in this repo
  • AI Slop Cleaner

    yangyuan-zhen/PolyWeather

    [OMX] Run an anti-slop cleanup/refactor/deslop workflow. An agent skill from yangyuan-zhen/PolyWeather.

    316 GitHub stars~2.2k tokensUpdated 19 days ago
    Auto-check passed
  • Analyze

    yangyuan-zhen/PolyWeather

    [OMX] Run read-only deep repository analysis and return a ranked synthesis with explicit confidence, concrete file references, and clear evidence-vs-inference boundaries.

    316 GitHub stars~1.6k tokensUpdated 19 days ago
    Auto-check passed
  • Autoresearch

    yangyuan-zhen/PolyWeather

    [OMX] Stateful validator-gated research loop with native-hook persistence

    316 GitHub stars~786 tokensUpdated 19 days ago
    Auto-check passed
  • Best Practice Research

    yangyuan-zhen/PolyWeather

    [OMX] Bounded best-practice research wrapper using official/upstream evidence first

    316 GitHub stars~1.4k tokensUpdated 19 days ago
    Auto-check passed
  • Cancel

    yangyuan-zhen/PolyWeather

    [OMX] Cancel any active OMX mode (autopilot, ralph, ultrawork, ecomode, ultraqa, swarm, ultrapilot, pipeline, team)

    316 GitHub stars~3.7k tokensUpdated 19 days ago
    Auto-check passed
  • Configure Notifications

    yangyuan-zhen/PolyWeather

    [OMX] Configure OMX notifications - unified entry point for all platforms

    316 GitHub stars~2.7k tokensUpdated 19 days ago
    Auto-check passed

Questions about Ralph

What does Ralph do?

[OMX] Self-referential loop until task completion with architect verification. Ralph is an agent skill from yangyuan-zhen/PolyWeather.

How do I install Ralph in Claude Code?

Run `npx skills add yangyuan-zhen/PolyWeather --skill ralph -a claude-code`. Or copy the skill folder (.codex/skills/ralph in yangyuan-zhen/PolyWeather) into .claude/skills/ralph in your project. Claude Code loads it when a task matches its description.

How do I install Ralph in Codex?

Run `npx skills add yangyuan-zhen/PolyWeather --skill ralph -a codex`. Or copy the skill folder (.codex/skills/ralph in yangyuan-zhen/PolyWeather) into .agents/skills/ralph in your project. Codex loads it when a task matches its description.

Can I use Ralph in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add yangyuan-zhen/PolyWeather --skill ralph -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/ralph, .gemini/skills/ralph, .github/skills/ralph and .opencode/skills/ralph in your project.

What does Ralph need to run?

Going by SKILL.md and its folder, Ralph needs the command-line tools its instructions call (make).

Does Ralph access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Ralph safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Ralph use?

Ralph is published under the AGPL-3.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Ralph use?

About 5.7k tokens (SKILL.md is roughly 23k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Ralph?

Skills that share tags, products or a category with Ralph: Ralph (Yeachan-Heo/oh-my-claudecode, 40k stars), Agent Repo Architect (ruvnet/ruflo, 74k stars), Hindsight Architect (vectorize-io/hindsight, 48k stars) and Ralph (zereight/gitlab-mcp, 2k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Ralph?

yangyuan-zhen (a GitHub user) maintains it in yangyuan-zhen/PolyWeather, which has 316 GitHub stars. The repository holds 26 skills in this directory. The repository was last updated on September 20, 2026.

Source: yangyuan-zhen/PolyWeather on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.