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. 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. 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>
当用户想要创建PRD时，将调用此skill。你需要遵循以下步骤，若认为某些步骤不必要可跳过。
  1. 请用户详细描述他们想要解决的问题，以及任何潜在的解决方案思路。
  2. 查看代码仓库以验证他们的表述，并了解代码库的当前状态。
  3. 针对该计划的各个方面对用户进行全面沟通，直至达成共识。梳理设计树的每个分支，逐一解决决策之间的依赖关系。
  4. 草拟完成实现所需构建或修改的主要模块。积极寻找可提取的深度模块，以便进行独立测试。
深度模块（与浅模块相对）是指通过简单、可测试且极少变更的接口封装大量功能的模块。
与用户确认这些模块是否符合他们的预期。询问用户希望为哪些模块编写测试。
  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>