The generic persistent-task Ralph pattern: iterate on one named task until its acceptance criteria are met and the suite is green, bounded by a 15-turn cap and a no-progress stop. Anti-reward-hacking clauses keep it from editing tests to go green, and it hands off via a PR instead of merging. Swap the check command for your stack's.
/loop Work the named task to completion. Each turn: pick the next incomplete subtask, make the smallest change that advances it, then run `npm test && npm run lint` and fix whatever breaks before moving on. Stop when every acceptance criterion for the task is met and `npm test` exits 0 — or stop after 15 turns, whichever comes first. Never modify, skip, or weaken a test to make it pass, never delete a failing assertion, and keep each diff minimal and scoped to the named task. If two consecutive turns produce no progress, stop and report what is blocking. When the task is done, open a pull request for review — never merge it yourself.
# dare-to-be-stupid — Design (v2, refined) > A Claude Code plugin. One command, /dare , hands an idea or PRD to an autonomous > loop that authors specs, designs, builds, tests, secures, ships, fixes, and iterates > until the app passes an enterprise-production definition of done — or the budget dies. > > Named for the Weird Al song. The joke is that it runs the Ralph Loop on purpose , > with --dangerously-skip-permissions , and narrates the whole thing in the voice of an > '80s Junkion. Pre-production only. Never points at anything with users. This is v2. It keeps the strong core of the original spec (external reviewer, ratchet, guard hook, Junkion style) and adds the three phases the original left thin relative to the actual goal: PRD authoring, a design phase, and a real enterprise DoD including security, CI, docs/observability, and design quality (with quality plugins auto-installed). --- ## 0. The premise, in one paragraph The User builds documentation-first: spec → system docs → API contracts → CLAUDE.md → code. dare-to-be-stupid is the deliberate inverse, packaged as comedy that also solves two real engineering problems. It is a real build , not a joke ar
--- description: Run the Ralph Wiggum loop for a spec (Claude Code) --- Use this command to run an autonomous Ralph loop for a spec: /ralph-loop:ralph-loop "Implement spec {spec-name} from specs/{spec-name}/spec.md. Complete ALL Completion Signal requirements. Output <promise>DONE</promise> when complete." --completion-promise "DONE" --max-iterations 30
/loop cadence: weekly. you are my share-of-model tracker. read share-of-model-STATE.md: the fixed query set and the time series so far. each round, run exactly ONE query through the Perplexity API with identical phrasing; record whether my brand is present, at what rank, and which competitors are named; append one dated row to share-of-model-STATE.md (append only, never rewrite history). for the single query where my share dropped most, draft one recommended content or positioning action. measure only, never claim causation. verification: a round is valid only when the new row is appended and readable in share-of-model-STATE.md. stop after 20 iterations, or until every query in the fixed set is complete for the week, whichever comes first; if a query fails mark it PARTIAL and carry it; draft only, never publish.
A fill-in-the-brackets charter that turns any pile of small tasks into a self-checking loop: where the work is, how to check each item with evidence, a needs-me escalation list, a state file, and a per-run stop.
You are running as a loop, not answering one prompt. Here is your charter.
GOAL: [Describe the finished state in one or two sentences. Be specific about what DONE looks like, and make it measurable.]
WHERE THE WORK IS: [e.g. "Scan the /pages folder for files with old pricing" or "Read TODO.md and treat each unchecked box as a task."]
HOW TO WORK: Do one item at a time; finish it fully before starting the next. Match the patterns in existing files; do not invent new ones. If an item needs a decision only I can make (spending money, deleting things, emailing a person), stop on that item, add it to a "needs me" list, and move to the next one.
HOW TO CHECK YOURSELF: After each item, prove it is done before you mark it done — run the tests / re-read the file / open the link. Checking means evidence, not confidence. If the check fails, fix it and check again: maximum 3 attempts per item, then log it as blocked and move on.
HOW TO REMEMBER: Keep LOOP-STATE.md. After each item write the item name, status (done / blocked / needs me), what changed, and anything the next run should know. Read this file FIRST every run.
WHEN TO STOP: Stop when every item is done or logged as blocked, or when you have finished [N] items this run. Then report: what got done, what is blocked, what needs my call.
Start by reading LOOP-STATE.md if it exists, then find the work.
Split a large mechanical job into 2–5 independent Codex lanes, each isolated in its own worktree with a frozen acceptance bar and binding judge, then block the final merge behind a full integration judge.
Dispatch a parallel Codex legion for a large mechanical job. Split the work into 2–5 genuinely independent lanes, one lane per piece.
First announce a muster table with:
- each lane,
- the exact files that lane may touch,
- the frozen acceptance check for that lane.
Do not proceed until I approve the split.
Before dispatch, the orchestrator must freeze and record each lane’s acceptance bar. After dispatch, each worker treats `.git` as read-only.
Each lane must run in its own git worktree with:
- a frozen acceptance bar recorded before code changes,
- a strictly disjoint may-touch manifest,
- its own sandbox,
- read-only `.git` state for the worker.
If any lane’s file footprint overlaps another lane, refuse the split and serialize the work instead.
When a lane finishes, run a fresh-context judge against that lane’s frozen bar. The judge must return binding PASS or FAIL. Allow at most 2 retries per lane; stop after 2 failed attempts, then escalate loudly.
Merge lanes in a fixed order. After merging, require a mandatory integration judge that reruns the full test suite across the combined result. Do not commit or merge unless the integration judge returns PASS.
Hard cap: 5 workers. If there are more than 5 pieces, run later waves. Never merge without the integration judge.
praetor is a Claude Code plugin that runs a plan → freeze acceptance bar → dispatch → independent fresh-context judge → resolve loop. Claude plans and judges, Codex executes; a FAIL from the judge cannot be overridden, with at most 2 retries before a loud takeover.
Plan the task and freeze the acceptance criteria in .codex/ACCEPTANCE.md before any work begins. Isolate on a throwaway branch, write a self-contained brief, then dispatch execution to Codex. When Codex finishes, spawn a fresh-context independent judge that runs every check in the frozen bar against the uncommitted working tree and returns a binding PASS or FAIL — a FAIL cannot be overridden. The judge never fixes anything and commits nothing; it touches manifest paths only. Resolve with at most 2 retries; on continued failure, hand back with a loud takeover. Commit only after the judge passes, then clean up and write the ledger. Iron laws: frozen bar before dispatch, binding judge, max 2 retries then loud takeover.
# Ralph  Ralph is a minimal, file‑based agent loop for autonomous coding. Each iteration starts fresh, reads the same on‑disk state, and commits work for one story at a time. ## How it works Ralph treats files and git as memory, not the model context: - PRD (JSON) defines stories, gates, and status - Loop executes one story per iteration - State persists in .ralph/  ## Global CLI (recommended) Install and run Ralph from anywhere: bash npm i -g @iannuttall/ralph ralph prd # launches an interactive prompt ralph build 1 # one Ralph run ### Template hierarchy Ralph will look for templates in this order: 1. .agents/ralph/ in the current project (if present) 2. Bundled defaults shipped with this repo State and logs always go to .ralph/ in the project. ### Install templates into a project (optional overrides) bash ralph install This creates .agents/ralph/ in the current repo so you can customize prompts and loop behavior. During install, you’ll be asked if you want to add the required skills. ### Install required skills (optional) bash ralph install --skills You’ll be prom Cap the run at 25 iterations; leave remaining work for the next session.
Email is the missing tool in your harness. ConnectMyEmail gives Claude Code and Codex a clean MCP into Gmail, Outlook, iCloud and IMAP — triage, drafts, follow-ups, on a loop.
/schedule every Friday at 2pm, draft release notes from the PRs merged since the last draft: group changes into features, fixes, and docs, write one plain-English line per change with the PR link, and save to releases/DRAFT.md. Draft only — a human edits and publishes; never post or send anywhere. Verify every PR link resolves and every merged PR since the last run is covered before saving. Stop after 1 pass per run.
/loop 20m Continue autoresearch. Read research-state.yaml and findings.md. Re-read the autoresearch SKILL.md occasionally to stay aligned. Step back and reflect holistically — is the research making real progress? Are you deepening understanding or just running experiments? If stalling, pivot or search literature for new ideas. Keep making research progress — never idle, never stop. Update findings.md, research-log.md, and research-state.yaml when there's new progress. Git commit periodically and clean up the repo if needed. Show the human your research progress with key plots and findings by preparing a report in to human/ and opening the HTML/PDF. Only when you believe the research is truly complete, invoke the ml-paper-writing skill to write the paper
Guardrails: Stop when the goal is verifiably met, or stop after 15 iterations, whichever comes first. Verify each pass by running the relevant tests or checks — self-reported success does not count.
Runs Claude Code/Codex as an autonomous multi-role dev team — planner → reviewer ↔ fixer → worker — across all of a user's GitHub repos, entirely driven by issue labels. Each loop runs in its own git worktree so multiple repos/issues proceed in parallel without collisions.
Register a repo with looper, then label an issue `looper:plan` and assign it to yourself. The planner reads the issue, explores the repo, drafts a spec, critiques and revises it, and opens a spec PR labeled `looper:spec-reviewing`. A reviewer re-reads the PR on every commit and posts inline review threads; a fixer pulls those threads, addresses them in its own worktree, and pushes, ping-ponging with the reviewer until every thread is resolved. Once labeled `looper:spec-ready`, a worker implements the spec, runs checks, and iterates on its own output until checks pass and the PR is ready for human review and merge. Every phase transition is gated on a GitHub label via `looperd`, so a human can pause or take over at any boundary.
Codex's native answer to scheduled agent loops: define a prompt plus a schedule in the Codex app and it runs in the cloud on cadence — nightly dependency audits, morning issue triage — with no terminal open. The Codex-side equivalent of Claude Code Routines.
Define an Automation in the Codex app: a prompt + schedule that runs in the cloud on cadence (e.g., nightly dependency audit, morning triage of new issues), no terminal open.
Guardrails: Stop when the goal is verifiably met, or stop after 15 iterations, whichever comes first. Verify each pass by running the relevant tests or checks — self-reported success does not count. Keep changes minimal and never touch files outside the task’s scope.
A cost-safety pattern that pairs every overnight loop with a second, dumber loop whose only job is stopping the first: spend alerts, a hard iteration cap, and a cron check that kills the worker when token burn spikes or the same command keeps repeating.
Pair every overnight loop with a watchdog: spend/usage alert thresholds, a hard `MAX_ITER`, and a cron check that kills the loop process if tokens-per-minute spikes or the same command repeats N times. The watchdog is a second, dumber loop whose only job is stopping the first one. Cap the run at 25 iterations; leave remaining work for the next session.
An outer-planner/inner-coder loop from an official OpenAI recipe: an Agents SDK orchestrator plans and verifies while Codex CLI, wrapped as an MCP server, performs one bounded code change per turn.
Wrap Codex CLI as an MCP server and drive it from an OpenAI Agents SDK orchestrator loop — the outer agent plans/verifies, the inner Codex call does one bounded code change per turn.
Guardrails: Stop when the goal is verifiably met, or stop after 15 iterations, whichever comes first. Verify each pass by running the relevant tests or checks — self-reported success does not count. Keep changes minimal and never touch files outside the task’s scope.
The two-layer answer to how do I run this overnight: /goal drives in-session work to done, while a scheduled Routine keeps recurring unattended work running on Anthropic's cloud with your laptop closed.
/schedule a Routine (runs on Anthropic cloud, laptop closed) for recurring unattended work, and use `/goal` for in-session iterate-to-done — the two-layer overnight pattern.
Guardrails: Stop when the goal is verifiably met, or stop after 15 iterations, whichever comes first. Verify each pass by running the relevant tests or checks — self-reported success does not count. Keep changes minimal and never touch files outside the task’s scope.
Anthropic's first-party file-as-memory harness for long-running agents: every fresh-context session recovers state from a progress file and the git log, does one unit of work, updates the file, commits, and exits.
Long-running agent harness: each fresh-context session starts by reading `claude-progress.txt` + git log to recover state, does one unit of work, updates the progress file, commits, exits. Initializer session sets up the file; coder sessions loop.
Guardrails: Stop when the goal is verifiably met, or stop after 15 iterations, whichever comes first. Verify each pass by running the relevant tests or checks — self-reported success does not count. Keep changes minimal and never touch files outside the task’s scope.
Email is the missing tool in your harness. ConnectMyEmail gives Claude Code and Codex a clean MCP into Gmail, Outlook, iCloud and IMAP — triage, drafts, follow-ups, on a loop.
Anthropic's first-party take on the Ralph loop: a Claude Code plugin that runs the iterate-fresh-context pattern with a managed stop and iteration mechanism built in.
Install the `ralph-wiggum` plugin from the anthropics/claude-code repo; it wraps the Ralph loop with a managed stop/iteration mechanism inside Claude Code.
Guardrails: Stop when the goal is verifiably met, or stop after 15 iterations, whichever comes first. Verify each pass by running the relevant tests or checks — self-reported success does not count. Keep changes minimal and never touch files outside the task’s scope.
The canonical Ralph Wiggum loop by Geoffrey Huntley: a bash while-loop that feeds Claude Code one fresh-context iteration at a time, using the filesystem and git as memory. Run it only in a sandboxed environment with permissions configured — never with permission checks disabled.
`while :; do cat PROMPT.md | claude -p ; done` — PROMPT.md holds the spec + "pick ONE task from the plan, implement, test, commit, exit." Fresh context every iteration; filesystem + git = memory.
Guardrails: Stop when the goal is verifiably met, or stop after 15 iterations, whichever comes first. Keep changes minimal and never touch files outside the task’s scope.
A Ralph-style loop that writes its own rules: when a check fails the same way twice, the failure pattern gets appended to a guardrails file that every later iteration reads first.
/loop read .ralph/guardrails.md before doing anything, then run the full check suite and fix the first failure; if a check fails twice with the same error, append the failure pattern and a one-line rule for avoiding it to .ralph/guardrails.md before retrying; stop when all checks pass or after 15 turns