agentleFS
team-attentionteam-attention/hoyeon/skills/ralph/SKILL.md

ralph

Skill173 starsChanged 8 months agoMITView on GitHub

Iterative task completion loop with Definition of Done verification. Combines the Ralph Wiggum technique (prompt re-injection via Stop hook) with DoD-based independent verification. Claude proposes DoD criteria, user confirms, then Claude works autonomously. Stop hook re-injects the original prompt and blocks exit until all DoD items are independently verified. "/ralph", "ralph loop", "ralph 루프", "반복 작업", "DoD 루프", "완료 검증 루프", "task loop", "keep going until done"

We split this skill into the rules it gives an agent

13 rules. 0 are common, 10 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 39 edited versions we read keep these.

  • 10

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    When you try to stop, the Stop hook checks the DoD checklist:

    line 36
  2. Distinctive:

    If unchecked items remain → blocks exit, re-injects original prompt + remaining items

    line 37
  3. Distinctive:

    If all items checked → allows exit

    line 38
  4. Distinctive:

    Read the user's request carefully.

    line 49
  5. Very specific:

    Use AskUserQuestion to confirm:

    line 75
  6. Distinctive:

    After user confirms, initialize the loop state and write the DoD file.

    line 91
  7. Very specific:

    Do NOT read or modify the DoD file (ralph-dod.md) — it's guarded by the system

    line 140
  8. Distinctive:

    Do NOT try to check off DoD items yourself — the Stop hook handles verification

    line 141
  9. Distinctive:

    When you believe the work is complete, simply finish your response normally.

    line 145
  10. Distinctive:

    Check the DoD file for unchecked items

    line 146
  11. Very specific:

    If items remain: block exit, re-inject the original prompt in reason, list remaining items in systemMessage

    line 147
  12. Distinctive:

    If all items checked: allow exit

    line 148
  13. Distinctive:

    If FAIL items were fixed, the next Stop hook will trigger another verification round

    line 162

“Common” is measured: kept by at least 6 in 10 of the 39 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

ralph

Iterative task completion loop driven by a user-confirmed Definition of Done. Combines the Ralph Wiggum technique (prompt re-injection on stop) with DoD-based independent verification.

How it works:

  1. You propose DoD criteria based on the user's request
  2. User confirms/modifies via AskUserQuestion
  3. You work on the task
  4. When you try to stop, the Stop hook checks the DoD checklist:
    • If unchecked items remain → blocks exit, re-injects original prompt + remaining items
    • If all items checked → allows exit
  5. Loop continues until all DoD items verified or circuit breaker (max 10 iterations)

Phase 1: DoD Collection

Build a Definition of Done through interactive confirmation before starting work.

Step 1 — Analyze & Propose

Read the user's request carefully. Based on the task, propose 3–7 concrete, verifiable DoD criteria.

Good criteria (binary, independently verifiable):

  • "All unit tests pass (npm test exits 0)"
  • "New function parseConfig() exists in src/config.ts"
  • "No TypeScript errors (tsc --noEmit exits 0)"

Bad criteria (vague, subjective):

  • "Code is clean" → reword to "No lint warnings (eslint . exits 0)"
  • "Works correctly" → reword to specific test or behavior check

Present as a numbered markdown checklist:

Based on your request, here's my proposed Definition of Done:

1. [concrete criterion 1]
2. [concrete criterion 2]
3. [concrete criterion 3]
...

Each item will be independently verified before the task is considered complete.

Step 2 — User Confirmation

Use AskUserQuestion to confirm:

"Here are the proposed DoD criteria. You can:

  • Accept as-is
  • Add criteria (tell me what to add)
  • Remove criteria (tell me which to remove)
  • Modify criteria (tell me what to change)

Also, set max iterations (default: 10) if you want to limit the loop."

Loop until the user accepts. Parse their response for:

  • Additions, removals, or modifications
  • Custom max_iterations (default 10 if not specified)

Step 3 — State Initialization

After user confirms, initialize the loop state and write the DoD file.

Write DoD file — create the checklist as a markdown file:

Bash: SESSION_ID="[session ID from hook]" && mkdir -p "$HOME/.hoyeon/$SESSION_ID/files" && cat > "$HOME/.hoyeon/$SESSION_ID/files/ralph-dod.md" << 'DODEOF'
# Definition of Done

- [ ] [criterion 1]
- [ ] [criterion 2]
- [ ] [criterion 3]
...
DODEOF

Write state — store the original prompt and configuration for the Stop hook:

Bash: SESSION_ID="[session ID from hook]" && PROMPT=$(cat << 'PROMPTEOF'
[The user's ORIGINAL request/prompt — exactly as they typed it, before any processing]
PROMPTEOF
) && hoyeon-cli session set --sid "$SESSION_ID" --json "$(jq -n \
  --arg prompt "$PROMPT" \
  --arg dod_file "$HOME/.hoyeon/$SESSION_ID/files/ralph-dod.md" \
  --arg created_at "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  '{ralph: {prompt: $prompt, iteration: 0, max_iterations: 10, dod_file: $dod_file, created_at: $created_at}}')"

Replace max_iterations: 10 with the user's chosen value if they specified one.

Display confirmation:

## Ralph Loop Initialized

**Task**: [summary of what you'll do]
**DoD**: [N] criteria
**Max iterations**: [max_iterations]

Starting work. The loop will verify each DoD item independently before allowing completion.

Phase 2: Work Execution

Now do the actual work. Focus on completing the task to satisfy all DoD criteria.

Rules during work:

  • Do NOT read or modify the DoD file (ralph-dod.md) — it's guarded by the system
  • Do NOT try to check off DoD items yourself — the Stop hook handles verification
  • Focus purely on the task described in the user's original request
  • Work thoroughly — the loop will catch anything you miss

When you believe the work is complete, simply finish your response normally. The Stop hook will:

  1. Check the DoD file for unchecked items
  2. If items remain: block exit, re-inject the original prompt in reason, list remaining items in systemMessage
  3. If all items checked: allow exit

On re-entry (after Stop hook blocks):

  • You will receive the original prompt again as your task
  • The systemMessage will instruct you to spawn a ralph-verifier agent

Verification via separate agent (context isolation):

  1. Spawn ralph-verifier agent with subagent_type="ralph-verifier" in FOREGROUND (do NOT use run_in_background=true)
    • Background spawn causes the main agent to stop → Stop hook fires → loop breaks
    • Pass the DoD file path and original prompt
  2. The verifier runs in a fresh context — no bias from the work phase
  3. Parse the verifier's JSON results:
    • PASS items → change - [ ] to - [x] in the DoD file
    • FAIL items → fix the underlying issue in this iteration
  4. If FAIL items were fixed, the next Stop hook will trigger another verification round

Why a separate agent? The agent that wrote the code should NOT verify its own work. The verifier agent starts clean, reads actual files/tests, and judges objectively.


Prompt Hardening

  • Store the original prompt in state.json via heredoc to prevent shell injection
  • The Stop hook re-injects the prompt via jq JSON construction (safe)
  • DoD file is guarded during work phase — only editable during verification
  • Circuit breaker at max_iterations prevents infinite loops

Download now (ZIP)

  • Other versions43 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 43

    1. Yeachan-Heo/oh-my-claudecode★ 40ksame name
    2. Yeachan-Heo/oh-my-claude-sisyphus★ 40ksame name
    3. Yeachan-Heo/oh-my-codex★ 34ksame name
    4. snarktank/ralph★ 22ksame name
    5. Q00/ouroboros★ 6.3ksame name
    6. zereight/gitlab-mcp★ 2.1ksame name
    7. srid/emanote★ 963same name
    8. opentabs-dev/opentabs★ 926same name
    9. first-fluke/fullstack-starter★ 223same name
    10. jellydn/my-ai-tools★ 126same name

    33 more not listed

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • Used alongsideProjects with it also use cancel, configure-notifications and 9 more.

    Other files people use alongside this one.

    Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
    • ibahgatSkill

      cancel

      Gracefully stop active autonomous workflow, preserve progress, and produce a resume-ready handoff.

      Also in 9 projects that use this

    • Jurel89Skill

      configure-notifications

      Wire Telegram / Discord / Slack notifications for copilot-omni run events (start, progress, completion, error)

      Also in 4 projects that use this

    • ibahgatSkill

      ralplan

      Create a strict, quality-first execution plan with explicit gates and rollback-ready sequencing.

      Also in 7 projects that use this

    • Jurel89Skill

      ai-slop-cleaner

      Clean AI-generated code slop with a regression-safe, deletion-first workflow and optional reviewer-only mode

      Also in 5 projects that use this

    • JokerRunSkill

      compound-engineering

      Compound Engineering workflow for AI-assisted development. Use when planning features, executing work, reviewing code, or codifying learnings. Follows the Plan → Work → Review → Compound loop where each unit of engineering makes subsequent work easier. Triggers on: plan this feature, implement this, review this code, compound learnings, create implementation plan, systematic development.

      Also in 3 projects that use this

    • klauswgSkill

      deep-interview

      在明确批准执行之前,通过数学化歧义门控进行苏格拉底式深度访谈

      Also in 6 projects that use this

    • +3 more from Jurel89
    • +1 more from ibahgat
  • In this repository27 other files it gives its agents.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.