/pd-brainstorming

融合渐进式设计（brainstorming）与深度追问（grill-me），把模糊想法变成经过充分推敲的完整设计方案，并记录到 .scratch/<feature>/RAD.md。

工作流程

阶段 0：前置检查（pd-setup）——【必须先执行，禁止跳过】

这是强制性步骤。在进入阶段1之前，必须通过以下检查：

1. 检测当前项目是否已经执行过 /pd-setup
   • 检查依据：CLAUDE.md 或 AGENTS.md 中存在 ## Agent skills 区块，且 docs/agents/ 目录存在
2. 如果上述检查条件任一不满足，则必须通过 Skill 工具调用 pd-setup：
   • 使用 Skill({skill: "pd-setup"}) 执行初始化
   • 等待其完成（pd-setup 可能需要用户交互确认 issue tracker、labels 等配置）
   • 确认 CLAUDE.md/AGENTS.md 中已出现 ## Agent skills 区块且 docs/agents/ 目录已生成
3. 严禁在未确认 /pd-setup 已完成的情况下进入阶段1

阶段 1：确定功能名

• 前提：确认阶段0已执行完毕（CLAUDE.md 中存在 ## Agent skills 区块，且 docs/agents/ 目录存在）
• 根据用户需求提取简短的功能名（kebab-case，如 user-auth、payment-flow）
• 如果不明确，先向用户确认功能名
• 创建 .scratch/<feature>/ 目录（如果不存在）

阶段 2：理解上下文

• 先查看项目当前状态（文件结构、docs、近期变更）
  • 如果存在 docs/architecture.md， docs/api.md， docs/changelog.md 则读取这些文档
  • 如果存在 .scratch/<feature>/previous-RAD.md 或历史方案，也一并读取
• 了解用户想法的目的、约束、成功标准
• 不明确的地方开始追问

阶段 3：深度追问（Grill 模式）

对每个关键决策点进行深度追问，确保想法被充分推敲：

• 一个一个问，每次只抛出一个问题，得到回答后再继续
• 优先多选题，给出 2-3 个选项+你的推荐+理由，减少用户的回答负担
• 能看代码就看代码，如果问题可以通过探索代码库回答，直接探索而不是问用户
• 走完整棵决策树，逐个分支追问，直到每个依赖关系都被理清
• 每个问题给出推荐答案，不要只问不给建议
• 不留模糊地带，无法确定的部分注明"待进一步分析"

阶段 4：探索方案

• 提出 2-3 种不同的实现方案
• 每种方案列出权衡取舍
• 给出你的推荐方案和理由，放在最前面
• YAGNI 原则：砍掉所有不必要的功能
• 探索替代方案：永远不要只给一个选项就定下来

阶段 5：渐进式呈现设计

• 理解要做什么之后，分段呈现设计（尽可能详细）
• 每段结束后停下来确认是否合理
• 覆盖：架构、组件、数据流、错误处理、测试策略
• 随时准备回退澄清

阶段 6：确认并保存方案

用户确认设计方案后，将完整方案保存到 .scratch/<feature>/RAD.md：

• 如果 .scratch/<feature>/ 不存在则创建
• 如果 .scratch/<feature>/RAD.md 不存在则创建
• 按时间倒序追加，每次记录为一个独立 section：

## YYYY-MM-DD — 方案摘要

### 需求分析
[具体的需求分析内容]

### 需要考虑的细节
[需要考虑的细节、注意事项等]

### 架构与方案
[架构设计、实现方案、方法等]

### 决策记录
- 选择了 XX 方案，原因是 ...
- 放弃了 YY 方案，因为 ...

### 待办事项
- [ ] 待进一步分析的内容

方案已保存到 .scratch/<feature>/RAD.md。根据当前状态引导用户下一步：

• 需要对方案进行压力测试和术语打磨 → 运行 /pd-grill-with-docs（它会用项目的领域模型和已有 ADR 来挑战当前方案，修正术语、补充边界条件）
• 想快速验证关键设计决策的可行性 → 运行 /pd-prototype（构建可交互的 throwaway 原型，验证状态机、UI 布局或数据模型）
• 方案已确定，需要转化为可执行需求文档 → 运行 /pd-to-prd（读取 .scratch/<feature>/RAD.md，合成结构化 PRD 并发布到 issue tracker）
• PRD 已发布，需要拆分为独立 issue → 运行 /pd-to-issues（将 PRD 拆分为垂直切片，发布为可被 AFK agent 执行的独立 issue）

关键原则

• 多选型优于开放型 — 给用户选项比开放式问题更容易回答
• YAGNI 到底 — 从所有设计中剔除不必要的部分
• 必须探索替代方案 — 至少 2-3 种方案再定下来
• 增量验证 — 设计分段呈现，每段都确认
• 保持灵活 — 不理解就回退澄清，不要硬推
• 深度追问不留死角 — 每个决策分支都要走到尽头
• 一次一问 — 不要一次抛一堆问题
• 给推荐而非只问 — 每个问题附带推荐答案和理由