Back to Details

ce-brainstorm

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Brainstorm a Feature or Improvement

功能或改进方案头脑风暴

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.
IMPORTANT: All file references in generated documents must use repo-relative paths (e.g., 
src/models/user.rb
), never absolute paths. Absolute paths break portability across machines, worktrees, and teammates.
**注意：当前年份为2026年。**撰写需求文档时请以此年份为准。
头脑风暴通过协作对话帮助明确要开发什么。它先于 
/ce-plan
流程，后者负责解决如何开发的问题。
此工作流的持久输出是一份需求文档。在其他工作流中，这可能被称为轻量化PRD或功能简报。在复合工程中，工作流名称保留为 
brainstorm
，但生成的书面文档需足够完善，确保后续规划无需重新定义产品行为、范围边界或成功标准。
此技能不负责代码实现，仅用于探索、澄清并记录决策，供后续规划或执行环节使用。
重要提示：生成文档中所有文件引用必须使用仓库相对路径（例如：
src/models/user.rb
），绝对路径不可用。绝对路径会破坏跨机器、工作树及团队成员间的可移植性。

Core Principles

核心原则

  1. Assess scope first - Match the amount of ceremony to the size and ambiguity of the work.
  2. Be a thinking partner - Suggest alternatives, challenge assumptions, and explore what-ifs instead of only extracting requirements.
  3. Resolve product decisions here - User-facing behavior, scope boundaries, and success criteria belong in this workflow. Detailed implementation belongs in planning.
  4. Keep implementation out of the requirements doc by default - Do not include libraries, schemas, endpoints, file layouts, or code-level design unless the brainstorm itself is inherently about a technical or architectural change.
  5. Right-size the artifact - Simple work gets a compact requirements document or brief alignment. Larger work gets a fuller document. Do not add ceremony that does not help planning.
  6. Apply YAGNI to carrying cost, not coding effort - Prefer the simplest approach that delivers meaningful value. Avoid speculative complexity and hypothetical future-proofing, but low-cost polish or delight is worth including when its ongoing cost is small and easy to maintain.
  1. 先评估范围 - 流程的正式程度需与工作的规模和模糊度相匹配。
  2. 成为思考伙伴 - 提出替代方案、挑战假设并探索各种可能性，而非仅提取需求。
  3. 在此解决产品决策 - 用户可见的行为、范围边界和成功标准属于此工作流范畴。详细实现方案属于规划环节。
  4. 默认将实现细节排除在需求文档外 - 除非头脑风暴本身是关于技术或架构变更的，否则请勿包含库、 schema、端点、文件布局或代码级设计内容。
  5. 按需调整文档规模 - 简单工作只需简洁的需求文档或简短的对齐说明。大型工作则需要更完整的文档。不要添加对规划无帮助的繁琐流程。
  6. 对维护成本应用YAGNI原则，而非编码工作量 - 优先选择能交付有意义价值的最简方案。避免投机性复杂度和假设性的未来适配，但如果低成本的优化或体验提升的长期维护成本低且易于维护，则值得纳入。

Interaction Rules

交互规则

  1. Ask one question at a time - Do not batch several unrelated questions into one message.
  2. Prefer single-select multiple choice - Use single-select when choosing one direction, one priority, or one next step.
  3. Use multi-select rarely and intentionally - Use it only for compatible sets such as goals, constraints, non-goals, or success criteria that can all coexist. If prioritization matters, follow up by asking which selected item is primary.
  4. Use the platform's question tool when available - When asking the user a question, prefer the platform's blocking question tool if one exists (
    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.
  1. 一次只提一个问题 - 不要在一条消息中批量提出多个不相关问题。
  2. 优先使用单选选择题 - 当选择一个方向、优先级或下一步操作时，使用单选形式。
  3. 谨慎且有目的地使用多选 - 仅适用于可共存的集合，如目标、约束、非目标或可同时存在的成功标准。如果需要排序，后续需询问选中项中的首要内容。
  4. 尽可能使用平台的提问工具 - 向用户提问时，优先使用平台的阻塞式提问工具（如Claude Code中的
    AskUserQuestion
    、Codex中的
    request_user_input
    、Gemini中的
    ask_user
    ）。若没有此类工具，则在聊天中列出编号选项，等待用户回复后再继续。

Output Guidance

输出指南

  • Keep outputs concise - Prefer short sections, brief bullets, and only enough detail to support the next decision.
  • Use repo-relative paths - When referencing files, use paths relative to the repo root (e.g., 
    src/models/user.rb
    ), never absolute paths. Absolute paths make documents non-portable across machines and teammates.
  • 保持输出简洁 - 优先使用短章节、简短项目符号，仅保留支持下一个决策所需的足够细节。
  • 使用仓库相对路径 - 引用文件时，使用相对于仓库根目录的路径（例如：
    src/models/user.rb
    ），绝对路径不可用。绝对路径会导致文档在不同机器和团队成员间无法移植。

Feature Description

功能描述

<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.
<feature_description> #$ARGUMENTS </feature_description>
如果上述功能描述为空，请询问用户： "您希望探索什么？请描述您正在构思的功能、问题或改进方案。"
在获取到用户提供的功能描述前，请勿继续流程。

Execution Flow

执行流程

Phase 0: Resume, Assess, and Route

阶段0：恢复、评估与路由

0.1 Resume Existing Work When Appropriate

0.1 适当时恢复现有工作

If the user references an existing brainstorm topic or document, or there is an obvious recent matching 
*-requirements.md
file in 
docs/brainstorms/
:
  • Read the document
  • Confirm with the user before resuming: "Found an existing requirements doc for [topic]. Should I continue from this, or start fresh?"
  • If resuming, summarize the current state briefly, continue from its existing decisions and outstanding questions, and update the existing document instead of creating a duplicate
如果用户提及现有的头脑风暴主题或文档，或
docs/brainstorms/
目录中存在明显匹配的近期
*-requirements.md
文件：
  • 读取该文档
  • 在恢复前与用户确认："找到关于[主题]的现有需求文档。我应该基于此继续，还是重新开始？"
  • 如果选择恢复，简要总结当前状态，基于现有决策和未解决问题继续，并更新现有文档而非创建副本

0.1b Classify Task Domain

0.1b 任务领域分类

Before proceeding to Phase 0.2, classify whether this is a software task. The key question is: does the task involve building, modifying, or architecting software? -- not whether the task mentions software topics.
Software (continue to Phase 0.2) -- the task references code, repositories, APIs, databases, or asks to build/modify/debug/deploy software.
Non-software brainstorming (route to universal brainstorming) -- BOTH conditions must be true:
  • None of the software signals above are present
  • The task describes something the user wants to explore, decide, or think through in a non-software domain
Neither (respond directly, skip all brainstorming phases) -- the input is a quick-help request, error message, factual question, or single-step task that doesn't need a brainstorm.
If non-software brainstorming is detected: Read 
references/universal-brainstorming.md
and use those facilitation principles to brainstorm with the user naturally. Do not follow the software brainstorming phases below.
进入阶段0.2前，先分类任务是否属于软件领域。核心问题是：该任务是否涉及构建、修改或架构设计软件？——而非任务是否提及软件相关话题。
软件领域（继续阶段0.2）——任务涉及代码、仓库、API、数据库，或要求构建/修改/调试/部署软件。
非软件头脑风暴（路由至通用头脑风暴）——需同时满足以下两个条件：
  • 未出现上述任何软件领域信号
  • 任务描述的是用户希望在非软件领域探索、决策或梳理的内容
两者都不是（直接响应，跳过所有头脑风暴阶段）——输入内容是快速帮助请求、错误信息、事实性问题或无需头脑风暴的单步骤任务。
如果检测到非软件头脑风暴： 读取
references/universal-brainstorming.md
并使用其中的引导原则与用户自然地进行头脑风暴。请勿遵循以下软件头脑风暴阶段。

0.2 Assess Whether Brainstorming Is Needed

0.2 评估是否需要头脑风暴

Clear requirements indicators:
  • Specific acceptance criteria provided
  • Referenced existing patterns to follow
  • Described exact expected behavior
  • Constrained, well-defined scope
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.
需求明确的指标：
  • 提供了具体的验收标准
  • 提及了可遵循的现有模式
  • 描述了确切的预期行为
  • 范围受限且定义清晰
如果需求已明确： 保持交互简洁。确认理解后提供简洁的下一步选项，而非强制进行冗长的头脑风暴。只有当需要向规划环节或后续评审进行持久交接时，才撰写简短的需求文档。直接跳过阶段1.1和1.2——进入阶段1.3或阶段3。

0.3 Assess Scope

0.3 评估范围

Use the feature description plus a light repo scan to classify the work:
  • Lightweight - small, well-bounded, low ambiguity
  • Standard - normal feature or bounded refactor with some decisions to make
  • Deep - cross-cutting, strategic, or highly ambiguous
If the scope is unclear, ask one targeted question to disambiguate and then proceed.
结合功能描述和对仓库的初步扫描对工作进行分类：
  • 轻量化 - 规模小、边界清晰、模糊度低
  • 标准型 - 常规功能或有边界的重构，存在部分待决策内容
  • 深度型 - 跨领域、战略性或高度模糊的工作
如果范围不明确，提出一个针对性问题澄清后再继续。

Phase 1: Understand the Idea

阶段1：理解构思

1.1 Existing Context Scan

1.1 现有上下文扫描

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. Two rules govern technical depth during the scan:
  1. Verify before claiming — When the brainstorm touches checkable infrastructure (database tables, routes, config files, dependencies, model definitions), read the relevant source files to confirm what actually exists. Any claim that something is absent — a missing table, an endpoint that doesn't exist, a dependency not in the Gemfile, a config option with no current support — must be verified against the codebase first; if not verified, label it as an unverified assumption. This applies to every brainstorm regardless of topic.
  2. Defer design decisions to planning — Implementation details like schemas, migration strategies, endpoint structure, or deployment topology belong in planning, not here — unless the brainstorm is itself about a technical or architectural decision, in which case those details are the subject of the brainstorm and should be explored.
Slack context (opt-in, Standard and Deep only) — never auto-dispatch. Route by condition:
  • Tools available + user asked: Dispatch 
    research:ce-slack-researcher
    with a brief summary of the brainstorm topic alongside Phase 1.1 work. Incorporate findings into constraint and context awareness.
  • Tools available + user didn't ask: Note in output: "Slack tools detected. Ask me to search Slack for organizational context at any point, or include it in your next prompt."
  • No tools + user asked: Note in output: "Slack context was requested but no Slack tools are available. Install and authenticate the Slack plugin to enable organizational context search."
在实质性头脑风暴前扫描仓库。扫描深度与范围匹配：
轻量化——搜索相关主题，检查是否已有类似内容，然后继续。
标准型和深度型——分两次扫描：
约束检查——查看项目指导文件（
AGENTS.md
，以及仅作为兼容上下文保留的
CLAUDE.md
），寻找影响头脑风暴的工作流、产品或范围约束。如果无相关内容，则继续。
主题扫描——搜索相关术语。如果存在最相关的现有工件（头脑风暴文档、规划文档、规格说明、技能文档、功能文档），则阅读该文档。略读涵盖类似行为的相邻示例。
如果短时间扫描后未发现明显相关内容，告知用户后继续。扫描期间的技术深度遵循以下两条规则：
  1. 先验证再断言——当头脑风暴涉及可检查的基础设施（数据库表、路由、配置文件、依赖项、模型定义）时，需读取相关源文件确认实际存在的内容。任何关于某事物不存在的断言——如缺失的表、不存在的端点、Gemfile中没有的依赖项、当前不支持的配置选项——必须先对照代码库验证；若未验证，则标记为未经验证的假设。此规则适用于所有头脑风暴主题。
  2. 将设计决策推迟至规划环节——实现细节如schema、迁移策略、端点结构或部署拓扑属于规划环节，而非此处——除非头脑风暴本身就是关于技术或架构决策的，此时这些细节是头脑风暴的主题，应进行探索。
Slack上下文（可选，仅适用于标准型和深度型）——绝不自动触发。根据情况路由：
  • 工具可用且用户提出请求：调用
    research:ce-slack-researcher
    ，同时提供头脑风暴主题的简要总结和阶段1.1的工作内容。将发现结果纳入约束和上下文认知中。
  • 工具可用但用户未提出请求：在输出中注明："检测到Slack工具。您可随时要求我搜索Slack获取组织上下文，或在下次提示中提及此需求。"
  • 无工具且用户提出请求：在输出中注明："已请求Slack上下文，但无可用的Slack工具。请安装并认证Slack插件以启用组织上下文搜索。"

1.2 Product Pressure Test

1.2 产品压力测试

Before generating approaches, challenge the request to catch misframing. Match depth to scope:
Lightweight:
  • Is this solving the real user problem?
  • Are we duplicating something that already covers this?
  • Is there a clearly better framing with near-zero extra cost?
Standard:
  • Is this the right problem, or a proxy for a more important one?
  • What user or business outcome actually matters here?
  • What happens if we do nothing?
  • Is there a nearby framing that creates more user value without more carrying cost? If so, what complexity does it add?
  • Given the current project state, user goal, and constraints, what is the single highest-leverage move right now: the request as framed, a reframing, one adjacent addition, a simplification, or doing nothing?
  • Favor moves that compound value, reduce future carrying cost, or make the product meaningfully more useful or compelling
  • Use the result to sharpen the conversation, not to bulldoze the user's intent
Deep — Standard questions plus:
  • What durable capability should this create in 6-12 months?
  • Does this move the product toward that, or is it only a local patch?
在提出方案前，挑战请求以发现框架偏差。测试深度与范围匹配：
轻量化：
  • 这是否解决了真实的用户问题？
  • 我们是否在重复已有功能？
  • 是否存在几乎无额外成本的更优框架？
标准型：
  • 这是正确的问题，还是更重要问题的替代？
  • 真正重要的用户或业务成果是什么？
  • 如果我们不采取任何行动会发生什么？
  • 是否存在能创造更多用户价值且无额外维护成本的相近框架？如果有，它会增加哪些复杂度？
  • 结合当前项目状态、用户目标和约束，当前最高杠杆的行动是什么：按原请求执行、重构框架、添加一个相邻功能、简化或不采取任何行动？
  • 优先选择能积累价值、降低未来维护成本或使产品更实用、更具吸引力的行动
  • 用结果优化对话，而非否定用户的意图
深度型——除标准问题外，还需：
  • 这在6-12个月内应该创造哪些持久能力？
  • 这是推动产品向该目标前进，还是仅作为局部补丁？

1.3 Collaborative Dialogue

1.3 协作对话

Follow the Interaction Rules above. Use the platform's blocking question tool when available.
Guidelines:
  • Ask what the user is already thinking before offering your own ideas. This surfaces hidden context and prevents fixation on AI-generated framings.
  • Start broad (problem, users, value) then narrow (constraints, exclusions, edge cases)
  • Clarify the problem frame, validate assumptions, and ask about success criteria
  • Make requirements concrete enough that planning will not need to invent behavior
  • Surface dependencies or prerequisites only when they materially affect scope
  • Resolve product decisions here; leave technical implementation choices for planning
  • Bring ideas, alternatives, and challenges instead of only interviewing
Exit condition: Continue until the idea is clear OR the user explicitly wants to proceed.
遵循上述交互规则。尽可能使用平台的阻塞式提问工具。
指南：
  • 在提出自己的想法前，先询问用户已有的思路。这能挖掘隐藏的上下文，避免局限于AI生成的框架。
  • 先从宏观层面（问题、用户、价值）入手，再缩小到微观层面（约束、排除项、边缘情况）
  • 澄清问题框架、验证假设并询问成功标准
  • 使需求足够具体，确保规划环节无需重新定义行为
  • 仅当依赖项或先决条件对范围有实质性影响时才提出
  • 在此解决产品决策；将技术实现选择留至规划环节
  • 提出想法、替代方案和挑战，而非仅进行访谈
退出条件： 持续对话直到构思清晰，或用户明确要求继续。

Phase 2: Explore Approaches

阶段2：探索方案

If multiple plausible directions remain, propose 2-3 concrete approaches based on research and conversation. Otherwise state the recommended direction directly.
Use at least one non-obvious angle — inversion (what if we did the opposite?), constraint removal (what if X weren't a limitation?), or analogy from how another domain solves this. The first approaches that come to mind are usually variations on the same axis.
Present approaches first, then evaluate. Let the user see all options before hearing which one is recommended — leading with a recommendation before the user has seen alternatives anchors the conversation prematurely.
When useful, include one deliberately higher-upside alternative:
  • Identify what adjacent addition or reframing would most increase usefulness, compounding value, or durability without disproportionate carrying cost. Present it as a challenger option alongside the baseline, not as the default. Omit it when the work is already obviously over-scoped or the baseline request is clearly the right move.
For each approach, provide:
  • Brief description (2-3 sentences)
  • Pros and cons
  • Key risks or unknowns
  • When it's best suited
After presenting all approaches, state 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:
  • Reuse an existing pattern
  • Extend an existing capability
  • Build something net new
如果仍存在多种可行方向，基于研究和对话提出2-3种具体方案。否则直接说明推荐方向。
至少使用一个非显而易见的角度——逆向思维（如果我们做相反的事会怎样？）、移除约束（如果X不是限制会怎样？）或借鉴其他领域的解决方案。最先想到的方案通常只是同一维度的变体。
先展示方案，再进行评估。让用户看到所有选项后再听取推荐——在用户看到替代方案前就给出推荐会过早限制对话。
如有必要，可包含一个特意设计的高潜力替代方案：
  • 确定哪些相邻功能添加或框架重构能在不增加过多维护成本的前提下最大程度提升实用性、积累价值或持久性。将其作为挑战选项与基线方案一同展示，而非默认方案。当工作范围已明显过大或基线请求显然是正确选择时，可省略此选项。
每个方案需包含：
  • 简要描述（2-3句话）
  • 优缺点
  • 关键风险或未知因素
  • 最适用场景
展示所有方案后，说明你的推荐并解释原因。当额外复杂度会带来实际维护成本时，优先选择更简单的解决方案，但不要仅因非必需而拒绝低成本、高价值的优化。
如果某一方案明显最优且替代方案无实际意义，可跳过选项列表直接说明推荐方向。
如有相关，说明选择属于以下哪种类型：
  • 复用现有模式
  • 扩展现有能力
  • 全新构建

Phase 3: Capture the Requirements

阶段3：记录需求

Write or update a requirements document only when the conversation produced durable decisions worth preserving. Read 
references/requirements-capture.md
for the document template, formatting rules, visual aid guidance, and completeness checks.
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.
仅当对话产生了值得保留的持久决策时，才撰写或更新需求文档。阅读
references/requirements-capture.md
获取文档模板、格式规则、视觉辅助指南和完整性检查标准。
对于轻量化头脑风暴，保持文档简洁。当用户仅需简短对齐且无持久决策需保留时，可跳过文档创建环节。

Phase 3.5: Document Review

阶段3.5：文档评审

When a requirements document was created or updated, run the 
ce-doc-review
skill on it before presenting handoff options. Pass the document path as the argument.
If document-review returns findings that were auto-applied, note them briefly when presenting handoff options. If residual P0/P1 findings were surfaced, mention them so the user can decide whether to address them before proceeding.
When document-review returns "Review complete", proceed to Phase 4.
当创建或更新需求文档后，在展示交接选项前对其运行
ce-doc-review
技能。将文档路径作为参数传入。
如果文档评审返回了已自动应用的发现结果，在展示交接选项时简要说明。如果发现了剩余的P0/P1级问题，需告知用户，以便用户决定是否在继续前解决这些问题。
当文档评审返回"评审完成"时，进入阶段4。

Phase 4: Handoff

阶段4：交接

Present next-step options and execute the user's selection. Read 
references/handoff.md
for the option logic, dispatch instructions, and closing summary format.
展示下一步选项并执行用户的选择。阅读
references/handoff.md
获取选项逻辑、调用说明和结束总结格式。