Claude Code Deep Interview + Ralph Loop: From a Single Idea to an Automatic PR

"I woke up the next morning and the PR was already up."

Honestly, when I first saw that review, I thought it was marketing copy. The idea of AI writing code for you is nothing new. But starting in mid-2025, experiences following the same pattern began piling up across communities. A tool appeared that crossed 12,000 GitHub stars in just two months, and enterprise blogs started publishing analysis pieces. At the center of it all is the combination of Ralph Loop and Deep Interview.

Each tool on its own is useful enough, but put them together and something different happens. Starting from a vague idea, the AI autonomously organizes requirements → writes code → runs tests → and fixes failures when they occur — the entire cycle runs on its own. This article takes a close look at how these two concepts fit together, where I got stuck when trying them myself, and what you need to keep in mind to safely run your first loop.

Core Concepts

Ralph Loop: "The AI Loop That Never Gives Up"

The structure of snarktank/ralph, published by Geoffrey Huntley in May 2025, is surprisingly simple. It's a bash script that takes a PRD (Product Requirements Document) file as input and repeatedly calls an AI coding tool until every item is complete. The 12,000+ stars in two months aren't because of technical complexity — they're because of its philosophy.

Naive persistence: Instead of crafting a perfect plan, pass errors and failures as input to the next iteration and simply repeat until the success criteria are met. "Tireless repetition" is the core design principle.

The core loop, simplified, looks like this:

#!/bin/bash
# ralph.sh core loop (simplified version)
# Install the claude command with: npm install -g @anthropic-ai/claude-code
 
PRD_FILE=$1
TOOL=${TOOL:-claude}
 
while true; do
  # Extract incomplete checkboxes (- [ ] pattern)
  NEXT_TASK=$(grep -n '- \[ \]' "$PRD_FILE" | head -1)
 
  [ -z "$NEXT_TASK" ] && echo "All items complete. Exiting loop." && break
 
  # Delegate task to AI with a fresh context
  $TOOL "prd: $PRD_FILE, task: $NEXT_TASK, run tests and commit if passed"
 
  echo "$(date): $NEXT_TASK attempted" >> progress.txt
done

The key is that each iteration starts with a fresh context. As the context window grows longer, LLMs tend to ignore early instructions and simply continue from recent output — starting with a fresh context every time structurally prevents this problem. Instead, state is carried across iterations via git history and progress.txt.

Deep Interview: "The Socrates of PRD Extraction"

No matter how powerful the Ralph Loop is, if the input PRD is sloppy, the entire loop falls apart. The real bottleneck is "creating a good PRD," and the /deep-interview skill from the obra/superpowers plugin targets exactly that bottleneck.

# Run in the Claude Code terminal
/deep-interview I want to build a todo management app

When you run it, the AI asks one question at a time. A real conversation flows something like this:

AI: Who will primarily use this app? Is it for personal use or shared by a team?
Me: Personal use.
 
AI: How should completed todos be handled? Should they be deleted,
    or kept separately in a completed list?
Me: I'd like them to stay in a completed list.
 
AI: Does it need to work offline?
Me: Yes, it needs to work without internet.

At first you think "do we really need these questions?", but by the end of the interview, a good number of edge cases and acceptance criteria you'd missed on your own come to light. In my first interview, I realized on the third question that I hadn't even thought about "handling offline sync conflicts."

Acceptance Criteria: Explicitly stated completion criteria that can be mechanically judged as pass/fail — for example, "When a user adds a todo, it is immediately reflected in the list." Getting these right in the Deep Interview is what makes the Ralph Loop's exit condition clear.

The output is saved as a file like tasks/prd-todo-app.md. You can also attach existing notes or conversation history so Claude skips redundant questions and only asks about the gaps — a progressive refinement mode that fits perfectly when "the spec exists but has holes."

Combining the Two: Full-Cycle Automation Flow

Core summary: The PRD is the input; acceptance criteria are the exit condition. Deep Interview determines the quality of the input, and that quality determines the outcome of the entire loop.

User Idea
    ↓
[Deep Interview]  ← /deep-interview skill
    ↓
prd.md generated   ← Structured tasks + acceptance criteria
    ↓
[Ralph Loop]      ← ./ralph.sh runs
    ↓
Iteration loop    ← Implement → Test → Fail → Retry
    ↓
All checkboxes done ← Git commits accumulate
    ↓
Finished codebase

Practical Application

[Basic] Example 1: Auto-implementing a Todo App from Scratch

The basic pattern: generate a PRD with Deep Interview, then immediately run the Ralph Loop.

# Step 1: Install the Superpowers plugin
git clone https://github.com/obra/superpowers ~/.claude/superpowers
 
# Step 2: Run Deep Interview inside Claude Code
# (inside the Claude Code terminal)
/deep-interview I want to build a todo management app
# → AI interactively asks about requirements
# → tasks/prd-todo-app.md is auto-generated
 
# Step 3: Autonomous implementation with Ralph Loop
git clone https://github.com/snarktank/ralph ~/ralph
cd my-project
~/ralph/ralph.sh --tool claude --prd tasks/prd-todo-app.md

The PRD file structure that Deep Interview produces looks roughly like this:

# PRD: Todo Management App
 
## Task List
 
### TASK-001: Add Todo Feature
- **Description**: Users can add a new todo by entering text
- **Acceptance Criteria**:
  - [ ] Empty string input does not create a todo
  - [ ] Input field resets after adding
  - [ ] Added item appears at the top of the list
- **Test**: `pnpm test -- todo-add`
 
### TASK-002: Complete Todo Feature
- **Description**: Toggle completion state by clicking the checkbox
- **Acceptance Criteria**:
  - [ ] Completed items are displayed with strikethrough
  - [ ] Completion state persists after page refresh
- **Test**: `pnpm test -- todo-complete`

ralph.sh tracks incomplete items with the - [ ] pattern, and when a test command passes, it updates that checkbox to - [x].

[Overnight Operation] Example 2: Start Before Leaving Work, Check Results in the Morning

The most dramatic usage pattern in practice. When running for the first time, it's recommended to try a short daytime run with --max-iterations 5 first. Running overnight without guardrails means API costs can quietly accumulate on tasks where the loop doesn't converge. I made this mistake myself early on.

#!/bin/bash
# overnight-ralph.sh: Unattended overnight development script
 
# Recommended to manage API keys in a .env file (never hardcode them)
source .env
 
LOG_FILE="ralph-$(date +%Y%m%d).log"
 
echo "=== Ralph Loop started: $(date) ===" >> "$LOG_FILE"
 
# super-ralph: A Ralph extension with enhanced guardrails (htlkg/super-ralph)
./super-ralph/ralph.sh \
  --tool claude \
  --prd tasks/current-sprint.md \
  --max-iterations 50 \
  --timeout-minutes 480 \
  --on-error "commit-and-continue" \
  2>&1 | tee -a "$LOG_FILE"
 
echo "=== Ralph Loop finished: $(date) ===" >> "$LOG_FILE"
 
# Completion notification (Slack webhook, etc.)
curl -X POST "$SLACK_WEBHOOK" \
  -d "{\"text\": \"Ralph Loop complete. Results: \`git log --oneline -10\`\"}"

htlkg/super-ralph is an extension of base ralph that adds safety measures like --max-iterations and --timeout-minutes. It's much safer to use this for overnight runs.

[Advanced] Example 3: Porting an Existing Codebase to Another Language

An extended pattern Geoffrey Huntley introduced through the LinearB blog and others. Compress an existing codebase into a language-neutral Markdown spec, then port it to another language with the Ralph Loop.

# Step 1: Convert existing Python codebase into a spec document
claude "Convert all behavior in this Python project into a language-neutral Markdown spec.
       Include each function's inputs/outputs, side effects, and edge cases.
       Output: spec/codebase-spec.md"
 
# Step 2: Generate a TypeScript porting PRD based on the spec
claude "Based on spec/codebase-spec.md, generate a TypeScript implementation PRD.
       Break each module into an independent task and specify tests in the acceptance criteria.
       Output: tasks/typescript-port.md"
 
# Step 3: Autonomous porting with Ralph Loop
~/ralph/ralph.sh --tool claude --prd tasks/typescript-port.md

Pros and Cons

Here's an honest summary:

Pros

Cons and Caveats

AI Slop: Code that passes tests but does not actually solve the requirements. For example, achieving a "passing" state by deleting a failing test. The more specific the acceptance criteria, the harder it is to circumvent them this way.

The Most Common Mistakes in Practice

1. Making tasks too large. If a single task exceeds the size that can be completed within one context window, the loop won't converge. It's safer to break things down small — "Implement JWT token issuance endpoint" rather than "Implement authentication system."

2. Handing off a PRD without acceptance criteria. If you only have "build a login feature" without "return 401 on incorrect password input," the loop has no idea when to stop. In the Deep Interview stage, always ask yourself "can this be verified with a test?"

3. Running overnight without guardrails. Running without --max-iterations lets API costs silently accumulate on tasks that don't converge. It's a good idea to run a few short daytime sessions first to confirm the loop converges as expected.

Closing Thoughts

In the end, what this workflow taught me is this: The concrete PRD drawn out by Deep Interview determines the quality of the Ralph Loop, and that quality comes from the clarity of the acceptance criteria. More than the tools themselves, "the ability to express requirements as testable conditions" is the real core of this workflow.

If you want to try it yourself, here's where to start:

1. Install Superpowers and run /deep-interview once. Install it with git clone https://github.com/obra/superpowers ~/.claude/superpowers, then start an interview with a project idea you've been carrying around in your head. See how many items appear in the resulting prd.md that you hadn't thought of beforehand.

2. Write a PRD yourself and practice sizing tasks. Break things down to units completable within 30 minutes each, and attach a runnable test command to each item — going through that process will give you a feel for how specific acceptance criteria need to be.

3. Run ~/ralph/ralph.sh with --max-iterations 5 for a short daytime test first. Run only the first few tasks to confirm the loop converges as expected and that results are accumulating in progress.txt and git log, before moving on to overnight runs.

References

• GitHub - snarktank/ralph: Core Ralph Loop implementation
• 2026 - The year of the Ralph Loop Agent | DEV Community
• Mastering Ralph loops transforms software engineering | LinearB Blog
• From ReAct to Ralph Loop | Alibaba Cloud Blog
• GitHub - obra/superpowers: Skills framework
• GitHub - oh-my-claudecode (OMC)
• GitHub - htlkg/super-ralph: Ralph extension with enhanced guardrails
• Spec-Driven Development with Claude Code | DataCamp
• Claude Code Superpowers Complete Guide | Frank's IT Blog