$ ~/registry/skill/obra-brainstorming

SKILL

brainstorming

Name: brainstorming
Author: obra

在创意与实现前梳理用户意图、需求与方案方向，降低返工风险。

星标

★ 244,334

来源

GitHub

更新于

2026-07-02

// 安全评估需留意

仅提示词，不执行代码
开源可审计

总评

该技能材料显示其本质是开源的纯提示型 brainstorming/workflow 说明，不需要密钥也未声明任何远程连接，整体风险较低。需注意其文档要求检查项目文件、写入设计文档并提交 commit，但这些更像流程指引而非独立执行能力，通常属于有限注意事项。

凭证密钥低风险

材料明确标注无需密钥或环境变量，未见 token、API key 或凭证收集/存储要求，凭证泄露面很小。

网络外发低风险

未声明任何远程端点或外部服务调用；从提供材料看，未见将用户数据发送到第三方网络位置的说明。

代码执行低风险

系统检查项标注为 prompt-only，材料本身是流程约束与对话指引；虽提到后续可 invoke 其他 skill、commit 设计文档，但未显示其自身具备本机起进程或执行代码能力。

数据访问需留意

README 要求“check files, docs, recent commits”并将设计写入 `docs/superpowers/specs/...`，说明其预期流程会读取项目上下文并写入仓库文件；这属于技能常规数据访问范围，未见明显过度授权红旗。

来源供应链需留意

来源为 GitHub 开源仓库，具备可审计性，这是明显的降风险因素；但许可证未声明、star 为 0、维护状态未知，社区验证与持续维护证据较弱，因此供应链侧建议保持留意。

安全建议

在受限仓库或测试分支中先试用，确认其只用于设计讨论而非触发额外实现动作。
若要按 README 写入设计文档或提交 commit，先人工审阅拟写入内容与变更范围。
结合仓库实际情况核查开源仓库历史、维护记录和许可证信息后再纳入正式流程。

审计模型: gpt-5.4 · 2026-06-17

// 安装

复制安装指令，让 AI 自动完成配置 · 推荐新手

请帮我安装 askskill 上的 "brainstorming" 技能：
1. 下载 https://raw.githubusercontent.com/obra/superpowers/main/skills/brainstorming/SKILL.md
2. 保存为 ~/.claude/skills/brainstorming/SKILL.md
3. 装好后重载技能，告诉我可以用了

// 下载

下载 SKILL.md机读安装清单 ↗

// 用法示例

开发前需求澄清

输入

我要为电商后台新增批量退款功能。请先不要写代码，先通过头脑风暴帮我梳理用户目标、关键场景、边界条件、风险点，以及可行的交互与技术方案。

预期产出

一份结构化的需求与方案清单，包含目标、场景、限制、风险和实现方向建议。

组件设计前方案探索

输入

我要设计一个可复用的日期筛选组件。请先头脑风暴不同使用场景、用户操作习惯、状态设计、可访问性要求，以及组件 API 的设计选项，再给出推荐方案。

预期产出

多种设计思路的对比分析，以及一个更适合落地的推荐组件方案。

功能修改前影响评估

输入

我想修改现有通知系统的发送逻辑。请在改动前先头脑风暴这次变更可能影响的用户体验、业务规则、异常情况、回滚策略和测试重点。

预期产出

一份变更影响评估与实施前检查清单，帮助安全推进修改。

// 文档

Brainstorming Ideas Into Designs

Help turn ideas into fully formed designs and specs through natural collaborative dialogue.

Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval.

<HARD-GATE> Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity. </HARD-GATE>

Anti-Pattern: "This Is Too Simple To Need A Design"

Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval.

Checklist

You MUST create a task for each of these items and complete them in order:

Explore project context — check files, docs, recent commits
Offer visual companion (if topic will involve visual questions) — this is its own message, not combined with a clarifying question. See the Visual Companion section below.
Ask clarifying questions — one at a time, understand purpose/constraints/success criteria
Propose 2-3 approaches — with trade-offs and your recommendation
Present design — in sections scaled to their complexity, get user approval after each section
Write design doc — save to docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md and commit
Spec self-review — quick inline check for placeholders, contradictions, ambiguity, scope (see below)
User reviews written spec — ask user to review the spec file before proceeding
Transition to implementation — invoke writing-plans skill to create implementation plan

Process Flow

digraph brainstorming {
    "Explore project context" [shape=box];
    "Visual questions ahead?" [shape=diamond];
    "Offer Visual Companion\n(own message, no other content)" [shape=box];
    "Ask clarifying questions" [shape=box];
    "Propose 2-3 approaches" [shape=box];
    "Present design sections" [shape=box];
    "User approves design?" [shape=diamond];
    "Write design doc" [shape=box];
    "Spec self-review\n(fix inline)" [shape=box];
    "User reviews spec?" [shape=diamond];
    "Invoke writing-plans skill" [shape=doublecircle];

    "Explore project context" -> "Visual questions ahead?";
    "Visual questions ahead?" -> "Offer Visual Companion\n(own message, no other content)" [label="yes"];
    "Visual questions ahead?" -> "Ask clarifying questions" [label="no"];
    "Offer Visual Companion\n(own message, no other content)" -> "Ask clarifying questions";
    "Ask clarifying questions" -> "Propose 2-3 approaches";
    "Propose 2-3 approaches" -> "Present design sections";
    "Present design sections" -> "User approves design?";
    "User approves design?" -> "Present design sections" [label="no, revise"];
    "User approves design?" -> "Write design doc" [label="yes"];
    "Write design doc" -> "Spec self-review\n(fix inline)";
    "Spec self-review\n(fix inline)" -> "User reviews spec?";
    "User reviews spec?" -> "Write design doc" [label="changes requested"];
    "User reviews spec?" -> "Invoke writing-plans skill" [label="approved"];
}

The terminal state is invoking writing-plans. Do NOT invoke frontend-design, mcp-builder, or any other implementation skill. The ONLY skill you invoke after brainstorming is writing-plans.

The Process

Understanding the idea:

Check out the current project state first (files, docs, recent commits)

…

查看完整文档 ↗

通过测试驱动开发流程，先写测试再实现功能或修复缺陷。

obra装→

$ loading_

请帮我安装 askskill 上的 "brainstorming" 技能： 1. 下载 https://raw.githubusercontent.com/obra/superpowers/main/skills/brainstorming/SKILL.md 2. 保存为 ~/.claude/skills/brainstorming/SKILL.md 3. 装好后重载技能，告诉我可以用了

// 用法示例

开发前需求澄清

输入

我要为电商后台新增批量退款功能。请先不要写代码，先通过头脑风暴帮我梳理用户目标、关键场景、边界条件、风险点，以及可行的交互与技术方案。

预期产出

一份结构化的需求与方案清单，包含目标、场景、限制、风险和实现方向建议。

组件设计前方案探索

输入

我要设计一个可复用的日期筛选组件。请先头脑风暴不同使用场景、用户操作习惯、状态设计、可访问性要求，以及组件 API 的设计选项，再给出推荐方案。

预期产出

多种设计思路的对比分析，以及一个更适合落地的推荐组件方案。

功能修改前影响评估

输入

我想修改现有通知系统的发送逻辑。请在改动前先头脑风暴这次变更可能影响的用户体验、业务规则、异常情况、回滚策略和测试重点。

预期产出

一份变更影响评估与实施前检查清单，帮助安全推进修改。

// 文档

Brainstorming Ideas Into Designs

Help turn ideas into fully formed designs and specs through natural collaborative dialogue.

Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval.

Anti-Pattern: "This Is Too Simple To Need A Design"

Checklist

You MUST create a task for each of these items and complete them in order:

Explore project context — check files, docs, recent commits
Offer visual companion (if topic will involve visual questions) — this is its own message, not combined with a clarifying question. See the Visual Companion section below.
Ask clarifying questions — one at a time, understand purpose/constraints/success criteria
Propose 2-3 approaches — with trade-offs and your recommendation
Present design — in sections scaled to their complexity, get user approval after each section
Write design doc — save to docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md and commit
Spec self-review — quick inline check for placeholders, contradictions, ambiguity, scope (see below)
User reviews written spec — ask user to review the spec file before proceeding
Transition to implementation — invoke writing-plans skill to create implementation plan

Process Flow

digraph brainstorming {
    "Explore project context" [shape=box];
    "Visual questions ahead?" [shape=diamond];
    "Offer Visual Companion\n(own message, no other content)" [shape=box];
    "Ask clarifying questions" [shape=box];
    "Propose 2-3 approaches" [shape=box];
    "Present design sections" [shape=box];
    "User approves design?" [shape=diamond];
    "Write design doc" [shape=box];
    "Spec self-review\n(fix inline)" [shape=box];
    "User reviews spec?" [shape=diamond];
    "Invoke writing-plans skill" [shape=doublecircle];

    "Explore project context" -> "Visual questions ahead?";
    "Visual questions ahead?" -> "Offer Visual Companion\n(own message, no other content)" [label="yes"];
    "Visual questions ahead?" -> "Ask clarifying questions" [label="no"];
    "Offer Visual Companion\n(own message, no other content)" -> "Ask clarifying questions";
    "Ask clarifying questions" -> "Propose 2-3 approaches";
    "Propose 2-3 approaches" -> "Present design sections";
    "Present design sections" -> "User approves design?";
    "User approves design?" -> "Present design sections" [label="no, revise"];
    "User approves design?" -> "Write design doc" [label="yes"];
    "Write design doc" -> "Spec self-review\n(fix inline)";
    "Spec self-review\n(fix inline)" -> "User reviews spec?";
    "User reviews spec?" -> "Write design doc" [label="changes requested"];
    "User reviews spec?" -> "Invoke writing-plans skill" [label="approved"];
}

The terminal state is invoking writing-plans. Do NOT invoke frontend-design, mcp-builder, or any other implementation skill. The ONLY skill you invoke after brainstorming is writing-plans.

The Process

Understanding the idea:

Check out the current project state first (files, docs, recent commits)

…

查看完整文档 ↗