brainstorminglisted

# 设计脑暴（brainstorming） ## 中文速查 - 中文名：设计脑暴 / 实现前方案校准 - 英文稳定名：`brainstorming` - 分类：产品与 PRD / 认知与协作之间的方案收敛桥 - 状态：`core` - 你可以这样叫我：`先脑暴一下方案`、`先不要写 PRD，帮我设计几种路径`、`参考 brainstorming 把这个需求变成设计 spec`、`实现前先讨论设计` - 适合：问题基本成立，但还没确定产品方案、信息架构、交互路径、技术切分或交付 spec，需要先探索 2-3 个可选设计并得到用户确认 - 不适合：问题还没定义清楚，改用 `ai-collaboration-calibration`；已有明确方案要被拷问，改用 `grill-me`；已经要写正式 PRD，改用 `prd-architect` ## Overview 使用这个 Skill 把“可讨论的想法”推进成“可交付给 PRD、mockup 或开发计划的设计 spec”。它强调先理解上下文、逐步澄清、提出多个方案、确认设计，再进入下游 artifact。 它的默认下游可以是 `prd-architect`、`ui-mockup-desktop-workbench`、`prd-to-issues` 或实现计划；如果方案涉及 UI/mockup/HTML 可视化，必须先对齐项目已有视觉语言，避免生成与真实产品割裂的通用页面。 ## Boundary 先判断用户当前阶段： - 问题、目标用户、成功标准或约束还不清楚：转 `ai-collaboration-calibration`，不要急着给方案。 - 问题已基本成立，但方案、路径、范围、交互或系统设计还没定：使用 `brainstorming`。 - 用户已经有一个具体方案，想找漏洞、压测失败模式或挑战取舍：转 `grill-me`。 - 用户明确要 PRD 文档、PRD 模板、PRD 图示或正式需求章节：转 `prd-architect`。 - 用户已有 PRD/handoff，要判断能否开发、可测试、可交付：转 `prd-review`。 - 用户已有 PRD 和 UI 规范，要真实桌面端 mockup：转 `ui-mockup-desktop-workbench`。 ## Hard Gate 在用户确认设计前，不要做以下事情： - 不写生产代码。 - 不创建完整 PRD。 - 不生成正式 GitHub issues。 - 不把方案包装成已经确定的结论。 - 不进入 Superpowers `writing-plans` 或其他实现计划。 简单需求也要经过轻量设计确认。确认可以很短，例如：“我建议按方案 B 做，范围只包含 X/Y，不做 Z。你确认后我再写 PRD-lite。” ## Workflow 1. **复述目标和阶段**：用一句话说明用户想解决的问题，以及当前是“方案脑暴”而不是执行。 2. **读取可发现上下文**：如果有 PRD、调研文档、代码、截图、UI 规范或历史讨论，先读；不要把可查信息问给用户。UI/mockup 相关任务还要读取 `references/visual-design-standards.md`。 3. **判断是否需要转路由**：按 `Boundary` 决定是否继续本 Skill。 4. **澄清关键缺口**：一次只问一个会改变方案的问题。优先问目标用户、成功标准、边界、约束、已有资产和不可接受方案。 5. **提出 2-3 个方案*