
Ralph Tui Prd
Turn a fuzzy feature idea into a ralph-tui-ready PRD with user stories, scope boundaries, and mandatory quality gates—without starting implementation.
Overview
ralph-tui-prd is an agent skill most often used in Validate (also Build pm, Ship testing) that generates PRDs with user stories and quality gates for ralph-tui orchestration.
Install
npx skills add https://github.com/subsy/ralph-tui --skill ralph-tui-prdWhat is this skill?
- Iterative clarifying questions (3–5 essentials) with lettered options, one set at a time
- Always elicits quality gates—commands that must pass per user story
- Outputs PRD wrapped in [PRD]...[/PRD] markers for ralph-tui parsing
- Optimized for conversion to beads issues or prd.json for automated execution
- Hard rule: do not implement—spec only
- 3–5 essential clarifying questions per iteration
- [PRD]...[/PRD] output markers for TUI parsing
Adoption & trust: 1.1k installs on skills.sh; 2.4k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You want ralph-tui to run a feature autonomously but only have a vague idea—no stories, boundaries, or pass/fail commands defined.
Who is it for?
Indie builders planning a feature for ralph-tui who need fast structured requirements and executable acceptance commands.
Skip if: Builders who already have an approved spec and only need code generation without another planning pass.
When should I use this skill?
Triggers on: create a prd, write prd for, plan this feature, requirements for, spec out.
What do I get? / Deliverables
You get a TUI-parsable PRD with scoped user stories and required quality gates, ready for beads issues or prd.json—then hand off to implementation skills separately.
- PRD document with user stories
- [PRD]-wrapped output for TUI parsing
- Documented quality gates per story
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
PRD creation is the canonical shelf in validate/scope where requirements are fixed before automated agent execution in build and ship. The skill explicitly scopes features, success criteria, and quality-gate commands—core pre-build specification work.
Where it fits
Clarify scope and quality-gate commands before converting the PRD to prd.json for ralph-tui.
Break a multi-story feature into agent-sized work items with integration notes for existing codebase areas.
Embed per-story test/lint commands as quality gates so automated runs know when a story is truly done.
How it compares
Use instead of ad-hoc chat planning when you need [PRD] markers and quality gates wired for ralph-tui—not a generic markdown spec with no execution contract.
Common Questions / FAQ
Who is ralph-tui-prd for?
Solo builders orchestrating work through ralph-tui who need PRDs that agents can parse and execute with clear per-story quality gates.
When should I use ralph-tui-prd?
Use when triggers match—create a prd, write prd for, plan this feature, requirements for, spec out—in validate/scope before build, and again when scoping incremental features before ship testing gates.
Is ralph-tui-prd safe to install?
Check the Security Audits panel on this Prism page; the skill is planning-only but your agent environment should still limit repo access if PRDs touch sensitive product details.
SKILL.md
READMESKILL.md - Ralph Tui Prd
# Ralph TUI PRD Generator Create detailed Product Requirements Documents optimized for AI agent execution via ralph-tui. --- ## The Job 1. Receive a feature description from the user 2. Ask 3-5 essential clarifying questions (with lettered options) - one set at a time 3. **Always ask about quality gates** (what commands must pass) 4. After each answer, ask follow-up questions if needed (adaptive exploration) 5. Generate a structured PRD when you have enough context 6. Output the PRD wrapped in `[PRD]...[/PRD]` markers for TUI parsing **Important:** Do NOT start implementing. Just create the PRD. --- ## Step 1: Clarifying Questions (Iterative) Ask questions one set at a time. Each answer should inform your next questions. Focus on: - **Problem/Goal:** What problem does this solve? - **Core Functionality:** What are the key actions? - **Scope/Boundaries:** What should it NOT do? - **Success Criteria:** How do we know it's done? - **Integration:** How does it fit with existing features? - **Quality Gates:** What commands must pass for each story? (REQUIRED) ### Format Questions Like This: ``` 1. What is the primary goal of this feature? A. Improve user onboarding experience B. Increase user retention C. Reduce support burden D. Other: [please specify] 2. Who is the target user? A. New users only B. Existing users only C. All users D. Admin users only ``` This lets users respond with "1A, 2C" for quick iteration. ### Quality Gates Question (REQUIRED) Always ask about quality gates - these are project-specific: ``` What quality commands must pass for each user story? A. pnpm typecheck && pnpm lint B. npm run typecheck && npm run lint C. bun run typecheck && bun run lint D. Other: [specify your commands] For UI stories, should we include browser verification? A. Yes, use dev-browser skill to verify visually B. No, automated tests are sufficient ``` ### Adaptive Questioning After each response, decide whether to: - Ask follow-up questions (if answers reveal complexity) - Ask about a new aspect (if current area is clear) - Generate the PRD (if you have enough context) Typically 2-4 rounds of questions are needed. --- ## Step 2: PRD Structure Generate the PRD with these sections: ### 1. Introduction/Overview Brief description of the feature and the problem it solves. ### 2. Goals Specific, measurable objectives (bullet list). ### 3. Quality Gates **CRITICAL:** List the commands that must pass for every user story. ```markdown ## Quality Gates These commands must pass for every user story: - `pnpm typecheck` - Type checking - `pnpm lint` - Linting For UI stories, also include: - Verify in browser using dev-browser skill ``` This section is extracted by conversion tools (ralph-tui-create-json, ralph-tui-create-beads) and appended to each story's acceptance criteria. ### 4. User Stories Each story needs: - **Title:** Short descriptive name - **Description:** "As a [user], I want [feature] so that [benefit]" - **Acceptance Criteria:** Verifiable checklist of what "done" means Each story should be small enough to implement in one focused AI agent session. **Format:** ```markdown ### US-001: [Title] **Description:** As a [user], I want [feature] so that [benefit]. **Acceptance Criteria:** - [ ] Specific verifiable criterion - [ ] Another criterion ``` **Note:** Do NOT include quality gate commands in individual story criteria - they are defined once in the Quality Gates section and applied automatically during conversion. **Important:** - Acceptance criteria must be verifiable, not vague - "Works correctly" is bad - "Button shows confirmation dialog b