Back to Details

dot-ai-prd-create

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

PRD Creation Slash Command

PRD创建Slash命令

Instructions

说明

You are helping create a Product Requirements Document (PRD) for a new feature. This process involves two main components:
  1. GitHub Issue: Short, immutable concept description that links to the detailed PRD
  2. PRD File: Project management document with milestone tracking and implementation plan
您正在协助为新功能创建产品需求文档（PRD）。此流程包含两个核心部分：
  1. GitHub Issue：简短、不可修改的概念描述，链接至详细的PRD
  2. PRD文件：包含里程碑追踪和实施计划的项目管理文档

Process

流程

Step 1: Understand the Feature Concept

步骤1：理解功能概念

Ask the user to describe the feature idea to understand the core concept and scope.
请用户描述功能想法，以明确核心概念和范围。

Step 2: Create GitHub Issue FIRST

步骤2：优先创建GitHub Issue

Create the GitHub issue immediately to get the issue ID. This ID is required for proper PRD file naming.
IMPORTANT: Add the "PRD" label to the issue for discoverability.
立即创建GitHub Issue以获取Issue ID，该ID是PRD文件正确命名的必要条件。
重要提示：为该Issue添加“PRD”标签，以便于查找。

Step 3: Create PRD File with Correct Naming

步骤3：使用正确命名创建PRD文件

Create the PRD file using the actual GitHub issue ID: 
prds/[issue-id]-[feature-name].md
使用实际的GitHub Issue ID创建PRD文件：
prds/[issue-id]-[feature-name].md

Step 4: Update GitHub Issue with PRD Link

步骤4：在GitHub Issue中添加PRD链接

Add the PRD file link to the GitHub issue description now that the filename is known.
在确定文件名后，将PRD文件链接添加至GitHub Issue的描述中。

Step 5: Create PRD as a Project Management Document

步骤5：将PRD创建为项目管理文档

Work through the PRD template focusing on project management, milestone tracking, and implementation planning. Documentation updates should be included as part of the implementation milestones.
Key Principle: Focus on 5-10 major milestones rather than exhaustive task lists. Each milestone should represent meaningful progress that can be clearly validated.
Consider Including (when applicable to the project/feature):
  • Tests - If the project has tests, include a milestone for test coverage of new functionality
  • Documentation - If the feature is user-facing, include a milestone for docs following existing project patterns
Good Milestones Examples:
  • Core functionality implemented and working
  • Tests passing for new functionality (if project has test suite)
  • Documentation complete following existing patterns (if user-facing feature)
  • Integration with existing systems working
  • Feature ready for user testing
Avoid Micro-Tasks:
  • ❌ Update README.md file
  • ❌ Write test for function X
  • ❌ Fix typo in documentation
  • ❌ Individual file modifications
Milestone Characteristics:
  • Meaningful: Represents significant progress toward completion
  • Testable: Clear success criteria that can be validated
  • User-focused: Relates to user value or feature capability
  • Manageable: Can be completed in reasonable timeframe
按照PRD模板完成文档内容，重点关注项目管理、里程碑追踪和实施规划。文档更新应作为实施里程碑的一部分。
核心原则： 聚焦5-10个主要里程碑，而非详尽的任务列表。每个里程碑应代表可清晰验证的实质性进展。
可包含内容（适用于项目/功能时）：
  • 测试 - 如果项目包含测试，需添加新功能测试覆盖的里程碑
  • 文档 - 如果功能面向用户，需添加遵循现有项目规范完成文档的里程碑
优秀里程碑示例：
  • 核心功能已实现并可正常运行
  • 新功能测试全部通过（若项目有测试套件）
  • 文档已按照现有规范完成（若为面向用户的功能）
  • 与现有系统的集成正常运行
  • 功能已准备好进行用户测试
应避免的微任务：
  • ❌ 更新README.md文件
  • ❌ 为函数X编写测试
  • ❌ 修复文档中的拼写错误
  • ❌ 单个文件修改
里程碑特征：
  • 有意义：代表向完成目标推进的实质性进展
  • 可验证：具备清晰的成功验证标准
  • 以用户为中心：与用户价值或功能能力相关
  • 可管理：可在合理时间范围内完成

GitHub Issue Template (Keep Short & Stable)

GitHub Issue模板（保持简短且稳定）

Initial Issue Creation (without PRD link):
markdown
undefined
初始Issue创建（无PRD链接）：
markdown
undefined

PRD: [Feature Name]

PRD: [Feature Name]

Problem: [1-2 sentence problem description]
Solution: [1-2 sentence solution overview]
Detailed PRD: Will be added after PRD file creation
Priority: [High/Medium/Low]

**Don't forget to add the "PRD" label to the issue after creation.**

**Issue Update (after PRD file created):**
```markdown
Problem: [1-2 sentence problem description]
Solution: [1-2 sentence solution overview]
Detailed PRD: Will be added after PRD file creation
Priority: [High/Medium/Low]

**创建Issue后别忘了添加“PRD”标签。**

**Issue更新（PRD文件创建后）：**
```markdown

PRD: [Feature Name]

PRD: [Feature Name]

Problem: [1-2 sentence problem description]
Solution: [1-2 sentence solution overview]
Detailed PRD: See prds/[actual-issue-id]-[feature-name].md
Priority: [High/Medium/Low]
undefined
Problem: [1-2 sentence problem description]
Solution: [1-2 sentence solution overview]
Detailed PRD: See prds/[actual-issue-id]-[feature-name].md
Priority: [High/Medium/Low]
undefined

Discussion Guidelines

讨论指南

PRD Planning Questions

PRD规划问题

  1. Problem Understanding: "What specific problem does this feature solve for users?"
  2. User Impact: "Walk me through the complete user journey — what will change for them?"
  3. Technical Scope: "What are the core technical changes required?"
  4. Documentation Impact: "Which existing docs need updates? What new docs are needed?"
  5. Integration Points: "How does this feature integrate with existing systems?"
  6. Success Criteria: "How will we know this feature is working well?"
  7. Implementation Phases: "How can we deliver value incrementally?"
  8. Risk Assessment: "What are the main risks and how do we mitigate them?"
  9. Dependencies: "What other systems or features does this depend on?"
  10. Validation Strategy: "How will we test and validate the implementation?"
  1. 问题理解：“该功能为用户解决了哪些具体问题？”
  2. 用户影响：“请完整描述用户旅程——用户体验会有哪些变化？”
  3. 技术范围：“需要进行哪些核心技术变更？”
  4. 文档影响：“哪些现有文档需要更新？需要创建哪些新文档？”
  5. 集成点：“该功能如何与现有系统集成？”
  6. 成功标准：“我们如何判断该功能运行良好？”
  7. 实施阶段：“我们如何分阶段交付价值？”
  8. 风险评估：“主要风险有哪些？如何缓解？”
  9. 依赖关系：“该功能依赖哪些其他系统或功能？”
  10. 验证策略：“我们将如何测试和验证实施效果？”

Discussion Tips:

讨论技巧：

  • Clarify ambiguity: If something isn't clear, ask follow-up questions until you understand
  • Challenge assumptions: Help the user think through edge cases, alternatives, and unintended consequences
  • Prioritize ruthlessly: Help distinguish between must-have and nice-to-have based on user impact
  • Think about users: Always bring the conversation back to user value, experience, and outcomes
  • Consider feasibility: While not diving into implementation details, ensure scope is realistic
  • Focus on major milestones: Create 5-10 meaningful milestones rather than exhaustive micro-tasks
  • Think cross-functionally: Consider impact on different teams, systems, and stakeholders
Note: If any 
gh
command fails with "command not found", inform the user that GitHub CLI is required and provide the installation link: https://cli.github.com/
Note: If creating the GitHub issue fails because the "PRD" label does not exist, create the label first (
gh label create "PRD" --description "Product Requirements Document" --color 0052CC
) and then retry creating the issue.
  • 明确模糊点：若有内容不清晰，继续提问直至完全理解
  • 挑战假设：帮助用户思考边缘情况、替代方案和意外后果
  • 严格优先级排序：根据用户影响区分必备功能和锦上添花的功能
  • 以用户为中心：始终将对话拉回到用户价值、体验和结果上
  • 考虑可行性：无需深入实现细节，但要确保范围切实可行
  • 聚焦主要里程碑：创建5-10个有意义的里程碑，而非详尽的微任务
  • 跨职能思考：考虑对不同团队、系统和利益相关者的影响
注意：如果任何
gh
命令执行失败并提示“command not found”，请告知用户需要安装GitHub CLI，并提供安装链接：https://cli.github.com/
注意：如果创建GitHub Issue时因“PRD”标签不存在而失败，请先创建该标签（
gh label create "PRD" --description "Product Requirements Document" --color 0052CC
），然后重试创建Issue。

Workflow

工作流程

  1. Concept Discussion: Get the basic idea and validate the need
  2. Create GitHub Issue FIRST: Short, stable concept description to get issue ID
  3. Create PRD File: Detailed document using actual issue ID: 
    prds/[issue-id]-[feature-name].md
  4. Update GitHub Issue: Add link to PRD file now that filename is known
  5. Section-by-Section Discussion: Work through each template section systematically
  6. Milestone Definition: Define 5-10 major milestones that represent meaningful progress
  7. Review & Validation: Ensure completeness and clarity
CRITICAL: Steps 2-4 must happen in this exact order to avoid the chicken-and-egg problem of needing the issue ID for the filename.
  1. 概念讨论：获取基本想法并验证需求
  2. 优先创建GitHub Issue：简短、稳定的概念描述以获取Issue ID
  3. 创建PRD文件：使用实际Issue ID创建详细文档：
    prds/[issue-id]-[feature-name].md
  4. 更新GitHub Issue：在确定文件名后添加PRD文件链接
  5. 分章节讨论：系统地完成模板的每个章节
  6. 定义里程碑：定义5-10个代表实质性进展的主要里程碑
  7. 审核与验证：确保内容完整且清晰
关键提示：步骤2-4必须严格按此顺序执行，以避免因文件名需要Issue ID而产生的循环依赖问题。

Update ROADMAP.md (If It Exists)

更新ROADMAP.md（若存在）

After creating the PRD, check if 
docs/ROADMAP.md
exists. If it does, add the new feature to the appropriate timeframe section based on PRD priority:
  • High Priority → Short-term section
  • Medium Priority → Medium-term section
  • Low Priority → Long-term section
Format: 
- [Brief feature description] (PRD #[issue-id])
The ROADMAP.md update will be included in the commit at the end of the workflow (Option 2).
创建PRD后，检查是否存在
docs/ROADMAP.md
。若存在，根据PRD优先级将新功能添加至相应时间范围章节：
  • 高优先级 → 短期章节
  • 中优先级 → 中期章节
  • 低优先级 → 长期章节
格式：
- [Brief feature description] (PRD #[issue-id])
ROADMAP.md的更新将包含在工作流程末尾的提交中（选项2）。

Next Steps After PRD Creation

PRD创建后的后续步骤

After completing the PRD, present the user with numbered options:
✅ PRD Created Successfully!

**PRD File**: prds/[issue-id]-[feature-name].md
**GitHub Issue**: #[issue-id]

What would you like to do next?

**1. Start working on this PRD now**
   Begin implementation immediately (recommended if you're ready to start)

**2. Commit and push PRD for later**
   Save the PRD and work on it later (will use [skip ci] flag)

Please enter 1 or 2:
完成PRD创建后，向用户展示以下编号选项：
✅ PRD创建成功！

**PRD文件**：prds/[issue-id]-[feature-name].md
**GitHub Issue**：#[issue-id]

接下来您想执行什么操作？

**1. 立即开始处理该PRD**
   立即启动实施工作（若您已准备好开始，推荐此选项）

**2. 提交并推送PRD供后续处理**
   保存PRD以便后续处理（将使用[skip ci]标识）

请输入1或2：

Option 1: Start Working Now

选项1：立即开始处理

If user chooses option 1, first commit and push the PRD (same as Option 2), then instruct them:
PRD committed and pushed.
To start working on this PRD, run 
/prd-start [issue-id]
若用户选择选项1，先提交并推送PRD（与选项2相同），然后告知用户：
PRD已提交并推送。
要开始处理该PRD，请运行
/prd-start [issue-id]

Option 2: Commit and Push for Later

选项2：提交并推送供后续处理

If user chooses option 2:
bash
undefined
若用户选择选项2：
bash
undefined

Stage the PRD file (and ROADMAP.md if it was updated)

暂存PRD文件（若更新了ROADMAP.md也需包含）

git add prds/[issue-id]-[feature-name].md
git add prds/[issue-id]-[feature-name].md

If docs/ROADMAP.md exists and was updated, include it:

若docs/ROADMAP.md存在且已更新，请添加：

git add docs/ROADMAP.md

git add docs/ROADMAP.md

Commit with skip CI flag to avoid unnecessary CI runs

提交时添加skip CI标识以避免不必要的CI运行

git commit -m "docs(prd-[issue-id]): create PRD #[issue-id] - [feature-name] [skip ci]
  • Created PRD for [brief feature description]
  • Defined [X] major milestones
  • Documented problem, solution, and success criteria
  • Added to ROADMAP.md ([timeframe] section)
  • Ready for implementation"
git commit -m "docs(prd-[issue-id]): create PRD #[issue-id] - [feature-name] [skip ci]
  • Created PRD for [brief feature description]
  • Defined [X] major milestones
  • Documented problem, solution, and success criteria
  • Added to ROADMAP.md ([timeframe] section)
  • Ready for implementation"

Pull latest and push to main

拉取最新代码并推送到主分支

git pull --rebase origin main && git push origin main

**Confirmation Message:**
✅ PRD committed and pushed to main
The PRD is now available in the repository. To start working on it later, execute: prd-start [issue-id]
undefined
git pull --rebase origin main && git push origin main

**确认消息：**
✅ PRD已提交并推送到main分支
PRD现已在仓库中可用。后续要处理该PRD，请执行： prd-start [issue-id]
undefined

Important Notes

重要提示

  • Option 1: Best when you have time to begin implementation immediately
  • Option 2: Best when creating multiple PRDs or planning future work
  • Skip CI flag: Always use 
    [skip ci]
    when committing PRD-only changes
  • Issue reference: Include issue number in commit message for traceability
  • 选项1：适合您有时间立即启动实施工作的场景
  • 选项2：适合创建多个PRD或规划未来工作的场景
  • Skip CI标识：提交仅包含PRD的变更时，务必使用
    [skip ci]
  • Issue引用：提交信息中需包含Issue编号以确保可追溯性