skills/dazuck/operator-skills/ralph-loop-creator

ralph-loop-creator

SKILL.md

Ralph Loop Creator

Core Purpose

Transform a rough idea, description, or PRD into a fully structured Ralph Loop prompt ready for execution. This automates the tedious work of structuring phases, validation criteria, and completion promises.

Based on @GeoffreyHuntley's Ralph Wiggum technique, @callam53's workflow guide.

Operating Philosophy

What This Skill IS

  • Prompt scaffolder that creates structured Ralph-ready prompts
  • Phase decomposer that breaks work into iterative chunks
  • Validation designer that ensures each phase has clear success criteria
  • Kanban translator that treats phases like tickets with ACs
  • Quality gate that runs blind review before declaring ready

What This Skill IS NOT

  • Interviewer (use /interview first if requirements are vague)
  • Ralph runner (use /ralph-loop to actually run it)

When to Use This Skill

Use AFTER you have clarity on what to build:

Rough idea → /interview → /ralph-loop-creator → /ralph-loop
                  ↑              ↑
            (if spec has    (THIS SKILL)
             ambiguities)     │
                              ├── Generate PROMPT.md
                              ├── Blind Review (subagent)
                              ├── Fix issues if confidence < 7
                              └── Output ready-to-run command

Activation Protocol

When invoked with /ralph-loop-creator <input> [output-path]:

  1. Parse input:

    • If file path: read the file (PRD, notes, rough plan)
    • If description: use the provided text
  2. Assess completeness:

    • Are requirements clear enough to structure?
    • If not: suggest /interview first
  3. Gather context:

    • Read relevant CLAUDE.md for project patterns
    • Check for existing architecture/infrastructure to reference
    • Identify dependencies and constraints
  4. Generate PROMPT.md:

    • Mission statement + completion promise
    • Context section (what exists, architecture)
    • Scope (in/out)
    • Phases with tasks and validation
    • File structure
    • Environment variables
    • Decision log
    • Success metrics
  5. Blind Review (critical step):

    • Spawn a subagent with ZERO context about the task
    • Have them review the PROMPT.md as if coming in cold
    • They report back:
      • What they expect to happen (validates clarity)
      • Implicit intent they're inferring (surfaces assumptions)
      • Pre-mortem: what could go wrong (finds gaps)
      • Confidence score 1-10 for autonomous execution
    • If confidence < 7: iterate on PROMPT.md to address issues
    • See "Blind Review Protocol" section below
  6. Output:

    • Write to specified path (or suggest default)
    • Include confidence score from blind review
    • Provide the exact /ralph-loop command to run

PROMPT.md Template

Generate prompts following this structure:

# [Feature Name] - Ralph Loop Prompt

## Mission

[1-2 sentence description of what we're building]

**Completion Promise:** When all phases complete and [success criteria], output:

\`\`\`
<promise>[FEATURE_NAME] COMPLETE</promise>
\`\`\`

---

## Context

### What Already Exists

[Relevant existing infrastructure, patterns, files]

| Component | Location | Purpose        |
| --------- | -------- | -------------- |
| [Name]    | [Path]   | [What it does] |

### Architecture Overview

\`\`\`
[ASCII diagram if helpful]
\`\`\`

---

## Scope

### In Scope

- [ ] [Feature/requirement 1]
- [ ] [Feature/requirement 2]

### Out of Scope (Future)

- [Thing explicitly deferred]

---

## Phases

Work through these sequentially. Each phase should result in working, tested code.

### Phase 1: [Foundation/Setup]

**Goal:** [What this phase achieves]

**Tasks:**

1. [Specific task]
2. [Specific task]

**Validation:**

- [ ] [Testable criterion]
- [ ] [Testable criterion]

**Reference:** [Docs/links if relevant]

---

### Phase 2: [Core Feature]

[Same structure]

---

### Phase N: Testing & Documentation

**Goal:** Production-ready with tests and docs.

**Tasks:**

1. Unit tests for [components]
2. Integration tests for [flows]
3. Documentation at [location]

**Validation:**

- [ ] Tests passing
- [ ] Coverage > [X]%
- [ ] Docs complete

---

## Key Files to Create

\`\`\`
[File tree of expected output]
\`\`\`

---

## Environment Variables

\`\`\`bash
[Required env vars with descriptions]
\`\`\`

---

## Decision Log

| Decision | Choice   | Rationale |
| -------- | -------- | --------- |
| [What]   | [Choice] | [Why]     |

---

## Success Metrics

**Functional:**

- [Measurable criterion]

**Quality:**

- [Quality gate]

---

## Notes for Implementation

- [Important gotcha]
- [Pattern to follow]
- [Thing to avoid]

---

## When Complete

Output the completion promise:

\`\`\`
<promise>[FEATURE_NAME] COMPLETE</promise>
\`\`\`

Phase Design Principles

Good Phases

  • Self-contained: Can be validated independently
  • Incremental: Build on previous phases
  • Testable: Clear pass/fail criteria
  • Sized right: Not too big (overwhelming) or small (trivial)

Phase Sequencing

Typical flow:

  1. Foundation - Setup, dependencies, scaffolding
  2. Core - Main functionality (may be multiple phases)
  3. Integration - Wire components together
  4. Polish - Error handling, edge cases
  5. Testing & Docs - Always last

Validation Criteria

Each phase needs checkboxes that are:

  • Binary - Pass or fail, not subjective
  • Testable - Can run a command or check to verify
  • Specific - "Tests pass" not "code works"
Good:
- [ ] `npm test` passes with 0 failures
- [ ] Bot joins test meeting within 10 seconds
- [ ] Response latency < 2s measured in logs

Bad:
- [ ] Code is clean
- [ ] Feature works well
- [ ] Good performance

Iteration Estimation

Suggest max iterations based on complexity:

Phases Complexity Suggested Iterations
2-3 Simple 15-20
4-5 Medium 30-40
6-8 Complex 50-75
8+ Large 100+ (consider splitting)

Output Format

After generating PROMPT.md and running blind review, provide:

## Ralph Loop Ready

Created: `[path/to/PROMPT.md]`

### Blind Review Results

**Confidence:** [X]/10
**Key findings:** [1-2 sentence summary of what reviewer caught]
**Changes made:** [What you fixed based on review, or "None needed"]

### To Run

\`\`\`
/ralph-loop [path/to/PROMPT.md] --max-iterations [N] --completion-promise "[PROMISE]"
\`\`\`

**Estimated phases:** [N]
**Suggested iterations:** [N]
**Completion promise:** [PROMISE]

Callam's Tips (Embedded)

Include these patterns in generated prompts:

  1. Commit after each step - Add to phase tasks: "Commit changes with descriptive message"

  2. Code review as phase - Include review validation:

    **Validation:**
    - [ ] Code review agent finds no critical issues
    
  3. Kanban mindset - Treat each phase like a ticket with ACs

  4. Brick by brick - Phases should be small enough to complete in 2-5 iterations each

  5. Testing loop - Every phase should have runnable validation

Blind Review Protocol

Purpose: Pressure-test the PROMPT.md before autonomous execution. A fresh perspective catches ambiguities that the author is blind to.

How to Run the Blind Review

Spawn a subagent using the Task tool with this prompt template:

You are a senior technical reviewer specializing in PRDs and implementation plans
for autonomous AI execution. You have NO prior context about this project -
you're coming in completely blind.

Your task: Review the PRD at `[PATH_TO_PROMPT.md]` and provide a critical assessment.

## Review Instructions

1. **Read the PRD thoroughly** - understand what's being built
2. **Read relevant existing code** mentioned in the PRD to understand patterns
3. **Produce a review with these sections:**

### A. What I Expect to Happen
Describe concretely what an AI agent executing this plan would build.
Be specific about deliverables.

### B. Implicit Intent I'm Inferring
What is NOT explicitly stated but seems to be the underlying goal?
What assumptions is this plan making?

### C. Pre-Mortem: What Could Go Wrong
Imagine this ralph loop fails. Most likely causes:
- Ambiguous requirements that could be misinterpreted
- Missing context an AI agent would need
- Technical pitfalls or edge cases not addressed
- Validation criteria too vague or too strict
- Dependencies or blockers not mentioned

### D. Confidence Assessment
On a scale of 1-10, how confident are you that an AI agent could execute
this plan successfully without human intervention? Explain your rating.

### E. Recommended Changes (if any)
Specific, actionable changes to improve the PRD before execution.

Be brutally honest. Find problems BEFORE execution, not after.

Interpreting Results

Confidence Action
8-10 Ready to execute. Minor polish optional.
6-7 Address critical issues, re-review optional.
4-5 Significant gaps. Must fix and re-review.
1-3 Fundamental problems. Consider /interview again.

Common Issues the Blind Review Catches

  1. Underspecified types - "Create a dataclass" without field definitions
  2. Undefined formulas - "Calculate P&L" without the actual formula
  3. No test cases - Validation says "tests pass" but no expected inputs/outputs
  4. Integration ambiguity - How new code relates to existing code unclear
  5. Fragile references - Links to other branches, external docs that may not exist

When to Skip Blind Review

  • Very simple prompts (2-3 phases, well-trodden patterns)
  • User explicitly requests skipping
  • Time-critical situations where speed > thoroughness

Default: Always run blind review for prompts with 4+ phases or novel implementations.


Integration with Your Workflow

This skill generates prompts compatible with your /ralph-loop plugin:

/ralph-loop-creator "Build a CLI tool that converts markdown to PDF"
→ Creates: ./docs/md-to-pdf/PROMPT.md
→ Runs blind review (confidence: 8/10)
→ Suggests: /ralph-loop "$(cat ./docs/md-to-pdf/PROMPT.md)" --max-iterations 30 --completion-promise "MD_TO_PDF_COMPLETE"

For complex features, use the full workflow:

/interview docs/X/prd.md              # Flesh out requirements
/ralph-loop-creator docs/X/prd.md     # Generate structured prompt + blind review
/ralph-loop ...                        # Execute
Weekly Installs
4
GitHub Stars
11
First Seen
Feb 19, 2026
Installed on
mcpjam4
codebuddy4
claude-code4
junie4
windsurf4
zencoder4