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.
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:
- 1. As an , I want a , so that
- 1. As a mobile bank customer, I want to see balance on my accounts, so that I can make better informed decisions about my spending
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.
技能名称：撰写产品需求文档
当用户想要创建产品需求文档时，将调用此技能。如果认为某些步骤不必要，可以跳过。
- 1. 请用户提供关于他们想要解决的问题的详细描述，以及任何潜在的解决方案思路。
- 2. 探索代码仓库以验证用户的断言，并了解代码库的当前状态。
- 3. 持续与用户就计划的每个方面进行深入访谈，直到达成共识。逐一梳理设计树的每个分支，逐个解决决策之间的依赖关系。
- 4. 勾勒出为实现目标需要构建或修改的主要模块。积极寻找可提取出能够独立测试的深度模块的机会。
深度模块（相对于浅层模块）是指能够将大量功能封装在简单、可测试且极少变更的接口中的模块。
与用户确认这些模块是否符合他们的预期。与用户确认他们希望为哪些模块编写测试。
- 5. 一旦对问题和解决方案有了全面理解，使用以下模板撰写产品需求文档。产品需求文档应作为 GitHub Issue 提交。
问题陈述
从用户角度出发，描述用户当前面临的问题。
解决方案
从用户角度出发，描述问题的解决方案。
用户故事
一份详尽的、带编号的用户故事列表。每个用户故事应采用以下格式：
- 1. 作为<角色>，我想要<功能>，以便<收益>
<用户故事示例>
- 1. 作为手机银行客户，我想要查看账户余额，以便更明智地做出消费决策
这份用户故事列表应极为详尽，涵盖该功能的各个方面。
实现决策
已做出的实现决策列表。可包括：
- - 将要构建/修改的模块
- 这些模块中将要修改的接口
- 来自开发者的技术澄清
- 架构决策
- 模式变更
- API 契约
- 特定交互
请勿包含具体的文件路径或代码片段，它们可能很快过时。
测试决策
已做出的测试决策列表。包括：
- - 好测试的标准描述（仅测试外部行为，而非实现细节）
- 将要测试的模块
- 测试的既有参考（即代码库中类似类型的测试）
范围外
本产品需求文档中不涉及的内容描述。
补充说明
关于该功能的任何其他说明。
