name: dot-ai-prd-update-decisions description: 根据对话中的设计决策和战略变化更新PRD user-invocable: true
PRD 更新决策斜杠命令
指令
你正在基于对话中做出的设计决策、战略变化和架构选择更新PRD。此命令捕获可能尚未在代码中体现但影响需求、方法或范围的概念性变化。
过程概述
- 确定目标PRD - 确定要更新哪个PRD
- 分析对话上下文 - 审查讨论中的设计决策和战略变化
- 识别决策点 - 找到架构、工作流、需求或范围的变化
- 映射到PRD部分 - 确定PRD的哪些部分需要更新
- 提出更新 - 建议对需求、方法和约束的更改
- 更新决策日志 - 记录新决策及其理由和影响
步骤 1: PRD分析
询问用户要更新哪个PRD，然后：
- 从
prds/[issue-id]-[feature-name].md读取PRD文件 - 理解当前需求、方法和约束
- 识别最可能受设计决策影响的区域
步骤 2: 对话分析
审查对话上下文以发现决策模式：
设计决策指示器
寻找表明战略变化的对话元素：
- 工作流变化: “让我们简化为…” “如果我们改为…”
- 架构决策: “我认为我们应该使用…” “更好的方法是…”
- 需求修改: “实际上，我们不需要…” “我们还应该包括…”
- 范围调整: “让我们推迟这个…” “这比我们想象的要复杂…”
- 用户体验转折: “用户会更喜欢…” “这个工作流更有意义…”
特定决策类型
- 技术架构: 框架选择、设计模式、数据结构
- 用户体验: 工作流变化、界面决策、交互模型
- 需求: 新需求、修改后的需求、移除的需求
- 范围管理: 添加的功能、推迟的功能、淘汰的功能
- 实施策略: 阶段变化、优先级调整、方法修改
步骤 3: 决策影响评估
对于每个识别的决策，评估：
影响类别
- 需求影响: 需要添加、修改或移除哪些需求？
- 范围影响: 这会扩大还是缩小项目范围？
- 时间线影响: 这会影响项目阶段或交付日期吗？
- 架构影响: 这会改变技术约束或方法吗？
- 代码示例影响: 哪些示例、接口或片段变得过时？
- 风险影响: 这会引入新风险还是缓解现有风险？
决策文档格式
对于每个决策，记录：
- 决策: 决定了什么
- 日期: 何时做出决策
- 理由: 为什么选择这种方法
- 影响: 这如何影响PRD需求、范围或方法
- 代码影响: 需要更新哪些代码示例、接口或片段
- 负责人: 谁做出或批准了决策
步骤 4: PRD更新
更新适当的PRD部分：
决策日志更新
- 添加新的已解决决策，包括日期和理由
- 如果决策已做出，标记开放问题为已解决
- 更新决策对需求和范围的影响
需求更新
- 基于设计更改修改功能需求
- 如果性能/质量标准改变，更新非功能需求
- 如果测量或目标改变，调整成功标准
实施方法更新
- 如果顺序或优先级改变，更新阶段
- 如果技术方法演变，修改架构决策
- 如果功能被添加、推迟或移除，调整范围管理
代码示例验证和更新
- 识别过时示例: 扫描PRD中可能受设计决策影响的代码片段
- 接口更改: 当函数签名、参数类型或返回值改变时，更新示例
- API修改: 当方法名称、类结构或数据格式演变时，修订示例
- 工作流更新: 当用户交互模式或步骤序列改变时，更新过程示例
- 标记为验证: 标记需要手动测试以确保仍能工作的代码示例
风险和依赖更新
- 添加由设计决策引入的新风险
- 如果方法改变，更新缓解策略
- 如果架构变化影响集成，修改依赖