ce%3Abrainstorm by everyinc/compound-engineering-plugin
npx skills add https://github.com/everyinc/compound-engineering-plugin --skill ce:brainstorm注意:当前年份是 2026 年。 在编写需求文档时请使用此日期。
构思通过协作对话来回答要构建什么。它先于 /ce:plan 执行,后者回答如何构建。
此工作流程的持久性产出是一份需求文档。在其他工作流程中,这可能被称为轻量级 PRD 或功能简报。在复合工程中,保持工作流程名称 brainstorm,但要使书面产物足够强大,以便规划阶段无需发明产品行为、范围边界或成功标准。
此技能不实现代码。它探索、澄清并记录决策,以供后续规划或执行使用。
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
AskUserQuestion,Codex 中的 request_user_input,Gemini 中的 ask_user),请优先使用。否则,在聊天中呈现编号选项,并在继续之前等待用户的回复。<feature_description> #$ARGUMENTS </feature_description>
如果上面的功能描述为空,请询问用户: "您想探索什么?请描述您正在考虑的功能、问题或改进。"
在获得用户提供的功能描述之前,请勿继续。
如果用户引用了现有的构思主题或文档,或者在 docs/brainstorms/ 目录中存在明显匹配的近期 *-requirements.md 文件:
明确需求的指标:
如果需求已经明确: 保持交互简短。确认理解并呈现简洁的下一步选项,而不是强制进行长时间的构思。仅当需要向规划或后续审查进行持久性交接时才编写简短的需求文档。完全跳过阶段 1.1 和 1.2 — 直接进入阶段 1.3 或阶段 3。
使用功能描述加上轻量级的仓库扫描来对工作进行分类:
如果范围不明确,提出一个有针对性的问题来消除歧义,然后继续。
在进行实质性构思之前扫描仓库。根据范围匹配扫描深度:
轻量级 — 搜索主题,检查是否已存在类似内容,然后继续。
标准和深度 — 两次扫描:
约束检查 — 检查项目指导文件(AGENTS.md,以及 CLAUDE.md 仅当保留为兼容性上下文时),寻找影响构思的工作流程、产品或范围约束。如果这些没有提供任何信息,则继续。
主题扫描 — 搜索相关术语。如果存在,阅读最相关的现有产物(构思、计划、规范、技能、功能文档)。浏览涵盖类似行为的相邻示例。
如果在简短扫描后没有发现明显内容,说明情况并继续。不要偏离到技术规划 — 避免检查测试、迁移、部署或低级架构,除非构思本身是关于技术决策的。
在生成方法之前,挑战请求以发现框架错误。根据范围匹配深度:
轻量级:
标准:
深度 — 标准问题加上:
在可用时使用平台的阻塞式提问工具(参见交互规则)。否则,在聊天中呈现编号选项,并在继续之前等待用户的回复。
指导原则:
退出条件: 继续直到想法清晰或用户明确希望继续。
如果存在多个合理的方向,根据研究和对话提出 2-3 个具体方法。否则直接陈述推荐的方向。
在有用时,包含一个刻意追求更高收益的替代方案:
对于每种方法,提供:
首先提出你的推荐并解释原因。当增加的复杂性带来真正的维护成本时,倾向于更简单的解决方案,但不要仅仅因为不是严格必要就拒绝低成本、高价值的美化工作。
如果一种方法明显最佳且替代方案没有意义,则跳过菜单,直接陈述推荐。
如果相关,指出选择是:
仅当对话产生了值得保存的持久性决策时,才编写或更新需求文档。
此文档应表现得像一个没有 PRD 繁文缛节的轻量级 PRD。包含规划阶段良好执行所需的内容,并跳过对该范围没有价值的章节。
需求文档用于产品定义和范围控制。不要包含实现细节,例如库、模式、端点、文件布局或代码结构,除非构思本身是技术性的,并且这些细节本身就是决策的主题。
非平凡工作所需的内容:
在实质性有用时包含:
文档结构: 使用此模板,并省略明显不适用的可选部分:
---
date: YYYY-MM-DD
topic: <kebab-case-topic>
---
# <主题标题>
## 问题框架
[谁受影响,什么在改变,以及为什么重要]
## 需求
- R1. [具体的面向用户的行为或需求]
- R2. [具体的面向用户的行为或需求]
## 成功标准
- [我们将如何知道这解决了正确的问题]
## 范围边界
- [有意的非目标或排除项]
## 关键决策
- [决策]: [理由]
## 依赖项 / 假设
- [仅在重要时包含]
## 未决问题
### 规划前需解决
- [影响 R1][用户决策] [在规划可以继续进行之前必须回答的问题]
### 推迟到规划阶段
- [影响 R2][技术] [应在规划或代码库探索期间回答的问题]
- [影响 R2][需要研究] [很可能需要在规划期间研究的问题]
## 后续步骤
[如果 `规划前需解决` 为空:`→ /ce:plan` 进行结构化实施规划]
[如果 `规划前需解决` 不为空:`→ 恢复 /ce:brainstorm` 以在规划前解决阻塞性问题]
对于标准和深度构思,通常需要需求文档。
对于轻量级构思,保持文档紧凑。当用户只需要简要的对齐且无需保存持久性决策时,跳过文档创建。
对于只有 1-3 个简单需求的非常小的需求文档,使用纯要点需求是可以接受的。对于标准和深度需求文档,使用稳定的 ID,如 R1、R2、R3,以便规划和后续审查可以明确地引用它们。
当工作简单时,合并章节而不是填充它们。简短的需求文档比臃肿的更好。
在最终确定之前,检查:
ce:plan 还需要发明什么?如果规划阶段需要发明产品行为、范围边界或成功标准,则构思尚未完成。
在编写之前确保 docs/brainstorms/ 目录存在。
如果文档包含未决问题:
规划前需解决规划前需解决 非空,默认情况下在构思期间继续处理这些问题推迟到规划阶段 的问题推迟到规划阶段 下,当它们在那里得到更好回答时[需要研究] 等标签在可用时使用平台的阻塞式提问工具呈现后续步骤(参见交互规则)。否则在聊天中呈现编号选项并结束回合。
如果 规划前需解决 包含任何项目:
推迟到规划阶段 的问题规划前需解决 仍为非空时,不要提供 进入规划 或 直接进入工作 选项当没有阻塞性问题时提问: "构思完成。您接下来想做什么?"
当存在阻塞性问题且用户希望暂停时提问: "构思暂停。规划被阻塞,直到剩余问题得到解决。您接下来想做什么?"
仅呈现适用的选项:
/ce:plan 进行结构化实施规划如果不满足直接工作的条件,则完全省略该选项。
如果用户选择"进入规划(推荐)":
在当前会话中立即运行 /ce:plan。当存在需求文档时传递其路径;否则传递最终构思决策的简洁摘要。不要先打印结束摘要。
如果用户选择"直接进入工作":
在当前会话中立即运行 /ce:work,使用最终构思输出作为上下文。如果存在紧凑的需求文档,传递其路径。不要先打印结束摘要。
如果用户选择"分享到 Proof":
CONTENT=$(cat docs/brainstorms/YYYY-MM-DD-<topic>-requirements.md)
TITLE="Requirements: <topic title>"
RESPONSE=$(curl -s -X POST https://www.proofeditor.ai/share/markdown \
-H "Content-Type: application/json" \
-d "$(jq -n --arg title "$TITLE" --arg markdown "$CONTENT" --arg by "ai:compound" '{title: $title, markdown: $markdown, by: $by}')")
PROOF_URL=$(echo "$RESPONSE" | jq -r '.tokenUrl')
突出显示 URL:在 Proof 中查看与协作:<PROOF_URL>
如果 curl 失败,则静默跳过。然后返回到阶段 4 的选项。
如果用户选择"提出更多问题": 返回到阶段 1.3(协作对话),并继续一次一个地向用户提问以进一步优化设计。更深入地探讨边界情况、约束、偏好或尚未探索的领域。继续直到用户满意,然后返回到阶段 4。暂时不要显示结束摘要。
如果用户选择"审查和优化":
加载 document-review 技能并将其应用于需求文档。
当 document-review 返回"审查完成"时,返回到正常的阶段 4 选项,并仅呈现仍然适用的选项。暂时不要显示结束摘要。
仅当此工作流程运行结束或交接时使用结束摘要,而不是当返回到阶段 4 选项时。
当完成并准备好进行规划时,显示:
构思完成!
需求文档:docs/brainstorms/YYYY-MM-DD-<topic>-requirements.md # 如果已创建
关键决策:
- [决策 1]
- [决策 2]
推荐后续步骤:`/ce:plan`
如果用户在 规划前需解决 仍有内容时暂停,显示:
构思暂停。
需求文档:docs/brainstorms/YYYY-MM-DD-<topic>-requirements.md # 如果已创建
规划被以下问题阻塞:
- [阻塞性问题 1]
- [阻塞性问题 2]
准备好在规划前解决这些问题时,使用 `/ce:brainstorm` 恢复。
每周安装次数
71
仓库
GitHub 星标数
10.9K
首次出现
12 天前
安装于
codex71
amp70
gemini-cli70
kimi-cli70
cursor70
opencode70
Note: The current year is 2026. Use this when dating requirements documents.
Brainstorming helps answer WHAT to build through collaborative dialogue. It precedes /ce:plan, which answers HOW to build it.
The durable output of this workflow is a requirements document. In other workflows this might be called a lightweight PRD or feature brief. In compound engineering, keep the workflow name brainstorm, but make the written artifact strong enough that planning does not need to invent product behavior, scope boundaries, or success criteria.
This skill does not implement code. It explores, clarifies, and documents decisions for later planning or execution.
AskUserQuestion in Claude Code, request_user_input in Codex, ask_user in Gemini). Otherwise, present numbered options in chat and wait for the user's reply before proceeding.<feature_description> #$ARGUMENTS </feature_description>
If the feature description above is empty, ask the user: "What would you like to explore? Please describe the feature, problem, or improvement you're thinking about."
Do not proceed until you have a feature description from the user.
If the user references an existing brainstorm topic or document, or there is an obvious recent matching *-requirements.md file in docs/brainstorms/:
Clear requirements indicators:
If requirements are already clear: Keep the interaction brief. Confirm understanding and present concise next-step options rather than forcing a long brainstorm. Only write a short requirements document when a durable handoff to planning or later review would be valuable. Skip Phase 1.1 and 1.2 entirely — go straight to Phase 1.3 or Phase 3.
Use the feature description plus a light repo scan to classify the work:
If the scope is unclear, ask one targeted question to disambiguate and then proceed.
Scan the repo before substantive brainstorming. Match depth to scope:
Lightweight — Search for the topic, check if something similar already exists, and move on.
Standard and Deep — Two passes:
Constraint Check — Check project instruction files (AGENTS.md, and CLAUDE.md only if retained as compatibility context) for workflow, product, or scope constraints that affect the brainstorm. If these add nothing, move on.
Topic Scan — Search for relevant terms. Read the most relevant existing artifact if one exists (brainstorm, plan, spec, skill, feature doc). Skim adjacent examples covering similar behavior.
If nothing obvious appears after a short scan, say so and continue. Do not drift into technical planning — avoid inspecting tests, migrations, deployment, or low-level architecture unless the brainstorm is itself about a technical decision.
Before generating approaches, challenge the request to catch misframing. Match depth to scope:
Lightweight:
Standard:
Deep — Standard questions plus:
Use the platform's blocking question tool when available (see Interaction Rules). Otherwise, present numbered options in chat and wait for the user's reply before proceeding.
Guidelines:
Exit condition: Continue until the idea is clear OR the user explicitly wants to proceed.
If multiple plausible directions remain, propose 2-3 concrete approaches based on research and conversation. Otherwise state the recommended direction directly.
When useful, include one deliberately higher-upside alternative:
For each approach, provide:
Lead with your recommendation and explain why. Prefer simpler solutions when added complexity creates real carrying cost, but do not reject low-cost, high-value polish just because it is not strictly necessary.
If one approach is clearly best and alternatives are not meaningful, skip the menu and state the recommendation directly.
If relevant, call out whether the choice is:
Write or update a requirements document only when the conversation produced durable decisions worth preserving.
This document should behave like a lightweight PRD without PRD ceremony. Include what planning needs to execute well, and skip sections that add no value for the scope.
The requirements document is for product definition and scope control. Do not include implementation details such as libraries, schemas, endpoints, file layouts, or code structure unless the brainstorm is inherently technical and those details are themselves the subject of the decision.
Required content for non-trivial work:
Include when materially useful:
Document structure: Use this template and omit clearly inapplicable optional sections:
---
date: YYYY-MM-DD
topic: <kebab-case-topic>
---
# <Topic Title>
## Problem Frame
[Who is affected, what is changing, and why it matters]
## Requirements
- R1. [Concrete user-facing behavior or requirement]
- R2. [Concrete user-facing behavior or requirement]
## Success Criteria
- [How we will know this solved the right problem]
## Scope Boundaries
- [Deliberate non-goal or exclusion]
## Key Decisions
- [Decision]: [Rationale]
## Dependencies / Assumptions
- [Only include if material]
## Outstanding Questions
### Resolve Before Planning
- [Affects R1][User decision] [Question that must be answered before planning can proceed]
### Deferred to Planning
- [Affects R2][Technical] [Question that should be answered during planning or codebase exploration]
- [Affects R2][Needs research] [Question that likely requires research during planning]
## Next Steps
[If `Resolve Before Planning` is empty: `→ /ce:plan` for structured implementation planning]
[If `Resolve Before Planning` is not empty: `→ Resume /ce:brainstorm` to resolve blocking questions before planning]
For Standard and Deep brainstorms, a requirements document is usually warranted.
For Lightweight brainstorms, keep the document compact. Skip document creation when the user only needs brief alignment and no durable decisions need to be preserved.
For very small requirements docs with only 1-3 simple requirements, plain bullet requirements are acceptable. For Standard and Deep requirements docs, use stable IDs like R1, R2, R3 so planning and later review can refer to them unambiguously.
When the work is simple, combine sections rather than padding them. A short requirements document is better than a bloated one.
Before finalizing, check:
ce:plan still have to invent if this brainstorm ended now?If planning would need to invent product behavior, scope boundaries, or success criteria, the brainstorm is not complete yet.
Ensure docs/brainstorms/ directory exists before writing.
If a document contains outstanding questions:
Resolve Before Planning only for questions that truly block planningResolve Before Planning is non-empty, keep working those questions during the brainstorm by defaultDeferred to Planning question before proceedingDeferred to Planning when they are better answered there[Needs research] when the planner should likely investigate the question rather than answer it from repo context alonePresent next steps using the platform's blocking question tool when available (see Interaction Rules). Otherwise present numbered options in chat and end the turn.
If Resolve Before Planning contains any items:
Deferred to Planning questionProceed to planning or Proceed directly to work while Resolve Before Planning remains non-emptyQuestion when no blocking questions remain: "Brainstorm complete. What would you like to do next?"
Question when blocking questions remain and user wants to pause: "Brainstorm paused. Planning is blocked until the remaining questions are resolved. What would you like to do next?"
Present only the options that apply:
/ce:plan for structured implementation planningIf the direct-to-work gate is not satisfied, omit that option entirely.
If user selects "Proceed to planning (Recommended)":
Immediately run /ce:plan in the current session. Pass the requirements document path when one exists; otherwise pass a concise summary of the finalized brainstorm decisions. Do not print the closing summary first.
If user selects "Proceed directly to work":
Immediately run /ce:work in the current session using the finalized brainstorm output as context. If a compact requirements document exists, pass its path. Do not print the closing summary first.
If user selects "Share to Proof":
CONTENT=$(cat docs/brainstorms/YYYY-MM-DD-<topic>-requirements.md)
TITLE="Requirements: <topic title>"
RESPONSE=$(curl -s -X POST https://www.proofeditor.ai/share/markdown \
-H "Content-Type: application/json" \
-d "$(jq -n --arg title "$TITLE" --arg markdown "$CONTENT" --arg by "ai:compound" '{title: $title, markdown: $markdown, by: $by}')")
PROOF_URL=$(echo "$RESPONSE" | jq -r '.tokenUrl')
Display the URL prominently: View & collaborate in Proof: <PROOF_URL>
If the curl fails, skip silently. Then return to the Phase 4 options.
If user selects "Ask more questions": Return to Phase 1.3 (Collaborative Dialogue) and continue asking the user questions one at a time to further refine the design. Probe deeper into edge cases, constraints, preferences, or areas not yet explored. Continue until the user is satisfied, then return to Phase 4. Do not show the closing summary yet.
If user selects "Review and refine":
Load the document-review skill and apply it to the requirements document.
When document-review returns "Review complete", return to the normal Phase 4 options and present only the options that still apply. Do not show the closing summary yet.
Use the closing summary only when this run of the workflow is ending or handing off, not when returning to the Phase 4 options.
When complete and ready for planning, display:
Brainstorm complete!
Requirements doc: docs/brainstorms/YYYY-MM-DD-<topic>-requirements.md # if one was created
Key decisions:
- [Decision 1]
- [Decision 2]
Recommended next step: `/ce:plan`
If the user pauses with Resolve Before Planning still populated, display:
Brainstorm paused.
Requirements doc: docs/brainstorms/YYYY-MM-DD-<topic>-requirements.md # if one was created
Planning is blocked by:
- [Blocking question 1]
- [Blocking question 2]
Resume with `/ce:brainstorm` when ready to resolve these before planning.
Weekly Installs
71
Repository
GitHub Stars
10.9K
First Seen
12 days ago
Installed on
codex71
amp70
gemini-cli70
kimi-cli70
cursor70
opencode70
AI 代码实施计划编写技能 | 自动化开发任务分解与 TDD 流程规划工具
50,900 周安装
Skill Creator 指南:如何为 Claude AI 创建高效技能模块 | 技能开发与优化
139 周安装
CSS伪元素最佳实践与视图过渡API检查工具 - 提升前端代码质量
139 周安装
Vercel React 最佳实践指南:65条性能优化规则,提升Next.js应用性能
141 周安装
NativeWind v4 Expo 配置指南:React Native Tailwind CSS 样式库集成教程
140 周安装
AI技能创建指南 - 如何为智能体开发高效、模块化的专业技能包
139 周安装
MCP CLI 使用指南:动态调用 MCP 服务器工具,无需永久集成
142 周安装