idea-superpowers-suite

Idea Superpowers 套件

此技能是一套 Superpowers 风格的统筹工作流，用于构思开发。

它会协调以下专注阶段：

• idea-to-design-doc：产品与设计思考
• idea-to-ui-design-brief：仅限 Full 模式的可选 UI 方向和图像生成概念
• idea-to-implementation-doc：可直接用于构建的实现规划

当用户需要一套更完整的多步骤工作流，希望它像可重复使用的系统，而非一次性提示词时，请使用此技能。

目的

将粗略想法转化为一系列结构化产物：

1. 想法记录——根据用户的高层次构想创建或更新本地想法笔记。
2. 澄清式访谈——记录粗略计划、理念、目标体验和限制条件。
3. 设计文档——将想法充实为完整的产品、UX 和技术设计文档。
4. 可选 UI 设计简报——仅限 Full 模式，定义屏幕、布局、视觉方向、状态，以及可选的图像生成概念提示词。
5. 调研环节——比较类似产品，并确定值得借鉴或应避免之处。
6. 实现规范——将设计转化为切实可行的构建策略。
7. 构建交接——生成一个 Markdown 文件，包含任务、提示词、测试、验收标准和 Superpowers 交接指南。
8. 规范评审——在执行前判断是否已准备就绪。

设计理念

此工作流应当：

• 快速记录；
• 深入澄清；
• 先调研，再构建；
• 将产品思考与工程思考分开；
• 当界面质量至关重要时，将 UI 方向与实现细节分开；
• 将每个阶段保存为独立的 Markdown 产物；
• 当用户需要快速推进时，能够跳过阶段且保持灵活。

UI 简报为可选项。它有助于界面占比高的项目，但不得增加 Lite 模式的负担，也不得破坏现有的设计文档 → 实现文档流程。

模式选择

开始时，除非用户明确指定，否则选择以下两种模式之一：

• Lite 模式——适用于草图、小型实用工具、初步想法，以及用户希望快速记录的构想。
• Full 模式——适用于严肃的应用或产品构想，后续可能由 AI 编码 Agent 或 Superpowers 构建。

当想法模糊或处于探索阶段时，默认使用 Lite 模式。当用户要求产品规范、实现计划、构建交接、调研环节、UI/模型图方向或可供 Agent 使用的产物时，默认使用 Full 模式。

默认文件布局

优先使用本地 Markdown 文件。如果用户之后需要导出到 Obsidian，将其作为单独步骤处理。

Lite 模式布局

ideas/<idea-slug>.md
ideas/index.md

仅在用户要求时提供可选内容：

ideas/<idea-slug>.implementation.md
ideas/<idea-slug>.build-prompt.md
ideas/<idea-slug>.ui-brief.md

包含 UI 阶段的 Full 模式布局

ideas/<idea-slug>/
  README.md
  00-idea-capture.md
  01-design-doc.md
  02-ui-design-brief.md
  03-implementation-spec.md
  04-agent-build-handoff.md
  05-spec-review.md

跳过 UI 阶段时的 Full 模式备用布局

如果跳过 UI 阶段，请保留之前较简单的编号：

ideas/<idea-slug>/
  README.md
  00-idea-capture.md
  01-design-doc.md
  02-implementation-spec.md
  03-agent-build-handoff.md
  04-spec-review.md

使用套件中已确立的编号。确保 README 中的产物映射保持一致。

工作流阶段

阶段 1：记录

当用户表示自己有一个想法时，创建一份工作笔记，包含：

• 标题；
• 简短摘要；
• 粗略的问题陈述；
• 初始要点；
• 模式：Lite 或 Full。

如有需要，可以询问名称，但优先使用临时标题继续推进，之后再完善。

阶段 2：访谈

每次只问一个问题。使用 references/interview-question-bank.md 来提出更有力的问题。

在 Lite 模式下，只需询问足以清晰了解想法的问题，然后起草文档。

在 Full 模式下，涵盖以下内容：

• 目标用户及其问题；
• 应用应实现的功能；
• 期望的行为和产品体验；
• 范围和非目标；
• 主要屏幕或版块；
• 用户一眼应能看到的内容；
• 用户采取操作的位置；
• 可按需显示的详细信息；
• 期望的视觉风格：极简、活泼、专业、信息密集、仪表盘风格、沉静、指挥中心风格等；
• 相关的空状态、加载、错误、成功、首次运行和权限状态；
• 数据、集成和平台限制；
• 数据存储位置和托管偏好；
• 目标平台：Web、桌面、移动 Web、iOS、Android 等；
• 拓扑结构：单个应用，还是由多个部分组成，例如桌面应用 + 托管 Web 应用 + API + worker；
• 身份验证、密钥、API 密钥、公开/私密共享，以及客户端/服务器边界；
• 哪些因素能让成果出色，而不仅仅是能用。

除非用户明确提出技术限制，否则不要过早引导其决定技术栈。开始技术规划时，先推荐实用的默认方案，再让用户接受或调整。

阶段 3：设计文档

编写 01-design-doc.md，记录产品方向，并提供足以支持规划的技术框架。

建议包含以下章节：

• 一句话摘要；
• 问题 / 目的；
• 产品理念；
• 目标用户；
• 核心概念；
• 期望的行为；
• 关键功能；
• 布局 / 信息架构；
• UX 说明；
• 技术框架；
• 数据 / 集成 / 平台需求；
• 托管 / 数据存储位置 / 部署偏好；
• 目标平台；
• 推荐的技术默认方案及已接受/已更改的决定；
• 非目标；
• 待解决问题；
• 后续步骤。

阶段 4：可选的 UI 设计简报

默认情况下，此阶段仅适用于 Full 模式。除非用户明确要求 UI、模型图、生成图像或视觉设计方向，否则不要将此阶段加入 Lite 模式。

此阶段运行时，加载 idea-to-ui-design-brief。

当界面质量很重要时，创建 02-ui-design-brief.md。其中应定义：

• UI 的目的；
• 产品氛围和设计原则；
• 主要屏幕/界面；
• 逐屏说明；
• 布局和信息架构；
• 组件清单；
• 关键用户流程；
• 需要设计的状态：空状态、加载、错误、成功、首次运行、权限；
• 视觉方向；
• 无障碍和响应式设计；
• 内容/文案说明；
• 可选的图像生成构想；
• 选定的方向；
• 实施交接说明。

可选的图像生成环节

图像生成用于探索概念，不是实现时的事实依据。

在以下情况下使用：

• 用户想了解可能的 UI 设计；
• 视觉偏好尚不明确；
• 仪表盘/应用/落地页需要在编写代码前进行视觉探索；
• 对比 2–3 种方向会有所帮助。

默认构想：

1. 保守型 — 熟悉、风险低、易于实现。
2. 高度契合型 — 对产品简报的最佳诠释。
3. 差异化型 — 更具特色，有助于发现用户偏好。

如果无法生成图像或跳过了图像生成，就编写提示词并继续以纯文本推进。如果生成了图像，则使用视觉检查/人工审核，将其转化为书面需求、组件说明和验收标准。不要要求 Superpowers 不加判断地照搬图像。

阶段 5：研究环节

针对具体想法，寻找类似产品并记录：

• 现有产品有哪些；
• 哪些属于常见功能 / 通用品；
• 有何不同；
• 应避免什么；
• 这个想法适合什么定位。

保持实用并控制范围。研究应强化规格说明，而不是演变成无休止的市场报告。

阶段 6：实施思路

如果存在 UI 简报，将想法转化为 03-implementation-spec.md；否则转化为 02-implementation-spec.md。

包括：

• 主要系统组件；
• 数据需求；
• 推荐的数据库／存储方案及原因；
• 托管／部署目标；
• 平台目标决策；
• 应用拓扑决策；
• 前端结构，以及在存在 UI 设计简报时如何遵循其要求；
• 后端／服务需求；
• 推荐的技术栈默认方案；
• 安全／密钥方案；
• 集成点；
• 工作流／里程碑；
• 风险与权衡；
• 可执行的构建任务；
• 测试与验证计划；
• 验收标准／完成定义；
• 开发者或 AI 编码 Agent 可以遵循的构建顺序。

对于技术选择，采用“先推荐，再确认”的方式：

1. 根据产品约束推断合理的默认方案；
2. 提供简明的推荐表；
3. 询问用户是否接受或要更改其中的项目；
4. 记录已接受的默认方案和明确的覆盖项；
5. 如果不确定，则将默认方案作为假设继续推进。

阶段 7：最终 Agent 构建交接

使用 templates/idea-package-readme-template.md 创建或更新 README.md。

最终交接文档命名为：

• 如果存在 UI 简报，则为 04-agent-build-handoff.md；
• 如果跳过了 UI 简报，则为 03-agent-build-handoff.md。

创建交接文档时加载 idea-to-implementation-doc，因为规范交接模板位于其中。

交接文档必须包括：

• 任务使命；
• 产品愿景；
• 不可妥协的要求；
• UI／设计方向或明确的 UI 假设；
• 范围外事项；
• 技术架构；
• 实施阶段；
• 构建任务；
• 测试要求；
• 验证命令／检查项；
• 验收标准；
• 完成定义检查清单；
• 面向构建 Agent 的提示词；
• 明确的 Superpowers 交接说明。

阶段 8：规范审查／就绪门槛

创建：

• 如果存在 UI 简报，则为 05-spec-review.md；
• 如果跳过了 UI 简报，则为 04-spec-review.md。

审查以下内容：

• 产品目标是否明确；
• UI／设计预期是否足够清晰，能让新的 Agent 避免产出泛泛而谈的结果；
• 需求是否可测试；
• 是否仍存在未解决的产品决策；
• 是否仍存在未解决的技术决策；
• 验收标准是否具体；
• 完成定义是否明确；
• 新的 Agent 能否直接根据文件构建，而不必提出显而易见的问题；
• 是否包含测试与验证要求；
• 非目标是否能防止范围蔓延。

结论：

• PASS — 已准备就绪，可以交给 Superpowers。
• PASS WITH CHANGES — 基本就绪；请先修复列出的问题。
• FAIL — 存在过多歧义或内容不完整。

阶段 9：审查／计划审查

如果用户希望进行评审，请分别审查各项文档：

• 设计文档以产品为核心；
• UI 简报提供具体的屏幕／风格／状态指导，但不指定不必要的代码；
• 实施文档以构建为核心；
• 最终交接文档可直接交给 Agent 使用；
• 规范审查如实说明不足之处；
• 套件摘要不重复所有专题文档的内容。

推进规则与覆盖短语

Lite 模式规则

• 快速记录；不要强行进行研究、编写 UI 简报或规划实施。
• 起草前最多提出 3-5 个澄清问题，除非用户希望提出更多问题。
• 除非用户升级到 Full 模式，或明确要求提供 UI／模型图方向，否则不要创建 02-ui-design-brief.md、实施规范、构建交接文档或规范审查文档。
• 如果用户表示这个想法只是个备注，就将其保留为备注。

Full 模式规则

• 在目标用户、问题和核心行为清晰到足以概述之前，不要从采集阶段进入设计阶段。
• 如果尚未解决的产品或 UI 问题会影响架构、MVP 范围或核心界面，就不要从设计阶段进入实现阶段。
• 在实现阶段划分、测试要求、验收标准和完成标准齐备之前，不要创建最终构建交接文档。
• 如果缺少验证检查、仍有重大产品或技术决策待定，或界面要求对于界面密集型应用来说过于模糊，就不要将规格审查标记为 PASS。
• 如果跳过 UI 阶段，请保留 UI 假设并在后续阶段中继续使用，而不是因此停下。

用户覆盖短语

用户可以使用以下确切短语强制推进：

GREENLIGHT NEXT STAGE

用户说出该短语时，进入下一阶段。简要说明风险，将未解决事项记入“待解决问题 / 假设”，然后继续。这不代表可以执行不安全操作或泄露凭证。

运行规则

• 保持工作流模块化。
• 不同阶段尽量使用不同文件。
• 以 Markdown 格式保存进度。
• 用户确认产品、架构或 UI 决策后，更新工作中的想法记录。
• 保持可复用的技能内容可公开分享；不要嵌入私有产品计划或凭证。
• 如果用户说停止、够了、暂时到此为止、完成了、先起草，或写下来，就停止提问并立即起草。
• 如果用户想要更轻量的体验，请使用 Lite 模式。
• 如果跳过某个阶段，请沿用之前的工作流，并记录相关假设。

与专注型技能的关系

• 用户只想完成设计阶段时，使用 idea-to-design-doc。
• 用户需要 UI 方向、生成的 UI 概念、逐屏模拟稿说明或构建后的 UI 改版时，使用 idea-to-ui-design-brief。
• 用户只想制定实现计划时，使用 idea-to-implementation-doc。
• 用户需要完整系统时，使用 idea-superpowers-suite。

与 Superpowers 的关系

idea 工作流是产品/规格前端流程。Superpowers 是执行规范流程。

预期交接流程：

1. idea-superpowers-suite 收集想法并提出澄清问题。
2. idea-to-design-doc 生成设计/规格文档。
3. idea-to-ui-design-brief 可选择生成 UI 方向和图像生成概念提示词。
4. idea-to-implementation-doc 生成可直接用于构建的 Markdown 交接文档。
5. Superpowers 负责验证、规划、实现、测试、审查和核验。

idea 工作流应为 Superpowers 提供高质量输入，而不是取代 Superpowers 的执行流程。

参考文件

• references/interview-question-bank.md — 用于 Lite 和 Full 访谈的可复用问题库。
• references/example-cli-tool-build-handoff.md — 小型开发者 CLI 工具的通用最终交接示例。
• references/example-saas-web-app-build-handoff.md — 小型 SaaS/网页应用的通用最终交接示例。
• references/example-automation-script-build-handoff.md — 实用自动化工作流的通用最终交接示例。

模板

• idea-to-implementation-doc/templates/agent-build-handoff-template.md — 最终 Agent/Superpowers 构建交接文档的必需结构。
• templates/idea-package-readme-template.md — Full 模式想法文件夹的 README/状态索引。

常见误区

1. 将 UI 阶段设为必需阶段。默认情况下，UI 阶段是可选的，且仅适用于 Full 模式。
2. 把生成的图像当作事实来源。应将图像转化为书面的 UI 要求。
3. 不一致地重新编号现有文件包。保留既定编号并更新 README 映射。
4. 让 Lite 模式负担过重。除非用户要求 UI 或 Full 模式，否则应保持 Lite 流程轻量快捷。
5. 生成泛泛而谈、质量低劣的 UI。应使用符合产品特点的屏幕、状态和操作。
6. 在影响范围的产品和 UI 决策尚未明确前就开始编写代码。

验证清单

• 模式已正确选择或推断。
• Lite 模式保持轻量，除非明确升级。
• Full 模式的产物按阶段分开。
• 仅在有用或有需求时提供 UI 简报，否则沿用 UI 假设。
• 将可选的图像生成提示词视为概念，而非实现依据。
• README 产物清单与实际文件名和编号一致。
• 最终交接包含 UI 方向或明确的 UI 假设。
• 规格审查如实报告尚未解决的产品、UI 和技术问题。