Claude Code Let's Build: The Ralph Loop Easy Setup Testing

TL;DR

Create a PRD JSON checklist where each task has a passes flag and optional dependency/priority ordering.

Briefing Cornell Notes

Briefing

A practical “Ralph loop” setup is shown as a hands-off way to build software feature-by-feature with Claude Code: each task runs in a fresh instance, wipes prior context, and uses a PRD-style JSON checklist to decide what to do next. The payoff is simple—complex projects can be assembled through repeated, single-feature iterations with automated testing and type checks, while progress is tracked in a log and the loop stops only when every task is marked complete. The approach matters because it turns LLM-driven coding from a one-shot prompt into a controlled workflow that can reliably advance through dependencies and avoid carrying over messy context between steps.

The workflow starts with a PRD file written as JSON, functioning like a to-do list. Each task includes a “passes” flag and a progress record; when a task is completed, its passes value flips to true. On every loop iteration, Claude Code is launched to work on exactly one feature: it selects the highest-priority task whose passes flag is still false, taking dependencies and logical ordering into account rather than simply picking the first item. After implementing the feature, it runs available tests and type checks, then updates the PRD JSON to mark the task as passed, appends an entry to a progress text log, and commits changes. Once all tasks are marked complete, the system outputs “Ralph complete” and halts.

A key operational detail is that Claude Code runs with “dangerously” broad script permissions, paired with a “skip permissions” mode—explicitly flagged as risky and requiring user caution. The loop also “resets” by wiping context between tasks, meaning the model does not inherit conversational memory from one task to the next. Instead, the PRD file acts as the durable memory: it contains the task list, completion state, and enough project structure for the next iteration to pick up where the checklist left off.

Two concrete projects demonstrate the setup. First, a 3JS VR “cinema room” lets users walk inside a curved 180-degree spherical screen and play a video mapped onto that surface. The PRD is expanded into 22 tasks generated via Cloud Code planning mode, then executed through an autonomous Ralph loop with up to 25 iterations (allowing retries). After an interruption caused by lost Wi‑Fi, the loop resumes and still completes all tasks because the PRD state has already been updated.

Second, a music “slot machine” game is built using the Suno API. The PRD is planned into 20 tasks, then run autonomously for about 25 minutes. The finished app presents four reels with genre/instrument/tag labels; each spin generates a random prompt and sends it to Suno to return a new song. Testing shows the song generation pipeline working end-to-end, with only minor UI issues noted (e.g., reel text orientation). Overall, the projects are presented as evidence that the Ralph loop can deliver working interactive demos with minimal manual intervention—at the cost of managing the security risk tied to elevated script permissions.

Cornell Notes

The Ralph loop workflow uses a PRD JSON checklist to drive Claude Code through software tasks one at a time. Each iteration launches a fresh Claude Code instance, wipes prior context, selects the highest-priority task whose “passes” flag is still false (respecting dependencies), implements that single feature, runs tests and type checks, then updates the PRD and a progress log before committing. When all tasks are marked complete, the loop stops. The durable “memory” is the PRD file itself, not accumulated chat context. The method is demonstrated by building a 3JS VR 180-degree cinema room (22 tasks) and a Suno-powered music slot machine game (20 tasks), both executed largely autonomously with only small follow-up fixes.

How does the Ralph loop decide what to build next, and how does it avoid repeating completed work?

Tasks live in a PRD JSON file with a boolean “passes” field. On each iteration, Claude Code searches the PRD for the highest-priority task where passes is false. After implementing the feature and verifying it with available tests and type checks, it updates that task’s passes value to true and commits changes. Because completed tasks are now marked true, later iterations skip them and move on to the next eligible task.

What does “wipe the context” mean in practice, and what replaces that lost context?

Each iteration resets by closing the Claude Code instance and starting fresh, so prior conversational context is not carried into the next task. Instead, the PRD file provides the persistent state: it contains the task list, completion flags, and enough project structure for the next iteration to continue. Logging/progress text further helps track where the project stands.

Why are “dangerously” script permissions and “skip permissions” mode mentioned, and what risk does it imply?

The loop runs Claude Code with “dangerously” script permissions and uses a “skip permissions” mode, meaning approvals are not enforced for every action. That can be risky because it may allow operations that would normally require explicit user consent. The transcript advises treating this as “on your own risk,” implying security and safety concerns if the code or scripts behave unexpectedly.

How were the two demo projects structured to fit the loop’s “one feature per iteration” rule?

Both projects were broken into many PRD tasks generated through planning mode. The VR cinema room expanded into 22 tasks, while the music slot machine expanded into 20 tasks. Each iteration then targets one task—such as setting up the VR scene, adding the curved 180-degree video screen, building the menu/start flow, or wiring the slot reels to random prompts and Suno API calls—followed by tests/type checks and PRD updates.

What verification steps were used after implementing each task?

After a single feature is implemented, the workflow runs available tests and type checks to verify the work. Only then does it update the PRD JSON passes flag and append to the progress log before committing changes.

Review Questions

In the Ralph loop, what specific fields in the PRD JSON control task selection and skipping?
How does the workflow maintain continuity across iterations if conversational context is wiped each time?
What security trade-off is introduced by using “dangerously” script permissions with “skip permissions” mode, and how might that affect how you run the loop?

Key Points

1
Create a PRD JSON checklist where each task has a passes flag and optional dependency/priority ordering.
2
Run Claude Code in a loop that launches a fresh instance per iteration and wipes prior context between tasks.
3
Select the next task by choosing the highest-priority PRD item with passes=false, not the first item blindly.
4
After implementing one feature, run available tests and type checks, then update the PRD passes flag and commit changes.
5
Append progress to a progress text log so the project’s state is auditable and resumable.
6
Stop the loop only when every PRD task is marked complete, producing a clear “Ralph complete” end state.
7
Use elevated script permissions only with caution, since “skip permissions” mode reduces approval safeguards.

Highlights

The PRD JSON file acts as the loop’s durable memory: context is wiped each iteration, but task state persists via passes flags.

Task selection is dependency-aware and priority-based—each iteration targets exactly one unfinished feature.

The VR cinema room demo reached a working 180-degree spherical video screen after autonomous execution of 22 PRD tasks.

The Suno-powered slot machine works end-to-end: random reel prompts are sent to the Suno API and returned audio is playable in the app.

Topics

Ralph Loop Setup
Claude Code Automation
PRD JSON Task Planning
3JS VR Cinema Room
Suno Music Slot Machine