openclaw 网盘下载
OpenClaw

技能详情(站内镜像,无评论)

首页 > 技能库 > Superpowers Brainstorming

Use before any creative work - creating features, building components, adding functionality, or modifying behavior - guides through exploration, questioning,...

开发与 DevOps

许可证:MIT-0

MIT-0 ·免费使用、修改和重新分发。无需归因。

版本:v1.0.0

统计:⭐ 0 · 41 · 0 current installs · 0 all-time installs

0

安装量(当前) 0

🛡 VirusTotal :挂起 · OpenClaw :良性

Package:axelhu/superpowers-brainstorming

安全扫描(ClawHub)

  • VirusTotal :挂起
  • OpenClaw :良性

OpenClaw 评估

The skill's instructions and requirements are coherent with its stated purpose (structured pre-implementation design and approvals); nothing gratuitous or unrelated is requested.

目的

Name and description promise a guided brainstorming/design workflow; the SKILL.md only asks the agent to explore project files, ask clarifying questions, propose options, write a short design, run a self-review, get owner approval, commit the spec, and then call a dedicated 'writing-plans' skill. These actions are proportionate to the stated purpose.

说明范围

Instructions legitimately direct the agent to inspect the current project state (files, docs, recent commits) and to write & commit a design document to docs/.... This is within scope, but it implies read/write access to the repository and the filesystem; the skill does not declare how git authentication or repository access is handled.

安装机制

No install spec or code is provided (instruction-only), so nothing is written to disk or fetched during install. Low install risk.

证书

The skill declares no environment variables or credentials, which matches the simple brainstorming purpose. However, the requirement to commit to git implies the agent will need repository write permissions (or credentials) at runtime — these are not declared here. Also the skill calls another skill ('superpowers-writing-plans'), so you should confirm that that secondary skill's requirements are acceptable before chaining.

持久

always is false and the skill does not request any special persistent privileges or modify other skills' settings. Autonomous invocation is enabled by default on the platform but that is normal and not excessive here.

综合结论

This skill appears to do what it says: guide a structured design and require owner approval before implementation. Before installing, confirm two runtime realities: (1) the agent will need permission to read the repo and to write/commit files — ensure the platform or agent has only the minimal git access you want to grant, and (2) check the 'superpowers-writing-plans' skill (which this skill will call) to verify its access and behavior. If you…

安装(复制给龙虾 AI)

将下方整段复制到龙虾中文库对话中,由龙虾按 SKILL.md 完成安装。

请把本段交给龙虾中文库(龙虾 AI)执行:为本机安装 OpenClaw 技能「Superpowers Brainstorming」。简介:Use before any creative work - creating features, building components, adding f…。
请 fetch 以下地址读取 SKILL.md 并按文档完成安装:https://raw.githubusercontent.com/openclaw/skills/refs/heads/main/skills/axelhu/superpowers-brainstorming/SKILL.md
(来源:yingzhi8.cn 技能库)

SKILL.md

打开原始 SKILL.md(GitHub raw)

---
name: superpowers-brainstorming
description: Use before any creative work - creating features, building components, adding functionality, or modifying behavior - guides through exploration, questioning, design proposal, and spec documentation before any implementation
---

# Superpowers Brainstorming - 想法到设计

## 核心准则

**在创造性工作之前,通过协作对话将想法转化为完整的设计和规格说明。**

**触发条件:** 创建功能、构建组件、添加功能、修改行为。

## 硬性门槛

```
在调用任何实现技能、写任何代码、搭建任何项目、或采取任何实现动作之前,
必须先展示设计并获得主人批准。
无论感知到的复杂度如何,每个项目都要走这个流程。
```

"简单"项目正是未审视假设造成最多浪费的地方。设计可以很短(真正简单的项目几句话就够),但必须展示并获得批准。

## 流程检查表

按顺序完成每个任务:

1. **探索项目上下文** — 检查文件、文档、最近提交
2. **提出视觉化同伴**(如果主题涉及视觉问题)— 这是独立消息,不与澄清问题合并
3. **提出澄清问题** — 一次一个,理解目的/约束/成功标准
4. **提出 2-3 种方案** — 带有权衡和推荐
5. **展示设计** — 按复杂度缩放各部分,在每个部分后获批准
6. **写设计文档** — 保存到 `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` 并 commit
7. **规格自审** — 快速内联检查占位符、矛盾、模糊、范围
8. **主人审查书面规格** — 在继续之前请主人审查规格文件
9. **过渡到实现** — 调用 `superpowers-writing-plans` 技能创建实现计划

**终点状态是调用 writing-plans。不要调用任何其他实现技能。**

## 流程详解

### 理解想法

- 先检查当前项目状态(文件、文档、最近提交)
- 在问详细问题前,评估范围:如果请求描述多个独立子系统(如"构建有聊天、文件存储、计费、分析的平台"),立即标记。不要在需要先分解的项目上花时间细化细节。
- 对于适当范围的项目,一次问一个问题来细化想法
- 尽量用多选问题,但开放问题也可以
- 一次只问一个问题——如果主题需要更多探索,拆成多个问题
- 重点理解:目的、约束、成功标准

### 探索方案

- 提出 2-3 个不同方案,带权衡
- 用对话方式展示选项,说明推荐和原因
- 用推荐选项开头并解释为什么

### 展示设计

- 一旦相信理解了要构建什么,就展示设计
- 每个部分按复杂度缩放:直接的几句话,复杂的 200-300 字
- 每个部分后问"这样看起来对吗"
- 覆盖:架构、组件、数据流、错误处理、测试
- 如果有不明白的地方准备好回去澄清

### 为隔离和清晰而设计

- 将系统分成更小的单元,每个有明确目的,通过清晰接口通信,可以独立理解和测试
- 对于每个单元,应该能回答:它做什么,你怎么用它,它依赖什么?
- 有人能在不读内部代码的情况下理解它做什么吗?能改变内部代码而不破坏消费者吗?如果不能,边界需要改进
- 更小、边界好的单元你也更容易处理——你更容易推理能放在脑子里的代码,编辑时也更可靠。当一个文件变大,通常是它做太多事的信号

### 现有代码库中工作

- 在提出变更前先探索当前结构。遵循已有模式。
- 对于影响工作的现有代码问题(如长得太大的文件、边界不清、职责混乱),把针对性改进作为设计的一部分——好开发者在工作的代码中会做这些改进。
- 不要提无关的重构。聚焦于服务当前目标的内容。

## 设计之后

**文档:**
- 将经验证的设计(规格)写到 `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`
- Commit 设计文档到 git

**规格自审:**
写完规格文档后,用新眼光看:

1. **占位符扫描:** 有"TBD"、"TODO"、不完整部分或模糊需求吗?修复它们。
2. **内部一致性:** 各部分有矛盾吗?架构和功能描述匹配吗?
3. **范围检查:** 这个范围对于单一实现计划够聚焦吗?需要分解吗?
4. **模糊检查:** 任何需求能有两种解释吗?如果有,选一个并明确。

内联修复问题。不需要重新审查——修复并继续。

**主人审查门槛:**
规格审查循环通过后,在继续之前请主人审查书面规格:

> "规格已写完并 commit 到 `<path>`。请审查,如果有要修改的告诉我,在我们开始写实现计划之前。"

等主人回复。如果请求变更,做修改并重新运行规格审查循环。只有在主人批准后才能继续。

**实现:**
- 调用 `superpowers-writing-plans` 技能创建详细实现计划
- 不要调用其他技能。writing-plans 是下一步。

## 关键原则

- **一次一个问题** — 不要用多个问题压垮
- **多选优先** — 比开放问题更容易回答
- **YAGNI 彻底** — 从所有设计中移除不必要功能
- **探索替代方案** — 在确定之前总是提出 2-3 个方案
- **增量验证** — 展示设计,获得批准后再继续
- **灵活** — 有不明白的回去澄清

## 视觉化同伴(Canvas)

当预期接下来的问题涉及视觉内容时(模型、布局图、图表),提供 canvas 展示:

- 使用 `canvas` 工具展示模型、图表、选项对比等视觉内容
- **每个问题决定是否用浏览器:** 用户看这个比读文字更好吗?
  - **用 canvas:** 内容本身是视觉的——模型、线框图、布局对比、架构图、并排视觉设计
  - **用文字:** 内容是文字的——需求问题、概念选择、权衡列表、A/B/C/D 文本选项、范围决策

关于 UI 主题的问题不自动是视觉问题。"在这个语境中个性意味着什么?"是概念问题——用文字。"哪种向导布局更好?"是视觉问题——用 canvas。

## 执行检查表

每次开始创意工作前,确认:

- [ ] 已探索项目上下文
- [ ] 已询问澄清问题(一次一个)
- [ ] 已提出 2-3 种方案并说明推荐
- [ ] 主人已批准设计
- [ ] 设计文档已写完并 commit
- [ ] 已做规格自审并修复问题
- [ ] 主人已审查书面规格
- [ ] 已调用 writing-plans 开始实现