安装热度榜

brainstorming

来自 obra/superpowers 的 brainstorming skill,用于在任何创造性工作(新功能、组件、功能修改)之前,通过人机协作对话把想法转化为完整设计与规格。核心机制是先对请求分类为三条路径之一——Spike(可行性验证,产出结论而非保留代码)、Bounded(针对仓库中已有代码的小范围改动,在对话中给出简短设计)、Architectural(新项目或子系统,走完整流程);若存疑则取更重路径,任务中途发现隐藏复杂度只能升级、不可降级。它要求用一句话写下对意图、约束与成功标准的理解供人纠正,一次只问一个重要问题,架构路径需提出 2-3 种方案、分段呈现设计、写入 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md 并提交、做占位符/一致性/范围/歧义自查,再经用户审阅后调用 writing-plans skill 生成实施计划。skill 内含 HARD-GATE:任何实现动作前必须获得对应阶段的明确批准,并强调“太简单不需要设计”是反模式。还提供可选的可视化伴侣:仅在确实出现图示比文字更清楚的问题时才单独发消息提议,获批后用浏览器标签页展示原型与图表。

分类
Agent 工作流
榜单排名
#162
安装量
382,242

它能做什么

中文摘要

来自 obra/superpowers 的 brainstorming skill,用于在任何创造性工作(新功能、组件、功能修改)之前,通过人机协作对话把想法转化为完整设计与规格。核心机制是先对请求分类为三条路径之一——Spike(可行性验证,产出结论而非保留代码)、Bounded(针对仓库中已有代码的小范围改动,在对话中给出简短设计)、Architectural(新项目或子系统,走完整流程);若存疑则取更重路径,任务中途发现隐藏复杂度只能升级、不可降级。它要求用一句话写下对意图、约束与成功标准的理解供人纠正,一次只问一个重要问题,架构路径需提出 2-3 种方案、分段呈现设计、写入 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md 并提交、做占位符/一致性/范围/歧义自查,再经用户审阅后调用 writing-plans skill 生成实施计划。skill 内含 HARD-GATE:任何实现动作前必须获得对应阶段的明确批准,并强调“太简单不需要设计”是反模式。还提供可选的可视化伴侣:仅在确实出现图示比文字更清楚的问题时才单独发消息提议,获批后用浏览器标签页展示原型与图表。

为什么推荐

推荐理由

适合希望在动手写代码之前强制澄清需求、避免直接跳到实现的团队与个人。它把“理解意图—确认设计—获得批准—再实现”固化为可执行流程,并用 spike/bounded/architectural 三路径按任务规模分配流程重量,既避免小改动被过度文档化,也防止大项目缺少规格。附带的红旗对照表与 HARD-GATE 能有效抑制“太简单不用批准”“先写起来再说”等常见失败模式;架构路径可直接衔接 writing-plans skill,形成设计到计划的闭环。安装量约 36.8 万(来自 skills.sh 公开 all-time 排行榜),来源为 obra/superpowers。

什么时候用

适用场景

  • 在开发新功能、构建组件或修改既有行为之前,先澄清用户意图、需求与成功标准
  • 面对“能不能做到”的可行性问题时,走 Spike 路径低成本验证并给出结论建议
  • 针对仓库中已存在流程的小改动(新增开关、小端点、单文件修复),在对话中给出简短设计并获得批准
  • 启动新项目或新子系统、重构组件关系或改动对外接口时,走架构路径产出规格文档与实施计划
  • 需求过大涉及多个独立子系统时,先协助拆分项目,再对第一个子项目走标准设计流程
  • 在已有代码库中工作时,先探查结构与既有模式,并把服务当前目标的针对性改进纳入设计
  • 出现需要图示才能讲清的布局、原型或架构问题时,按需启用浏览器可视化伴侣逐题决定展示方式

使用前先看

主要亮点

  • 01

    HARD-GATE 规定:任何实现动作(调用实现类 skill、写产品代码、脚手架、安装依赖、创建外部项目)前必须完成所选路径的前置审批,仅批准某一阶段不等于批准后续未产出的产物

  • 02

    三条路径显式分类并在首个提问前说出分类结果供人覆盖:Spike 产出答案且构建物标注为一次性;Bounded 产出对话内简短设计;Architectural 走完整流程直至 writing-plans

  • 03

    路径只能单向升级:任务中途发现隐藏复杂度须停下说明并升级路径,没有任何情况在中途降级

  • 04

    每次只问一个问题,优先多选题,聚焦目的、约束与成功标准,并建议先评估范围,对需要拆分的多子系统项目先分解再逐个子项目走完整周期

  • 05

    架构路径产出物固定为 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md,须提交 git 并做占位符扫描、内部一致性、范围检查与歧义检查四项自查

  • 06

    架构路径的终端状态限定为调用 writing-plans skill,明确不得调用 frontend-design、mcp-builder 等其他实现类 skill

  • 07

    可视化伴侣按需(just-in-time)提议且提议必须是单独一条消息,不与其他内容混发;即便用户接受,也需逐题判断用浏览器还是终端,测试标准是“看到是否比读到更易理解”

  • 08

    提供红旗对照表纠正常见误区,例如“我懂这类应用所以算 bounded”“spike 能跑就保留代码”“快做完了不用重新分类”等

  • 09

    包含设计隔离与清晰度指引:拆成单一职责、通过明确接口通信、可独立理解与测试的单元,并针对既有代码库要求沿用现有模式、只做服务当前目标的改进

原始文档

原文摘录

Brainstorming Ideas Into Designs Help turn ideas into fully formed designs and specs through natural collaborative dialogue. Start by classifying how much process the request needs, then work