
Generate Prd
- 33 installs
- 17 repo stars
- Updated March 28, 2026
- cfircoo/claude-code-toolkit
Analyze and validate technical documentation and project architecture
About
generate-prd helps analyze technical designs, PRDs, and architecture. Use it during build to review technical specifications, validate design decisions, and ensure project alignment.
- Design analysis
- Technical review
- Validation
Generate Prd by the numbers
- 33 all-time installs (skills.sh)
- Ranked #653 of 1,352 Code Review & Quality skills by installs in the Skillselion catalog
- Data as of Jul 28, 2026 (Skillselion catalog sync)
npx skills add https://github.com/cfircoo/claude-code-toolkit --skill generate-prdAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 33 |
|---|---|
| repo stars | ★ 17 |
| Last updated | March 28, 2026 |
| Repository | cfircoo/claude-code-toolkit ↗ |
What it does
Analyze and validate technical documentation and project architecture
Files
<objective> Generate detailed, actionable Product Requirements Documents (PRDs) for new features. Guide users through clarifying questions, then produce specifications suitable for implementation by developers or AI agents.
Important: This skill creates PRDs only—it does NOT begin implementation. </objective>
<quick_start> 1. Ask 3-5 clarifying questions with lettered options (A, B, C, D) 2. Generate structured PRD based on answers 3. Save to tasks/prd-[feature-name].md </quick_start>
<process>
<step name="1_clarifying_questions"> Ask 3-5 essential questions using AskUserQuestion tool. Cover:
- Problem/Goal: What problem does this solve? Who benefits?
- Core Functionality: What are the must-have features?
- Scope/Boundaries: What is explicitly NOT included?
- Success Criteria: How will we know this worked?
Each question should have 3-4 concrete options (A, B, C, D format) plus "Other" for custom input. </step>
<step name="2_generate_prd"> Create the PRD document with these sections:
1. Introduction/Overview – Brief feature description and problem statement 2. Goals – Specific, measurable objectives 3. User Stories – Each with title, description, and verifiable acceptance criteria 4. Functional Requirements – Numbered explicitly (FR-1, FR-2, etc.) 5. Non-Goals – Clear scope boundaries 6. Design Considerations – UI/UX requirements (if applicable) 7. Technical Considerations – Constraints and dependencies (if applicable) 8. Success Metrics – Measurable outcomes 9. Open Questions – Remaining clarifications needed </step>
<step name="3_save_document"> Save the PRD to: tasks/prd-[feature-name].md
Use kebab-case for feature name (e.g., prd-user-authentication.md). </step>
</process>
<principles>
<principle name="explicitness"> Avoid jargon or explain it. Provide concrete examples. A junior developer should understand every requirement without additional context. </principle>
<principle name="verifiability"> Acceptance criteria must be testable and specific.
Good: "Login button redirects to /dashboard on success" Bad: "Login works correctly" </principle>
<principle name="ui_stories"> Every UI-focused user story MUST include this acceptance criterion: "Verify in browser using dev-browser skill" </principle>
<principle name="atomic_stories"> Each user story should be small enough to implement in one session. If a story feels too large, break it into smaller stories. </principle>
</principles>
<prd_template>
# PRD: {{Feature Name}}
## 1. Introduction
{{Brief description of the feature and the problem it solves}}
## 2. Goals
- {{Goal 1: Specific, measurable objective}}
- {{Goal 2: Specific, measurable objective}}
## 3. User Stories
### US-1: {{Story Title}}
**As a** {{user type}}, **I want** {{feature}} **so that** {{benefit}}.
**Acceptance Criteria:**
- {{Specific, testable criterion}}
- {{Specific, testable criterion}}
- Verify in browser using dev-browser skill (for UI stories)
### US-2: {{Story Title}}
...
## 4. Functional Requirements
- **FR-1**: {{Explicit requirement}}
- **FR-2**: {{Explicit requirement}}
- **FR-3**: {{Explicit requirement}}
## 5. Non-Goals
- {{What this feature explicitly does NOT do}}
- {{Scope boundary}}
## 6. Design Considerations
{{UI/UX requirements, wireframe references, design patterns}}
## 7. Technical Considerations
{{Constraints, dependencies, integration points, performance requirements}}
## 8. Success Metrics
- {{Measurable outcome 1}}
- {{Measurable outcome 2}}
## 9. Open Questions
- [ ] {{Unresolved question needing clarification}}</prd_template>
<examples>
<example name="good_acceptance_criteria"> Good:
- "Search results display within 2 seconds"
- "Error message shows 'Invalid email format' for malformed input"
- "Clicking 'Save' disables button and shows spinner until complete"
Bad:
- "Search is fast"
- "Shows appropriate error messages"
- "Good UX on save"
</example>
<example name="good_functional_requirements">
- FR-1: System shall validate email format using RFC 5322 pattern
- FR-2: Password must be minimum 8 characters with at least one number
- FR-3: Session expires after 30 minutes of inactivity
</example>
</examples>
<success_criteria> PRD is complete when:
- [ ] 3-5 clarifying questions were asked and answered
- [ ] All 9 PRD sections are filled with concrete content
- [ ] User stories have verifiable acceptance criteria
- [ ] UI stories include browser verification criterion
- [ ] Functional requirements are numbered (FR-1, FR-2, etc.)
- [ ] Non-goals clearly define scope boundaries
- [ ] Document saved to
tasks/prd-[feature-name].md - [ ] No implementation has begun (PRD only)
</success_criteria>