Ralph PRD Converter

Converts existing PRDs to the prd.json format that Ralph uses for autonomous execution.

The Job

Take a PRD (markdown file or text) and convert it to prd.json in your ralph directory.

Output Format

{
  "project": "[Project Name]",
  "branchName": "ralph/[feature-name-kebab-case]",
  "description": "[Feature description from PRD title/intro]",
  "userStories": [
    {
      "id": "US-001",
      "title": "[Story title]",
      "description": "As a [user], I want [feature] so that [benefit]",
      "acceptanceCriteria": [
        "Criterion 1",
        "Criterion 2",
        "Code builds successfully"
        "All Tests pass with code coverage greater than 80%"
      ],
      "priority": 1,
      "passes": false,
      "notes": ""
    }
  ]
}

Story Size: The Number One Rule

Each story must be completable in ONE Ralph iteration (one context window).

Ralph spawns a fresh Claude instance per iteration with no memory of previous work. If a story is too big, the LLM runs out of context before finishing and produces broken code.

Right-sized stories:

• •Add a database column and migration
• •Add a UI component to an existing page
• •Update a server action with new logic
• •Add a filter dropdown to a list

Too big (split these):

• •"Build the entire dashboard" - Split into: schema, queries, UI components, filters
• •"Add authentication" - Split into: schema, middleware, login UI, session handling
• •"Refactor the API" - Split into one story per endpoint or pattern

Rule of thumb: If you cannot describe the change in 2-3 sentences, it is too big.

Story Ordering: Dependencies First

Stories execute in priority order. Earlier stories must not depend on later ones.

Correct order:

1. •Schema/database changes (migrations)
2. •Server actions / backend logic
3. •UI components that use the backend
4. •Dashboard/summary views that aggregate data

Wrong order:

1. •UI component (depends on schema that does not exist yet)
2. •Schema change

Acceptance Criteria: Must Be Verifiable

Each criterion must be something Ralph can CHECK, not something vague.

Good criteria (verifiable):

• •"Add status column to tasks table with default 'pending'"
• •"Filter dropdown has options: All, Active, Completed"
• •"Clicking delete shows confirmation dialog"
• •"Code builds successfully"
• •"Tests pass with greater than 80% code coverage"

Bad criteria (vague):

• •"Works correctly"
• •"User can do X easily"
• •"Good UX"
• •"Handles edge cases"

Always include as final criterion:

"Code builds successfully"
And
"Tests pass with greater than 80% code coverage"

For stories that change UI, also include:

"Verify in browser using dev-browser skill"

Frontend stories are NOT complete until visually verified. Ralph will use the dev-browser skill to navigate to the page, interact with the UI, and confirm changes work.

For stories that change apis, also include:

"Verify all endpoints that have changed return 200 status codes by performing curl requests on them"

Api stories are NOT complete until verified. Ralph will perform curl requests against the endpoints, and confirm changes work.

Final Testing Story: Always Required

Every prd.json MUST include a final testing story as the last user story.

This story is dedicated to comprehensive testing and verification of the new functionality implemented in this PRD.

Testing Story Requirements:

1. •

   Create integration tests for the new functionality

   • •Tests specific to the features/functionality added in this PRD
   • •Tests that verify the system works in deployed and local running environments
   • •These tests should be runnable independently to validate new deployments
2. •

   API-specific integration tests (if PRD includes API changes):

   • •Create tests using curl requests for new/modified endpoints
   • •Verify response status codes, headers, and payloads
   • •Test both success and error scenarios
   • •Document curl commands for manual verification
3. •

   UI-specific integration tests (if PRD includes UI changes):

   • •Create UI/browser tests for new user flows and components
   • •Verify visual elements, interactions, and state management
   • •Test the new functionality end-to-end from user perspective
4. •

   Full-stack integration tests (if PRD has both frontend and backend changes):

   • •Test integration between new frontend and backend components
   • •Verify end-to-end user workflows for new functionality
   • •Test data flow from UI → API → database and back for new features
5. •

   Run all tests as final verification (FINAL STEP):

   • •Execute the full test suite including newly created integration tests
   • •Verify code coverage remains above 80%
   • •All tests must pass before story is complete

Example Final Testing Story:

{
  "id": "US-XXX",
  "title": "Comprehensive testing and integration verification",
  "description": "As a developer, I need comprehensive tests to verify the new functionality works correctly in all environments.",
  "acceptanceCriteria": [
    "Integration tests created for new functionality in local and deployment environments",
    "API integration tests created using curl requests for new/modified endpoints",
    "UI integration tests created for new user flows and components",
    "Frontend-backend integration tests verify end-to-end workflows for new features",
    "Integration tests are documented and runnable independently",
    "Code builds successfully",
    "All tests pass including newly created integration tests with >80% code coverage"
  ],
  "priority": 999,
  "passes": false,
  "notes": ""
}

Note: Assign this story the highest priority number (after all implementation stories) so it executes last.

Conversion Rules

1. •Each user story becomes one JSON entry
2. •IDs: Sequential (US-001, US-002, etc.)
3. •Priority: Based on dependency order, then document order
4. •All stories: passes: false and empty notes
5. •branchName: Derive from feature name, kebab-case, prefixed with ralph/
6. •Always add: "Code builds successfully" to every story's acceptance criteria
7. •Always add: "All Tests pass with code coverage greater than 80%" to every story's acceptance criteria
8. •Always include: A final testing story (highest priority number) that runs all tests and creates integration tests as described in "Final Testing Story: Always Required"

Splitting Large PRDs

If a PRD has big features, split them:

Original:

"Add user notification system"

Split into:

1. •US-001: Add notifications table to database
2. •US-002: Create notification service for sending notifications
3. •US-003: Add notification bell icon to header
4. •US-004: Create notification dropdown panel
5. •US-005: Add mark-as-read functionality
6. •US-006: Add notification preferences page

Each is one focused change that can be completed and verified independently.

Example

Input PRD:

# Task Status Feature

Add ability to mark tasks with different statuses.

## Requirements
- Toggle between pending/in-progress/done on task list
- Filter list by status
- Show status badge on each task
- Persist status in database

Output prd.json:

{
  "project": "TaskApp",
  "branchName": "ralph/task-status",
  "description": "Task Status Feature - Track task progress with status indicators",
  "userStories": [
    {
      "id": "US-001",
      "title": "Add status field to tasks table",
      "description": "As a developer, I need to store task status in the database.",
      "acceptanceCriteria": [
        "Add status column: 'pending' | 'in_progress' | 'done' (default 'pending')",
        "Generate and run migration successfully",
        "Code builds successfully",
      ],
      "priority": 1,
      "passes": false,
      "notes": ""
    },
    {
      "id": "US-002",
      "title": "Display status badge on task cards",
      "description": "As a user, I want to see task status at a glance.",
      "acceptanceCriteria": [
        "Each task card shows colored status badge",
        "Badge colors: gray=pending, blue=in_progress, green=done",
        "Code builds successfully",
        "Verify in browser using dev-browser skill"
      ],
      "priority": 2,
      "passes": false,
      "notes": ""
    },
    {
      "id": "US-003",
      "title": "Add status toggle to task list rows",
      "description": "As a user, I want to change task status directly from the list.",
      "acceptanceCriteria": [
        "Each row has status dropdown or toggle",
        "Changing status saves immediately",
        "UI updates without page refresh",
        "Code builds successfully",
        "Verify in browser using dev-browser skill"
      ],
      "priority": 3,
      "passes": false,
      "notes": ""
    },
    {
      "id": "US-004",
      "title": "Filter tasks by status",
      "description": "As a user, I want to filter the list to see only certain statuses.",
      "acceptanceCriteria": [
        "Filter dropdown: All | Pending | In Progress | Done",
        "Filter persists in URL params",
        "Code builds successfully",
        "Verify in browser using dev-browser skill"
      ],
      "priority": 4,
      "passes": false,
      "notes": ""
    },
    {
      "id": "US-005",
      "title": "Comprehensive testing and integration verification",
      "description": "As a developer, I need comprehensive tests to verify the task status feature works correctly in all environments.",
      "acceptanceCriteria": [
        "Integration tests created for task status functionality in local and deployment environments",
        "API integration tests created using curl requests for status update endpoints",
        "UI integration tests created for status badge display, toggle, and filter workflows",
        "Frontend-backend integration tests verify status changes persist correctly from UI to database",
        "Integration tests are documented and runnable independently",
        "Code builds successfully",
        "All tests pass including newly created integration tests with >80% code coverage"
      ],
      "priority": 5,
      "passes": false,
      "notes": ""
    }
  ]
}

Archiving Previous Runs

Before writing a new prd.json, check if there is an existing one from a different feature:

1. •Read the current prd.json if it exists
2. •Check if branchName differs from the new feature's branch name
3. •If different AND progress.txt has content beyond the header:
   • •Create archive folder: archive/YYYY-MM-DD-feature-name/
   • •Copy current prd.json and progress.txt to archive
   • •Reset progress.txt with fresh header

The ralph.sh script handles this automatically when you run it, but if you are manually updating prd.json between runs, archive first.

Checklist Before Saving

Before writing prd.json, verify:

• • Previous run archived (if prd.json exists with different branchName, archive it first)
• • Each story is completable in one iteration (small enough)
• • Stories are ordered by dependency (schema to backend to UI)
• • Every story has "Code builds successfully" as criterion
• • UI stories have "Verify in browser using dev-browser skill" as criterion
• • Acceptance criteria are verifiable (not vague)
• • No story depends on a later story
• • Final testing story included as the last story with highest priority number
• • Final testing story includes integration tests appropriate for the project type (API curl tests, UI tests, and/or frontend-backend integration tests)