majiayu000/prd-master
PRD writing and product definition expert. Use when writing PRDs, user stories, acceptance criteria, or prioritizing features. Covers RICE/MoSCoW frameworks, agile requirements, and specification best practices.
npx skills add https://github.com/majiayu000/spellbook --skill prd-master
> These rules are mandatory. Violating them means the skill is not working correctly.
All metrics and requirements must be quantifiable. Vague descriptions are forbidden.
❌ FORBIDDEN:
- "The app should be fast"
- "Support many users"
- "Good user experience"
- "The system should be reliable"
- "Easy to use interface"
✅ REQUIRED:
- "Page load time < 2s on 4G, < 500ms on WiFi (P95)"
- "Support 10,000 concurrent users with 99.9% uptime"
- "NPS > 50, Task completion rate > 85%"
- "99.9% availability, MTTR < 1 hour"
- "User can complete checkout in < 3 clicks"
Never propose a solution without clearly defining the problem first.
❌ FORBIDDEN:
"We should add a search bar to the navigation"
✅ REQUIRED:
"Problem: Users can't find products quickly (40% exit rate on catalog).
They need a way to filter 1000+ products by attributes.
Proposed solutions: search bar, smart filters, AI recommendations."
All user stories must pass the INVEST criteria checklist.
❌ FORBIDDEN:
- Dependent stories that can't be delivered independently
- Stories without acceptance criteria
- Stories too large to complete in one sprint
- Stories without clear user value
✅ REQUIRED:
- [ ] Independent — Can be delivered alone
- [ ] Negotiable — Details can be discussed
- [ ] Valuable — Clear user/business value
- [ ] Estimable — Team can estimate effort
- [ ] Small — Fits in one sprint
- [ ] Testable — Has acceptance criteria
| Scenario | Approach | Tool/Framework |
|----------|----------|----------------|
| Feature prioritization | Scoring model | RICE, ICE |
| Release planning | Must/Should/Could/Won't | MoSCoW |
| Customer satisfaction | Delight vs basics | Kano Model |
| Sprint planning | User stories + BDD | Given-When-Then |
| Complex requirements | Traditional PRD | Full template |
| Agile iteration | Lean requirements | User stories + acceptance criteria |
## 1. Executive Summary
- Problem statement (2-3 sentences)
- Proposed solution (1-2 sentences)
- Success metrics (3-5 key metrics)
## 2. Context & Background
- Why now? Market opportunity or user pain
- Strategic alignment with company goals
- What happens if we don't build this?
## 3. Goals & Success Metrics
- Business objectives (revenue, retention, growth)
- User objectives (satisfaction, engagement)
- Success criteria (quantifiable targets)
## 4. Target Users & Personas
- Primary users (who benefits most?)
- Secondary users (indirect beneficiaries)
- User needs, pain points, motivations
- Jobs to be done
## 5. User Stories & Use Cases
- Core user flows
- Edge cases and error scenarios
- Integration with existing features
## 6. Requirements
- Functional requirements (what it does)
- Non-functional requirements (performance, security)
- Acceptance criteria (how we verify)
## 7. Out of Scope
- What we're explicitly NOT building
- Future considerations for later phases
## 8. Design & UX
- Link to design files (Figma, etc.)
- Key design decisions
- Accessibility requirements (WCAG 2.2 AA)
## 9. Technical Considerations
- Architecture overview
- Dependencies and integrations
- Data model changes
- API contracts
## 10. Rollout & Launch Plan
- Phased rollout strategy
- Feature flags and A/B tests
- Monitoring and alerts
- Rollback plan
## 11. Open Questions & Risks
- Unknowns requiring research
- Technical risks and mitigations
- Dependencies on other teams
As a [persona/role],
I want to [action/goal],
So that [benefit/value].
Card — Brief description on index card
→ Captures essence, not details
→ Placeholder for conversation
Conversation — Discussion between team members
→ Explore edge cases
→ Clarify assumptions
→ Uncover hidden requirements
Confirmation — Acceptance criteria
→ Defines "done"
→ Testable conditions
→ Given-When-Then format
Independent — Story stands alone, minimal dependencies
Negotiable — Details emerge through conversation
Valuable — Delivers value to users or business
Estimable — Team can estimate effort
Small — Completable within one sprint
Testable — Clear acceptance criteria
## Good User Stories
### Feature: Password Reset
As a user who forgot my password,
I want to reset it via email,
So that I can regain access to my account without contacting support.
**Acceptance Criteria:**
- Given I'm on the login page
- When I click "Forgot Password"
- Then I see a form requesting my email address
- Given I've entered my registered email
- When I submit the form
- Then I receive a password reset link within 2 minutes
- Given I click the reset link within 24 hours
- When I set a new password (min 8 chars, 1 number, 1 symbol)
- Then I'm logged in automatically
### Feature: Bulk Upload
As a content manager,
I want to upload multiple products via CSV,
So that I can save time compared to manual entry.
**Acceptance Criteria:**
- Given I'm on the products page
- When I click "Bulk Upload" and select a CSV file
- Then the system validates the file format (max 10MB, .csv only)
- Given the CSV has 1000 rows
- When I start the upload
- Then I see a progress bar showing completion percentage
- Given the upload completes
- When I view the results
- Then I see: success count, error count, downloadable error report
❌ Too technical
"As a user, I want the API to return a 200 status code"
→ Focus on user benefit, not implementation
❌ Too vague
"As a user, I want the system to be fast"
→ Define measurable performance targets
❌ Missing the "so that"
"As a user, I want to filter products by price"
→ Add the value: "so that I can find items within my budget"
❌ Too large (Epic)
"As a user, I want a complete e-commerce checkout experience"
→ Break into smaller stories: cart, address, payment, confirmation
Given [precondition/context]
When [action/trigger]
Then [expected outcome]
And [additional context/outcome]
✓ Keep scenarios focused (one behavior per scenario)
✓ Maintain clear separation of Given/When/Then
✓ Avoid UI-specific details (test behavior, not implementation)
✓ Make criteria testable and measurable
✓ Include both happy path and edge cases
✓ Use real user interactions, not hypothetical
## E-commerce Checkout
Scenario: Successful payment with saved card
Given I have items in my cart
And I'm logged in with a saved payment method
When I click "Place Order"
Then I see an order confirmation page
And I receive a confirmation email within 2 minutes
And my cart is emptied
Scenario: Payment declined
Given I'm at the payment step
When I submit payment and the card is declined
Then I see an error message: "Payment declined. Please try another card."
And I remain on the payment page
And my cart items are preserved
Scenario: Session timeout during checkout
Given I've been idle for 30 minutes
When I attempt to place an order
Then I'm redirected to login
And my cart items are preserved after re-authentication
## Search Feature
Scenario: Search with results
Given I'm on the homepage
When I search for "laptop"
Then I see results within 500ms
And results are ranked by relevance
And I see result count: "Showing 1-20 of 156 results"
Scenario: Search with no results
Given I'm on the search page
When I search for "xyznonexistent"
Then I see "No results found for 'xyznonexistent'"
And I see search suggestions or alternative queries
For simpler features, use a checklist:
## File Upload Acceptance Criteria
- [ ] Supports formats: PDF, DOCX, XLSX (max 10MB each)
- [ ] Shows upload progress bar
- [ ] Displays file name and size after upload
- [ ] Allows removal of uploaded files
- [ ] Shows error message for unsupported formats
- [ ] Shows error message for files exceeding size limit
- [ ] Scans files for malware before processing
- [ ] Works on mobile (iOS Safari, Android Chrome)
RICE Score = (Reach × Impact × Confidence) / Effort
Reach — How many users affected per time period?
(users/quarter, transactions/month)
Impact — How much does it improve their experience?
3 = Massive, 2 = High, 1 = Medium, 0.5 = Low, 0.25 = Minimal
Confidence — How certain are we?
100% = High data, 80% = Medium, 50% = Low
Effort — Person-months required
(engineering + design + PM time)
Example:
| Feature | Reach | Impact | Confidence | Effort | RICE Score |
|---------|-------|--------|------------|--------|------------|
| Password reset | 5000/month | 3 | 100% | 1 | 15,000 |
| Dark mode | 10000/month | 0.5 | 80% | 2 | 2,000 |
| Export to PDF | 500/month | 2 | 50% | 0.5 | 1,000 |
When to use: Managing many ideas, need quantitative comparison, have user data.
ICE Score = (Impact + Confidence + Ease) / 3
Impact — 1-10: How much business/user value?
Confidence — 1-10: How certain are we?
Ease — 1-10: How easy to implement? (10 = very easy)
Example:
| Feature | Impact | Confidence | Ease | ICE Score |
|---------|--------|------------|------|-----------|
| One-click login | 9 | 8 | 6 | 7.7 |
| AI recommendations | 10 | 5 | 3 | 6.0 |
| Email notifications | 6 | 9 | 9 | 8.0 |
When to use: Quick prioritization, weekly grooming, growth experiments, speed over precision.
Must Have — Critical for launch, non-negotiable
Without this, the product fails
Should Have — Important but not vital
Painful to omit, but workarounds exist
Could Have — Nice to have, "vitamins not painkillers"
Include if time/resources allow
Won't Have — Explicitly out of scope
Defer to future releases
Example: MVP E-commerce Site
| Must Have | Should Have | Could Have | Won't Have |
|-----------|-------------|------------|------------|
| Product listing | Product reviews | Wishlist | AR try-on |
| Shopping cart | Related products | Gift wrapping | Live chat |
| Checkout | Order tracking | Discount codes | Loyalty program |
| Payment (Stripe) | Email receipts | Social sharing | Mobile app |
| User accounts | Guest checkout | Product comparison | Subscriptions |
When to use: Sprint planning, MVP scoping, release boundaries, stakeholder alignment.
Basic Needs — Must-haves, assumed by users
Absence = dissatisfaction, presence = neutral
Example: Website loads, checkout works
Performance — More is better, linear satisfaction
Example: Faster page load, more payment options
Delighters — Unexpected features that wow
Absence = neutral, presence = delight
Example: Free shipping, personalized recommendations
Indifferent — Users don't care either way
Example: Animated logo, theme customization
When to use: Customer-driven decisions, balancing basics vs innovation, UX improvements.
Process:
Best practice: Combine frameworks
1. Use MoSCoW to define release scope
→ Separate must-haves from nice-to-haves
2. Use RICE to rank must-haves
→ Sequence within release based on impact
3. Use Kano to ensure balance
→ Don't over-invest in basics, under-invest in delight
Example:
- All "Must Have" items → Score with RICE → Build in RICE order
- Validate with Kano → Ensure we have delighters, not just basics
Detailed material starting at ## Agile Requirements Management has been moved to reference/extended.md to keep this skill concise. Load that reference when the task requires the moved examples, command catalogs, checklists, platform details, or implementation templates.
Take majiayu000/prd-master from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.