Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Generate structured Product Requirements Documents using hypothesis-driven methodology with Implementation Phases tracking.
version
1.1.0
model
sonnet
invoked_by
agent
user_invocable
false
tools
["Read","Write","AskUserQuestion"]
assigned_agents
["pm"]
best_practices
["Problem-first before solution","Evidence-backed hypothesis","MoSCoW prioritization for scope","Implementation Phases table for traceability"]
error_handling
standard
streaming
supported
verified
true
lastVerifiedAt
"2026-02-22T00:00:00.000Z"
source
builtin
trust_score
100
provenance_sha
23855899eaf585ca
PRD Generator Skill
Overview
Generate structured Product Requirements Documents (PRDs) using problem-first, hypothesis-driven methodology. Ensures clear problem statements, evidence-backed decisions, and traceable implementation phases.
Core principle: Validate "why" before "how". Problem → Evidence → Hypothesis → Solution.
When to Use
Always:
New features requiring product definition
Product changes requiring stakeholder alignment
Requirements gathering for HIGH/EPIC complexity features
Feature requests needing structured analysis
Use specifically for:
Features with unclear requirements (progressive disclosure)
Multi-phase implementations needing tracking
Features requiring decision documentation
Product initiatives needing success metrics
Don't use for:
Simple bug fixes (no PRD needed)
Trivial configuration changes
Code-only refactors without product impact
Purpose
Problem-First: Define problem with evidence before proposing solutions
Hypothesis-Driven: State measurable hypothesis for validation
MoSCoW Prioritization: Prevent scope creep with Must/Should/Could/Won't
Implementation Phases: Track progress with phases table (Status, Dependencies, Plan Links)
Decision Log: Record "why we chose X over Y" for future reference
Traceability: PRD → Planner → Developer with full context
Workflow
Step 1: Gather Requirements
Interactive Mode (when requirements unclear):
// Use AskUserQuestion for structured gatheringconst problem = awaitAskUserQuestion({
question: 'What problem does this solve? (Be specific about user pain points)',
});
const evidence = awaitAskUserQuestion({
question: 'What evidence shows this problem exists? (Data, feedback, metrics)',
});
hypothesis = ({
: ,
});
const
await
AskUserQuestion
question
'What measurable outcome will prove this feature solves the problem?'
Prompt Mode (when requirements provided):
Extract requirements from user prompt or task description
Progressive Disclosure (for ambiguous features):
If requirements are unclear, use 8-phase questioning workflow:
## Problem Statement
[Specific problem description with user impact]
## Evidence- User feedback: [quotes or summary]
- Data: [metrics showing problem scale]
- Business impact: [why this matters now]
Key Hypothesis:
## Key Hypothesis
We believe [capability] will [solve problem] for [users].
We'll know we're right when [measurable outcome].
Example:
We believe adding JWT refresh tokens will reduce user re-authentication friction for mobile users.
We'll know we're right when session timeout complaints drop by 50% and mobile DAU increases by 10%.
Success Metrics:
Metric
Target
How Measured
Session timeout complaints
-50%
Support ticket analysis
Mobile DAU
+10%
Analytics dashboard
Token refresh success rate
>95%
Backend logs
Core Capabilities (MoSCoW):
Priority
Capability
Rationale
Must
JWT refresh token endpoint
Required for MVP - enables session extension
Must
Token rotation on refresh
Security best practice
Should
Refresh token revocation
Allows user logout from all devices
Could
Token usage analytics
Nice to have for monitoring
Won't
Biometric auth integration
Out of scope - future consideration
MoSCoW Definitions:
Must: MVP blocker - without this, feature fails
Should: High value, include if time permits
Could: Nice to have, defer if needed
Won't: Explicitly excluded from current scope
Users & Context:
## Users & Context**Primary User**: Mobile app user (iOS/Android) who experiences session expiration mid-workflow
**Current Behavior**: User logs in → session expires after 1 hour → forced to re-login → loses context
**Trigger**: Session expiration during active use
**Success State**: User stays logged in seamlessly, only re-authenticates when truly needed
**Job to Be Done**: When my session expires, I want to continue my work without re-entering credentials, so I can maintain my workflow momentum.
Parallel: Can this run in parallel with other phases?
Depends: Which phase(s) must complete first? (comma-separated numbers)
Plan Link: Link to planner's implementation plan (.claude/context/plans/impl-{phase}-{date}.md)
Decisions Log:
Decision
Choice
Alternatives
Rationale
Token storage
Secure storage (Keychain/KeyStore)
Local storage, Session storage
Security requirement - tokens are sensitive
Refresh strategy
Automatic on 401
Manual user action
Better UX - transparent to user
Token lifetime
Access: 1hr, Refresh: 30 days
Access: 5min, Refresh: 90 days
Balance security and UX
Research Summary:
## Research Summary**Market Context:**- Auth0, Firebase use similar refresh token patterns
- Industry standard: short-lived access + long-lived refresh
- OWASP recommends token rotation on refresh
**Technical Context:**- Existing JWT library supports refresh
- Mobile SDK has secure storage
- Backend already has session management
Risks:
Risk
Likelihood
Mitigation
Token theft
Medium
Use secure storage, rotate on refresh
Refresh loop (invalid token)
Low
Add exponential backoff, max retry limit
Clock skew issues
Low
Use 5min grace period for exp validation
Open Questions:
## Open Questions- [ ] What happens to active refresh tokens on password change?
- [ ] How do we handle token refresh during network outage?
- [ ] Should we notify user on refresh token expiration?
User: "Make the app faster"
PM:
1. [Progressive Disclosure: 8-phase questioning]
- What specific slowness? (App launch? Navigation? Data load?)
- Where is evidence? (Metrics showing 5s app launch vs 2s competitor)
- What outcome? (Launch time < 2s for 95th percentile)
2. [After gathering context]
- Problem: App launch time 5s vs industry 2s
- Hypothesis: Lazy loading modules will reduce launch to <2s
3. Write PRD → specs/app-launch-performance-prd-2026-02-09.md
NEVER define a solution before articulating the problem with evidence — solution-first thinking generates features no one needs and hypotheses that cannot be validated.
ALWAYS include at least one "Won't" item in MoSCoW prioritization — explicit exclusions are what prevent scope creep and uncontrolled feature growth.
ALWAYS make the success hypothesis measurable with specific numeric targets — vague outcomes like "better UX" or "faster performance" cannot be validated or refuted.
ALWAYS map phase dependencies before implementation begins — undiscovered dependencies cause mid-sprint blockers and cascade delays across the entire roadmap.
NEVER let a PRD go stale during implementation — update phase statuses and the decisions log continuously as work progresses and discoveries are made.
Anti-Patterns
Anti-Pattern
Why It Fails
Correct Approach
Jumping to solution without a problem statement
Builds the wrong thing; no baseline to measure success
Define problem with evidence before proposing any solution
