w95/prd-writer
Write comprehensive Product Requirements Documents with user stories, acceptance criteria, technical specifications, wireframe descriptions, and prioritization frameworks (RICE, MoSCoW). Create clear specifications for product teams.
npx skills add https://github.com/w95/awesome-claude-corporate-skills --skill prd-writerThe PRD Writer skill guides product managers in creating clear, actionable Product Requirements Documents that align teams around feature specifications. It combines user-centered design, technical clarity, and business context to ensure successful implementation.
Feature Name: [Clear, descriptive name]
Owner (PM): [Name]
Stakeholders: [Engineering, Design, Marketing, Legal, etc.]
Status: [Draft, Under Review, Approved, In Development]
Last Updated: [Date]
Vision Statement:
[1-2 sentences describing the big picture)
Example: "Enable users to collaborate on projects in real-time, reducing communication overhead and improving team alignment."
Business Objective:
User Problem Being Solved:
[Describe the pain point this feature addresses]
"Users currently spend 30+ minutes in meetings synchronizing project status manually. This feature enables asynchronous updates, reducing meeting time by 50%."
Success Criteria:
Primary Use Cases:
Use Case 1: Team Real-Time Collaboration
Use Case 2: Asynchronous Status Reporting
Story 1: View Real-Time Updates
As a [project manager]
I want to [see live updates of task status]
So that [I can monitor progress without status meetings]
Acceptance Criteria:
- When a team member updates task status, I see the update within 2 seconds
- Status changes show in the main project view
- Activity timeline shows all updates with timestamps
- Notifications alert me to priority changes
- I can filter updates by assignee or task type
Definition of Done:
- Code reviewed and approved
- Unit tests pass (>80% coverage)
- QA tested on Chrome, Firefox, Safari
- Product Manager has signed off
- Updated help documentation
Story 2: Receive Activity Notifications
As a [team lead]
I want to [control which activities trigger notifications]
So that [I'm not overwhelmed with alerts]
Acceptance Criteria:
- Notification settings are accessible in preferences
- I can enable/disable alerts by activity type
- I can choose delivery method (in-app, email, Slack)
- Settings persist across devices
- Changes apply immediately
Definition of Done:
- Backend stores notification preferences
- Frontend UI implemented and tested
- Email delivery tested
- Slack integration verified
- Analytics event added for tracking
Story 3: Mobile Notification Delivery
As a [remote employee]
I want to [receive notifications on my phone]
So that [I stay informed while away from desk]
Acceptance Criteria:
- Push notifications delivered to iOS and Android apps
- Notifications respect local time zone
- User can tap notification to jump to relevant item
- Notification includes context (project, task, change)
- Deep linking to specific feature works
Definition of Done:
- Push service integrated (Firebase Cloud Messaging)
- iOS and Android implementations complete
- Battery/battery testing on both platforms
- Deep linking tested on Android and iOS
Feature Name: [Name]
Scope: [What's included and explicitly NOT included]
Dependencies: [Features that must exist first]
Data Model Changes: [Database schema updates]
Requirement 1: Real-Time Status Updates
Requirement 2: Activity Feed Display
Requirement 3: Notification Delivery
Technology Stack:
API Endpoints:
POST /api/tasks/{taskId}/status
Updates task status, triggers broadcast
GET /api/projects/{projectId}/activity
Fetches activity feed with pagination
PUT /api/notifications/preferences
Updates user notification settings
POST /api/notifications/subscribe
Subscribes to WebSocket for real-time updates
Database Schema Changes:
CREATE TABLE activity_feeds (
id UUID PRIMARY KEY,
project_id UUID REFERENCES projects(id),
actor_id UUID REFERENCES users(id),
action_type VARCHAR(50), -- task_updated, comment_added, etc.
target_id UUID, -- task, comment, project
target_type VARCHAR(50),
changes JSONB, -- before/after values
created_at TIMESTAMP DEFAULT NOW()
);
CREATE TABLE notification_settings (
id UUID PRIMARY KEY,
user_id UUID REFERENCES users(id),
activity_type VARCHAR(50),
email BOOLEAN DEFAULT true,
in_app BOOLEAN DEFAULT true,
slack BOOLEAN DEFAULT false,
mobile_push BOOLEAN DEFAULT true,
dnd_start TIME,
dnd_end TIME
);
Screen 1: Activity Feed
[Header: "Activity"]
[Filter bar: Activity Type dropdown, Date range picker]
[Activity Item 1]
├─ [Avatar] [Name] [Action] [Context]
├─ [Timestamp] [2 hours ago]
└─ [Details: Task name, Previous → New status]
[Activity Item 2]
...
[Load more button]
Screen 2: Notification Settings Modal
[Header: "Notification Preferences"]
[Tabs: Delivery Methods | Do Not Disturb]
[Activity Type Toggles]
├─ Task Status Updated
│ ├─ ☑ Email ☑ In-app ☑ Mobile Push
│ ├─ Batch these notifications (dropdown: real-time, daily, weekly)
├─ New Comment
│ ├─ ☑ Email ☑ In-app ☑ Mobile Push
├─ Task Assigned to Me
│ ├─ ☑ Email ☑ In-app ☑ Mobile Push
[Save] [Cancel]
RICE Scoring Formula: (Reach × Impact × Confidence) / Effort
Reach (How many users affected in 3-month period)
Impact (How much does this change user outcome)
Confidence (How confident are we in this estimate)
Effort (How many person-weeks to implement)
RICE Calculation Example:
Rice Score = (8000 × 2 × 0.75) / 4 = 3,000
Must Have (Feature shipping incomplete without)
Should Have (Important, ships in first iteration)
Could Have (Nice to have, future iteration)
Won't Have (Explicitly out of scope)
Phase 1: MVP (4 weeks)
Phase 2: Enhancement (3 weeks)
Phase 3: Integration (4 weeks)
Adoption:
Engagement:
Business Impact:
Quality Metrics:
| Risk | Impact | Probability | Mitigation |
|------|--------|-------------|-----------|
| WebSocket scalability issues | High | Medium | Load test with 10K concurrent users before launch |
| Notification fatigue causing opt-outs | High | Medium | Implement smart batching and do-not-disturb by default |
| Mobile app notification permissions | Medium | High | Provide clear education on benefits before permission request |
| Slack integration delays | Low | Medium | Build without Slack first, add as phase 2 |
Take w95/prd-writer 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.