Agent Skills
› mohitagw15856/pm-claude-skills
› prd-template
prd-template
GitHub根据最佳实践生成专业产品需求文档（PRD），涵盖问题陈述、用户故事、功能/非功能需求及技术考量。支持从Brain读取上下文以增强事实依据，并输出结构化文档及关联资产。
Trigger Scenarios
编写PRD
撰写产品规格书
创建功能规范
起草需求文档
Install
npx skills add mohitagw15856/pm-claude-skills --skill prd-template -g -y
SKILL.md
Frontmatter
{
"name": "prd-template",
"description": "Create a Product Requirements Document following proven PM template structure. Use when asked to write a PRD, product spec, feature specification, or requirements document for a new feature or product. Produces a complete PRD with problem statement, user stories, functional requirements, technical considerations, and success metrics."
}
PRD Template Skill
This skill helps create professional Product Requirements Documents following industry best practices.
Required Inputs
Ask the user for these if not provided:
- Feature or product name
- Problem being solved (from the user's perspective)
- Target user (role, context, what they're trying to accomplish)
- Success metrics (how will you know it worked?)
- Scope (MVP vs full vision — what's in and out of scope)
- Key stakeholders (who needs to review and approve)
Reads from / Writes to the Brain
If a professional-brain (brain/) exists, use it instead of asking for context you already have:
- Read first:
context.md(product, metrics definitions, voice),knowledge/strategy.md(where the product is going), any relatedhypotheses/and the matchingentities/feature file. Runpython3 ../professional-brain/scripts/brain_query.py ./brain "<feature>"to pull grounded facts, and carry their provenance tags into the PRD (don't present a[hunch]as a settled requirement). - Write after: save the feature as/into
entities/<feature>.md, log any scoping decision todecisions/, and add new assumptions tohypotheses/. Tag each with its provenance.
Deeper Materials
This skill ships with two support files — use them when they're available:
templates/prd-skeleton.md— a fill-in PRD skeleton with a "what good looks like" hint per section. Start from it when the user wants a document to complete themselves rather than a generated draft.references/success-metrics-guide.md— calibration for the Success Metrics section: the four-part metric test, the standard adoption/outcome/business/guardrail set, and the common traps. Consult it whenever writing or reviewing the metrics table.
Template Structure
Every PRD should include these sections in order:
1. Overview
- Problem Statement: What problem are we solving? (2-3 sentences)
- Proposed Solution: High-level description of what we're building (2-3 sentences)
- Success Metrics: How we'll measure success (3-5 key metrics)
2. Context & Background
- Why Now: Why is this the right time?
- Strategic Alignment: How does this align with company objectives?
- User Research Summary: Key insights from research (if applicable)
3. User Stories & Use Cases
Format: "As a [user type], I want to [action] so that [benefit]"
- Include 3-7 primary user stories
- Add acceptance criteria for each
4. Requirements
Functional Requirements:
- Must-have features (P0)
- Should-have features (P1)
- Nice-to-have features (P2)
Non-Functional Requirements:
- Performance expectations
- Security considerations
- Accessibility requirements
5. Design & User Experience
- Link to design mocks or wireframes
- Key user flows
- Edge cases and error states
6. Technical Considerations
- Architecture implications
- Dependencies on other systems
- Technical risks and mitigations
7. Implementation Plan
- Phase 1 (MVP): What goes in first version
- Phase 2: What comes next
- Phase 3: Future enhancements
8. Open Questions
- Decisions that still need to be made
- Stakeholders to consult
- Research needed
9. Appendix
- Research links
- Related documents
- Competitive analysis
Writing Guidelines
Tone: Clear, concise, actionable Audience: Engineers, designers, stakeholders Length: Aim for 3-6 pages for features, 8-12 for products
Best Practices:
- Use concrete examples over abstractions
- Include "why" not just "what"
- Make requirements testable
- Link to supporting materials
- Update as decisions are made
What Makes a Good PRD
✅ Do:
- Write from the user's perspective
- Include specific success metrics
- Address edge cases
- Link to research and data
- Make trade-offs explicit
❌ Don't:
- Write implementation details (that's tech spec)
- Assume everyone has context
- Leave requirements ambiguous
- Skip the "why"
- Forget about accessibility
Quality Checks
- Problem statement is written from the user's perspective (not the company's)
- Success metrics are specific and measurable
- User stories include acceptance criteria
- Requirements are testable (not vague)
- Open questions are listed explicitly
- Implementation plan distinguishes MVP from future phases
Anti-Patterns
- Do not write requirements from the company's perspective — every requirement must trace back to a user need
- Do not include vague requirements like "the system should be fast" — every requirement must be testable
- Do not conflate MVP with future phases — be explicit about what is and is not in scope for the first release
- Do not leave success metrics as percentages without baselines — specify the current state and the target
- Do not skip open questions — unresolved assumptions are risks; surfacing them is the PM's job
Example PRD Opening
# PRD: Multi-Channel Customer Support Dashboard
## Overview
**Problem Statement**: Support teams are currently managing customer inquiries across email, chat, and social media using three separate tools, leading to delayed responses, duplicated work, and inconsistent customer experiences. On average, support agents waste 2.3 hours per day switching between tools and manually tracking conversation history.
**Proposed Solution**: Build a unified dashboard that aggregates customer inquiries from all channels into a single interface, maintains conversation history across channels, and provides intelligent routing based on agent expertise and availability.
**Success Metrics**:
- Reduce average response time from 4 hours to 1 hour
- Decrease tool-switching time by 80% (from 2.3 to <0.5 hours)
- Improve customer satisfaction score from 3.8 to 4.5 (out of 5)
- Increase support agent productivity by 35%
## Context & Background
**Why Now**: Customer satisfaction has declined 15% over the past 6 months, primarily due to slow response times. Our top competitor launched a unified support dashboard last quarter, and we're hearing about it in sales calls. Support team turnover is at 45% annually, with "tool complexity" cited as a top frustration.
**Strategic Alignment**: This aligns with our Q1 company objective to "Improve customer retention by 10%" and our support team's OKR to "Reduce average handle time by 25%."
**User Research Summary**: We conducted interviews with 12 support agents and observed 20 hours of support sessions. Key findings:
- Agents spend 35% of their time finding context from previous interactions
- 65% of escalations are due to lack of conversation history
- Agents rated tool-switching as their #1 daily frustration (9.2/10 pain)
- Current NPS for support experience is -12
## User Stories & Use Cases
**US1: Unified Inbox**
As a support agent, I want to see all customer inquiries in one place so that I don't miss urgent requests and can prioritize effectively.
Acceptance Criteria:
- Inbox shows inquiries from email, chat, and social media
- Inquiries are sorted by priority (urgent, high, normal, low)
- Agent can filter by channel, customer, or status
- Real-time updates when new inquiries arrive
**US2: Cross-Channel Context**
As a support agent, I want to see the full conversation history regardless of channel so that I can provide consistent, informed responses without asking customers to repeat themselves.
Acceptance Criteria:
- Timeline view shows all interactions chronologically
- Each interaction displays channel, timestamp, and content
- Customer profile shows demographics and account information
- Previous issues and resolutions are accessible
[Continue with 5-7 total user stories...]
Version History
- a38bc30 Current 2026-07-05 11:19
