write-a-prd
Generates professional PRDs by interviewing users and analyzing existing architecture.
Install
mkdir -p .claude/skills/write-a-prd && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/12862" && unzip -o skill.zip -d .claude/skills/write-a-prd && rm skill.zipInstalls to .claude/skills/write-a-prd
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Create a PRD through user interview, codebase exploration, and module design. Use when user wants to write a PRD, create a product requirements document, or plan a new feature.Key capabilities
- →Ask user for problem description and ideas
- →Explore repository to verify assertions
- →Interview user to reach shared understanding
- →Sketch major modules for implementation
- →Write problem statement
- →Create numbered list of user stories
How it works
This skill creates a PRD by interviewing the user, exploring the codebase, designing modules, and then populating a template with problem statements, solutions, user stories, and implementation decisions.
Inputs & outputs
When to use write-a-prd
- →Plan a new feature
- →Draft product requirements
- →Define user stories
- →Explore architectural needs
About this skill
This skill will be invoked when the user wants to create a PRD. You may skip steps if you don't consider them necessary.
- Ask the user for a long, detailed description of the problem they want to solve and any potential ideas for solutions.
- Explore the repo to verify their assertions and understand the current state of the codebase.
- Interview the user relentlessly about every aspect of this plan until you reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one.
- Sketch out the major modules you will need to build or modify to complete the implementation. Actively look for opportunities to extract deep modules that can be tested in isolation.
A deep module (as opposed to a shallow module) is one which encapsulates a lot of functionality in a simple, testable interface which rarely changes.
Check with the user that these modules match their expectations. Check with the user which modules they want tests written for.
- Once you have a complete understanding of the problem and solution, use the template below to write the PRD.
Problem Statement
The problem that the user is facing, from the user's perspective.
Solution
The solution to the problem, from the user's perspective.
User Stories
A LONG, numbered list of user stories. Each user story should be in the format of:
- As an
<actor>, I want a<feature>, so that<benefit>
This list of user stories should be extremely extensive and cover all aspects of the feature.
Implementation Decisions
A list of implementation decisions that were made. This can include:
- The modules that will be built/modified
- The interfaces of those modules that will be modified
- Technical clarifications from the developer
- Architectural decisions
- Schema changes
- API contracts
- Specific interactions
Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.
Testing Decisions
A list of testing decisions that were made. Include:
- A description of what makes a good test (only test external behavior, not implementation details)
- Which modules will be tested
- Prior art for the tests (i.e. similar types of tests in the codebase)
Out of Scope
A description of the things that are out of scope for this PRD.
Further Notes
Any further notes about the feature.
</prd-template>When not to use it
- →When not creating a Product Requirements Document
- →When not planning a new feature
- →When not needing module design
Limitations
- →Does not include specific file paths in implementation decisions
- →Does not include code snippets in implementation decisions
- →Requires extensive user stories
How it compares
This workflow integrates user interviews and codebase exploration directly into the PRD creation process, ensuring alignment and technical feasibility, unlike simply filling out a template.
Compared to similar skills
write-a-prd side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| write-a-prd (this skill) | 0 | 4mo | No flags | Advanced |
| internal-comms | 8 | 3mo | No flags | Beginner |
| startup-business-analyst-business-case | 6 | 4mo | No flags | Beginner |
| getting-started-guide | 1 | 8mo | No flags | Beginner |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
internal-comms
anthropics
A set of resources to help me write all kinds of internal communications, using the formats that my company likes to use. Claude should use this skill whenever asked to write some sort of internal communications (status reports, leadership updates, 3P updates, company newsletters, FAQs, incident reports, project updates, etc.).
startup-business-analyst-business-case
sickn33
Generate comprehensive investor-ready business case document with market, solution, financials, and strategy
getting-started-guide
Microck
当用户开始新小说项目时激活 - 通过温和的提示和解释引导他们完成七步方法论（constitution → specify → clarify → plan → tasks → write → analyze）
content-creation-flow
OutSystems
Step-by-step content creation workflow for documentation and training materials. Includes MCP validation, discovery, content design, Jira planning, and draft generation with priority-based execution. Use when starting the content creation flow, creating documentation or training materials, or when t
project-proposals
SofiaDT
When the user wants to write a project proposal, business case, project charter, or project brief to get something approved. Use when the user says "I need to write a proposal," "business case," "project charter," "getting this approved," "I need to make the case for this project," or "project brief
identify-kill-list
lyndonkl
Names what the substacker writer should stop doing — habits with no evidence of use, goals that became theatre, sections with 2 consecutive dormant quarters, and agents in the team whose output the writer ignores. Produces a bulleted list, each item with one sentence of why. Max 4 items. Ordered by