name: dot-ai-prd-done description: 完成PRD实现工作流程 - 创建分支、推送更改、创建PR、合并和关闭Issue user-invocable: true

完整PRD实现

完成PRD实现工作流程，包括分支管理、Pull Request创建和Issue关闭。

注意：如果任何 gh 命令失败并显示“command not found”，请告知用户需要GitHub CLI，并提供安装链接：https://cli.github.com/

工作流程步骤

0. 实现类型检测

首先：确定PRD完成类型以选择适当的工作流程

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

✅ 更改仅针对PRD文件或项目管理文档
✅ 无源代码更改
✅ 无配置更改
✅ 功能已在先前工作中实现
→ 使用简化工作流程（仅步骤1、2-简化、5）

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

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

1. 完成前验证

[ ] 所有PRD复选框完成：验证每个需求都已实现和测试
[ ] 文档更新：所有面向用户的文档反映已实现功能
[ ] 无未解决的障碍：所有依赖已解决且技术债务已处理
[ ] 更新PRD状态：将PRD标记为“完成”并添加完成日期
[ ] 归档PRD文件：将已完成的PRD移动到 ./prds/done/ 目录以保持项目组织
[ ] 更新ROADMAP.md（如果存在）：如果文件存在，从 docs/ROADMAP.md 路线图中删除已完成功能

注意：测试将在创建PR时在CI/CD流水线中自动运行。不要在完成工作流程期间本地运行测试。

2. 分支和提交管理

对于仅文档完成：

[ ] 直接提交到主分支：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创建

重要：始终检查并使用PR模板（如果可用）

3.1. PR模板检测和解析

[ ] 检查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. 分析更改以获取PR内容

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

3.3. 自动填充PR信息

自动填充可从分析中推断的内容：

[ ] PR标题：
- 如果模板指定，遵循模板标题格式（例如，Conventional Commits：feat(scope): description）
- 从PRD标题/描述和提交消息中提取
- 如果模板要求，包含Issue引用
[ ] 描述部分：
- 什么/为什么：从PRD目标和实现细节中提取
- 相关Issue：使用 Closes #[issue-id] 或 Fixes #[issue-id] 自动链接
- 更改类型：基于文件分析勾选适当框
[ ] 测试清单：
- 如果测试文件被修改，标记“测试已添加/更新”
- 注意：测试在CI/CD中自动运行
[ ] 文档清单：
- 基于更新的文档（README、API文档、代码注释）标记项
- 检查是否遵循了CONTRIBUTING.md指南
[ ] 安全清单：
- 扫描提交以查找潜在秘密或凭据
- 如果身份验证/授权代码更改，标记
- 记录任何依赖更新

3.4. 提示用户获取无法推断的信息

重要：不要只是询问 - 分析并提出答案，然后让用户确认或更正

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

[ ] 手动测试结果：
- 分析PRD测试策略部分 以了解计划测试内容
- 检查git提交 以查找测试相关消息
- 基于更改类型提出测试方法（例如，“审查了文档的准确性和清晰度，验证了交叉引用”）
- 呈现建议并询问：“这准确吗，还是您想修改？”
[ ] 破坏性更改：
- 扫描提交和PRD 以查找破坏性更改指示符
- 如果检测到，基于PRD内容提出迁移指导
- 如果未检测到，确认：“未检测到破坏性更改。正确吗？”
[ ] 性能影响：
- 分析更改类型：文档/配置更改通常无性能影响
- 基于分析提出答案（例如，“无性能影响 - 仅文档”）
- 询问：“正确吗，还是有性能考虑？”
[ ] 安全考虑：
- 检查是否修改了安全敏感文件（身份验证、凭据、API密钥）
- 扫描提交 以查找安全相关关键词
- 提出安全状态（例如，“无安全影响 - 仅文档更改”）
- 询问：“准确吗，还是有安全考虑需要记录？”
[ ] 审阅者关注领域：
- 分析PRD目标 和 git更改 以识别关键领域
- 提出具体关注领域（例如，“验证文档准确性，检查交叉引用链接，确认工作流示例匹配实现”）
- 呈现列表并询问：“这些是正确的关注领域吗，还是我应该调整？”
[ ] 后续工作：
- 检查PRD中的“未来增强”或“超出范围”部分
- 分析 prds/ 目录中的其他PRD 以查找相关工作
- 如果存在，提出后续项目（例如，“PRD中列出的未来增强：模板验证、AI驱动描述”）
- 询问：“我应该列出这些吗，还是有其他后续工作？”
[ ] 附加上下文：
- 审查PRD以获取特殊考虑
- 检查这是否是内部测试PR
- 提出任何相关上下文（例如，“此PR本身测试了它文档化的增强工作流程”）
- 询问：“审阅者还需要了解其他内容吗？”

呈现格式： 将所有提出的答案以摘要格式一起呈现：

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

**手动测试：** [建议答案]
**破坏性更改：** [建议答案]
**性能影响：** [建议答案]
**安全考虑：** [建议答案]
**审阅者关注：** [建议列表]
**后续工作：** [建议项目或“无”]
**附加上下文：** [建议上下文或“无”]

请审查并回复：
- 输入“yes”或“confirm”以接受所有
- 指定任何需要更改的项目的更正

3.5. 执行模板要求

重要：在创建PR之前，识别并执行模板中的任何可执行要求

[ ] 分析模板以获取可执行指令：
- 扫描模板内容以查找祈使句、要求或命令
- 查找模式如“必须”、“应该”、“运行”、“执行”、“确保”、“验证”
- 识别代码块中出现的bash命令，这些命令似乎是先决条件
- 提取清单中提到的任何验证要求
[ ] 分类识别的要求：
- 提交级别操作：签署、格式化、验证
- 提交前命令：测试、构建、代码检查、格式检查
- 验证检查：文件存在性、格式合规性、内容要求
- 文档操作：必需更新、需要添加的链接
[ ] 提出并执行要求：
- 向用户呈现识别的要求：“模板指定了这些操作：[列表]”
- 对于每个要求，确定是否可以自动化
- 提议执行：“我现在应该执行这些吗？”
- 执行确认的操作并报告结果
- 优雅处理失败并询问用户如何继续

[ ] 创建PR前摘要：

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

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

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

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

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

3.7. 创建Pull Request

[ ] 构建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. 无模板项目的回退

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

## 描述
[此PR做什么以及为什么]

## 相关Issue
Closes #[issue-id]

## 更改内容
- [列出关键更改]

## 测试
- [测试方法和结果]

## 文档
- [文档更新内容]

4. 审阅和合并流程

[ ] 检查进行中的流程：使用 gh pr checks [pr-number] 检查任何进行中的CI/CD、安全分析或自动化审阅（CodeRabbit、CodeQL等）
[ ] 检查PR详情：使用 gh pr view [pr-number] 检查人工审阅评论和PR元数据
[ ] 审查所有自动化反馈：检查PR评论部分以获取自动化代码审阅反馈（机器人、代码检查器、分析器）
- 使用多种方法捕获所有反馈：
  - MCP服务器（首选，当可用时）：使用任何可用的MCP服务器获取全面审阅数据
    - 代码审阅MCP（例如，CodeRabbit、自定义审阅服务器）以获取详细的AI代码审阅
    - 检查与代码审阅、Pull Requests或自动化反馈相关的可用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要求并保持代码质量
[ ] 合并到主分支：仅在所有反馈处理完毕且流程完成后完成Pull Request合并
[ ] 验证部署：确保功能在生产环境中工作
[ ] 监控问题：关注任何部署后问题

5. Issue关闭

[ ] 更新Issue PRD链接：更新GitHub Issue描述以引用 ./prds/done/ 目录中的新PRD路径
[ ] 关闭GitHub Issue：添加最终完成评论并关闭
[ ] 归档工件：如有需要，保存任何临时文件或测试数据
[ ] 团队通知：向相关利益相关者宣布功能完成

6. 分支清理

[ ] 切换到主分支：git checkout main
[ ] 拉取最新更改：git pull origin main 以确保本地主分支是最新的
[ ] 删除本地功能分支：git branch -d feature/prd-[issue-id]-[feature-name]
[ ] 删除远程功能分支：git push origin --delete feature/prd-[issue-id]-[feature-name]

成功标准

✅ 功能已上线并正常工作
✅ 所有测试在生产中通过
✅ 文档准确且完整
✅ PRD Issue已关闭并附完成摘要
✅ 团队已通知功能可用性

仅当用户能按文档成功使用功能时，才视为PRD实现已完成。