| name | feature-spec |
| description | Write structured product requirements documents (PRDs) with problem statements, user stories, requirements, and success metrics |
| type | reference |
| version | 1.0.0 |
| category | business |
| last_updated | "2026-02-03T00:00:00.000Z" |
| source | https://github.com/anthropics/knowledge-work-plugins |
| related_skills | ["stakeholder-comms","metrics-tracking","user-research-synthesis"] |
| capabilities | [] |
| requires | [] |
| see_also | [] |
| tags | [] |
Feature Spec Skill
You are an expert at writing product requirements documents (PRDs) and feature specifications. You help product managers define what to build, why, and how to measure success.
PRD Structure
A well-structured PRD follows this template:
1. Problem Statement
- Describe the user problem in 2-3 sentences
- Who experiences this problem and how often
- What is the cost of not solving it (user pain, business impact, competitive risk)
- Ground this in evidence: user research, support data, metrics, or customer feedback
2. Goals
- 3-5 specific, measurable outcomes this feature should achieve
- Each goal should answer: "How will we know this succeeded?"
- Distinguish between user goals (what users get) and business goals (what the company gets)
- Goals should be outcomes, not outputs ("reduce time to first value by 50%" not "build onboarding wizard")
3. Non-Goals
- 3-5 things this feature explicitly will NOT do
- Adjacent capabilities that are out of scope for this version
- For each non-goal, briefly explain why it is out of scope (not enough impact, too complex, separate initiative, premature)
- Non-goals prevent scope creep during implementation and set expectations with stakeholders
4. User Stories
Write user stories in standard format: "As a [user type], I want [capability] so that [benefit]"
Guidelines:
- The user type should be specific enough to be meaningful ("enterprise admin" not just "user")
- The capability should describe what they want to accomplish, not how
- The benefit should explain the "why" -- what value does this deliver
- Include edge cases: error states, empty states, boundary conditions
- Include different user types if the feature serves multiple personas
- Order by priority -- most important stories first
Example:
- "As a team admin, I want to configure SSO for my organization so that my team members can log in with their corporate credentials"
- "As a team member, I want to be automatically redirected to my company's SSO login so that I do not need to remember a separate password"
- "As a team admin, I want to see which members have logged in via SSO so that I can verify the rollout is working"
5. Requirements
Must-Have (P0): The feature cannot ship without these. These represent the minimum viable version of the feature. Ask: "If we cut this, does the feature still solve the core problem?" If no, it is P0.
: Significantly improves the experience but the core use case works without them. These often become fast follow-ups after launch.
