Back to Blog
PRPVibePlanningContextEngineeringAIProductManagementAgenticAIRalphLoop

PRP Framework: Ship Production-Ready AI Code on the First Pass

9 min read

Continuing from last week's post on BMAD Method, this week I'll deep-dive into the second planning framework: PRP (Product Requirements Prompt). This...

Continuing from last week's post on BMAD Method, this week I'll deep-dive into the second planning framework: PRP (Product Requirements Prompt). This is part of my weekly AI series where I take you progressively through AI fundamentals, and PRP represents the lean, context-engineering approach to vibe-planning. ## What is PRP? You may wonder, what exactly is PRP, or how is it different from BMAD? That is because while BMAD provides comprehensive enterprise structure with 21 agents, PRP focuses on one goal: giving AI the minimum viable context to ship production-ready code on the first pass. Rasmus Widing, a product manager, built PRP after getting frustrated watching AI coding assistants "build random, useless things instead of what was actually needed." He identified the core problem: **AI doesn't know your codebase.** It doesn't know your file structure, your library versions, or your coding conventions. Without this context, AI generates generic code that doesn't fit your system. As Widing notes: "After building dozens of projects with AI agents, I kept hitting the same wall: the AI is smart, but it doesn't know the codebase. PRPs fix that." ## The Three Components of a PRP A traditional PRD tells AI WHAT to build and WHY. A PRP adds two critical layers that transform vague instructions into production-ready code. ### Component 1: PRD (What & Why) This is familiar territory—standard product requirements: - What are you building? - Why does it need to exist? - Who is it for? - What does success look like? Here's Widing's distinction: "Global rules are for things that will be true forever in your codebase. PRPs are for the specific work you're doing right now." ### Component 2: Curated Codebase Context (The How) This is what makes PRP different from every other approach. You provide AI with: - **Precise file paths**: Not "somewhere in the auth folder"—exact paths - **Library versions**: "Express 4.18.2, not 5.x" - **Code snippet examples**: Show existing patterns the AI should follow - **Architectural conventions**: "We use repository pattern, not direct DB access" - **Dependencies between components**: What connects to what Why does this matter? That is because AI doesn't know your codebase. It doesn't know you use semicolons or prefer async/await over callbacks. Without this context, AI generates generic code that doesn't fit your system. ### Component 3: Validation Commands (The Proof) This is PRP's secret weapon: executable commands the AI runs to verify its own work. ```bash # Type checking npm run typecheck # Linting npm run lint # Unit tests npm run test # Build verification npm run build ``` The AI doesn't just write code—it validates that the code works against your actual requirements. ## The Critical Best Practice: Context Separation Here's perhaps the most important insight from the PRP methodology: **"Between the creation of the PRP and the execution, you should use a new instance of your AI assistant or at least clear the context. If you do planning and execution in the same context window, you will run out of context quickly, and it can lead to hallucinations."** You may wonder, why is this necessary? Shouldn't AI remember what it just planned? That is because context windows are finite. If your planning conversation uses 50,000 tokens, and your implementation needs 100,000 tokens, you're competing for space. The planning context gets compressed or lost, leading to implementations that drift from requirements. The solution: Plan in one session, save the PRP to a file, clear context, then execute from the saved PRP in a fresh session. ## The Five-Phase Workflow PRP follows a structured progression: **Phase 1: Load** AI gathers all requirements and existing codebase patterns. This is the context engineering phase—collecting everything AI needs to understand your specific situation. **Phase 2: Plan** AI creates a comprehensive task breakdown based on the loaded context. Requirements become discrete, implementable tasks. **Phase 3: Execute** AI carries out the plan, implementing each task. Code is written following your patterns and conventions. **Phase 4: Validate** AI runs all validation commands—type checking, linting, tests, builds. Code is verified against your actual requirements, not just AI assumptions. **Phase 5: Complete** Artifacts are finalized with PRP reference for future maintenance. Documentation is updated, implementation is tracked. ## The Ralph Loop: AI That Debugs Itself And the best part? The Ralph Loop—named after Ralph Wiggum from The Simpsons ("I'm in danger!")—is PRP's autonomous execution feature. As the documentation describes it: "Ralph isn't just a loop that codes. It's a funnel with 3 Phases, 2 Prompts, and 1 Loop." ### How It Works 1. **Planning Phase**: AI does gap analysis (specs vs. code) and outputs a prioritized TODO list. No implementation, no commits—just planning. 2. **Building Phase**: AI picks tasks from the plan, implements them, runs tests (backpressure), and commits. 3. **Validation Loop**: Implement → Validate → Fix failures → Re-validate → Repeat When all validations pass, the loop outputs `<promise>COMPLETE</promise>` and exits. ### Why This Matters Traditional AI workflows: You prompt, AI responds, you review, you ask for fixes, repeat. Ralph Loop: AI implements, validates its own work, fixes its own failures, re-validates—autonomously iterating until done. This is what "agentic" actually means in practice: AI that can complete multi-step tasks with self-correction. ### Backpressure Beyond Code The Ralph Loop supports "LLM-as-judge" tests for subjective criteria: - Creative quality - Aesthetics - UX feel - Code readability Binary pass/fail tests provide backpressure even for non-programmatic acceptance criteria. ## Slash Commands: PRP in Practice PRP provides IDE commands for the complete workflow: ### Core Workflow - `/prp-prd` – Interactive PRD generator with implementation phases - `/prp-plan` – Create implementation plan from PRP - `/prp-implement` – Execute plan with validation loops ### Issue Handling - `/prp-issue-investigate` – Analyze GitHub issues - `/prp-issue-fix` – Implement fixes - `/prp-debug` – Root cause analysis using 5 Whys technique ### Git Integration - `/prp-commit` – Smart commits with natural language targeting - `/prp-pr` – PR creation with template support - `/prp-review` – Comprehensive code review ### Autonomous Execution - `/prp-ralph` – Start Ralph Loop until all validations pass - `/prp-ralph-cancel` – Stop active loops ## Directory Structure PRP organizes artifacts systematically: ``` .claude/PRPs/ ├── prds/ # Product requirement documents ├── plans/ # Implementation plans │ └── completed/ # Finished plans ├── reports/ # Implementation reports ├── issues/ # Investigation artifacts │ └── completed/ # Resolved issues └── reviews/ # PR review reports ``` Why does this matter? That is because this structure creates institutional memory. Six months from now, when you need to extend a feature, future AI sessions can reference past decisions—instead of starting from scratch. ## PRP vs. Traditional Prompting You may wonder, why does PRP work better than just asking AI to "build X"? | Aspect | Simple Prompt | PRP | |--------|---------------|-----| | **Codebase Knowledge** | None | Full context | | **Pattern Matching** | Generic | Your conventions | | **Validation** | Hope it works | Executable tests | | **First-Pass Quality** | Buggy | Production-ready | | **Maintenance** | Start over | Reference docs | As the PRP documentation states: "A simple prompt gets you a generic, buggy app. A PRP gets you a production-ready application that works, often on the first try, because you did the thinking and planning upfront." ## PRP vs. BMAD You may also wonder, how does PRP compare to last week's BMAD framework? | Aspect | BMAD | PRP | |--------|------|-----| | **Approach** | Comprehensive structure | Minimum viable context | | **Agents** | 21 specialized personas | Single context-aware agent | | **Best For** | Enterprise systems | Feature development | | **Documentation** | Extensive (source of truth) | Focused (context packet) | | **Learning Curve** | Steeper | Gentler | | **Autonomy** | Human oversight each phase | Ralph Loop self-corrects | **Use BMAD when**: Building enterprise systems from scratch, multiple teams, long-term maintenance critical. **Use PRP when**: Adding features to existing codebase, need production-ready on first pass, working solo or small team. ## Why This Matters for You Understanding PRP is the difference between generic AI code and code that fits your system. **For developers**: PRP solves the "AI doesn't know my codebase" problem. You provide context once, AI implements correctly the first time. **For PMs**: PRP transforms your requirements into executable specifications. The validation commands ensure AI builds what you actually asked for. **For teams**: PRP creates consistency. Every developer uses the same context packets, producing code that follows the same patterns. Six months from now, when you need to extend a feature, your PRP documents provide the context AI needs—instead of guessing or starting over. ## Connecting to Our AI Fundamentals This is exactly why I've been taking you through AI fundamentals in this series: | Previous Topic | Connection to PRP | |----------------|-------------------| | **Embeddings** | Enable semantic search for codebase context | | **Vector Databases** | Store and retrieve code patterns efficiently | | **Context Engineering** | PRP IS context engineering for product requirements | | **Vibe-Planning** | PRP is vibe-planning's lean implementation | | **BMAD** | PRP offers lighter alternative for feature work | ## Getting Started with PRP **Step 1: Install PRP Commands** Clone the repository and add commands to your Claude Code or Cursor setup: ```bash git clone https://github.com/Wirasm/PRPs-agentic-eng ``` **Step 2: Create Your First PRP** Start with `/prp-prd` to generate requirements interactively. **Step 3: Add Codebase Context** Document your file paths, patterns, and conventions. **Step 4: Define Validation Commands** Add executable tests that verify your requirements. **Step 5: Execute with Ralph Loop** Run `/prp-ralph` and let AI implement, validate, and self-correct. ## What's Next Stay tuned!! In next week's post, I will explain Spec-Driven Development (SDD)—where specifications become executable and the goal is 95%+ accuracy implementing specs on the first try. We'll explore GitHub's Spec-Kit, Amazon's Kiro IDE, and why the industry is moving toward "intent as the source of truth." ## Key Takeaways - **PRP** = PRD + Curated Codebase Context + Validation Commands - **The goal**: "Minimum viable packet an AI needs to ship production-ready code on the first pass" - **The problem PRP solves**: AI doesn't know your codebase - **Critical practice**: Clear context between planning and execution to prevent hallucinations - **Five phases**: Load → Plan → Execute → Validate → Complete - **Ralph Loop**: AI implements, validates, fixes, re-validates autonomously - **Context separation**: Plan in one session, execute in fresh session - **Validation commands**: AI verifies its own work against your requirements ## Additional Documents to Read on This - [PRP Framework - GitHub](https://github.com/Wirasm/PRPs-agentic-eng) - Original open-source framework by Rasmus Widing - [Context Engineering & PRP Guide](https://www.aifire.co/p/ai-coding-assistants-a-guide-to-context-engineering-prp) - Comprehensive tutorial - [PRP Deep Dive - TechyDiaries](https://www.techiediaries.com/the-prp-framework-a-deep-dive-into-context-engineering-for-ai-assistants/) - Technical deep dive - [Ralph Loop - GitHub](https://github.com/snarktank/ralph) - Autonomous execution pattern - [Context Engineering Introduction](https://github.com/coleam00/context-engineering-intro) - PRP in broader context --- *This is part of my weekly AI series taking you progressively from fundamentals to practical applications. Previous posts covered embeddings, vector databases, neural networks, prompting techniques, vibe coding dangers, vibe-planning, and BMAD Method. Next week: Spec-Driven Development.*