name: dot-ai-prd-next description: 分析现有产品需求文档以识别并推荐下一个最高优先级任务 user-invocable: true

PRD Next - 处理下一个任务

说明

您正在帮助分析现有的产品需求文档（PRD）以建议下一个最高优先级的任务，然后如果用户确认他们想处理它，讨论其设计。

流程概述

检查上下文清晰度 - 确定PRD是否从最近的对话中显而易见
自动检测目标PRD - 如果上下文不清晰，智能确定要分析哪个PRD
分析当前实现 - 理解已实现与缺失的内容（如果最近上下文可用则跳过）
识别单个最佳下一个任务 - 找到应该处理的下一个任务
呈现推荐 - 给出清晰的原理并等待确认
设计讨论 - 如果确认，深入实施设计细节
实施 - 用户实施任务
更新进度 - 提示用户运行 /prd-update-progress

步骤0：上下文意识检查

首先：检查PRD上下文是否已从最近对话中清晰：

如果最近对话显示以下情况，则跳过检测/分析：

最近讨论了PRD工作 - “我们刚刚处理了PRD 29”，“刚刚完成了PRD更新”等。
提到了特定PRD - “PRD #X”，“MCP Prompts PRD”等。
使用了PRD特定命令 - 最近使用了 /prd-update-progress, /prd-start 与特定PRD
清晰的工作上下文 - 讨论已知PRD的特定功能、任务或要求

如果上下文清晰：

跳至步骤6（单个任务推荐），使用已知PRD
使用对话历史理解当前状态和最近进度
直接基于已知PRD状态进行任务推荐

如果上下文不清晰：

继续到步骤1（PRD检测）进行完整分析

步骤1：智能PRD检测（仅当上下文不清晰时）

使用这些上下文线索自动检测目标PRD（按优先级顺序）：

Git分支分析 - 检查当前分支名称的PRD模式：
- feature/prd-12-* → PRD 12
- prd-13-* → PRD 13
- feature/prd-* → 提取PRD编号
最近Git提交 - 查看最近提交消息中的PRD引用：
- “fix: PRD 12 documentation” → PRD 12
- “feat: implement prd-13 features” → PRD 13
Git状态分析 - 检查修改/暂存文件以获取PRD线索：
- 修改 prds/12-*.md → PRD 12
- 更改功能特定目录
可用PRD发现 - 列出 prds/ 目录中的所有PRD：
- prds/12-documentation-testing.md
- prds/13-cicd-documentation-testing.md
回退到用户选择 - 仅当上下文检测失败时，要求用户指定

PRD检测实现：

# 使用这些工具收集上下文：
# 1. 检查git分支：gitStatus显示当前分支
# 2. 检查git状态：查找修改的PRD文件  
# 3. 列出PRD：使用LS或Glob查找prds/*.md文件
# 4. 最近提交：使用Bash 'git log --oneline -n 5'获取最近上下文

检测逻辑：

高置信度：分支名称匹配PRD模式（例如，feature/prd-12-documentation-testing）
中等置信度：git状态或最近提交中提到的修改PRD文件
低置信度：多个PRD可用，使用启发式方法（最近、最大）
无上下文：向用户呈现可用选项

示例检测输出：

🎯 **自动检测到PRD 12** (文档测试)
- 分支：`feature/prd-12-documentation-testing` ✅
- 修改文件：`prds/12-documentation-testing.md` ✅
- 最近提交提到PRD 12功能 ✅

一旦识别PRD：

从 prds/[issue-id]-[feature-name].md 读取PRD文件
分析所有部分的完成状态
识别已完成与剩余工作的模式

步骤2：文档与实现分析（仅当上下文不清晰时）

在评估任务优先级之前，分析文档化规范和当前实现状态：

文档分析（文档优先PRD）

对于使用文档优先方法的PRD：

读取引用的文档：检查PRD中的“内容位置图”以找到功能规范所在位置
理解目标状态：已文档化但尚未实现的功能
检查文档完整性：所有用户工作流和示例是否完全文档化
验证交叉引用：所有文档链接和引用是否正确工作

代码发现

搜索相关文件：使用Grep/Glob查找与功能相关的文件
识别关键模块：定位PRD中提到的主要实现文件
查找测试文件：发现功能的现有测试覆盖
检查依赖项：审查导入和模块关系

实现与文档差距分析

比较文档与代码：已文档化与实际上已实现的内容
部分实现：识别半完成的功能或TODO注释
文档验证：文档化的示例和命令是否能实际工作
架构对齐：当前代码是否匹配文档化行为和PRD架构决策
质量评估：代码风格、错误处理、测试覆盖差距

技术可行性分析

依赖冲突：PRD要求是否与现有代码兼容
破坏性更改：剩余任务是否需要重构现有代码
集成点：新工作如何与当前实现连接
技术债务：可能阻碍或减慢未来工作的问题

步骤3：完成度评估（仅当上下文不清晰时）

分析复选框状态

计数和分类所有复选框：

已完成：[x] 项目
待处理：[ ] 项目
推迟：[~] 项目
阻塞：[!] 项目

阶段分析

对于每个实施阶段：

计算完成百分比
识别瓶颈或停滞工作
评估移动到下一阶段的准备情况

要求覆盖

审查要求类别：

功能要求：核心功能完成
非功能要求：质量和性能方面
成功标准：可衡量结果
依赖项：外部要求
风险缓解：风险管理进度

步骤4：依赖分析（仅当上下文不清晰时）

识别关键路径项目

查找那些：

阻塞其他工作 - 必须在其他开始之前完成
启用主要能力 - 完成后解锁显著价值
解决当前阻塞 - 移除进展障碍

依赖模式

PRD级别依赖

顺序依赖 - A必须在B之前完成
并行机会 - 可以同时工作的多个项目
基础要求 - 多个功能需要的核心能力
集成点 - 连接系统不同部分的项目

代码级别依赖

导入依赖 - 模块依赖于其他模块先实现
接口契约 - API/类型必须在消费者之前定义
数据库模式 - 业务逻辑之前需要的数据模型更改
测试依赖 - 需要某些基础设施或模拟的测试
构建/部署 - 影响多个组件的配置更改

步骤5：战略价值评估（仅当上下文不清晰时）

高价值下一步

优先处理那些：

解锁多个其他项目 - 高杠杆影响
提供用户可见价值 - 直接用户受益
减少技术风险 - 解决主要不确定性
启用验证 - 允许测试关键假设
提供学习 - 为未来工作生成见解

低优先级项目

识别那些：

有许多依赖项 - 尚不能开始
是可有可无的 - 不影响核心价值主张
是优化导向的 - 改进现有工作功能
需要外部依赖项 - 等待他人

步骤6：单个任务推荐

注意：如果您从步骤0（清晰上下文）到达这里，使用对话历史和已知PRD状态进行推荐。如果您通过完整分析到达这里，使用您的详细发现。

以此聚焦格式呈现发现：

# 下一个任务推荐：[功能名称]

## 推荐任务：[特定任务名称]

**为什么是这个任务**：[2-3句话解释为什么这是当前最高优先级]

**它解锁了什么**：[完成此任务后变得可能的事情]

**依赖项**：[已经完成的内容使得此任务可以开始]

**成功标准**：[您将如何知道它已完成]

---

**您想处理这个任务吗？** 

如果是，我将帮助您设计实施方法。如果不是，让我知道您想处理什么。

步骤7：设计讨论（如果确认）

如果用户确认他们想处理推荐的任务，那么深入：

实施计划

架构方法：如何适应现有代码库
关键组件：需要构建/修改什么
集成点：如何与现有代码连接
测试策略：如何验证实施

设计决策

技术选择：要做的框架/库决策
接口设计：API、数据结构、用户界面
错误处理：如何处理故障情况
性能考虑：可扩展性和优化需求

实施步骤

逐步分解：实施的逻辑序列
快速胜利：首先可以完成的部分以进行验证
风险缓解：首先解决最大的不确定性
测试检查点：何时以及如何验证进度

要解决的问题

开放决策：需要做出的设计选择
需要澄清：需要更多细节的要求
要验证的假设：我们假设应该确认的事情

成功标准

这个命令应该：

✅ 基于当前PRD状态识别下一个最高价值的任务
✅ 提供清晰、有说服力的原理，说明为什么这个特定任务应优先处理
✅ 在继续之前等待用户确认
✅ 如果确认，提供详细的实施设计指导
✅ 通过从推荐过渡到设计讨论，使团队专注于最重要的工作，而不是用选项淹没他们
✅ 实现立即行动

步骤8：完成后的进度更新

关键：不要自己更新PRD。不要直接编辑PRD文件。您的工作是提示用户运行更新命令。

在用户完成任务实施后，仅输出此消息：

任务实施完成。

要更新PRD进度并提交您的工作，运行 /prd-update-progress。

然后停止。不要继续。/prd-update-progress 命令处理PRD更新、进度跟踪和提交。这种分离确保适当的工作流程，避免重复/冲突的更新。