81 lines
3.2 KiB
Markdown
81 lines
3.2 KiB
Markdown
---
|
|
name: write-a-prd
|
|
description: Create a PRD through user interviews, codebase exploration, and module design, then submit it as a GitHub issue. Use this when the user wants to write a PRD, create product requirement documents, or plan a new feature.
|
|
---
|
|
|
|
This skill will be invoked when the user wants to create a PRD. You may skip steps if you don't consider them necessary.
|
|
|
|
1. Ask the user for a long, detailed description of the problem they want to solve and any potential ideas for solutions.
|
|
|
|
2. Explore the repo to verify their assertions and understand the current state of the codebase.
|
|
|
|
3. 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.
|
|
|
|
4. 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.
|
|
|
|
5. Once you have a complete understanding of the problem and solution, use the template below to write the PRD. The PRD should be submitted as a GitHub issue.
|
|
|
|
**Announce at start:** "I'm using the write-a-prd skill to create the implementation plan."
|
|
|
|
**Context:** This should be run in a dedicated worktree (created by brainstorming skill).
|
|
|
|
**Save plans to:** `docs/prd/{date}-{feature}.md`
|
|
- (User preferences for plan location override this default)
|
|
|
|
<prd-template>
|
|
|
|
## Problem Statement
|
|
|
|
From the user's perspective, the problem the user is currently facing.
|
|
|
|
## Solution
|
|
|
|
From the user's perspective, the solution to the problem.
|
|
|
|
## User Stories
|
|
|
|
A detailed, numbered list of user stories. Each user story should follow this format:
|
|
|
|
1. As a <role>, I want to <feature>, so that I can <benefit>
|
|
|
|
<user-story-example>
|
|
1. As a mobile banking customer, I want to see my account balance, so that I can make more informed decisions about my spending.
|
|
</user-story-example>
|
|
|
|
This list of user stories should be very detailed, covering all aspects of the functionality.
|
|
|
|
## Implementation Decisions
|
|
|
|
A list of implementation decisions that have been made. May include:
|
|
|
|
- Modules to be created/modified
|
|
- Module interfaces to be modified
|
|
- Technical clarifications for developers
|
|
- Architecture decisions
|
|
- Schema changes
|
|
- API contracts
|
|
- Specific interaction logic
|
|
|
|
Please do not include specific file paths or code snippets, as they may quickly go out of date.
|
|
|
|
## Testing Decisions
|
|
|
|
A list of testing decisions that have been made. Includes:
|
|
|
|
- A description of what makes a good test (testing external behavior only, not implementation details)
|
|
- Which modules will be tested
|
|
- Reference cases for tests (i.e. similar types of tests in the codebase)
|
|
|
|
## Out of Scope
|
|
|
|
Describe things that are outside the scope of this PRD.
|
|
|
|
## Further Notes
|
|
|
|
Any other notes regarding this feature.
|
|
|
|
</prd-template> |