Back to Details

write-a-prd

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
This skill will be invoked when the user wants to create a PRD in ./docs/<feature-name>/PRD.md. 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.
  1. 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>
当用户想要在 ./docs/<feature-name>/PRD.md 路径下创建PRD时，将调用本技能。你可以跳过你认为不必要的步骤。
  1. 请用户详细描述他们想要解决的问题，以及任何可能的解决方案思路。
  2. 调研repo以验证他们的表述，了解代码库的当前状态。
  3. 针对该方案的各个方面对用户进行充分访谈，直到双方达成共识。逐一梳理设计思路的每个分支，逐个解决决策之间的依赖问题。
  4. 勾勒出完成实现所需构建或修改的主要模块。主动寻找机会抽取可独立测试的深度模块（deep module）。
深度模块（与浅模块shallow module相对）指的是在极少变动的简单可测试接口中封装了大量功能的模块。
和用户确认这些模块是否符合他们的预期，同时确认用户希望为哪些模块编写测试。
  1. 当你对问题和解决方案有了完整的理解后，使用下方模板编写PRD。该PRD需要作为GitHub Issue提交。
<prd-template>

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 <actor>, I want a <feature>, so that <benefit>
<user-story-example> 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 </user-story-example>
This list of user stories should be extremely extensive and cover all aspects of the feature.
一份详尽的编号用户故事列表。每条用户故事的格式为：
  1. 作为<角色>，我想要<功能>，以便<获得收益>
<user-story-example> 1. 作为手机银行客户，我想要查看我的账户余额，以便我可以更明智地做出消费决策 </user-story-example>
该用户故事列表需要尽可能全面，覆盖功能的所有方面。

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.
已做出的实现决策列表，可包括：
  • 将要构建/修改的模块
  • 将要修改的模块接口
  • 开发人员提供的技术说明
  • 架构决策
  • Schema变更
  • API契约
  • 具体交互逻辑
请勿包含具体的文件路径或代码片段，这些内容可能很快就会过时。

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.
描述本PRD不涵盖的内容。

Further Notes

其他说明

Any further notes about the feature.
</prd-template>
关于该功能的其他补充说明。
</prd-template>