How I Got Ralph to Ship Overnight

I woke up to five pull requests this morning. Passing tests, clean commits, generated PR descriptions.

I didn’t write a single line of code (but I did review).

This is what product management looks like now. I describe the problem. We shape it into a PRD. Then the agent translates that into structured issues, sequences the work, and starts building.

My job is less “writing specs” and more thinking clearly, making good calls, and steering the system while it moves.

I’ve been building my own take on the Ralph Wiggum Loop: a system of Claude Code skills that plans, structures, and executes features mostly autonomously.

What’s a Ralph Loop?

Named after Ralph Wiggum from The Simpsons, the concept has been gaining a ton of traction among developers building with AI. The idea is to run an agent in a loop until done.

And instead of hoping the agent gets it right in one shot, you let it keep trying until it succeeds.

Matt Pocock’s video is a great introduction.

Claude Code has an official Ralph Wiggum plugin, but I wanted something I could experiment with. My implementation adds structure: PRDs that define the work, JSON that sequences it, and skills that tie it together.

The pipeline

I have three skills I work through:

/create-prd starts a conversation. I describe what I want, the agent asks clarifying questions with lettered options. “Who’s the primary user? A) Logged-in users, B) All visitors, C) Admins.” I answer “1A, 2B, 3C” and move fast.

Once it understands the scope, it generates a PRD with user stories and acceptance criteria in a (currently) JSON format, like this:

"userStories": [
    {
      "id": "US-001",
      "title": "Create migration to drop todos table",
      "description": "As a developer, I need a database migration that drops the todos table and its associated indexes and RLS policies",
      "acceptanceCriteria": [
        "Migration file created at supabase/migrations/xxx_drop_todos_table.sql",
        "Migration drops todos table",
        "Migration drops todos_user_id_idx index",
        "Migration drops todos_status_idx index",
        "Migration drops RLS policies on todos table",
        "Typecheck passes",
        "Lint passes"
      ],
      "priority": 1,
      "passes": true,
      "notes": ""
    }
]

I see this as the upstream of Claude Code’s plan mode. Plan mode is tactical: Claude figures out how to implement something, then does it in one session. /create-prd is requirements shaping, focused on what should be built.

/create-prd-json converts that document into something executable. It breaks the PRD into stories sized for one context window each. “Build entire auth system” becomes “Add login form”, “Add email validation”, “Add auth server action.” Sequenced, dependencies resolved, etc.

/ralph runs the loop. It picks the next available project without incomplete dependencies, creates a git worktree, and iterates: read the PRD, pick the highest-priority incomplete story, implement it, run typecheck and lint, commit, update the JSON story as a record of action. Repeat until done.

Story sizing

This constraint makes the loop more effective. Each story has to fit in one iteration. If Ralph can’t finish it, update the JSON, and commit before context runs out, the story is too big.

Right-sized:

• Add a database column
• Create a single UI component
• Add one API endpoint
• Update a server action

Too large:

• “Build entire auth system”
• “Implement the dashboard”
• “Add real-time sync”

The /create-prd-json skill enforces this. It won’t accept vague criteria like “works correctly.” Every story needs “Typecheck passes” and “Lint passes.” UI stories need “Verify at localhost:3000/path.”

Dependencies

Very quickly I ran into dependency trees, where features depend on other features, so I baked in a way to inform the agent of another PRD that needs to be completed first:

{
  "projectName": "Evening Ritual",
  "dependsOn": ["elevenlabs-integration", "morning-brief"]
}

Ralph won’t start “Evening Ritual” until both dependencies are complete. This way I can queue up a bunch of PRDs and move on to planning the next features.

The completion signal

When all stories have passes: true, it outputs a marker informing the agent to stop:

<promise>COMPLETE</promise>

Ralph pushes the branch, creates a PR, and moves to the next PRD in the dependency graph. If nothing’s ready, it exits and I wake up to pull requests.

Why worktrees

Git worktrees let Ralph work in isolation. The main repo stays clean. If something goes wrong, delete a directory and try again. Multiple Ralphs can run in parallel: different features, different worktrees, different terminals.

The part I haven’t figured out is the branching strategy. Each worktree branches from main, so merge conflicts accumulate when running features in parallel. You deal with them at merge time, manually or by asking Claude to help rebase.

Should dependent PRDs branch from their dependencies instead? A nightly rebase step? I’d love to hear how others handle this. The parallel execution works, but the merge story feels unfinished.

Why not GitHub Issues or Linear?

I started with local JSON because I wanted the system transparent and self-contained. Just files in a prds/ directory I can edit, version, and inspect. I can see what Ralph thinks it’s doing and adjust if needed.

For solo work, this is perfect. For teams, it won’t scale. The next step is GitHub Issues: same workflow, but stories live as issues and progress shows up where the team already looks.

Credit and caveats

The Ralph Loop has been shaped by many people: Geoffrey Huntley, Ryan Carson, Matt Pocock, Jeffrey Way. I’ve learned a lot watching how others approach this.

What I’ve shared is my extrapolation of how these techniques might work for me. The space is evolving fast, and some of this may be overcomplex or oversimplified.

That’s the point of experimenting in public: you learn faster when you share what you’re trying.

The skills are open source: github.com/richtabor/agent-skills