The Ralph Wiggum Technique: Let Claude Code Work Through Your Entire Task List While You Sleep

Jeffrey Way published a nearly three-hour session on AI-assisted development a few weeks ago. No hype, no slides, just him working through real problems in Claude Code for almost three hours straight.

About two-thirds of the way through, he pauses and says: "This is called the Ralph Wiggum technique, after the Simpsons character."

Then he opens a bash script, points at a loop, and says: queue up your tasks, run this, go to bed.

That was it. No plugin, no config. Just a for loop, a tasks.md file, and Claude running non-interactively through each item one by one.

I've been using a version of this on my own Laravel projects since watching it. And after digging into the official Anthropic implementation (yes, there's a proper plugin now), I want to give you the full picture: what it is, two ways to implement it, what tasks it handles well in a Laravel codebase, and where it'll burn your API budget without delivering anything useful.

What Ralph Wiggum Actually Is

The core idea is stupid simple, which is why it works.

Normal Claude Code workflow: you write a prompt, Claude does some work, you review it, you write another prompt. You're in the loop the whole time. You're the bottleneck.

Ralph Wiggum inverts that. You define a list of tasks upfront. Claude works through them autonomously. You're not in the loop at all until you come back and review the results.

The name comes from the Simpsons character: keep trying, keep iterating, don't stop just because it didn't work on the first attempt. The philosophy is that persistent iteration beats perfect first attempts. Some tasks need three passes before they converge. That's fine. The loop handles that.

There are two ways to implement this.

The Bash Script Approach (Jeffrey's Version)

This is what Jeffrey demoed. No plugin required. Just the -p flag (print mode, aka non-interactive) and a loop.

Here's the structure:

#!/bin/bash

tasks=(
  "Create a UserRepository interface and implementation following the repository pattern. Implement findByEmail, findActive, and paginate methods. Add the binding in AppServiceProvider."
  "Write feature tests for the UserRepository. Cover findByEmail with existing and non-existing emails, findActive returning only verified users, and paginate returning correct page sizes."
  "Add a Filament resource for User management. Include filters for status and verified_at. Add bulk actions for activating and deactivating users."
)

MAX_ITERATIONS=3

for task in "${tasks[@]}"; do
  echo "Starting task: $task"
  for ((i=1; i<=MAX_ITERATIONS; i++)); do
    echo "Attempt $i..."
    claude -p "$task" --dangerously-skip-permissions
    exit_code=$?
    if [ $exit_code -eq 0 ]; then
      echo "Task completed successfully."
      break
    fi
    echo "Attempt $i failed. Retrying..."
  done
done

echo "All tasks processed."

Jeffrey's refinement (suggested live in the session) was exactly this: use a for loop with a configurable MAX_ITERATIONS cap rather than a while true loop. That prevents runaway costs if a task gets stuck.

The --dangerously-skip-permissions flag lets Claude make file changes without prompting for confirmation. You'd only use this in a dev environment, never on a production server.

A cleaner version uses a tasks.md file instead of hardcoding tasks in the script:

#!/bin/bash
# Reads tasks from tasks.md - one task per line, skip lines starting with #

MAX_ITERATIONS=3

while IFS= read -r task || [[ -n "$task" ]]; do
  # Skip empty lines and comments
  [[ -z "$task" || "$task" == \#* ]] && continue

  echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
  echo "Task: $task"
  echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"

  for ((i=1; i<=MAX_ITERATIONS; i++)); do
    claude -p "$task" --dangerously-skip-permissions && break
    echo "Attempt $i failed. Retrying..."
  done

done < tasks.md

echo "Done."

Your tasks.md then looks like this:

# User management feature
Create a UserRepository interface and implementation. Methods: findByEmail, findActive, paginate. Add binding in AppServiceProvider.
Write feature tests for UserRepository covering all three methods with edge cases.
Add a Filament resource for User management with status filters and bulk activate/deactivate actions.

# Subscription feature
Add a subscriptions table migration with billable_type, billable_id, plan, status, and trial_ends_at columns. Create and run it.
Create an IsSubscribed middleware that checks subscription status and redirects with a flash message if inactive.

One task per line. Comments with # for grouping. Run the script before bed. Come back to commits.

The Official Plugin (The Production Version)

The bash loop is great for getting started. But Anthropic shipped an official plugin that handles this more robustly.

/plugin marketplace add anthropics/claude-code
/plugin install ralph-wiggum@claude-plugins-official

The difference is in the mechanism. Instead of an external bash loop, the plugin uses a Stop hook that intercepts Claude's exit attempts from inside the session itself. When Claude tries to finish, the hook blocks it and re-feeds the original prompt, along with a completion promise to check against.

/ralph-loop "Your task here" --completion-promise "COMPLETE" --max-iterations 20

Claude works on the task, and when it genuinely believes it's done, it outputs the completion promise. The hook checks for it. If it's there, the loop exits cleanly. If not, it tries again.

The --max-iterations flag is non-negotiable. Always set it. The --completion-promise flag uses exact string matching, so it's not bulletproof. Treat --max-iterations as your real safety net.

For a batch of tasks, you'd still use an external script, but the underlying mechanism is more robust because it happens inside the Claude session, with context from previous attempts carried forward.

Which approach should you use? The bash loop is simpler and requires no plugin. The official plugin is better for single complex tasks where Claude needs to see its previous attempts to improve. For a list of independent tasks (the overnight backlog scenario), the bash loop is honestly fine.

What Tasks Actually Work for Laravel Projects

This is where most guides fall short. They give you the mechanism and leave you to figure out what to put in tasks.md. Here's what I've found works well in a Laravel context, and what doesn't.

Tasks that work well:

Repetitive but non-trivial code generation. Writing repositories, form requests, DTOs, resource classes. Claude handles these reliably when you give it the interface to implement against. "Create a PostRepository implementing PostRepositoryInterface. The interface is in app/Contracts/PostRepositoryInterface.php. Use Eloquent. Inject the Model via the constructor. Don't add any methods not in the interface."

Migration and model scaffolding. "Add a soft-deleted archived_at column to the posts table. Create and run the migration. Update the Post model to use SoftDeletes and add an archived scope." Give it the exact column names and types. Vague migrations cause problems.

Feature test coverage for existing code. This is probably the highest-value use case. "Write feature tests for PostController. Cover index (paginated, authenticated), store (validation errors, successful creation), and destroy (own post vs another user's post). Use RefreshDatabase." Claude reads the controller and writes reasonable tests consistently.

Artisan command creation. Routine commands that process records, generate reports, or clean up old data are a natural fit. The pattern is predictable. Claude knows it well.

Filament resource scaffolding. If you're using Filament, resource creation is a great loop task, especially when you specify the exact columns, filters, and actions upfront. The more specific the prompt, the more consistently it converges.

Tasks that don't work well:

Anything requiring judgment about architecture. "Refactor the billing system to be more maintainable" will produce something, but it might not be something you want. These need your eyes at every step.

Tasks with unclear completion criteria. "Improve error handling" loops forever or exits too early. "Add a try/catch block around the Stripe charge call in BillingService::charge() that catches Stripe\Exception\CardException and logs it to the billing_errors channel" works fine.

Database-touching tasks in production. Obviously. Always point this at a dev environment with a disposable database.

Multi-file refactors that depend on each other. If task 3 depends on what task 2 produced, and task 2 failed silently, task 3 will produce broken code. The loop has no concept of dependencies between tasks. Structure your list so each task is self-contained, or verify after each one before moving on.

Writing Prompts That Actually Converge

The technique lives and dies by prompt quality. You're the architect. Claude is the hands. That's the deal.

A few patterns that help:

Give Claude a way to verify its own work. "Run php artisan test --filter=PostRepositoryTest when done. If any tests fail, fix them before finishing." Without verification, Claude has no signal for when it's actually done.

Reference existing code explicitly. "Follow the same pattern as UserRepository in app/Repositories/UserRepository.php." Claude reads files. Use that. It won't guess at your conventions if you point it at a concrete example.

Define done clearly. "This task is complete when: (1) the migration file exists and passes php artisan migrate --dry-run, (2) the Post model has the archived scope, (3) existing tests still pass." Ambiguous completion criteria are the number one cause of loops that run to MAX_ITERATIONS without producing anything useful.

Keep tasks small. One conceptually complete thing per task. Not "build the subscription feature." That's a week of work. "Add the subscriptions table migration" is one task. "Create the Subscription model with billable morph, plan enum, and trial date casting" is the next one.

This pairs naturally with a solid CLAUDE.md context file that describes your project structure, conventions, and test setup. Once that exists, every task prompt gets shorter because you're not re-explaining the context each time. The skills directory post has a good walkthrough of setting that up.

Honest Trade-offs

Ralph Wiggum is not magic. Here's what you're actually signing up for.

Cost. A 50-iteration loop on a medium-sized codebase can run $50-100+ in API credits. On a Claude Max subscription, you'll hit rate limits faster than you expect. Set MAX_ITERATIONS conservatively. Start with 3-5 for routine code generation, and only go higher for complex tasks you've already verified converge reliably.

Review is not optional. You still need to read every file Claude touched. The loop automates execution, not judgment. I'd never merge a Ralph Wiggum run without reviewing the diff. Think of it as getting a pull request from a very fast junior dev: the code might be great, but you're not deploying it without reading it.

Context window limits. When Claude's context fills up mid-task, quality degrades. The official plugin handles this better than the bash loop because it can use Claude's native context management. If you're using the bash script, keep individual tasks short enough to complete in one context window.

It fails quietly sometimes. The bash script moves to the next task even if the previous one produced broken code. If you're running an overnight batch, add a git commit after each successful task so you can bisect failures in the morning:

claude -p "$task" --dangerously-skip-permissions && \
  git add -A && \
  git commit -m "ralph: ${task:0:60}"

That way each task is its own commit. If something went wrong, you know exactly where.

Where This Fits in Your Workflow

I don't use this for exploratory work. When I'm figuring out an architecture, debugging a subtle issue, or making tradeoff decisions, I'm in an interactive Claude Code session the whole time. That's what git worktrees are great for: running multiple interactive sessions in parallel when you need focus.

Ralph Wiggum is for the backlog. The list of things you know need to be done, where the how is obvious, and the only bottleneck is actually sitting down to do them. Feature tests for existing controllers. Artisan commands for routine data processing. Form request classes for every endpoint that's still doing manual validation. Filament resources for models that don't have admin UI yet.

If you're building something with the Laravel AI SDK or any other feature that generates repetitive-but-predictable code, this is where the technique pays for itself.

Set up the tasks.md, run it before you go to bed, review the diff in the morning. That's the whole workflow.

FAQ

Do I need a specific Claude Code version?

The -p flag has been stable for a while. The official plugin (ralph-wiggum@claude-plugins-official) requires a recent version. Run claude update if you're not sure, then claude doctor to verify your setup.

Is --dangerously-skip-permissions safe to use?

In an isolated dev environment with no production data, yes. It means Claude won't prompt you for confirmation before modifying files or running commands. Never use it on a server with real data, and never run the script from a directory you wouldn't want Claude touching freely.

What if a task fails after all iterations?

With the bash script: the script moves on and the task simply doesn't get done. With the official plugin: the loop exits when --max-iterations is hit. Either way, check the output. For the bash approach, log failures explicitly so you know what needs manual attention.

Can I run this on a remote server?

Yes, with caveats. You'd need Claude Code installed on the server with an authenticated session. The more practical setup is running it locally against a dev database. For remote execution, the --output-format json flag lets you pipe results into something that logs them properly.

What's the difference between Ralph Wiggum and Claude's native task management?

Claude Code now has a native task system (Ctrl+T in a session) that persists tasks across context compaction. That's useful for tasks you're actively working on interactively. Ralph Wiggum is for autonomous execution without you in the loop at all. They solve different problems.

Wrapping Up

The Ralph Wiggum technique is one of those workflow changes that sounds gimmicky until you try it. Queue up ten feature tests you've been putting off, run the script, come back to commits. It's not always perfect. You'll review the diff, fix a few things, move on. But the bottleneck shifted from "do I have time to write these tests" to "do I have time to review what Claude wrote."

For most of that backlog, the answer is yes.

If you want to talk through how this fits into your specific Laravel project, or you're looking for help architecting a system where this kind of automation actually pays off, you can reach out via the contact page.