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. Ask whether they have considered other options, and present other options to them.
  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.
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时，将调用此技能。你需要按照以下步骤操作，若认为某些步骤不必要可跳过。
  1. 请用户详细描述他们想要解决的问题，以及任何潜在的解决方案思路。
  2. 查看代码仓库以验证他们的表述，并了解代码库的当前状态。
  3. 询问用户是否考虑过其他方案，并向他们介绍其他可选方案。
  4. 与用户深入沟通实现细节，务必做到详尽彻底。
  5. 明确界定实现的具体范围。确定在本次PRD中计划构建的内容，以及不计划构建的内容。
  6. 概述完成实现所需构建或修改的主要模块。积极寻找可提取的深度模块，以便进行独立测试。
深度模块（相对于浅度模块）是指通过简单、可测试且极少变更的接口封装大量功能的模块。
与用户确认这些模块是否符合他们的预期，并询问用户希望为哪些模块编写测试。
  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>
此用户故事列表应尽可能全面，覆盖该功能的所有方面。

'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:
  • 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.
列出已做出的实现决策，可包括：
  • 将要构建/修改的模块
  • 将要修改的模块接口
  • 来自开发者的技术说明
  • 架构决策
  • 模式变更
  • 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>