brainstorming by everyinc/compound-engineering-plugin
npx skills add https://github.com/everyinc/compound-engineering-plugin --skill brainstorming此技能提供详细的过程知识,用于开展有效的头脑风暴会议,在深入探讨如何构建之前,先明确要构建什么。
在以下情况下,头脑风暴很有价值:
在以下情况下,可以跳过头脑风暴:
在深入提问之前,先评估是否需要头脑风暴。
需求清晰的信号:
需要头脑风暴的信号:
如果需求清晰,建议:"您的需求似乎很明确。请考虑直接进入规划或实施阶段。"
一次只问一个问题,以理解用户的意图。避免用多个问题让用户不知所措。
提问技巧:
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
需要探讨的关键主题:
| 主题 | 示例问题 |
|---|---|
| 目的 | 这解决了什么问题?动机是什么? |
| 用户 | 谁使用这个?他们的使用场景是什么? |
| 限制 | 有任何技术限制吗?时间线?依赖项? |
| 成功标准 | 您将如何衡量成功?理想路径是什么? |
| 边界情况 | 不应该发生什么?需要考虑任何错误状态吗? |
| 现有模式 | 代码库中是否有类似的功能可以遵循? |
退出条件: 持续进行,直到想法清晰为止,或者用户说"继续"或"我们继续吧"
理解想法后,提出 2-3 个具体方法。
每种方法的结构:
### 方法 A: [名称]
[2-3 句话的描述]
**优点:**
- [好处 1]
- [好处 2]
**缺点:**
- [缺点 1]
- [缺点 2]
**最佳适用场景:** [此方法最适用的环境]
指导原则:
以结构化格式总结关键决策。
设计文档结构:
---
date: YYYY-MM-DD
topic: <kebab-case-topic>
---
# <主题标题>
## 我们要构建什么
[简洁描述——最多 1-2 段]
## 为何选择此方法
[简要解释考虑过的方法以及选择此方法的原因]
## 关键决策
- [决策 1]: [理由]
- [决策 2]: [理由]
## 待解决问题
- [任何需要在规划阶段解决的未决问题]
## 后续步骤
→ `/ce:plan` 获取实施细节
输出位置: docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md
为下一步做什么提供明确的选项:
/ce:plan在头脑风暴期间,积极抵制复杂性:
保持各部分简短——最多 200-300 字。每次输出一部分后,暂停以验证理解:
这可以防止在方向不一致的设计上浪费精力。
| 反模式 | 更好的方法 |
|---|---|
| 一次问 5 个问题 | 一次问一个 |
| 直接跳转到实施细节 | 专注于是什么,而不是如何做 |
| 提出过于复杂的解决方案 | 从简单开始,仅在需要时增加复杂性 |
| 忽略现有代码库模式 | 先研究现有的内容 |
| 未经验证就做出假设 | 明确陈述假设并进行确认 |
| 创建冗长的设计文档 | 保持简洁——细节放在规划中 |
头脑风暴回答要构建什么:
规划回答如何构建它:
当存在头脑风暴输出时,/ce:plan 应检测到它并将其用作输入,跳过其自身的想法细化阶段。
每周安装量
275
代码仓库
GitHub 星标数
11.0K
首次出现
2026 年 1 月 22 日
安全审计
已安装于
opencode238
gemini-cli229
codex224
claude-code213
github-copilot206
cursor194
This skill provides detailed process knowledge for effective brainstorming sessions that clarify WHAT to build before diving into HOW to build it.
Brainstorming is valuable when:
Brainstorming can be skipped when:
Before diving into questions, assess whether brainstorming is needed.
Signals that requirements are clear:
Signals that brainstorming is needed:
If requirements are clear, suggest: "Your requirements seem clear. Consider proceeding directly to planning or implementation."
Ask questions one at a time to understand the user's intent. Avoid overwhelming with multiple questions.
Question Techniques:
Prefer multiple choice when natural options exist
Start broad, then narrow
Validate assumptions explicitly
Ask about success criteria early
Key Topics to Explore:
| Topic | Example Questions |
|---|---|
| Purpose | What problem does this solve? What's the motivation? |
| Users | Who uses this? What's their context? |
| Constraints | Any technical limitations? Timeline? Dependencies? |
| Success | How will you measure success? What's the happy path? |
| Edge Cases | What shouldn't happen? Any error states to consider? |
| Existing Patterns | Are there similar features in the codebase to follow? |
Exit Condition: Continue until the idea is clear OR user says "proceed" or "let's move on"
After understanding the idea, propose 2-3 concrete approaches.
Structure for Each Approach:
### Approach A: [Name]
[2-3 sentence description]
**Pros:**
- [Benefit 1]
- [Benefit 2]
**Cons:**
- [Drawback 1]
- [Drawback 2]
**Best when:** [Circumstances where this approach shines]
Guidelines:
Summarize key decisions in a structured format.
Design Doc Structure:
---
date: YYYY-MM-DD
topic: <kebab-case-topic>
---
# <Topic Title>
## What We're Building
[Concise description—1-2 paragraphs max]
## Why This Approach
[Brief explanation of approaches considered and why this one was chosen]
## Key Decisions
- [Decision 1]: [Rationale]
- [Decision 2]: [Rationale]
## Open Questions
- [Any unresolved questions for the planning phase]
## Next Steps
→ `/ce:plan` for implementation details
Output Location: docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md
Present clear options for what to do next:
/ce:planDuring brainstorming, actively resist complexity:
Keep sections short—200-300 words maximum. After each section of output, pause to validate understanding:
This prevents wasted effort on misaligned designs.
| Anti-Pattern | Better Approach |
|---|---|
| Asking 5 questions at once | Ask one at a time |
| Jumping to implementation details | Stay focused on WHAT, not HOW |
| Proposing overly complex solutions | Start simple, add complexity only if needed |
| Ignoring existing codebase patterns | Research what exists first |
| Making assumptions without validating | State assumptions explicitly and confirm |
| Creating lengthy design documents | Keep it concise—details go in the plan |
Brainstorming answers WHAT to build:
Planning answers HOW to build it:
When brainstorm output exists, /ce:plan should detect it and use it as input, skipping its own idea refinement phase.
Weekly Installs
275
Repository
GitHub Stars
11.0K
First Seen
Jan 22, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykPass
Installed on
opencode238
gemini-cli229
codex224
claude-code213
github-copilot206
cursor194
飞书日程待办摘要工作流:AI自动生成每日/每周开工报告,提升个人生产力
15,600 周安装