dot-ai-prd-done

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Complete PRD Implementation

完整的PRD实施

Complete the PRD implementation workflow including branch management, pull request creation, and issue closure.

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/

完成PRD实施工作流，包括分支管理、Pull Request创建及议题关闭。

注意：如果任何

gh

命令执行失败并提示"command not found"，请告知用户需要安装GitHub CLI，并提供安装链接：https://cli.github.com/

Workflow Steps

工作流步骤

0. Implementation Type Detection

0. 实施类型检测

FIRST: Determine the type of PRD completion to choose the appropriate workflow

Documentation-Only Completion (Skip PR workflow):

✅ Changes are only to PRD files or project management documents
✅ No source code changes
✅ No configuration changes
✅ Feature was already implemented in previous work
→ Use Simplified Workflow (Steps 1, 2-simplified, 5 only)

Code Implementation Completion (Full PR workflow):

✅ Contains source code changes
✅ Contains configuration changes
✅ Contains new functionality or modifications
✅ Requires testing and integration
→ Use Full Workflow (Steps 1-6)

第一步：确定PRD完成的类型，以选择合适的工作流

仅文档类完成（跳过PR工作流）：

✅ 仅修改PRD文件或项目管理文档
✅ 无源代码变更
✅ 无配置变更
✅ 功能已在之前的工作中实现
→ 使用简化工作流（仅执行步骤1、简化版步骤2、步骤5）

代码实现类完成（完整PR工作流）：

✅ 包含源代码变更
✅ 包含配置变更
✅ 包含新功能或功能修改
✅ 需要测试与集成
→ 使用完整工作流（执行步骤1-6）

1. Pre-Completion Validation

1. 完成前验证

All PRD checkboxes completed: Verify every requirement is implemented and tested
Documentation updated: All user-facing docs reflect implemented functionality
No outstanding blockers: All dependencies resolved and technical debt addressed
Update PRD status: Mark PRD as "Complete" with completion date
Archive PRD file: Move completed PRD to
```
./prds/done/
```
directory to maintain project organization
Update ROADMAP.md (if it exists): Remove the completed feature from
```
docs/ROADMAP.md
```
roadmap if the file exists

Note: Tests will run automatically in the CI/CD pipeline when the PR is created. Do not run tests locally during the completion workflow.

所有PRD复选框已完成：验证所有需求均已实现并测试
文档已更新：所有面向用户的文档均已反映已实现的功能
无未解决的阻塞项：所有依赖已解决，技术债务已处理
更新PRD状态：将PRD标记为“已完成”并填写完成日期
归档PRD文件：将已完成的PRD移动到
```
./prds/done/
```
目录，以保持项目结构清晰
更新ROADMAP.md（若存在）：如果
```
docs/ROADMAP.md
```
文件存在，从中移除已完成的功能

注意：当PR创建后，测试将在CI/CD流水线中自动运行。在完成工作流期间无需本地运行测试。

2. Branch and Commit Management

2. 分支与提交管理

For Documentation-Only Completions:

Commit directly to main:
```
git add [prd-files]
```
and commit with skip CI flag
Use skip CI commit message: Include CI skip pattern in commit message to avoid unnecessary CI runs
- Common patterns:
```
[skip ci]
```
  ,
```
[ci skip]
```
  ,
```
***NO_CI***
```
  ,
```
[skip actions]
```
- Check project's CI configuration for the correct pattern

Push to remote:

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

to sync changes

For Code Implementation Completions:

Create feature branch:

git checkout -b feature/prd-[issue-id]-[feature-name]

Commit all changes: Ensure all implementation work is committed
Clean commit history: Squash or organize commits for clear history

Push to remote:

git push -u origin feature/prd-[issue-id]-[feature-name]

仅文档类完成的操作：

直接提交到main分支：执行
```
git add [prd-files]
```
并添加跳过CI的标记进行提交
使用跳过CI的提交信息：在提交信息中包含CI跳过标识，以避免不必要的CI运行
- 常见标识：
```
[skip ci]
```
  ,
```
[ci skip]
```
  ,
```
***NO_CI***
```
  ,
```
[skip actions]
```
- 请查看项目的CI配置以确认正确的标识格式

推送到远程仓库：执行

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

以同步变更

代码实现类完成的操作：

创建功能分支：执行

git checkout -b feature/prd-[issue-id]-[feature-name]

提交所有变更：确保所有实现工作均已提交
清理提交历史：合并或整理提交记录，保持历史清晰

推送到远程仓库：执行

git push -u origin feature/prd-[issue-id]-[feature-name]

3. Pull Request Creation

3. Pull Request创建

IMPORTANT: Always check for and use PR template if available

重要提示：请始终检查并使用可用的PR模板

3.1. PR Template Detection and Parsing

3.1. PR模板检测与解析

Check for PR template in common locations:

```
.github/PULL_REQUEST_TEMPLATE.md
```
```
.github/pull_request_template.md
```
```
.github/PULL_REQUEST_TEMPLATE/
```
(directory with multiple templates)
```
docs/pull_request_template.md
```

Read and parse template comprehensively: If found, analyze the template to extract:
- Structural elements: Required sections, checklists, format requirements
- Content requirements: What information needs to be provided in each section
- Process instructions: Any workflow enhancements or prerequisites specified in the template
- Validation requirements: Any checks, sign-offs, or verifications mentioned
Extract actionable instructions from template:
- Commit requirements: Look for DCO sign-off, commit message format, commit signing requirements
- Pre-submission actions: Build commands, test commands, linting, format checks
- Documentation requirements: Which docs must be updated, links that must be added
- Review requirements: Required reviewers, approval processes, special considerations
Examples of template instructions to identify and execute:
- "All commits must include a
```
Signed-off-by
```
  line" → Validate commits have DCO sign-off, amend if missing
- "Run
```
npm test
```
  before submitting" → Execute test command
- "PR title follows Conventional Commits format" → Validate title format
- "Update CHANGELOG.md" → Check if changelog was updated
- Any bash commands shown in code blocks → Consider if they should be executed

检查PR模板的常见位置：

```
.github/PULL_REQUEST_TEMPLATE.md
```
```
.github/pull_request_template.md
```
```
.github/PULL_REQUEST_TEMPLATE/
```
（包含多个模板的目录）
```
docs/pull_request_template.md
```

全面读取并解析模板：如果找到模板，分析模板以提取：
- 结构元素：必填章节、复选框、格式要求
- 内容要求：每个章节需要提供的信息
- 流程说明：模板中指定的任何工作流增强项或前置条件
- 验证要求：提到的任何检查、签字确认或验证步骤
从模板中提取可执行的指令：
- 提交要求：查找DCO签字、提交信息格式、提交签名要求
- 提交前操作：构建命令、测试命令、代码检查、格式校验
- 文档要求：必须更新的文档、必须添加的链接
- 评审要求：必填评审人、审批流程、特殊注意事项
需要识别并执行的模板指令示例：
- "所有提交必须包含
```
Signed-off-by
```
  行" → 验证提交是否有DCO签字，若缺失则补充
- "提交前请运行
```
npm test
```
  " → 执行测试命令
- "PR标题需遵循Conventional Commits格式" → 验证标题格式
- "更新CHANGELOG.md" → 检查是否已更新变更日志
- 代码块中的任何bash命令 → 考虑是否需要执行

3.2. Analyze Changes for PR Content

3.2. 分析变更以准备PR内容

Review git diff: Analyze
```
git diff main...HEAD
```
to understand scope of changes
Review commit history: Use
```
git log main..HEAD
```
to understand implementation progression
Identify change types: Determine if changes include:
- New features, bug fixes, refactoring, documentation, tests, configuration, dependencies
- Breaking changes or backward-compatible changes
- Performance improvements or security fixes
Check modified files: Identify which areas of codebase were affected
- Source code files
- Test files
- Documentation files
- Configuration files

查看git diff：分析
```
git diff main...HEAD
```
以了解变更范围
查看提交历史：使用
```
git log main..HEAD
```
以了解实现过程
识别变更类型：确定变更是否包括：
- 新功能、Bug修复、代码重构、文档更新、测试、配置变更、依赖更新
- 破坏性变更或向后兼容的变更
- 性能优化或安全修复
检查修改的文件：识别代码库中受影响的区域
- 源代码文件
- 测试文件
- 文档文件
- 配置文件

3.3. Auto-Fill PR Information

3.3. 自动填充PR信息

Automatically populate what can be deduced from analysis:

PR Title:
- Follow template title format if specified (e.g., Conventional Commits:
```
feat(scope): description
```
  )
- Extract from PRD title/description and commit messages
- Include issue reference if required by template
Description sections:
- What/Why: Extract from PRD objectives and implementation details
- Related issues: Automatically link using
```
Closes #[issue-id]
```
  or
```
Fixes #[issue-id]
```
- Type of change: Check appropriate boxes based on file analysis
Testing checklist:
- Mark "Tests added/updated" if test files were modified
- Note: Tests run in CI/CD automatically
Documentation checklist:
- Mark items based on which docs were updated (README, API docs, code comments)
- Check if CONTRIBUTING.md guidelines followed
Security checklist:
- Scan commits for potential secrets or credentials
- Flag if authentication/authorization code changed
- Note any dependency updates

根据分析自动填充可推导的信息：

PR标题：
- 若模板指定了标题格式，则遵循该格式（例如Conventional Commits：
```
feat(scope): description
```
  ）
- 从PRD标题/描述及提交信息中提取内容
- 若模板要求，包含议题引用
描述章节：
- 内容/原因：从PRD目标及实现细节中提取
- 相关议题：使用
```
Closes #[issue-id]
```
  或
```
Fixes #[issue-id]
```
  自动关联
- 变更类型：根据文件分析勾选相应的选项
测试复选框：
- 若测试文件已修改，则标记“测试已添加/更新”
- 注意：测试将在CI/CD中自动运行
文档复选框：
- 根据已更新的文档（README、API文档、代码注释）标记相应项
- 检查是否遵循了CONTRIBUTING.md的指南
安全复选框：
- 扫描提交记录以查找潜在的密钥或凭证
- 若认证/授权代码有变更，则标记
- 记录任何依赖更新

3.4. Prompt User for Information That Cannot Be Deduced

3.4. 提示用户提供无法推导的信息

IMPORTANT: Don't just ask - analyze and propose answers, then let user confirm or correct

For each item, use available context to propose an answer, then present it to the user for confirmation:

Manual testing results:
- Analyze PRD testing strategy section to understand what testing was planned
- Check git commits for testing-related messages
- Propose testing approach based on change type (e.g., "Documentation reviewed for accuracy and clarity, cross-references validated")
- Present proposal and ask: "Is this accurate, or would you like to modify?"
Breaking changes:
- Scan commits and PRD for breaking change indicators
- If detected, propose migration guidance based on PRD content
- If not detected, confirm: "No breaking changes detected. Correct?"
Performance implications:
- Analyze change type: Documentation/config changes typically have no performance impact
- Propose answer based on analysis (e.g., "No performance impact - documentation only")
- Ask: "Correct, or are there performance considerations?"
Security considerations:
- Check if security-sensitive files were modified (auth, credentials, API keys)
- Scan commits for security-related keywords
- Propose security status (e.g., "No security implications - documentation changes only")
- Ask: "Accurate, or are there security considerations to document?"
Reviewer focus areas:
- Analyze PRD objectives and git changes to identify key areas
- Propose specific focus areas (e.g., "Verify documentation accuracy, check cross-reference links, confirm workflow examples match implementation")
- Present list and ask: "Are these the right focus areas, or should I adjust?"
Follow-up work:
- Check PRD for "Future Enhancements" or "Out of Scope" sections
- Analyze other PRDs in
```
prds/
```
  directory for related work
- Propose follow-up items if any (e.g., "Future enhancements listed in PRD: template validation, AI-powered descriptions")
- Ask: "Should I list these, or is there other follow-up work?"
Additional context:
- Review PRD for special considerations
- Check if this is a dogfooding/testing PR
- Propose any relevant context (e.g., "This PR itself tests the enhanced workflow it documents")
- Ask: "Anything else reviewers should know?"

Presentation Format: Present all proposed answers together in a summary format:

markdown

📋 **Proposed PR Information** (based on analysis)

**Manual Testing:** [proposed answer]
**Breaking Changes:** [proposed answer]
**Performance Impact:** [proposed answer]
**Security Considerations:** [proposed answer]
**Reviewer Focus:** [proposed list]
**Follow-up Work:** [proposed items or "None"]
**Additional Context:** [proposed context or "None"]

Please review and respond:
- Type "yes" or "confirm" to accept all
- Specify corrections for any items that need changes

重要提示：不要直接提问 - 先分析并提出建议，再让用户确认或修改

对于每一项，使用可用上下文提出建议答案，然后呈现给用户确认：

手动测试结果：
- 分析PRD的测试策略章节以了解计划的测试内容
- 检查git提交记录以查找测试相关的信息
- 根据变更类型提出测试方法（例如：“已审核文档的准确性与清晰度，验证了交叉引用链接”）
- 呈现建议并询问：“此内容是否准确，或需要修改？”
破坏性变更：
- 扫描提交记录和PRD以查找破坏性变更的迹象
- 若检测到，根据PRD内容提出迁移指南
- 若未检测到，确认：“未检测到破坏性变更，是否正确？”
性能影响：
- 分析变更类型：文档/配置变更通常无性能影响
- 根据分析提出答案（例如：“无性能影响 - 仅文档变更”）
- 询问：“是否正确，或存在性能方面的考虑？”
安全考虑：
- 检查是否修改了安全敏感文件（认证、凭证、API密钥相关）
- 扫描提交记录以查找安全相关的关键词
- 提出安全状态（例如：“无安全影响 - 仅文档变更”）
- 询问：“是否准确，或存在需要记录的安全考虑？”
评审人关注点：
- 分析PRD目标和git变更以确定关键区域
- 提出具体的关注点（例如：“验证文档准确性，检查交叉引用链接，确认工作流示例与实现一致”）
- 呈现列表并询问：“这些是正确的关注点吗，或需要调整？”
后续工作：
- 检查PRD中的“未来增强”或“范围外”章节
- 分析
  prds/
  目录中的其他PRD以查找相关工作
- 若有相关项，提出后续工作建议（例如：“PRD中列出的未来增强：模板验证、AI驱动的描述生成”）
- 询问：“是否需要列出这些，或存在其他后续工作？”
额外上下文：
- 查看PRD中的特殊注意事项
- 检查是否为内部测试/试用PR
- 提出相关上下文（例如：“此PR本身测试了其文档中描述的增强工作流”）
- 询问：“评审人还需要了解其他信息吗？”

呈现格式：将所有建议答案汇总成摘要格式呈现：

markdown

📋 **建议的PR信息**（基于分析结果）

**手动测试**：[建议答案]
**破坏性变更**：[建议答案]
**性能影响**：[建议答案]
**安全考虑**：[建议答案]
**评审人关注点**：[建议列表]
**后续工作**：[建议项或“无”]
**额外上下文**：[建议上下文或“无”]

请审阅并回复：
- 输入“yes”或“confirm”以接受所有内容
- 针对需要修改的项指定具体的更正内容

3.5. Execute Template Requirements

3.5. 执行模板要求

IMPORTANT: Before creating the PR, identify and execute any actionable requirements from the template

Analyze template for actionable instructions:
- Scan template content for imperative statements, requirements, or commands
- Look for patterns like "must", "should", "run", "execute", "ensure", "verify"
- Identify bash commands in code blocks that appear to be prerequisites
- Extract any validation requirements mentioned in checklists
Categorize identified requirements:
- Commit-level actions: Sign-offs, formatting, validation
- Pre-submission commands: Tests, builds, lints, format checks
- Validation checks: File existence, format compliance, content requirements
- Documentation actions: Required updates, links to add
Propose and execute requirements:
- Present identified requirements to user: "Template specifies these actions: [list]"
- For each requirement, determine if it can be automated
- Propose execution: "Should I execute these now?"
- Execute confirmed actions and report results
- Handle failures gracefully and ask user how to proceed

Summary before PR creation:

markdown

✅ Template Requirements Status:
[List each requirement with status: executed/validated/skipped/failed]

Ready to create PR? (yes/no)

重要提示：创建PR前，请识别并执行模板中的所有可执行要求

分析模板中的可执行指令：
- 扫描模板内容以查找命令式语句、要求或命令
- 查找类似“必须”、“应该”、“运行”、“执行”、“确保”、“验证”等关键词
- 识别代码块中作为前置条件的bash命令
- 提取复选框中提到的任何验证要求
对识别的要求进行分类：
- 提交级操作：签字、格式、验证
- 提交前命令：测试、构建、代码检查、格式校验
- 验证检查：文件存在性、格式合规性、内容要求
- 文档操作：必填更新、需添加的链接
提出并执行要求：
- 向用户呈现识别的要求：“模板指定了以下操作：[列表]”
- 对于每项要求，确定是否可自动化执行
- 提出执行请求：“是否需要现在执行这些操作？”
- 执行已确认的操作并报告结果
- 若执行失败，友好处理并询问用户如何继续

创建PR前的摘要：

markdown

✅ 模板要求执行状态：
[列出每项要求及其状态：已执行/已验证/已跳过/执行失败]

是否准备好创建PR？（是/否）

3.6. Detect and Apply PR Label (if release.yml exists)

3.6. 检测并应用PR标签（若release.yml存在）

IMPORTANT: Only apply labels if
.github/release.yml
exists - fully dynamic based on that file

Check for
.github/release.yml
:
- If file exists → Proceed with label detection
- If file doesn't exist → Skip label detection, proceed to create PR without labels
If release.yml exists, parse it to understand available categories and labels:
- Read the YAML file
- Extract all category definitions with their associated labels
- Build a mapping of: category → list of labels
- Note the category order (categories listed first are typically more important)
Analyze PR characteristics:
- Primary change type: What is the MAIN purpose of this PR?
- File changes: Types of files modified (extensions, paths, purposes)
- Change scope: Which areas of codebase affected
- Commit messages: Keywords, patterns, prefixes
- PR title and description: Keywords indicating change type
- PRD context: Original problem/solution description
Select the SINGLE best-matching label:
- For each category in release.yml, score how well it matches the PR's PRIMARY purpose
- Consider the importance hierarchy from release.yml:
  - Breaking changes > New features > Bug fixes > Documentation > Dependencies > Other
- Select ONE label from the category that BEST represents the main change
- Why single label?: Prevents PRs from appearing in multiple release note categories
- Selection priority:
  1. If any breaking changes → use
```
breaking-change
```
    or
```
breaking
```
  2. If primarily new functionality → use
```
feat
```
    ,
```
feature
```
    , or
```
enhancement
```
  3. If primarily fixing bugs → use
```
fix
```
    ,
```
bug
```
    , or
```
bugfix
```
  4. If primarily documentation → use
```
documentation
```
    or
```
docs
```
  5. If primarily dependencies → use
```
dependencies
```
    ,
```
deps
```
    , or
```
dependency
```
  6. Otherwise → no specific label needed (will appear in "Other Changes")
Apply detected label: Add the single best-matching label to the PR creation command
- Example:
```
gh pr create --title "..." --body "..." --label "fix"
```

重要提示：仅当
.github/release.yml
存在时才应用标签 - 完全基于该文件动态处理

检查
.github/release.yml
文件：
- 若文件存在 → 继续标签检测
- 若文件不存在 → 跳过标签检测，直接创建PR
若release.yml存在，解析它以了解可用的分类和标签：
- 读取YAML文件
- 提取所有分类定义及其关联的标签
- 构建映射关系：分类 → 标签列表
- 记录分类顺序（先列出的分类通常更重要）
分析PR的特征：
- 主要变更类型：此PR的核心目的是什么？
- 文件变更：修改的文件类型（扩展名、路径、用途）
- 变更范围：代码库中受影响的区域
- 提交信息：关键词、模式、前缀
- PR标题与描述：指示变更类型的关键词
- PRD上下文：原始问题/解决方案描述
选择最匹配的单个标签：
- 对于release.yml中的每个分类，根据PR的核心目的评分匹配度
- 考虑release.yml中的优先级：破坏性变更 > 新功能 > Bug修复 > 文档更新 > 依赖更新 > 其他
- 从最能代表主要变更的分类中选择一个标签
- 为何选择单个标签？：避免PR出现在多个发布说明分类中
- 选择优先级：
  1. 若存在任何破坏性变更 → 使用
```
breaking-change
```
    或
```
breaking
```
  2. 若主要是新功能 → 使用
```
feat
```
    ,
```
feature
```
    , 或
```
enhancement
```
  3. 若主要是修复Bug → 使用
```
fix
```
    ,
```
bug
```
    , 或
```
bugfix
```
  4. 若主要是文档更新 → 使用
```
documentation
```
    或
```
docs
```
  5. 若主要是依赖更新 → 使用
```
dependencies
```
    ,
```
deps
```
    , 或
```
dependency
```
  6. 否则 → 无需特定标签（将出现在“其他变更”中）
应用检测到的标签：将最匹配的单个标签添加到PR创建命令中
- 示例：
```
gh pr create --title "..." --body "..." --label "fix"
```

3.7. Create Pull Request

3.7. 创建Pull Request

Construct PR body: Combine auto-filled and user-provided information following template structure

Create PR:

If label detected:

gh pr create --title "[title]" --body "[body]" --label "[single-label]"

If no release.yml or no matching label:

gh pr create --title "[title]" --body "[body]"

Verify PR created: Confirm PR was created successfully, template populated correctly, and label applied (if applicable)
Request reviews: Assign appropriate team members for code review if specified

构建PR内容：结合自动填充和用户提供的信息，遵循模板结构

创建PR：

若检测到标签：

gh pr create --title "[title]" --body "[body]" --label "[single-label]"

若无release.yml或无匹配标签：

gh pr create --title "[title]" --body "[body]"

验证PR已创建：确认PR已成功创建，模板已正确填充，标签已应用（若有）
请求评审：若有指定，为代码评审分配合适的团队成员

3.8. Fallback for Projects Without Templates

3.8. 无模板项目的备选方案

If no PR template is found, create a sensible default structure:

markdown

undefined

若未找到PR模板，创建合理的默认结构：

markdown

undefined

Description

描述

[What this PR does and why]

[此PR的内容及目的]

Related Issues

Changes Made

已做变更

[List key changes]

[列出关键变更]

Testing

测试

[Testing approach and results]

[测试方法及结果]

Documentation

文档

[Documentation updates made]

undefined

[已做的文档更新]

undefined

4. Review and Merge Process

4. 评审与合并流程

Check ongoing processes: Use
```
gh pr checks [pr-number]
```
to check for any ongoing CI/CD, security analysis, or automated reviews (CodeRabbit, CodeQL, etc.)
Check PR details: Use
```
gh pr view [pr-number]
```
to check for human review comments and PR metadata
Review all automated feedback: Check PR comments section for automated code review feedback (bots, linters, analyzers)
- Use multiple methods to capture all feedback:
  - MCP servers (preferred when available): Use any available MCP servers for comprehensive review data
    - Code review MCPs (e.g., CodeRabbit, custom review servers) for detailed AI code reviews
    - Check available MCP tools/functions related to code reviews, pull requests, or automated feedback
  - CLI commands:
```
gh pr view [pr-number]
```
    ,
```
gh pr checks [pr-number]
```
    ,
```
gh api repos/owner/repo/pulls/[pr-number]/comments
```
  - Web interface inspection: Fetch the PR URL directly to capture all comments, including inline code suggestions that CLI tools may miss
  - Look for comments from automated tools (usernames ending in 'ai', 'bot', or known review tools)
Present ALL code review findings: ALWAYS present every review comment to the user, regardless of severity
- Show ALL comments: Present every suggestion, nitpick, and recommendation - do not filter or omit any
- Categorize findings: Critical, Important, Optional/Nitpick based on impact
- Provide specific examples: Quote actual suggestions and their locations
- Explain assessment: Why each category was assigned
- User decision: Let user decide which improvements to implement before merge (critical items must be addressed, others are user's choice)
Assess feedback priority: Categorize review feedback
- Critical: Security issues, breaking changes, test failures - MUST address before merge
- Important: Code quality, maintainability, performance - SHOULD address for production readiness
- Optional: Style preferences, minor optimizations - MAY address based on project standards
Wait for ALL reviews to complete: Do NOT merge if any reviews are pending or in progress, including:
- Automated code reviews (CodeRabbit, CodeQL, etc.) - Must wait until complete even if CI passes
- Security analysis - Must complete and pass
- CI/CD processes - All builds and tests must pass
- Human reviews - If requested reviewers haven't approved
- CRITICAL: Never skip automated code reviews - they provide valuable feedback even when CI passes
Address review feedback: Make required changes from code review (both automated and human)
- Create additional commits on the feature branch to address feedback
- Update tests if needed to cover suggested improvements
- Document any feedback that was intentionally not addressed and why
Verify all checks pass: Ensure all CI/CD, tests, security analysis, and automated processes are complete and passing
Final review: Confirm the PR addresses the original PRD requirements and maintains code quality
Merge to main: Complete the pull request merge only after all feedback addressed and processes complete
Verify deployment: Ensure feature works in production environment
Monitor for issues: Watch for any post-deployment problems

检查进行中的流程：使用
```
gh pr checks [pr-number]
```
检查是否有正在运行的CI/CD、安全分析或自动化评审（CodeRabbit、CodeQL等）
检查PR详情：使用
```
gh pr view [pr-number]
```
查看人工评审意见和PR元数据
查看所有自动化反馈：检查PR评论区以获取自动化代码评审反馈（机器人、代码检查工具、分析工具）
- 使用多种方法捕获所有反馈：
  - MCP服务器（若可用则优先使用）：使用任何可用的MCP服务器获取全面的评审数据
    - 代码评审MCP（如CodeRabbit、自定义评审服务器）以获取详细的AI代码评审
    - 查看与代码评审、Pull Request或自动化反馈相关的可用MCP工具/功能
  - CLI命令：
```
gh pr view [pr-number]
```
    ,
```
gh pr checks [pr-number]
```
    ,
```
gh api repos/owner/repo/pulls/[pr-number]/comments
```
  - Web界面检查：直接获取PR URL以捕获所有评论，包括CLI工具可能遗漏的内联代码建议
  - 查找自动化工具的评论（用户名以'ai'、'bot'结尾，或已知的评审工具）
呈现所有代码评审结果：始终向用户呈现每一条评审意见，无论严重程度如何
- 显示所有评论：呈现每一条建议、细节优化和推荐 - 不要过滤或省略任何内容
- 对结果分类：根据影响分为关键、重要、可选/细节优化
- 提供具体示例：引用实际建议及其位置
- 解释评估：说明每个分类的分配原因
- 用户决策：让用户决定合并前需要实施哪些改进（关键项必须处理，其他项由用户选择）
评估反馈优先级：对评审反馈进行分类
- 关键：安全问题、破坏性变更、测试失败 - 合并前必须处理
- 重要：代码质量、可维护性、性能 - 为了生产就绪应处理
- 可选：风格偏好、微小优化 - 可根据项目标准选择是否处理
等待所有评审完成：若有任何待处理或进行中的评审，请勿合并，包括：
- 自动化代码评审（CodeRabbit、CodeQL等）- 即使CI通过，也必须等待完成
- 安全分析 - 必须完成并通过
- CI/CD流程 - 所有构建和测试必须通过
- 人工评审 - 若指定了评审人，需等待其批准
- 关键提示：永远不要跳过自动化代码评审 - 即使CI通过，它们也能提供有价值的反馈
处理评审反馈：根据代码评审反馈（自动化和人工）进行必要的变更
- 在功能分支上创建额外的提交以处理反馈
- 若需要，更新测试以覆盖建议的改进
- 记录任何故意未处理的反馈及原因
验证所有检查通过：确保所有CI/CD、测试、安全分析和自动化流程均已完成并通过
最终评审：确认PR满足原始PRD需求并保持代码质量
合并到main分支：仅在所有反馈已处理且所有流程完成后，完成Pull Request的合并
验证部署：确保功能在生产环境中正常工作
监控问题：留意部署后的任何问题

5. Issue Closure

5. 议题关闭

Update issue PRD link: Update the GitHub issue description to reference the new PRD path in
```
./prds/done/
```
directory
Close GitHub issue: Add final completion comment and close
Archive artifacts: Save any temporary files or testing data if needed
Team notification: Announce feature completion to relevant stakeholders

更新议题中的PRD链接：更新GitHub议题描述，使其指向
```
./prds/done/
```
目录中的新PRD路径
关闭GitHub议题：添加最终完成总结评论并关闭议题
归档工件：若需要，保存任何临时文件或测试数据
团队通知：向相关干系人宣布功能已完成

6. Branch Cleanup

6. 分支清理

Switch to main branch:
```
git checkout main
```
Pull latest changes:
```
git pull origin main
```
to ensure local main is up to date

Delete local feature branch:

git branch -d feature/prd-[issue-id]-[feature-name]

Delete remote feature branch:

git push origin --delete feature/prd-[issue-id]-[feature-name]

切换到main分支：
```
git checkout main
```
拉取最新变更：执行
```
git pull origin main
```
以确保本地main分支是最新的

删除本地功能分支：执行

git branch -d feature/prd-[issue-id]-[feature-name]

删除远程功能分支：执行

git push origin --delete feature/prd-[issue-id]-[feature-name]

Success Criteria

成功标准

✅ Feature is live and functional
✅ All tests passing in production
✅ Documentation is accurate and complete
✅ PRD issue is closed with completion summary
✅ Team is notified of feature availability

The PRD implementation is only considered done when users can successfully use the feature as documented.

✅ 功能已上线并正常运行
✅ 生产环境中所有测试通过
✅ 文档准确且完整
✅ PRD议题已关闭并包含完成总结
✅ 团队已收到功能可用的通知

只有当用户能够按照文档成功使用功能时PRD实施才被视为完成。

dot-ai-prd-done

Original

Translation

Complete PRD Implementation

完整的PRD实施

Workflow Steps

工作流步骤

0. Implementation Type Detection

0. 实施类型检测

1. Pre-Completion Validation

1. 完成前验证

2. Branch and Commit Management

2. 分支与提交管理

3. Pull Request Creation

3. Pull Request创建

3.1. PR Template Detection and Parsing

3.1. PR模板检测与解析

3.2. Analyze Changes for PR Content

3.2. 分析变更以准备PR内容

3.3. Auto-Fill PR Information

3.3. 自动填充PR信息

3.4. Prompt User for Information That Cannot Be Deduced

3.4. 提示用户提供无法推导的信息

3.5. Execute Template Requirements

3.5. 执行模板要求

3.6. Detect and Apply PR Label (if release.yml exists)

3.6. 检测并应用PR标签（若release.yml存在）

3.7. Create Pull Request

3.7. 创建Pull Request

3.8. Fallback for Projects Without Templates

3.8. 无模板项目的备选方案

Description

描述

Related Issues

相关议题

Changes Made

已做变更

Testing

测试

Documentation

文档

4. Review and Merge Process

4. 评审与合并流程

5. Issue Closure

5. 议题关闭

6. Branch Cleanup

6. 分支清理

Success Criteria

成功标准