mirror of
https://github.com/mattpocock/skills.git
synced 2026-04-30 22:13:54 +07:00
Updates
This commit is contained in:
+3
-20
@@ -1,27 +1,18 @@
|
||||
---
|
||||
name: write-a-prd
|
||||
description: Use this skill when writing a PRD for a feature.
|
||||
---
|
||||
|
||||
This skill will be invoked when the user wants to create a PRD. You should go through the steps below. 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. Ask whether they have considered other options, and present other options to them.
|
||||
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. Interview the user about the implementation. Be extremely detailed and thorough.
|
||||
|
||||
5. Hammer out the exact scope of the implementation. Work out what you plan to build and what you DON'T plan to build as part of this PRD.
|
||||
|
||||
6. 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.
|
||||
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.
|
||||
|
||||
7. 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.
|
||||
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.
|
||||
|
||||
<prd-template>
|
||||
|
||||
@@ -45,14 +36,6 @@ A LONG, numbered list of user stories. Each user story should be in the format o
|
||||
|
||||
This list of user stories should be extremely extensive and cover all aspects of the feature.
|
||||
|
||||
## 'Polishing' Requirements
|
||||
|
||||
Once the user stories are complete, we will end up with a working, but not refined, feature or application. After the work is complete, we should enter a polishing phase.
|
||||
|
||||
This should be a list of checks that we want to make at the end of the work to polish and refine the work done for maximum user enjoyment and experience.
|
||||
|
||||
They should not meaningfully extend the work but instead ensure harmony of all created elements and ensure any errors are properly handled and make things delightful and beautiful.
|
||||
|
||||
## Implementation Decisions
|
||||
|
||||
A list of implementation decisions that were made. This can include:
|
||||
|
||||
Reference in New Issue
Block a user