Back to Details

dot-ai-prd-update-decisions

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

PRD Update Decisions Slash Command

PRD更新决策斜杠命令

Instructions

说明

You are updating a PRD based on design decisions, strategic changes, and architectural choices made during conversations. This command captures conceptual changes that may not yet be reflected in code but affect requirements, approach, or scope.
你需要根据对话过程中达成的设计决策、战略变更和架构选择来更新PRD。该命令用于记录那些尚未在代码中体现，但会影响需求、实现方法或范围的概念性变更。

Process Overview

流程概述

  1. Identify Target PRD - Determine which PRD to update
  2. Analyze Conversation Context - Review discussions for design decisions and strategic changes
  3. Identify Decision Points - Find architecture, workflow, requirement, or scope changes
  4. Map to PRD Sections - Determine which parts of the PRD need updates
  5. Propose Updates - Suggest changes to requirements, approaches, and constraints
  6. Update Decision Log - Record new decisions with rationale and impact
  1. 确定目标PRD - 明确需要更新的PRD文件
  2. 分析对话上下文 - 回顾对话内容，提取设计决策和战略变更
  3. 识别决策点 - 找出架构、工作流、需求或范围的变更
  4. 匹配PRD章节 - 确定PRD中需要更新的部分
  5. 提出更新建议 - 针对需求、实现方法和约束条件提出修改建议
  6. 更新决策日志 - 记录新的决策及其依据和影响

Step 1: PRD Analysis

步骤1：PRD分析

Ask the user which PRD to update, then:
  • Read the PRD file from 
    prds/[issue-id]-[feature-name].md
  • Understand current requirements, approach, and constraints
  • Identify areas most likely to be affected by design decisions
询问用户需要更新哪份PRD，然后：
  • 从
    prds/[issue-id]-[feature-name].md
    路径读取PRD文件
  • 理解当前的需求、实现方法和约束条件
  • 识别最可能受设计决策影响的区域

Step 2: Conversation Analysis

步骤2：对话分析

Review the conversation context for decision-making patterns:
回顾对话上下文，寻找决策模式：

Design Decision Indicators

设计决策识别标志

Look for conversation elements that suggest strategic changes:
  • Workflow changes: "Let's simplify this to..." "What if we instead..."
  • Architecture decisions: "I think we should use..." "The better approach would be..."
  • Requirement modifications: "Actually, we don't need..." "We should also include..."
  • Scope adjustments: "Let's defer this..." "This is more complex than we thought..."
  • User experience pivots: "Users would prefer..." "This workflow makes more sense..."
寻找对话中暗示战略变更的元素：
  • 工作流变更：“我们把这个简化为...”“如果我们换成...会怎样？”
  • 架构决策：“我认为我们应该使用...”“更好的方法是...”
  • 需求修改：“实际上，我们不需要...”“我们还应该包含...”
  • 范围调整：“我们把这个延后...”“这比我们想象的更复杂...”
  • 用户体验转向：“用户更倾向于...”“这个工作流更合理...”

Specific Decision Types

具体决策类型

  • Technical Architecture: Framework choices, design patterns, data structures
  • User Experience: Workflow changes, interface decisions, interaction models
  • Requirements: New requirements, modified requirements, removed requirements
  • Scope Management: Features added, deferred, or eliminated
  • Implementation Strategy: Phasing changes, priority adjustments, approach modifications
  • 技术架构：框架选择、设计模式、数据结构
  • 用户体验：工作流变更、界面决策、交互模型
  • 需求：新增需求、修改需求、移除需求
  • 范围管理：新增、延后或移除功能
  • 实施策略：阶段变更、优先级调整、实现方法修改

Step 3: Decision Impact Assessment

步骤3：决策影响评估

For each identified decision, assess:
针对每个识别出的决策，评估以下内容：

Impact Categories

影响类别

  • Requirements Impact: What requirements need to be added, modified, or removed?
  • Scope Impact: Does this expand or contract the project scope?
  • Timeline Impact: Does this affect project phases or delivery dates?
  • Architecture Impact: Does this change technical constraints or approaches?
  • Code Example Impact: Which examples, interfaces, or snippets become outdated?
  • Risk Impact: Does this introduce new risks or mitigate existing ones?
  • 需求影响：哪些需求需要新增、修改或移除？
  • 范围影响：这会扩大还是缩小项目范围？
  • 时间线影响：这会影响项目阶段或交付日期吗？
  • 架构影响：这会改变技术约束或实现方法吗？
  • 代码示例影响：哪些示例、接口或代码片段会过时？
  • 风险影响：这会引入新风险还是缓解现有风险？

Decision Documentation Format

决策文档格式

For each decision, record:
  • Decision: What was decided
  • Date: When the decision was made
  • Rationale: Why this approach was chosen
  • Impact: How this affects the PRD requirements, scope, or approach
  • Code Impact: Which code examples, interfaces, or snippets need updating
  • Owner: Who made or approved the decision
针对每个决策，记录：
  • 决策内容：达成的具体决策
  • 日期：决策制定的时间
  • 依据：选择该方案的原因
  • 影响：这会如何影响PRD的需求、范围或实现方法
  • 代码影响：哪些代码示例、接口或片段需要更新
  • 负责人：制定或批准该决策的人员

Step 4: PRD Updates

步骤4：PRD更新

Update the appropriate PRD sections:
更新PRD的对应章节：

Decision Log Updates

决策日志更新

  • Add new resolved decisions with date and rationale
  • Mark open questions as resolved if decisions were made
  • Update decision impact on requirements and scope
  • 添加带有日期和依据的已解决新决策
  • 如果相关问题已做出决策，将其标记为已解决
  • 更新决策对需求和范围的影响

Requirements Updates

需求更新

  • Modify functional requirements based on design changes
  • Update non-functional requirements if performance/quality criteria changed
  • Adjust success criteria if measurements or targets changed
  • 根据设计变更修改功能需求
  • 如果性能/质量标准发生变化，更新非功能需求
  • 如果衡量指标或目标发生变化，调整成功标准

Implementation Approach Updates

实现方法更新

  • Update phases if sequencing or priorities changed
  • Modify architecture decisions if technical approach evolved
  • Adjust scope management if features were added, deferred, or removed
  • 如果顺序或优先级发生变化，更新项目阶段
  • 如果技术实现方法演进，修改架构决策
  • 如果功能被新增、延后或移除，调整范围管理内容

Code Example Validation and Updates

代码示例验证与更新

  • Identify Outdated Examples: Scan PRD for code snippets that may be affected by design decisions
  • Interface Changes: Update examples when function signatures, parameter types, or return values change
  • API Modifications: Revise examples when method names, class structures, or data formats evolve
  • Workflow Updates: Update process examples when user interaction patterns or step sequences change
  • Mark for Verification: Flag code examples that need manual testing to ensure they still work
  • 识别过时示例：扫描PRD，找出可能受设计决策影响的代码片段
  • 接口变更：当函数签名、参数类型或返回值变化时，更新示例
  • API修改：当方法名称、类结构或数据格式演进时，修订示例
  • 工作流更新：当用户交互模式或步骤顺序变化时，更新流程示例
  • 标记待验证：标记需要手动测试以确保仍可正常运行的代码示例

Risk and Dependency Updates

风险与依赖更新

  • Add new risks introduced by design decisions
  • Update mitigation strategies if approach changed
  • Modify dependencies if architectural changes affect integrations
  • 添加设计决策引入的新风险
  • 如果实现方法变更，更新风险缓解策略
  • 如果架构变更影响集成，修改依赖关系