Ralph PRD Converter Skill

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 ralph/prd.json at the root of the current directory (the workspace or project you are working in—not inside .agents or other nested tool folders unless that is explicitly the project root).

Before writing a new prd.json, follow Archiving before a new PRD so prior runs are preserved.

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",
        "Typecheck/lint passes"
      ],
      "priority": 1,
      "passes": false,
      "notes": ""
    }
  ]
}

Story Size: The Number One Rule

Each story must be completable in ONE focused session.

Ralph spawns a fresh agent 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:

Schema/database changes (migrations)
Server actions / backend logic
UI components that use the backend
Dashboard/summary views that aggregate data

Wrong order:

UI component (depends on schema that does not exist yet)
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"
"Typecheck/lint passes"
"Tests pass"

Bad criteria (vague):

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

Always include as final criterion:

"Typecheck/lint passes"

For stories with testable logic, also include:

"Tests pass"

For stories that change UI, also include:

"Verify in browser using agent-browser skill"

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

Conversion Rules

Each user story becomes one JSON entry
IDs: Sequential (US-001, US-002, etc.)
Priority: Based on dependency order, then document order
All stories: passes: false and empty notes
branchName: Derive from feature name, kebab-case, prefixed with ralph/
Always add: "Typecheck/lint passes" to every story's acceptance criteria

Splitting Large PRDs

If a PRD has big features, split them:

Original:

"Add user notification system"

Split into:

US-001: Add notifications table to database
US-002: Create notification service for sending notifications
US-003: Add notification bell icon to header
US-004: Create notification dropdown panel
US-005: Add mark-as-read functionality
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",
        "Typecheck/lint passes"
      ],
      "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",
        "Typecheck/lint passes",
        "Verify in browser using agent-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",
        "Typecheck/lint passes",
        "Verify in browser using agent-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",
        "Typecheck/lint passes",
        "Verify in browser using agent-browser skill"
      ],
      "priority": 4,
      "passes": false,
      "notes": ""
    }
  ]
}

Archiving before a new PRD

Paths (relative to project root):

New PRD file: ralph/prd.json
Progress file (when Ralph uses it): ralph/progress.txt

Before writing or overwriting ralph/prd.json:

Ensure the ralph/ directory exists (create it if needed).
If ralph/prd.json already exists or ralph/progress.txt exists, archive whatever is present:
- Create a folder: ralph/archive/YYYY-MM-DD_HHMMSS_<short-slug>/
  - Use the new feature’s kebab-case name (from the incoming PRD or planned branchName) for <short-slug>, or previous-run if unknown.
  - YYYY-MM-DD_HHMMSS is local time when the archive is created (ensures unique folders if you regenerate the same day).
- If ralph/prd.json exists: move it into that folder as prd.json (not copy-only, so the old file no longer sits beside the new one).
- If ralph/progress.txt exists: move it into that folder as progress.txt.
Write the new prd.json to ralph/prd.json.

Do not skip archiving because branchName matches a prior run; any existing ralph/prd.json is always archived before replacement.

Note: ralph.sh may still perform its own housekeeping when you run it; when you create or refresh prd.json via this skill, you still perform the steps above so files under ralph/ stay consistent.

Checklist Before Saving

Before writing ralph/prd.json, verify:

[ ] Existing ralph/prd.json archived (move into ralph/archive/.../ before overwrite)
[ ] Existing ralph/progress.txt archived if it was present (same archive folder)
[ ] Each story is completable in one iteration (small enough)
[ ] Stories are ordered by dependency (schema to backend to UI)
[ ] Every story has "Typecheck/lint passes" as criterion
[ ] UI stories have "Verify in browser using agent-browser skill" as criterion
[ ] Acceptance criteria are verifiable (not vague)
[ ] No story depends on a later story

Agent Skills: Ralph PRD Converter

Install this agent skill to your local

Skill Files