Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Ralph Wiggum-inspired automation loop for specification-driven development. Orchestrates task implementation, review, cleanup, and synchronization using a Python script. Use when: user runs /loop command, user asks to automate task implementation, user wants to iterate through spec tasks step-by-step, or user wants to run development workflow automation with context window management. One step per invocation. State machine: init → choose_task → implementation → review → fix → cleanup → sync → up
.claude/skills/giuseppe-trisciuoglio-ralph-loop/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-05 | ✗→✓ | ▲ Improved | 350% | 0% |
| case-04 | ✗→✓ | ▲ Improved | 380% | 0% |
| case-08 | ✗→✓ | ▲ Improved | 213% | 0% |
| case-11 | ✗→✓ | ▲ Improved | 86% | 0% |
| case-13 | ✗→✓ | ▲ Improved | 69% | 0% |
> ⚠️ WARNING: This skill was deprecated in favor of a new command ralph-loop-v2 that uses a Python orchestrator script. > The old /specs:ralph-loop command will be removed soon. Please migrate to the new command.
⚠️ IMPORTANT: This skill uses a Python orchestrator script. Do NOT execute arbitrary bash commands. Use Bash ONLY to run ralph_loop.py. All task commands (like /developer-kit-specs:specs.task-implementation) are shown to the user to execute manually.
The Ralph Loop applies Geoffrey Huntley's "Ralph Wiggum as a Software Engineer" technique to specification-driven development. It uses a Python orchestrator script that manages a state machine: one invocation = one step, state persisted in fix_plan.json.
Key insight: Implementing + reviewing + syncing in one invocation explodes the context window. Solution: each loop iteration does exactly one step, saves state to fix_plan.json, and stops. The next iteration resumes from saved state.
Key improvement: The Python script ralph_loop.py handles all state management, task selection, and command generation. It does NOT execute task commands directly — it shows you the correct command to execute in your CLI.
/loop command for recurring automation┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ ralph_loop.py │────▶│ fix_plan.json │────▶│ User executes │
│ (orchestrator)│ │ (state file) │ │ command in CLI │
└─────────────────┘ └─────────────────┘ └─────────────────┘
│ │
│ ▼
│ ┌─────────────────┐
└──────────────────────────────────────│ Task result │
│ (success/ │
│ failure) │
└─────────────────┘One Step Flow:
ralph_loop.py --action=loopfix_plan.json and determines current step/developer-kit-specs:specs.task-implementation)ralph_loop.py --action=loop againfix_plan.json state machine:
┌─────────────────────────────────────────────────────────────┐
│ state: "init" │
│ → --action=start: Initialize fix_plan.json │
│ → Load tasks from tasks/TASK-*.md files │
│ → Apply task_range filter │
│ │
│ state: "choose_task" │
│ → Pick next pending task (within range, deps satisfied)│
│ → No tasks in range → state: "complete" │
│ → Task found → state: "implementation" │
│ │
│ state: "implementation" │
│ → Show /developer-kit-specs:specs.task-implementation command │
│ → User executes, then runs loop again │
│ → Next state: "review" │
│ │
│ state: "review" ││ → Show /developer-kit-specs:specs.task-implementation --action=cleanup command│},{find: │
│ → User reviews results, then runs loop again │
│ → Issues found → state: "fix" (retry ≤ 3) │
│ → Clean → state: "cleanup" │
│ │
│ state: "fix" │
│ → Show commands to fix issues │
│ → User applies fixes, then runs loop again │
│ → Next state: "review" │
│ │
│ state: "cleanup" │
│ → Show /developer-kit-specs:specs.task-implementation --action=cleanup command│
│ → Next state: "sync" │
│ │
│ state: "sync" │
│ → Show /developer-kit-specs:specs.sync command │
│ → Next state: "update_done" │
│ │
│ state: "update_done" │
│ → Mark task done, commit git changes │
│ → Re-evaluate dependencies │
│ → state: "choose_task" │
│ │
│ state: "complete" | "failed" │
│ → Print result, stop │
└─────────────────────────────────────────────────────────────┘⚠️ CRITICAL: The fix_plan.json file MUST ALWAYS be located in:
docs/specs/[ID-feature]/_ralph_loop/fix_plan.jsonThis is enforced by the script to prevent LLMs from creating files in wrong locations.
Migration: If you have an old fix_plan.json in the root of your spec folder, the script will automatically migrate it to _ralph_loop/ on first run.
Run the Python script with --action=start to scan task files and create fix_plan.json in the correct location:
bashpython3 plugins/developer-kit-specs/skills/ralph-loop/scripts/ralph_loop.py \ --action=start \ --spec=docs/specs/001-feature/ \ --from-task=TASK-036 \ --to-task=TASK-041
Run the script with --action=loop to get the current state and the command to execute:
bashpython3 plugins/developer-kit-specs/skills/ralph-loop/scripts/ralph_loop.py \ --action=loop \ --spec=docs/specs/001-feature/
The script will show you the exact command to execute for the current step. Execute it in your CLI, then run the loop command again.
After executing the shown command, manually advance to the next step:
bashpython3 plugins/developer-kit-specs/skills/ralph-loop/scripts/ralph_loop.py \ --action=next \ --spec=docs/specs/001-feature/
This updates fix_plan.json to the next state (e.g., implementation → review).
Check status anytime with --action=status:
bashpython3 plugins/developer-kit-specs/skills/ralph-loop/scripts/ralph_loop.py \ --action=status \ --spec=docs/specs/001-feature/
bashpython3 plugins/developer-kit-specs/skills/ralph-loop/scripts/ralph_loop.py \ --action=start \ --spec=docs/specs/001-feature/ \ --from-task=TASK-036 \ --to-task=TASK-041 \ --agent=claude
bashpython3 plugins/developer-kit-specs/skills/ralph-loop/scripts/ralph_loop.py \ --action=loop \ --spec=docs/specs/001-feature/
The script will show you the command to execute. Run it, then run the loop again.
bashpython3 plugins/developer-kit-specs/skills/ralph-loop/scripts/ralph_loop.py \ --action=status \ --spec=docs/specs/001-feature/
| Argument | Description | |----------|-------------| | --action | start (init), loop (run one step), status, resume, next (advance step) | | --spec | Spec folder path (e.g. docs/specs/001-feature/) | | --from-task | Start of task range (e.g. TASK-036) | | --to-task | End of task range (e.g. TASK-041) | | --agent | Default agent: claude, codex, copilot, kimi, gemini, glm4, minimax | | --no-commit | Skip git commits (for testing) |
--action=start)The script:
tasks/TASK-*.md files in the spec folder--from-task and --to-task filtersfix_plan.json with full statechoose_task)The script:
fix_plan.json with current_taskimplementation)The script shows:
→ Implementation: TASK-037
Execute:
/developer-kit-specs:specs.task-implementation --task=TASK-037
After execution, update state:
python3 ralph_loop.py --action=loop --spec=docs/specs/001-feature/review)The script shows:
→ Review: TASK-037 | Retry: 0/3
Execute:
/developer-kit-specs:specs.task-review --task=TASK-037
Review the generated review report, then update state:
python3 ralph_loop.py --action=loop --spec=docs/specs/001-feature/fix) - If Review FailedIf issues found, script shows fix instructions. After fixes, user runs loop again.
cleanup)The script shows:
→ Cleanup: TASK-037
Execute:
/developer-kit-specs:specs.task-implementation --task=TASK-037 --action=cleanupsync)The script shows:
→ Sync: TASK-037
Execute:
/developer-kit-specs:specs.sync docs/specs/001-feature/ --after-task=TASK-037update_done)The script:
fix_plan.json--no-commit)choose_taskbashpython3 ralph_loop.py --action=start --spec=... --agent=codex
Specify agent in task file YAML frontmatter:
yaml--- id: TASK-036 title: Refactor user service status: pending lang: java agent: codex ---
Supported agents: claude, codex, copilot, kimi, gemini, glm4, minimax
For automatic scheduling every 5 minutes:
bash/loop 5m python3 plugins/developer-kit-specs/skills/ralph-loop/scripts/ralph_loop.py \ --action=loop \ --spec=docs/specs/001-feature/
This will repeatedly run the loop, showing you the next command each time.
Note: The Ralph Loop is now managed directly through the Python script. The deprecated /developer-kit-specs:specs.ralph-loop command has been removed.
Each task should be a separate file: tasks/TASK-XXX.md
markdown--- id: TASK-036 title: Implement user authentication status: pending lang: java dependencies: [] complexity: medium agent: claude --- ## Description Implement JWT-based authentication for the API. ## Acceptance Criteria - [ ] Login endpoint returns JWT token - [ ] Token validation middleware - [ ] Refresh token mechanism
bash# Initialize python3 ralph_loop.py --action=start \ --spec=docs/specs/001-feature/ \ --from-task=TASK-001 \ --to-task=TASK-005 # Loop until complete while true; do python3 ralph_loop.py --action=loop --spec=docs/specs/001-feature/ # Execute the shown command manually # Then continue loop done
bash# Start with specific range /loop 5m python3 plugins/developer-kit-specs/skills/ralph-loop/scripts/ralph_loop.py \ --action=loop \ --spec=docs/specs/002-tdd-command \ --from-task=TASK-001 \ --to-task=TASK-010
bash# Initialize with Claude as default python3 ralph_loop.py --action=start \ --spec=docs/specs/001-feature/ \ --agent=claude # Some tasks have "agent: codex" in their frontmatter # Those will show Codex-formatted commands
fix_plan.json, write to fix_plan.jsontask_rangestate.step values are ONLY: init, choose_task, implementation, review, fix, cleanup, sync, update_done, complete, failedRun --action=start first:
bashpython3 ralph_loop.py --action=start --spec=docs/specs/001-feature/
The script will create fix_plan.json in the correct location:
docs/specs/001-feature/_ralph_loop/fix_plan.jsonIf you see a warning about the file being in the wrong location, the script will guide you through migration:
bash# Manual migration if needed mkdir -p docs/specs/001-feature/_ralph_loop mv docs/specs/001-feature/fix_plan.json docs/specs/001-feature/_ralph_loop/fix_plan.json
The script will automatically migrate old files on first run.
Run --action=start first:
bashpython3 ralph_loop.py --action=start --spec=docs/specs/001-feature/
Ensure tasks are in tasks/TASK-XXX.md format with YAML frontmatter.
Check --agent parameter or task agent: frontmatter field.
references/state-machine.md - Complete state machine documentationreferences/multi-cli-integration.md - Multi-CLI setup guidereferences/loop-prompt-template.md - Prompt template for shell loops| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-05 | fail→pass | 6,586 | 4,227 | -36% | 1 | 1 | 0% | 1,011 | 4,549 | +350% | 0 | 0 | — |
case-01 | fail→fail | 9,640 | 8,035 | -17% | 1 | 1 | 0% | 1,884 | 4,377 | +132% | 0 | 0 | — |
case-02 | fail→fail | 3,929 | 6,416 | +63% | 1 | 1 | 0% | 336 | 4,301 | +1180% | 0 | 0 | — |
case-03 | fail→fail | 6,461 | 7,462 | +15% | 1 | 1 | 0% | 418 | 4,340 | +938% | 0 | 0 | — |
case-04 | fail→pass | 5,775 | 2,517 | -56% | 1 | 1 | 0% | 919 | 4,410 | +380% | 0 | 0 | — |
case-15 | pass→pass | 12,641 | 6,658 | -47% | 1 | 1 | 0% | 1,854 | 4,905 | +165% | 0 | 0 | — |
case-06 | pass→pass | 9,387 | 2,399 | -74% | 1 | 1 | 0% | 1,522 | 4,333 | +185% | 0 | 0 | — |
case-07 | pass→pass | 21,117 | 8,936 | -58% | 1 | 1 | 0% | 1,784 | 5,523 | +210% | 0 | 0 | — |
case-08 | fail→pass | 9,102 | 4,435 | -51% | 1 | 1 | 0% | 1,524 | 4,766 | +213% | 0 | 0 | — |
case-09 | pass→pass | 5,071 | 4,996 | -1% | 1 | 1 | 0% | 842 | 4,629 | +450% | 0 | 0 | — |
case-10 | pass→pass | 4,139 | 4,818 | +16% | 1 | 1 | 0% | 683 | 4,707 | +589% | 0 | 0 | — |
case-11 | fail→pass | 12,730 | 1,866 | -85% | 1 | 1 | 0% | 2,287 | 4,257 | +86% | 0 | 0 | — |
case-12 | pass→pass | 7,333 | 2,021 | -72% | 1 | 1 | 0% | 1,267 | 4,350 | +243% | 0 | 0 | — |
case-13 | fail→pass | 15,974 | 4,207 | -74% | 1 | 1 | 0% | 2,791 | 4,706 | +69% | 0 | 0 | — |
case-14 | fail→pass | 6,532 | 3,234 | -50% | 1 | 1 | 0% | 978 | 4,391 | +349% | 0 | 0 | — |
case-16 | fail→pass | 11,966 | 2,498 | -79% | 1 | 1 | 0% | 1,821 | 4,338 | +138% | 0 | 0 | — |
case-17 | fail→pass | 6,440 | 4,280 | -34% | 1 | 1 | 0% | 960 | 4,768 | +397% | 0 | 0 | — |
case-18 | pass→pass | 4,183 | 6,561 | +57% | 1 | 1 | 0% | 735 | 4,806 | +554% | 0 | 0 | — |
case-19 | fail→pass | 9,930 | 3,115 | -69% | 1 | 1 | 0% | 1,867 | 4,486 | +140% | 0 | 0 | — |
case-20 | pass→pass | 15,784 | 11,410 | -28% | 1 | 1 | 0% | 2,806 | 6,119 | +118% | 0 | 0 | — |
case-21 | pass→pass | 9,134 | 6,261 | -31% | 1 | 1 | 0% | 1,702 | 5,077 | +198% | 0 | 0 | — |
case-22 | pass→pass | 13,519 | 8,563 | -37% | 1 | 1 | 0% | 2,764 | 5,634 | +104% | 0 | 0 | — |
case-23 | fail→pass | 11,302 | 2,286 | -80% | 1 | 1 | 0% | 1,863 | 4,311 | +131% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 23 cases were attempted, and 21 counted toward the lift figure. The other 2 produced results that are not comparable between the two arms, so they are excluded from the headline rather than averaged into it. The headline lift of +43 percentage points is the difference between those two pass rates over the 21 comparable cases.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.