prd-next

引用自 vfarcic/dot-ai 的 shared-prompts/prd-next.md（MIT，版权所有 (c) 2025 Viktor Farcic）。原作者：Viktor Farcic。

PRD Next - 开始处理下一项任务

说明

你将协助分析现有的产品需求文档（PRD），推荐下一项优先级最高的任务，然后在用户确认要处理该任务后，讨论其设计。

流程概览

1. 检查上下文是否明确 - 判断 PRD 是否能从近期对话中明确识别
2. 自动检测目标 PRD - 如果上下文不明确，则智能判断要分析哪个 PRD
3. 分析当前实现 - 了解已实现与缺失的内容（近期上下文可用时跳过）
4. 确定最佳的下一项任务 - 找出下一步最应该处理的那一项任务
5. 提出建议 - 清晰说明理由并等待确认
6. 讨论设计 - 如果用户确认，则深入探讨实现设计细节
7. 实现 - 用户实现该任务
8. 更新进度 - 提示用户运行 /prd-update-progress

步骤 0：上下文感知检查

首先，检查近期对话中是否已明确 PRD 上下文：

如果近期对话表明以下情况，则跳过检测和分析：

• 讨论了近期 PRD 工作 - “我们刚处理完 PRD 29”、“刚完成 PRD 更新”等
• 提到了特定 PRD - “PRD #X”、“MCP Prompts PRD”等
• 使用了特定 PRD 命令 - 近期使用了 /prd-update-progress、针对特定 PRD 使用了 /prd-start
• 工作上下文明确 - 讨论了已知 PRD 的具体功能、任务或需求

如果上下文明确：

• 跳转到步骤 6（单项任务建议），使用已知的 PRD
• 使用对话历史了解当前状态和近期进度
• 根据已知 PRD 的状态，直接提出任务建议

如果上下文不明确：

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

步骤 1：智能检测 PRD（仅在上下文不明确时）

按照以下线索的优先级，自动检测目标 PRD：

1. Git 分支分析 - 检查当前分支名称是否符合 PRD 格式：

   • feature/prd-12-* → PRD 12
   • prd-13-* → PRD 13
   • feature/prd-* → 提取 PRD 编号

2. 近期 Git 提交 - 查看近期提交消息中是否提及 PRD：

   • “fix: PRD 12 documentation” → PRD 12
   • “feat: implement prd-13 features” → PRD 13

3. Git 状态分析 - 检查已修改或暂存的文件中是否有 PRD 线索：

   • 已修改 prds/12-*.md → PRD 12
   • 特定功能目录中的变更

4. 发现可用 PRD - 列出 prds/ 目录中的所有 PRD：

   • prds/12-documentation-testing.md
   • prds/13-cicd-documentation-testing.md

5. 让用户选择 - 仅在上下文检测失败时，询问用户指定 PRD

PRD 检测实现：

# Use these tools to gather context:
# 1. Check git branch: gitStatus shows current branch
# 2. Check git status: Look for modified PRD files  
# 3. List PRDs: Use LS or Glob to find prds/*.md files
# 4. Recent commits: Use Bash 'git log --oneline -n 5' for recent context

检测逻辑：

• 高置信度：分支名称与 PRD 格式匹配（例如，feature/prd-12-documentation-testing）
• 中置信度：Git 状态中有已修改的 PRD 文件，或近期提交提及 PRD
• 低置信度：有多个可用 PRD，使用启发式方法（最新或最大的 PRD）
• 无上下文：向用户列出可用选项

检测结果示例：

🎯 **Auto-detected PRD 12** (Documentation Testing)
- Branch: `feature/prd-12-documentation-testing` ✅
- Modified files: `prds/12-documentation-testing.md` ✅
- Recent commits mention PRD 12 features ✅

确定 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 状态给出建议。如果你完成了全部分析，请根据详细分析结果给出建议。

请按以下精简格式呈现结果：

# Next Task Recommendation: [Feature Name]

## Recommended Task: [Specific Task Name]

**Why this task**: [2-3 sentences explaining why this is the highest priority right now]

**What it unlocks**: [What becomes possible after completing this]

**Dependencies**: [What's already complete that makes this ready to work on]

**Success criteria**: [How you'll know it's done]

---

**Do you want to work on this task?** 

If yes, I'll plan and implement it. If no, let me know what you'd prefer to work on instead.

第 7 步：规划任务（确认后）

如果用户确认，请自行规划任务；不要将其变成与用户讨论设计的环节。由你决定技术方案，并将每项选择及其理由记录在 PRD 的 Decision Log 中。

• 方案：说明任务如何融入现有代码、会涉及哪些模块和接口，以及在哪个边界进行测试。
• 顺序：先完成最小的端到端步骤，以便尽早验证；尽快检查风险最高的假设。
• 技术选择：自行决定并记录库、接口、错误处理和性能权衡，不要向用户询问。
• 仅在以下情况升级处理：现有规则要求升级的事项（外部 API 合约变更、影响现有数据的架构变更、身份验证或安全模型变更、不可逆操作），或尚未解决的产品意图。将这些事项合并为一个问题，并附上推荐答案。

成功标准

此命令应当：

• ✅ 根据当前 PRD 状态，找出下一个要处理的最高价值单项任务
• ✅ 清晰、有说服力地说明为何应优先处理这一特定任务
• ✅ 在继续之前等待用户确认
• ✅ 如果用户确认，提供详细的实施设计指导
• ✅ 让团队专注于最重要的工作，而不是被过多选项淹没
• ✅ 从建议直接过渡到设计讨论，以便立即采取行动

第 8 步：完成后更新进度

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

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

---

任务实施已完成。

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

---

然后停止。不要继续执行。/prd-update-progress 命令会处理 PRD 更新、进度跟踪和提交。此职责分离可确保工作流规范，避免重复或冲突的更新。