prd
PRD Generator
Overview
All subagent dispatches use disk-mediated dispatch. See shared/dispatch-convention.md for the full protocol.
Generates a Product Requirements Document (PRD) from a finalized design doc. The PRD reformats technical design decisions into stakeholder-friendly language — problem statement, user stories, requirements, scope, success metrics.
Announce at start: "I'm using the PRD skill to generate a product requirements document."
Core principle: The PRD derives everything from the design doc. It does not introduce new decisions or requirements — it translates existing technical decisions for a non-technical audience.
When to Use
- After
/designor/buildPhase 1 completes — you have a finalized design doc - When a stakeholder asks for a PRD, product spec, or requirements document
- When archiving a feature's requirements in Confluence, Jira, Notion, or similar
Input
The skill needs a design doc path. If not provided, it searches:
- Check if the user specified a path:
/prd docs/plans/2026-03-23-my-feature-design.md - If no path: scan
docs/plans/for the most recently modified*-design.mdfile - If no design docs found: inform user and stop
The Process
- Read the design doc — verify it exists and has the expected structure (Overview, acceptance criteria, etc.)
- Dispatch a Sonnet PRD Writer using the prompt template at
skills/build/prd-writer-prompt.md- Input: full design doc text
- Output: PRD in standard format
- Save to
docs/prds/YYYY-MM-DD-<topic>-prd.md - Commit:
docs: add PRD for [feature] - Report the file path to the user
PRD Structure
The generated PRD follows a fixed structure:
- Problem Statement — what problem this solves, in plain language
- User Stories / Use Cases — "As a [role], I want [goal] so that [benefit]"
- Requirements — functional and non-functional, each a testable statement
- Scope — what's included
- Out of Scope — what was explicitly excluded
- Success Metrics — measurable outcomes
- Technical Notes — brief architectural context for stakeholders who want it
- Dependencies — external systems, teams, or services
Integration
Called by:
- crucible:build — Phase 1 Step 2.5 (after design finalized, before acceptance tests). Runs by default in feature mode, skipped in refactor mode.
Standalone usage:
/prd <design-doc-path>— generate PRD from any design doc/prd(no args) — auto-detect most recent design doc
Prompt template: skills/build/prd-writer-prompt.md (shared with build pipeline)
Red Flags
- Inventing requirements not in the design doc
- Including code, file paths, or architecture diagrams in the PRD
- Writing more than 2 pages — PRDs should be concise
- Skipping sections rather than stating "Not specified in design"
More from raddue/crucible
test-driven-development
Use when implementing any feature or bugfix, before writing implementation code
8adversarial-tester
Use after completing implementation to find unknown failure modes. Reads implementation diff and writes up to 5 tests designed to make it break. Triggers on 'break it', 'adversarial test', 'stress test implementation', 'find weaknesses', or any task seeking to expose unknown failure modes.
5quality-gate
Iterative red-teaming of any artifact (design docs, plans, code, hypotheses, mockups). Loops until clean or stagnation. Invoked by artifact-producing skills or their parent orchestrator.
5code-review
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
5finish
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
4verify
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
4