ralph-convert-prd
Converts Product Requirements Documents into prd.json format for the Ralph autonomous agent system. Use when preparing PRDs for Ralph execution, breaking down features into atomic user stories, or when the user mentions Ralph, prd.json, or autonomous agent workflows.
When & Why to Use This Skill
This Claude skill automates the transformation of Product Requirements Documents (PRDs) into a structured `prd.json` format specifically optimized for the Ralph autonomous agent system. It streamlines the transition from planning to execution by decomposing complex features into atomic, context-aware user stories, ensuring each task is perfectly sized for LLM processing while maintaining strict dependency logic and verifiable acceptance criteria.
Use Cases
- Converting high-level PRDs into machine-readable JSON formats for autonomous AI agent workflows.
- Breaking down monolithic software features into small, independent tasks to prevent LLM context overflow and broken code.
- Standardizing project backlogs with mandatory 'Typecheck passes' and browser-based verification criteria for automated QA.
- Mapping development dependencies to ensure sequential execution from database schema and backend logic to UI components.
- Preparing structured input for the Ralph agent system when initiating new feature branches or autonomous coding sessions.
| name | ralph-convert-prd |
|---|---|
| description | Converts Product Requirements Documents into prd.json format for the Ralph autonomous agent system. Use when preparing PRDs for Ralph execution, breaking down features into atomic user stories, or when the user mentions Ralph, prd.json, or autonomous agent workflows. |
| model | claude-opus-4-5 |
| context | fork |
Stories that are too large cause the LLM to run out of context before completion, resulting in broken code.
Right-sized stories:
- Add a database column
- Create a UI component
- Update server actions
- Implement a filter
Too large (split these):
- Build entire dashboards
- Add authentication systems
- Refactor entire APIs
- Schema/database changes
- Server actions and backend logic
- UI components
- Dashboard/summary views
Never reference something that doesn't exist yet.
Each criterion must be verifiable and specific. Avoid vague language.Good criteria:
- "Add status column with values: 'pending' | 'in_progress' | 'done'"
- "Filter dropdown includes: All, Active, Completed"
- "Clicking delete shows confirmation dialog"
Bad criteria (too vague):
- "Works correctly"
- "Good UX"
- "Handles edge cases"
UI-focused stories MUST also include: "Verify in browser using dev-browser skill"
Field requirements:
id: Sequential US-001, US-002, etc.title: Short, descriptive actiondescription: User story format (As a... I want... so that...)acceptanceCriteria: Array of specific, verifiable criteriapriority: Execution order (1 = first)passes: Alwaysfalseinitiallynotes: Empty string initially
Before outputting the final prd.json, verify:
- Previous runs archived (if applicable)
- Each story completable in one iteration
- Stories ordered by dependency (no forward references)
- All stories include "Typecheck passes"
- UI stories include browser verification criterion
- Acceptance criteria are verifiable, not vague
- No story depends on later stories
- All features from PRD are captured as user stories
- Each story is atomic (one context window)
- Stories are properly ordered by dependency
- All acceptance criteria are specific and verifiable
- Mandatory criteria ("Typecheck passes") present on all stories
- UI stories include browser verification
- Valid JSON structure with all required fields
- Pre-save checklist passes