AI-PRD智能更新助手Skill dot-ai-prd-update-progress

---

名称: dot-ai-prd-update-progress 描述: 基于git提交和代码更改更新PRD进度，增强对话上下文 用户可调用: true

PRD更新进度斜杠命令

指令

你正在帮助基于已完成的实现工作更新现有的产品需求文档（PRD）。此命令分析git提交和代码更改，增强对话上下文，以跟踪PRD完成进度并提议基于证据的更新。

流程概述

1. 识别目标PRD - 确定要更新哪个PRD
2. 上下文优先进度分析 - 先使用对话上下文，Git分析作为后备
3. 映射更改到PRD项目 - 智能连接工作到需求
4. 提议更新 - 建议复选框完成和需求更改
5. 用户确认 - 验证提议并处理边缘情况
6. 更新PRD - 应用更改到复选框和状态
7. 标记分歧 - 提醒实际工作与计划工作不同时
8. 提交进度更新 - 保存进度检查点
9. 继续到下一个任务 - 提示用户运行 /prd-next

步骤1: 智能PRD识别

使用对话上下文自动检测目标PRD：

1. 当前工作上下文：查找最近关于特定PRD工作、功能或问题的对话
2. Git分支分析：检查当前git分支是否有PRD指示器（如 feature/prd-*, 问题编号）
3. 最近文件活动：识别 prds/ 目录中最近修改的PRD文件
4. 待办列表上下文：检查TodoWrite工具是否显示进行中的PRD特定任务

检测优先级顺序：

• 如果对话明确提到“PRD #X”或特定PRD文件 → 使用该PRD
• 如果git分支包含PRD引用（如“feature/prd-12-*”）→ 使用PRD #12
• 如果TodoWrite显示PRD特定任务 → 使用该PRD上下文
• 如果只有一个PRD文件最近修改 → 使用该PRD
• 如果多个PRD可能 → 请用户澄清

步骤2: 上下文优先进度分析

优先级：先使用对话上下文，再使用Git分析

对话上下文分析（快速 - 优先使用）

如果最近对话显示明确的工作完成：

• 最近讨论的实现：“刚完成X”、“实现了Y”、“构建了Z”
• 待办列表上下文：检查TodoWrite工具中已完成/进行中的项目
• 文件创建提及：“创建了文件X”、“添加了Y功能”
• 测试完成引用：“测试通过”、“所有X测试完成”
• 用户确认：“那可行”、“实现完成”、“准备下一步”

当对话上下文可用时使用 - 比Git解析更快更准确

Git更改分析（后备 - 仅当上下文不清晰时使用）

仅当对话上下文不足时使用git工具：

提交分析

# 获取最近提交（最后10-20个提交）
git log --oneline -n 20

# 获取自上次PRD更新以来的详细更改
git log --since="1周前" --pretty=format:"%h %an %ad %s" --date=short

文件更改分析

# 查看最近修改的文件
git diff --name-status HEAD~10..HEAD

# 获取关键目录中的具体更改
git diff --stat HEAD~10..HEAD

更改分类

识别不同类型的更改：

• 新文件：表示新功能或组件
• 修改文件：显示现有功能的更新
• 测试文件：测试实现的证据
• 文档文件：显示文档更新
• 配置文件：表示设置或部署更改

步骤3: 全面PRD结构分析

关键：系统化复选框扫描

必须执行此步骤以避免遗漏需求：

1. 扫描PRD中所有未勾选的项目 使用grep或搜索

2. 按类型分类每个未勾选的需求：

   • 实现（代码、功能、技术任务）
   • 文档（指南、示例、交叉引用）
   • 验证（测试示例工作、用户旅程）
   • 用户验收（实际使用、跨客户端测试）
   • 启动活动（培训、部署、推出）
   • 成功指标（采用、分析、支持影响）

3. 仅将git更改映射到适当类别

4. 保守 - 仅在有直接证据时标记项目完成

基于证据的完成标准

实现需求 - 标记完成当：

• 代码文件：显示功能已实现
• 测试文件：证明全面测试
• 集成：组件正确连接

文档需求 - 标记完成当：

• 文件已创建：文档文件存在
• 示例已验证：命令/示例已测试
• 交叉引用工作：内部链接已验证

验证需求 - 标记完成当：

• 手动测试已完成：工作流程端到端测试
• 示例已验证：所有记录示例工作
• 用户旅程已确认：完整工作流程已验证

启动活动 - 标记完成当：

• 培训已提供：团队已培训
• 部署已完成：功能已上线可访问
• 推出已完成：用户正在积极使用功能

保守完成政策

除非有直接证据，否则不要标记完成：

• ❌ 不要假设文档“足够好”而未经验证
• ❌ 没有实际测试证据时不要标记测试完成
• ❌ 没有推出证明时不要标记启动项目完成
• ❌ 没有指标时不要标记成功标准完成

差距分析

系统化识别：

• 无证据的需求（仍需工作）
• 无需求的证据（范围外完成的工作）
• 缺失验证（已实现但未测试）
• 缺失推出（就绪但未部署/采用）

步骤4: 全面进度报告

必需：完整状态分析

呈现全面细分：

## PRD进度分析：[PRD名称]

### ✅ 已完成（有证据）：
**实现**（X/Y项目）：
- [x] 项目名称 - 证据：具体文件/更改
- [x] 项目名称 - 证据：具体文件/更改

**文档**（X/Y项目）：
- [x] 项目名称 - 证据：文档已创建，示例已测试
- [x] 项目名称 - 证据：交叉引用已验证

### ⏳ 剩余工作：
**验证**（X项目未勾选）：
- [ ] 项目名称 - 原因：需要手动测试/验证
- [ ] 项目名称 - 原因：示例未测试

**用户验收**（X项目未勾选）：
- [ ] 项目名称 - 原因：无跨客户端测试完成
- [ ] 项目名称 - 原因：无用户反馈收集

**启动活动**（X项目未勾选）：
- [ ] 项目名称 - 原因：团队未培训
- [ ] 项目名称 - 原因：未部署到生产

**成功指标**（X项目未勾选）：
- [ ] 项目名称 - 原因：无使用数据可用
- [ ] 项目名称 - 原因：采用未测量

### 🎯 完成状态：
- **总体进度**：X% 完成（总共Z项目中的Y项）
- **实现阶段**：100% 完成 ✅
- **验证阶段**：X% 完成（缺少什么）
- **启动阶段**：X% 完成（缺少什么）

保守推荐政策

仅当有直接证据时建议标记项目完成。 清晰列出仍需完成的工作。 除非所有项目真正完成，否则不要声称“一切都完成”。

步骤5: 实现与计划分析

分歧检测

标记实际实现与计划方法不同时：

• 架构更改：与原始计划不同的技术方法
• 范围更改：实现期间添加或移除功能
• 需求演变：开发期间变得更清晰的用户需求
• 技术发现：编码期间发现的约束或机会

更新推荐

发现分歧时建议PRD更新：

• 决策日志更新：记录实现方法更改的原因
• 需求修改：更新需求以匹配实际功能
• 架构更新：修订技术方法文档
• 范围调整：在阶段间移动项目或更新功能定义

步骤6: 用户确认流程

清晰呈现提议更改，完全透明：

1. 证据摘要：显示检测到的工作
2. 提议完成：列出要标记完成的具体复选框项目及其证据
3. 剩余工作分析：清晰显示未勾选项目及原因
4. 分歧警报：高亮计划与现实的任何差异
5. 诚实进度评估：给出现实的完成百分比

关键要求：

• 除非所有复选框真正完成，否则不要声称“一切都完成”
• 明确git-based分析的局限性
• 当无法验证功能工作时，承认验证差距
• 分离实现与验证/推出

在用户确认前等待，并处理：

• 部分接受：用户同意一些但非所有建议
• 附加上下文：用户提供git历史中不可见的信息
• 范围澄清：用户解释似乎是范围外的工作
• 未来规划：用户想根据当前进度调整即将进行的工作

步骤7: 系统化更新应用

应用更新时：

1. 仅更新已确认项目 - 不要做假设
2. 更新状态部分 以反映当前阶段
3. 保留仍需工作的未勾选项目
4. 更新完成百分比 现实地

步骤7.5: 代码示例验证

基于实现进度更新PRD时：

关键：始终检查PRD中的代码示例是否与当前实现匹配

示例影响检测

1. 接口更改：函数签名、参数类型、返回格式
2. API演变：方法名称、类结构、数据模型
3. 工作流程更新：用户交互模式、步骤序列
4. 集成更改：组件如何连接和通信

代码示例更新流程

1. 扫描PRD：识别所有代码片段和示例
2. 交叉引用实现：比较示例与实际代码
3. 标记过时：标记不再匹配的示例
4. 优先级评估：确定哪些示例需要立即更新
5. 更新示例：修订代码片段以匹配当前实现
6. 验证示例：测试更新后的示例以确保工作

要检查的示例类别

• 函数调用：参数顺序、类型、名称
• 接口定义：TypeScript接口、类结构
• API响应：数据格式、字段名称、响应结构
• 工作流程步骤：用户交互序列、工具使用模式
• 配置：设置示例、环境变量、配置文件

何时更新示例

• 立即：当接口更改破坏现有示例时
• 完成前：当标记实现里程碑完成时
• 审查期间：当验证PRD准确性时
• 用户反馈：当有人报告示例不工作时

步骤8: 提交进度更新

成功更新PRD后，提交所有更改以保存进度检查点：

提交实现工作

# 强制：暂存所有文件 - 实现工作和PRD更新一起
# 不要只选择性地添加PRD文件 - 提交所有内容作为一个原子单元
git add .

# 验证将要提交的内容
git status

# 创建包含PRD引用的全面提交
git commit -m "feat(prd-X): 实现[已完成工作的简要描述]

- [关键实现成就的简要列表]
- 更新了已完成项目的PRD复选框

进度：X% 完成 - [下一个主要里程碑]"

提交消息指南

• 引用PRD编号：始终在提交消息中包含 prd-X
• 描述性摘要：已完成工作的简短清晰描述
• 进度指示：包含完成状态和下一步骤
• 基于证据：仅当有实际实现进度时提交

注意：除非用户明确请求，否则不要推送提交。提交保存本地进度检查点而不影响远程分支。

步骤9: 基于PRD状态的下一步骤

完成PRD更新并提交更改后，根据完成状态引导用户：

如果PRD有剩余任务

---

PRD进度已更新并提交。

要继续在此PRD上工作：

1. 清除/重置对话上下文
2. 运行 /prd-next 以获取下一个任务

---

如果PRD是100%完成

---

PRD #X 已完成！

要最终化：

1. 清除/重置对话上下文
2. 运行 /prd-done 将PRD移动到完成文件夹并关闭GitHub问题

---