القائمة
Generate structured Product Requirements Documents using hypothesis-driven methodology with Implementation Phases tracking.
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/oimiragieo/agent-studio --skill prd-generatorيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
Agent frontmatter enhancements — disallowedTools, mcpServers scoping, fork_eligible field
Context management — pre-compact persistence, threshold alignment, microcompact/circuit breaker detection
Hook enhancements — updatedInput for bash safety prefixes, suppressOutput for verbose blocks, denial-based routing feedback
عرض SKILL.md
استنادا إلى تصنيف SOC المهني
| name | prd-generator |
| description | 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 |
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.
Always:
Use specifically for:
Don't use for:
Interactive Mode (when requirements unclear):
// Use AskUserQuestion for structured gathering
const problem = await AskUserQuestion({
question: 'What problem does this solve? (Be specific about user pain points)',
});
const evidence = await AskUserQuestion({
question: 'What evidence shows this problem exists? (Data, feedback, metrics)',
});
hypothesis = ({
: ,
});
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:
When to use Progressive Disclosure:
When to skip:
// Read PRD template
const template = Read({ file_path: '.claude/templates/prd-template.md' });
Template includes these sections (required):
Problem Statement (Evidence-Backed):
## 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:
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.
Implementation Phases Table:
| # | Phase | Description | Status | Parallel | Depends | Plan Link |
|---|---|---|---|---|---|---|
| 1 | Design | Auth architecture design with refresh token flow | pending | No | - | - |
| 2 | Backend API | Implement /refresh endpoint with token rotation | pending | No | 1 | - |
| 3 | Mobile Client | Add refresh logic to mobile SDK | pending | No | 2 | - |
| 4 | Testing | E2E tests for refresh flows | pending | Yes | 2,3 | - |
| 5 | Monitoring | Add refresh metrics to dashboard | pending | Yes | 2 | - |
Phase Columns Explained:
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?
Required Sections Checklist:
const requiredSections = [
'Problem Statement',
'Evidence',
'Key Hypothesis',
'Success Metrics',
'Core Capabilities',
'Implementation Phases',
'Decisions Log',
];
// Verify all present
const missingRequiredSections = requiredSections.filter(section => !prdContent.includes(section));
if (missingRequiredSections.length > 0) {
throw new Error(`Missing required sections: ${missingRequiredSections.join(', ')}`);
}
Quality Checks:
// Generate filename
const featureName = 'auth-refresh-tokens'; // from problem statement
const date = new Date().toISOString().split('T')[0]; // YYYY-MM-DD
const filename = `${featureName}-prd-${date}.md`;
// Write to specs directory
Write({
file_path: `.claude/context/artifacts/specs/${filename}`,
content: prdContent,
});
Output Location: .claude/context/artifacts/specs/{feature-name}-prd-{YYYY-MM-DD}.md
Provenance Header:
<!-- Agent: pm | Task: #{task-id} | Session: {date} -->
# PRD: {Feature Name}
**Version**: 1.0
**Author**: PM Agent
**Date**: {YYYY-MM-DD}
**Status**: Draft
PM creates PRD:
## Implementation Phases
| # | Phase | Description | Status | Parallel | Depends | Plan Link |
| --- | ------- | ----------------- | ------- | -------- | ------- | --------- |
| 1 | Design | Auth architecture | pending | No | - | - |
| 2 | Backend | /refresh endpoint | pending | No | 1 | - |
Planner reads PRD:
| 1 | Design | Auth architecture | completed | No | - | [Plan](.claude/context/plans/impl-phase1-2026-02-09.md) |
Developer reads plan:
Result:
Before writing PRD, verify:
User: "Add dark mode to the app"
PM:
1. Problem: Users report eye strain in low-light conditions
2. Evidence: 200+ support tickets, 4.2 → 3.8 app rating mentions "too bright"
3. Hypothesis: Dark mode will reduce eye strain complaints by 60%
4. MoSCoW:
- Must: System-default theme detection
- Must: Manual toggle in settings
- Should: Per-screen theme override
- Won't: Automatic sunset-based switching (future)
5. Phases:
- Phase 1: Design system color tokens
- Phase 2: Implement theme provider
- Phase 3: Update all screens
6. Write PRD → specs/dark-mode-prd-2026-02-09.md
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
Planner completes Phase 1 design:
Update PRD:
| 1 | Design | Auth architecture | completed | No | - | [Plan](.claude/context/plans/impl-phase1-2026-02-09.md) |
| 2 | Backend | /refresh endpoint | in_progress | No | 1 | [Plan](.claude/context/plans/impl-phase2-2026-02-09.md) |
Add decision to log:
| Token algorithm | RS256 | HS256 | RS256 for key rotation support |
DO:
DON'T:
| 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 |
| Vague success metrics ("improve UX", "make faster") | Cannot validate hypothesis; no way to know if feature succeeded | Specify numeric targets: "-50% support tickets", "<2s load time" |
| Marking everything as "Must" in MoSCoW | No prioritization leads to impossible scope and missed deadlines | Explicitly mark Won't items; treat Could/Should as negotiable |
| Phases without dependency mapping | Parallel execution assumptions break when dependencies surface | Map "Depends" column before implementation; block accordingly |
| Letting PRD go stale after kickoff | Developers lose context; decisions become invisible tribal knowledge | Update phase statuses and decisions log throughout implementation |
<!-- Agent: pm | Task: #42 | Session: 2026-02-09 -->
# PRD: JWT Refresh Token Implementation
**Version**: 1.0
**Author**: PM Agent
**Date**: 2026-02-09
**Status**: Draft
---
## Problem Statement
Mobile app users experience session expiration (1 hour timeout) during active use, forcing re-authentication and losing workflow context. This creates friction and frustration, particularly for users performing multi-step tasks.
## Evidence
- **Support Tickets**: 200+ complaints about "forced logout" in past 2 months
- **Analytics**: 35% of mobile sessions end with forced re-auth (vs 5% desktop)
- **User Feedback**: App store reviews mention "annoying login prompts" (4.2 → 3.8 rating)
- **Business Impact**: 15% cart abandonment rate correlates with session timeout
## Key Hypothesis
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%.
## What We're NOT Building
- Biometric authentication integration (future Phase 2)
- Social login providers (separate initiative)
- Multi-device session management (v2.0)
## 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 |
| Forced re-auth rate | <10% | Analytics events |
## 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 (OWASP) |
| Must | Secure token storage (Keychain/KeyStore) | Prevent token theft |
| Should | Refresh token revocation | Allows user logout from all devices |
| Should | Token usage analytics | Monitoring and debugging |
| Could | Configurable token lifetimes | Admin flexibility |
| Won't | Biometric auth integration | Out of scope - future consideration |
| Won't | Push notification on token expiry | Nice to have, defer to v2 |
## Users & Context
**Primary User**: Mobile app user (iOS/Android) who experiences session expiration during active use (shopping, form filling, browsing)
**Current Behavior**: User logs in → performs task → session expires after 1 hour → forced to re-login → loses form data/cart context
**Trigger**: Session expiration during active use OR app returning from background after >1 hour
**Success State**: User stays logged in seamlessly for up to 30 days (refresh token lifetime), 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 and complete my tasks.
## Solution Detail
### MVP Scope
**Phase 1**: Design auth architecture with refresh token flow
**Phase 2**: Implement backend /refresh endpoint with token rotation
**Phase 3**: Add refresh logic to mobile SDK (iOS/Android)
**Phase 4**: E2E tests for refresh flows
**Phase 5**: Add refresh metrics to monitoring dashboard
### User Flow
1. User logs in → receives access token (1 hour) + refresh token (30 days)
2. User makes API call → server validates access token
3. Access token expires → next API call returns 401
4. Mobile SDK detects 401 → calls /refresh with refresh token
5. Server validates refresh token → issues new access + refresh tokens
6. SDK retries original API call with new access token
7. User continues seamlessly (no re-login)
### Edge Cases
- Network failure during refresh → retry with exponential backoff
- Refresh token expired → force re-login with "session expired" message
- Refresh token revoked (password change) → force re-login
- Concurrent API calls during refresh → queue and retry after refresh completes
## Technical Approach
**Feasibility**: HIGH
**Dependencies**:
- Existing JWT library (jsonwebtoken) supports refresh
- Mobile SDK has secure storage (Keychain/KeyStore)
- Backend has session management infrastructure
**Integration Points**:
- Mobile SDK (iOS/Android) needs refresh interceptor
- Backend needs /refresh endpoint
- Database needs refresh token storage (w/ expiry)
**Architecture Notes**:
- Access token: 1 hour lifetime, stateless (JWT)
- Refresh token: 30 days lifetime, stateful (stored in DB)
- Token rotation: each refresh invalidates old token, issues new one
- Secure storage: Keychain (iOS), KeyStore (Android)
## Implementation Phases
| # | Phase | Description | Status | Parallel | Depends | Plan Link |
| --- | ----------- | ------------------------------------------------ | ------- | -------- | ------- | --------- |
| 1 | Design | Auth architecture design with refresh token flow | pending | No | - | - |
| 2 | Backend API | Implement /refresh endpoint with token rotation | pending | No | 1 | - |
| 3 | Mobile SDK | Add refresh logic to iOS/Android SDK | pending | No | 2 | - |
| 4 | Testing | E2E tests for refresh flows | pending | Yes | 2,3 | - |
| 5 | Monitoring | Add refresh metrics to dashboard | pending | Yes | 2 | - |
## Decisions Log
| Decision | Choice | Alternatives | Rationale |
| ---------------- | ---------------------------------- | -------------------------------------- | ------------------------------------------------------- |
| Token storage | Secure storage (Keychain/KeyStore) | Local storage, Session storage | Security requirement - tokens are sensitive credentials |
| Refresh strategy | Automatic on 401 | Manual user action, Proactive refresh | Better UX - transparent to user, no extra UI |
| Token lifetime | Access: 1hr, Refresh: 30 days | Access: 5min/90min, Refresh: 7/90 days | Balance security (short access) and UX (long refresh) |
| Token algorithm | RS256 (asymmetric) | HS256 (symmetric) | Enables key rotation, better for distributed systems |
| Refresh rotation | Always rotate | Rotate on suspicious activity | OWASP best practice, prevents token replay |
| Storage location | Database | Redis, In-memory | Need persistent storage, DB already available |
## Research Summary
**Market Context**:
- Auth0, Firebase, Okta all use refresh token pattern
- Industry standard: short-lived access + long-lived refresh
- OWASP recommends token rotation on every refresh
- JWT RFC 7519 and OAuth 2.0 RFC 6749 define patterns
**Technical Context**:
- Existing backend uses jsonwebtoken library (supports refresh)
- Mobile SDK has secure storage capabilities
- Backend has session management and database for token storage
- Average API latency: 100ms (refresh won't impact UX significantly)
**Feasibility Assessment**: HIGH
- All dependencies available
- No new infrastructure required
- Clear implementation path
- Low risk of scope creep
## Risks
| Risk | Likelihood | Mitigation |
| ------------------------------ | ---------- | --------------------------------------------------------- |
| Token theft (XSS/MITM) | Medium | Use secure storage, HTTPS only, rotate on refresh |
| Refresh loop (invalid token) | Low | Add exponential backoff, max 3 retries, fallback to login |
| Clock skew issues | Low | Use 5min grace period for exp validation |
| DB performance (token lookups) | Low | Index refresh tokens, implement token cleanup job |
| Concurrent refresh attempts | Low | Use mutex/lock during refresh, queue pending requests |
## Open Questions
- [ ] What happens to active refresh tokens on password change? (Decision: revoke all)
- [ ] How do we handle token refresh during network outage? (Decision: retry with backoff)
- [ ] Should we notify user on refresh token expiration? (Decision: yes, with "session expired" message)
- [ ] Do we need per-device refresh tokens? (Decision: yes, for "logout all devices" feature)
---
_Generated: 2026-02-09_
_Status: Draft_
context-compressor - Progressive disclosure for unclear requirementsplan-generator - Break PRD phases into implementation tasksresearch-synthesis - Gather evidence for problem statementThis skill is invoked by:
pm (Product Manager) - Primary user of this skillBefore starting:
Read .claude/context/memory/learnings.md
Check for:
After completing:
.claude/context/memory/learnings.md.claude/context/memory/decisions.md.claude/context/memory/issues.mdASSUME INTERRUPTION: If it's not in memory, it didn't happen.