Ce Brainstorm

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.

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.

Interaction Rules

These rules apply to every brainstorm, including the universal (non-software) flow routed to references/universal-brainstorming.md.

1. Ask one question at a time - One question per turn, even when sub-questions feel related. Stacking several questions in a single message produces diluted answers; pick the single most useful one and ask it. 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. Default to the platform's blocking question tool - Use AskUserQuestion in Claude Code (call ToolSearch with select:AskUserQuestion first if its schema isn't loaded), request_user_input in Codex, ask_user in Gemini, ask_user in Pi (requires the pi-ask-user extension). These tools include a free-text fallback (e.g., "Other" in Claude Code), so options scaffold the answer without confining it — well-chosen options surface dimensions the user may not have separated, and pick-plus-optional-note is lower activation energy than composing prose from scratch. This default holds for opening and elicitation questions too, not only narrowing. Fall back to numbered options in chat only when no blocking tool exists in the harness or the call errors (e.g., Codex edit modes) — not because a schema load is required. Never silently skip the question. 5. Use prose only when the question is genuinely open - Drop the blocking tool only when (a) the answer is inherently narrative ("walk me through how you got here"), (b) the question is diagnostic or introspective and presented options would leak your priors and bias the answer (e.g., "what concerns you most?" where a 4-option menu signals which axes matter), or (c) you cannot write 3-4 genuinely distinct, plausibly-correct options that cover the space without padding or strawmen. The test: if you'd be straining to fill the option slots, the question is open — use prose. Rule 1 still applies: still one question per turn.

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.

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.

Execution Flow

Phase 0: Resume, Assess, and Route

0.1 Resume Existing Work When Appropriate

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

0.1b Classify Task Domain

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. Skip Phases 0.2–4 below — the Core Principles and Interaction Rules above still apply unchanged, including one-question-per-turn and the default to the platform's blocking question tool.

0.2 Assess Whether Brainstorming Is Needed

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 2.5 in announce-mode (synthesis emitted for visibility, no blocking confirmation), then to Phase 3.

0.3 Assess Scope

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.

Deep sub-mode: feature vs product. For Deep scope, also classify whether the brainstorm must establish product shape or inherit it:

• Deep — feature (default): existing product shape anchors decisions. Primary actors, core outcome, positioning, and primary flows are already established in the product or repo. The brainstorm extends or refines within that shape.
• Deep — product: the brainstorm must establish product shape rather than inherit it. Primary actors, core outcome, positioning against adjacent products, or primary end-to-end flows are materially unresolved. Existing code lowers the odds of product-tier but does not by itself rule it out — a half-built tool with ambiguous shape is still product-tier.

Product-tier triggers additional Phase 1.2 questions and additional sections in the requirements document. Feature-tier uses the current Deep behavior unchanged.

Phase 1: Understand the Idea

1.1 Existing Context Scan

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. Also read STRATEGY.md if it exists — the product's target problem, approach, persona, and active tracks are direct input to what this brainstorm should deliver and should shape scope, success criteria, and which approaches are aligned vs out-of-scope. 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 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."

1.2 Product Pressure Test

Before generating approaches, scan the user's opening for rigor gaps. Match depth to scope.

This is agent-internal analysis, not a user-facing checklist. Read the opening, note which gaps actually exist, and raise only those as questions during Phase 1.3 — folded into the normal flow of dialogue, not fired as a pre-flight gauntlet. A fuzzy opening may earn three or four probes; a concrete, well-framed one may earn zero because no scope-appropriate gaps were found.

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 — scan for these gaps:

• Evidence gap. The opening asserts want or need, but doesn't point to anything the would-be user has already done — time spent, money paid, workarounds built — that would make the want observable. When present, ask for the most concrete thing someone has already done about this.

• Specificity gap. The opening describes the beneficiary at a level of abstraction where the agent couldn't design without silently inventing who they are and what changes for them. When present, ask the user to name a specific person or narrow segment, and what changes for that person when this ships.

• Counterfactual gap. The opening doesn't make visible what users do today when this problem arises, nor what changes if nothing ships. When present, ask what the current workaround is, even if it's messy — and what it costs them.

• Attachment gap. The opening treats a particular solution shape as the thing being built, rather than the value that shape is supposed to deliver, and hasn't been examined against smaller forms that might deliver the same value. When present, ask what the smallest version that still delivers real value would look like.

Plus these synthesis questions — not gap lenses, product-judgment the agent weighs in its own reasoning:

• 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 lenses and synthesis questions plus:

• Is this a local patch, or does it move the broader system toward where it wants to be?

Deep — product — Deep plus:

• Durability gap. The opening's value proposition rests on a current state of the world that may shift in predictable ways within the horizon the user cares about. When present, ask how the idea fares under the most plausible near-term shifts — and push past rising-tide answers every competitor could make.

• What adjacent product could we accidentally build instead, and why is that the wrong one?
• What would have to be true in the world for this to fail?

These questions force an explicit product thesis and feed the Scope Boundaries subsections ("Deferred for later" and "Outside this product's identity") and Dependencies / Assumptions in the requirements document.

1.3 Collaborative Dialogue

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)
• Rigor probes fire before Phase 2 and are prose, not menus. Narrowing is legitimate, but Phase 1 cannot end with un-probed rigor gaps. Each scope-appropriate gap from Phase 1.2 fires as a separate direct prose probe — one probe satisfies one gap, not multiple. Standard brainstorms scan four gap lenses (evidence, specificity, counterfactual, attachment); Deep-product adds durability (five total), but only the gaps actually present in the opening must be probed. Surface those probes progressively across the conversation — interleaving with narrowing moves is fine, as long as every scope-appropriate gap that was found in Phase 1.2 has been probed in prose before Phase 2. Rigor probes map to Interaction Rule 5(b): a 4-option menu signals which kinds of evidence count and lets the user pick rather than produce. Prose forces them to produce real observation or surface their uncertainty. Examples (one per gap): evidence — "What's the most concrete thing someone's already done about this — paid, built a workaround, quit a tool over it?" / specificity — "Can you name a team you've actually watched hit this, or are you reasoning?" / counterfactual — "What do teams do today when this breaks — who reconciles?" / attachment — "Before we move to shapes or approaches — what's the smallest version that would still prove the bet right, and what's excluded?" — attachment is the final rigor probe before Phase 2 when the attachment gap is present. Fire it regardless of whether a specific shape has emerged through narrowing; its job is to pressure-test the user's implicit framing of the product before Phase 2 inherits it / durability — "Under the most plausible near-term shifts, how does this bet hold?" If the answer reveals genuine uncertainty, record it as an explicit assumption in the requirements document rather than skipping the probe.
• 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.

Phase 2: Explore Approaches

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.

At product tier, alternatives should differ on what is built (product shape, actor set, positioning), not how it is built. Implementation-variant alternatives belong at feature tier.

For each approach, provide:

• Brief description (2-3 sentences)
• Pros and cons
• Key risks or unknowns
• When it's best suited

Approach granularity: mechanism / product shape, not architecture. Approach descriptions name mechanism-level distinctions ("pause as a rule property" vs "pause as an event filter" vs "pause as a separate entity") and product-relevant trade-offs (plan-tier coupling, complexity surface, migration difficulty). They do NOT name implementation specifics — column names, table names, file paths, service classes, JSON shapes, exact method names. Those are ce-plan's job. Bringing architecture forward at brainstorm time forces the user to make architectural decisions on ce-brainstorm's intentionally-shallow research, and the synthesis at Phase 2.5 then has to filter out the leak.

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

Phase 2.5: Synthesis Summary

STOP. Before composing the synthesis, read `references/synthesis-summary.md`. The discipline rules, prose-summary requirement, three-bucket structure, anti-pattern guidance, soft-cut behavior, self-redirect support, prose-feedback rules, and bucket-content routing into doc body sections all live there. Composing a synthesis without these rules loaded reliably produces malformed output — missing prose summary, implementation-detail leakage, the proposal-pitch anti-pattern. This is not optional supplementary reading; it is the source of truth for how the phase behaves.

Surface a synthesis to the user before Phase 3 writes the requirements doc — the user's last opportunity to correct scope before the artifact lands.

Fires for all tiers including Lightweight. Skip Phase 2.5 entirely on the Phase 0.1b non-software (universal-brainstorming) route.

Headless mode (LFG / disable-model-invocation): the synthesis is composed but not confirmed. Inferred bets route to a ## Assumptions section in the doc (so downstream review can scrutinize them as un-validated), not into Key Decisions. See references/synthesis-summary.md Headless mode for the full routing.

Announce-mode (Phase 0.2 fast path): on the "requirements already clear" fast path, Phase 2.5 fires in announce-mode — emit the synthesis (Stated / Inferred / Out) for visibility, then end the turn. Do NOT call the Write tool in the same turn as the synthesis emission. On the user's next message: if it's an acknowledgment, follow-up, or any non-correcting input, proceed to Phase 3 doc-write; if it indicates a correction (push-back on an Inferred bullet, scope adjustment), revise the synthesis and emit again. Lighter than full Phase 2.5 (no AskUserQuestion menu, no formal confirm option) but still gives the user a real interruption window before the doc lands. ce-brainstorm sits early in the workflow; a wrong-doc has downstream consequence (feeds ce-plan, then implementation), so the turn boundary is justified even on the fast path.

Phase 3: Capture the Requirements

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.

Phase 4: Handoff

Present next-step options and execute the user's selection. Read references/handoff.md for the option logic, dispatch instructions, and closing summary format.

Handoff

This content is loaded when Phase 4 begins — after the requirements document is written.

---

4.1 Present Next-Step Options

The Phase 4 menu's visible option count varies by state: no requirements doc hides the review and Proof options, unresolved Resolve Before Planning hides Plan implementation and Build it now, a failing direct-to-work gate hides Build it now. Count the visible options for the current state and choose the rendering mode accordingly:

• 4 or fewer visible: use the platform's blocking question tool (AskUserQuestion in Claude Code — call ToolSearch with select:AskUserQuestion first if its schema isn't loaded; request_user_input in Codex; ask_user in Gemini, ask_user in Pi (requires the pi-ask-user extension)). This is the default.
• 5 or more visible: render as a numbered list in chat. This is the narrow option-overflow fallback; trimming would hide legitimate choices (plan, review, Proof, build, refine, pause are all distinct destinations). Include a hint that free-form input is accepted ("Pick a number or describe what you want.") so the numbered list retains the blocking tool's open-endedness.

Never silently skip the question.

If Resolve Before Planning contains any items:

• Ask the blocking questions now, one at a time, by default
• If the user explicitly wants to proceed anyway, first convert each remaining item into an explicit decision, assumption, or Deferred to Planning question
• If the user chooses to pause instead, present the handoff as paused or blocked rather than complete
• Do not offer the Plan implementation or Build it now options while Resolve Before Planning remains non-empty

In both preambles below, the "Pick a number or describe what you want." hint applies only in numbered-list mode. When using the blocking tool, omit that line and pass the remaining stem as the question.

Path format: Use absolute paths for chat-output file references — relative paths are not auto-linked as clickable in most terminals.

Preamble when no blocking questions remain:

Brainstorm complete.

Requirements doc: <absolute path to requirements doc>  # omit line if no doc was created

What would you like to do next? (Pick a number or describe what you want.)

Preamble when blocking questions remain and user wants to pause:

Brainstorm paused. Planning is blocked until the remaining questions are resolved.

Requirements doc: <absolute path to requirements doc>  # omit line if no doc was created

What would you like to do next? (Pick a number or describe what you want.)

Present only the options that apply. Renumber so visible options stay contiguous starting at 1.

1. Plan implementation with `ce-plan` (Recommended) - Move to ce-plan for structured implementation planning. Shown only when Resolve Before Planning is empty. 2. Agent review of requirements doc with `ce-doc-review` - Dispatch reviewer agents to check the doc for coherence, feasibility, scope, and other persona-specific issues; auto-apply safe fixes; route remaining findings interactively. Shown only when a requirements document exists. 3. Open in Proof — review and comment to iterate with the agent - Open the doc in Every's Proof editor, iterate with the agent via comments, or copy a link to share with others. Shown only when a requirements document exists. 4. Build it now with `ce-work` (skip planning) - Skip planning and move to ce-work; suited to lightweight, well-defined changes. Shown only when Resolve Before Planning is empty and scope is lightweight, success criteria are clear, scope boundaries are clear, and no meaningful technical or research questions remain (the "direct-to-work gate"). 5. More clarifying questions to sharpen the doc - Keep refining scope, edge cases, constraints, and preferences through further dialogue. Always shown. 6. Done for now - Pause; the requirements doc is saved and can be resumed later. Always shown.

Post-review nudge (subsequent rounds only): If the user has already run ce-doc-review this session and residual P0/P1 findings remain unaddressed, add a one-line prose nudge adjacent to the menu (e.g., "Document review flagged 2 P1 findings you may want to address — pick \"Agent review of requirements doc\" to run another pass."). Reference the option by label, not number: the menu renumbers when Resolve Before Planning hides Plan implementation and Build it now, so a hardcoded option number can point users at the wrong action. Do not add a separate menu option; reuse the existing agent-review option.

4.2 Handle the Selected Option

Selections may be the literal option label (when the user types the label or a close paraphrase) or the option number. Match numbers against the currently-rendered (post-trim) list. Free-form input that doesn't match an option or describe an alternative action should be treated as clarification — ask a follow-up rather than guessing.

If user selects "Plan implementation with `ce-plan` (Recommended)":

Immediately load the ce-plan skill 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 "Agent review of requirements doc with `ce-doc-review`":

Load the ce-doc-review skill, passing the requirements document path as the argument. When ce-doc-review returns "Review complete", return to the Phase 4 options and re-render the menu (the doc may have changed, so re-evaluate Resolve Before Planning, direct-to-work gate, and residual findings). If residual P0/P1 findings remain unaddressed, include the post-review nudge above the menu. Do not show the closing summary yet.

If user selects "Build it now with `ce-work` (skip planning)":

Immediately load the ce-work skill 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 "More clarifying questions to sharpen the doc": Return to Phase 1.3 (Collaborative Dialogue) and continue asking the user clarifying questions one at a time to further refine scope, edge cases, constraints, and preferences. Continue until the user is satisfied, then return to Phase 4. Do not show the closing summary yet.

If user selects "Open in Proof — review and comment to iterate with the agent":

Load the ce-proof skill in HITL-review mode with:

• source file: docs/brainstorms/YYYY-MM-DD-<topic>-requirements.md
• doc title: Requirements: <topic title>
• identity: ai:compound-engineering / Compound Engineering
• recommended next step: ce-plan (shown in the ce-proof skill's final terminal output)

Follow references/hitl-review.md in the ce-proof skill. It uploads the doc, prompts the user for review in Proof's web UI, ingests each thread by reading it fresh and replying in-thread, applies agreed edits as tracked suggestions, and syncs the final markdown back to the source file atomically on proceed.

When the ce-proof skill returns control:

• status: proceeded with localSynced: true → the requirements doc on disk now reflects the review. Return to the Phase 4 options and re-render the menu (the doc may have changed substantially during review, so option eligibility can shift — re-evaluate Resolve Before Planning, direct-to-work gate, and residual ce-doc-review findings against the updated doc).
• status: proceeded with localSynced: false → the reviewed version lives in Proof at docUrl but the local copy is stale. Offer to pull the Proof doc to localPath using the ce-proof skill's Pull workflow. Re-render the Phase 4 menu after the pull completes (or is declined). If the pull was declined, include a one-line note above the menu that <localPath> is stale vs. Proof — otherwise Plan implementation / Build it now / Agent review of requirements doc will silently read the pre-review copy (ce-doc-review would analyze stale content, and planning or work would skip the user's Proof edits).
• status: done_for_now → the doc on disk may be stale if the user edited in Proof before leaving. Offer to pull the Proof doc to localPath so the local requirements file stays in sync, then return to the Phase 4 options. If the pull was declined, include the stale-local note above the menu. done_for_now means the user stopped the HITL loop without syncing — it does not mean they ended the whole brainstorm; they may still want to plan implementation, run an agent review, or keep refining the doc.
• status: aborted → fall back to the Phase 4 options without changes.

If the initial upload fails (network error, Proof API down), retry once after a short wait. If it still fails, tell the user the upload didn't succeed and briefly explain why, then return to the Phase 4 options — don't leave them wondering why the option did nothing.

If user selects "Done for now": Display the closing summary (see 4.3) and end the turn.

4.3 Closing Summary

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.

Requirements Capture

This content is loaded when Phase 3 begins — after the collaborative dialogue (Phases 0-2) has 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.

Section matrix

Summary vs Problem Frame discipline

Both sections describe the work, but from different angles. They earn separate sections only when each holds to its own purpose:

Disciplines:

• Summary doesn't need problem context. A reader scanning Summary gets the proposal at a glance without first reading why. The Problem Frame is the next stop if they need motivation.
• Problem Frame doesn't restate the proposal. It establishes the situation, the specific moment of pain, and the cost shape — then stops. The remedy lives in Summary; restating it in Problem Frame is the duplication that makes the two sections feel redundant. Even a single transition sentence to the remedy at the end of Problem Frame ("A dedicated X primitive collapses both pains into a single action...") slips the proposal in and undermines the discipline. If the last paragraph of Problem Frame names what the doc is proposing, cut it — Summary above already covers it.

In the truly-trivial Lightweight case where Summary is skipped (synthesis ≤ 2 bullets that echo the prompt — see the Section matrix above), Problem Frame may absorb the situational + remedy framing in a tighter form. In all other cases — Standard, Deep, and any Lightweight doc with more substance — both Summary and Problem Frame are present and must follow the discipline above.

Triggered sections — when to include

Actors — include when multiple humans, agents, or systems are meaningfully involved, or when decisions change based on whose perspective is optimized for. Covers both end-user actors (for product work) and pipeline-agent actors (for agent-workflow work, such as changes to CE's own review or planning flows).

Key Flows — include when the work involves multi-step interaction or coordinates across existing flows. At Deep-product tier, include 2-4 primary flows by default; omit only when the product is not meaningfully flow-shaped (e.g., pure API, policy, or artifact output) and Actors, Requirements, Scope Boundaries, and Acceptance Examples already prevent downstream invention of user/agent paths. When omitting at product tier, note the reason in the doc.

Acceptance Examples — include when a requirement's behavior is hard to pin down without a concrete scenario. Always include AEs covering behavioral-conditional requirements — any requirement framed as "When X, Y" or "If X, Y" — regardless of tier. Conditional framing signals state-dependent behavior, which is exactly where prose alone leaves implicit ambiguity (e.g., "When --quiet is set, errors continue to surface" — does that include warnings? does it include binary-side errors? AE pins it down). Each example disambiguates one or more requirements via a Covers: R-IDs back-reference. Non-conditional requirements may be omitted unless ambiguity surfaces in review; the section is not exhaustive.

Template

Use this template and omit sections per the matrix above. At Deep-product tier, keep the Scope Boundaries split. At other tiers, use the single Scope Boundaries list.

---
date: YYYY-MM-DD
topic: <kebab-case-topic>
---

# <Topic Title>

## Summary

[1-3 line prose summary — what is being proposed, in plain language. Forward-looking (what *will* be in the doc), not retrospective. Required for Standard / Deep-feature / Deep-product. Skip for Lightweight when the Requirements bullets ARE the summary.]

---

## Problem Frame

[Who is affected, what is changing, and why it matters. Backward-looking / situational. Establishes the pain that motivates the work — does NOT restate the proposal (that lives in Summary).]

---

<!-- Include ONLY in non-interactive (headless) mode when the agent had Inferred bets that
     were not user-confirmed in chat. Lists the un-validated agent inferences explicitly so
     downstream review (ce-doc-review, ce-plan, human PR review) can scrutinize them as bets,
     not as authoritative requirements. Omit entirely in interactive mode — Inferred bets get
     user-corrected in chat and either become decisions or are revised away. -->
## Assumptions

*This requirements doc was authored without synchronous user confirmation. The items below are agent inferences that fill gaps in the input — un-validated bets that should be reviewed before planning proceeds.*

- [Inferred scope item the agent chose without user confirmation]

---

## Actors

[Include when triggered. Each actor gets a stable A-ID and a one-line role description.]

- A1. [Name or role]: [What they do in this context]
- A2. [Name or role]: [What they do in this context]

---

## Key Flows

[Include when triggered. Each flow has trigger, actors, steps, outcome, and a Covered by back-reference.]

- F1. [Flow name]
  - **Trigger:** [What initiates the flow]
  - **Actors:** A1, A2
  - **Steps:** [3-7 steps, prose or short list]
  - **Outcome:** [What is true after the flow completes]
  - **Covered by:** R1, R2, R5

---

## Requirements

[Group under bold inline headers when requirements span distinct concerns. Keep R-IDs sequential across groups — numbering does not restart per group.]

**[Group header, e.g., "Brainstorming workflow"]**
- R1. [Concrete requirement]
- R2. [Concrete requirement]

**[Group header, e.g., "Output document"]**
- R3. [Concrete requirement]

---

## Acceptance Examples

[Include when triggered. Each example is a definitive scenario; the list is not exhaustive.]

- AE1. **Covers R1, R2.** Given [state], when [action], [outcome].
- AE2. **Covers R4.** Given [state], when [action], [outcome].

---

## Success Criteria

- [How we will know this solved the right problem — human outcome.]
- [How a downstream agent or implementer can tell the handoff was clean.]

---

## Scope Boundaries

[At Lightweight, Standard, and Deep-feature tiers, use a single list.]

- [Deliberate non-goal or exclusion]

[At Deep-product tier, split into two subsections:]

### Deferred for later

- [Work that will be done eventually but not in v1]

### Outside this product's identity

- [Adjacent product we could build but are rejecting — positioning decision, not a deferral]

---

## Key Decisions

- [Decision]: [Rationale]

---

## Dependencies / Assumptions

- [Material dependency or assumption]

---

## 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 answered during planning or codebase exploration]
- [Affects R2][Needs research] [Question likely requiring research during planning]

ID and layout rules

Stable IDs. Standard and Deep scope always assign R-IDs to requirements. Triggered sections use their own prefixes: A for Actors, F for Key Flows, AE for Acceptance Examples. No other ID namespaces.

ID format. Use R1., A1., F1., AE1. as a plain prefix at the start of the bullet — do not bold the ID. The prefix is visually distinctive on its own.

Bold leader labels inside Flows and Acceptance Examples (e.g., **Trigger:**, **Covers R4, R8.**) give the bullet structure without needing tables or deeper heading levels.

Horizontal rules (`---`) between top-level sections in Standard and Deep docs. Omit for Lightweight.

Grouping within Requirements. When Standard or Deep requirements span distinct concerns, group them under bold inline headers (not H3s) within the Requirements section. The trigger is distinct logical areas, not item count — even four requirements benefit from headers if they cover three different topics. Group by capability or concern (e.g., "Packaging", "Migration and compatibility", "Contributor workflow"), not by the order they were discussed. Skip grouping only when all requirements are about the same thing.

Tables — only for genuinely comparative info. Bullets are cheaper and more portable for content lists.

Size heuristics

• If a capability-named group has only one requirement, ungroup it.
• If total requirements exceed ~15-20, stop and ask whether this is one brainstorm or several.
• If a requirement can be fully described in a single short bullet with no sub-items, it probably doesn't need grouping at all.
• For Lightweight docs with only 1-3 simple requirements, plain bullets without R-IDs are acceptable.

Visual communication

Include a visual aid when the requirements would be significantly easier to understand with one. Read references/visual-communication.md for the decision criteria, format selection, and placement rules.

When a document is warranted

• Lightweight — keep the document compact. Skip document creation when the user only needs brief alignment and no durable decisions need to be preserved.
• Standard and Deep (feature or product) — a requirements document is usually warranted. When the work is simple, combine sections rather than padding them. A short requirements document is better than a bloated one.

Finalization checklist

Before finalizing:

• What would ce-plan still have to invent if this brainstorm ended now?
• Does every Standard/Deep requirement have either an observable behavior or a stated reason it is structural?
• Do Success Criteria cover both human outcome and downstream-agent handoff quality?
• If Actors are named, is each actor mentioned in the problem represented in at least one requirement, flow, or scope boundary?
• If Key Flows are present, does each flow identify actor, trigger, outcome, and a failure or escape path when relevant?
• At Deep-product tier: if Key Flows are omitted, is the reason stated in the doc, and do Actors, Requirements, Scope Boundaries, and Acceptance Examples together prevent downstream invention of user/agent paths?
• At Deep-product tier: does Scope Boundaries distinguish "Deferred for later" from "Outside this product's identity"?
• Do any requirements depend on something claimed to be out of scope?
• Are any unresolved items actually product decisions rather than planning questions?
• Did implementation details leak in when they shouldn't have?
• Do any requirements claim that infrastructure is absent without that claim having been verified against the codebase? If so, verify now or label as an unverified assumption.
• Is there a low-cost change that would make this materially more useful?
• Would a visual aid (flow diagram, comparison table, relationship diagram) help a reader grasp the requirements faster than prose alone?

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.

Outstanding questions guidance

If a document contains outstanding questions:

• Use Resolve Before Planning only for questions that truly block planning.
• If Resolve Before Planning is non-empty, keep working those questions during the brainstorm by default.
• If the user explicitly wants to proceed anyway, convert each remaining item into an explicit decision, assumption, or Deferred to Planning question before proceeding.
• Do not force resolution of technical questions during brainstorming just to remove uncertainty.
• Put technical questions, or questions that require validation or research, under Deferred to Planning when they are better answered there.
• Use tags like [Needs research] when the planner should likely investigate the question rather than answer it from repo context alone.
• Carry deferred questions forward explicitly rather than treating them as a failure to finish the requirements doc.

Synthesis Summary

Synthesis ≠ requirements doc. The synthesis is NOT a preview, draft, or substitute for the requirements doc — it's the scope checkpoint that doc-write consumes as input. The requirements doc itself is written in Phase 3 from the confirmed synthesis. Both the synthesis and the requirements doc stay scope-only — implementation detail (file paths, code shapes, exact error wording) is downstream (ce-plan's job), not the requirements doc. If the synthesis reads like a doc preview, it's misshaped — re-cut to scope-only.

Three-bucket structure is a chat-time artifact only. It does its scope-confirmation job in dialogue with the user, then dissolves when Phase 3 writes the doc: Stated content informs the Requirements section, Inferred content informs Key Decisions (interactive mode) or ## Assumptions (non-interactive mode), Out-of-scope content informs Scope Boundaries. The doc has no parallel ## Synthesis section — only the prose summary embeds, as ## Summary. See "Doc shape after confirmation" below for the routing.

This content is loaded when Phase 2.5 fires — after Phase 2 (approaches chosen) and before Phase 3 (write requirements doc). The synthesis is the user's last opportunity to correct the agent's interpretation before the doc lands. It serves two purposes: synthesis confirmation (the user agreed to many individual things in dialogue but never saw the whole) and a transition checkpoint ("about to write a doc").

Fires for all tiers including Lightweight. Skip Phase 2.5 entirely on the Phase 0.1b non-software (universal-brainstorming) route — that flow has its own facilitation pattern. In non-interactive (headless) mode, Phase 2.5 still fires — the synthesis is composed but not user-confirmed; Inferred bets route to a ## Assumptions section in the doc. See "Headless mode" below for the full routing.

---

Three-bucket structure

Every synthesis is structured in three labeled buckets. Items may appear in two buckets when meaningfully both — flag the inclusion-then-exclusion as Inferred so the reader sees the agent's reasoning.

• Stated — what the user said directly (in the original prompt, prior conversation, dialogue answers, approach selection in Phase 2). Items here have explicit user-language anchors.
• Inferred — what the agent assumed to fill gaps. Scope boundaries the user never explicitly named, success criteria extrapolated from intent, technical assumptions made because the brief interview didn't probe them. The "Inferred" list is the most actionable bucket — items here are the agent's bets that the user can correct.
• Out of scope — deliberately excluded items. Adjacent work the agent considered but decided not to include, refactors, nice-to-haves, future-work items. Making exclusions explicit lets the user spot anything they actually wanted included.

---

Tier-shaped output

Lightweight gets one paragraph plus brief bulleted lists. Standard, Deep-feature, and Deep-product get a few paragraphs with explicit lists per bucket.

The synthesis is a chat-time artifact. The buckets exist for the user to scan, correct, or confirm — they do not carry into the doc as a parallel section. After confirmation, only the prose summary embeds in the doc (as ## Summary); bucket content dissolves into the doc's body sections per "Doc shape after confirmation" below.

Prompt template

This is directional guidance — adjust phrasing to fit dialogue context. Open prose feedback per Interaction Rule 5(a) (option sets would leak the agent's framing of valid corrections).

Prose summary discipline (required for all tiers): start the synthesis with a 1-3 line summary in plain prose describing what's being proposed for the requirements doc at a glance. Forward-looking (what will be in the doc), not retrospective (what's been discussed). The prose's job is to help the user pattern-match against intent before reading bullets — they may agree with each individual Stated bullet but disagree with the overall framing, and the prose surfaces that gist. Even Lightweight benefits from a gestalt; a synthesis with more than 2-3 bullets total benefits from a 1-3 line summary at the top. The only legitimate skip is the truly-trivial case (e.g., the user's prompt was itself a complete scope statement like "fix the typo on line 47" and the synthesis is one or two Stated bullets that just echo it).

Prose lives inside the synthesis section, immediately after the lead-in line and before the Stated bucket — not as a separate prose block above the synthesis. Putting extensive prose ABOVE the synthesis (an approach pitch, behavior bullets, rationale) inverts the structure: the synthesis becomes a footnote to the proposal instead of the proposal being a 1-3 line gloss on the synthesis.

Anti-fluff guidance: if the prose starts with "This is a substantive proposal that..." or "The synthesis addresses important concerns about...", stop and rewrite. Lead with the actual thing being proposed in plain words. No qualifiers ("comprehensive," "thoughtful," "substantive"). No re-stating dialogue context the user just lived through. If you can't say what the work is in 1-3 lines without filler, the synthesis isn't ready yet.

Anti-pattern: synthesis as proposal-pitch. If you find yourself writing a "Recommendation" / "Behavior when X" / "Why this shape" block above the synthesis with file paths, JSON shapes, or error messages, stop. That content is Phase 3 (doc-write) territory — it belongs in the requirements doc body the next phase will write, not in the synthesis presentation. The synthesis is a scope checkpoint: three buckets plus a 1-3 line gloss. Implementation detail leaking into the synthesis is a sign that Phase 2 (approach selection) and Phase 3 (doc-write) have collapsed into Phase 2.5.

Based on our dialogue and approach selection, here's the scope I'm proposing for the requirements doc:

[1-3 line prose summary — what's being proposed in plain language. Required for all tiers; skip only for truly-trivial cases where the synthesis is ≤ 2 bullets that echo the prompt.]

**Stated** (from your input and our dialogue):
- [item]
- [item]

**Inferred** (gaps I filled with assumptions — flag anything I got wrong):
- [item]
- [item]

**Out of scope** (deliberately excluded):
- [item]
- [item]

Does this match your intent? Tell me what to add, remove, redirect, or that I got wrong — or just confirm to proceed. (You can rebut even if my synthesis accurately reflects what you said earlier — you may have changed your mind, surfaced new context, or want to correct an unstated assumption.)

Use prose for the user response (no AskUserQuestion menu). The justification is Interaction Rule 5(a) in SKILL.md — option sets bias the answer by signaling which dimensions matter.

---

Re-present after revision; write only on confirm

A revision is not a confirmation. After any user revision (even a trivially-understood swap like "rename --foo to --bar"), integrate the change, re-present the revised synthesis with the change reflected, and wait for explicit confirmation before writing the doc. The loop is:

1. Present synthesis → user responds 2. User confirms → write the doc 3. User revises → integrate, re-present revised synthesis, return to step 1

Doc-write fires only on explicit confirm or after the soft-cut blocking question's "proceed" option (see below). The confirmation step is what makes the synthesis confirmed rather than "agent's last proposal" — never write immediately after a revision, even when the revision is small enough that the agent feels it understood.

---

Granularity: name the decision; don't expand it

Each Stated and Inferred bullet should be affirmable or rejectable by the user without reading code or looking up implementation details. Name the decision at the scope level the user can judge — anything more specific is Phase 3 (doc-write) content.

Not allowed in synthesis bullets (always doc-body):

• Implementation paths, file names, method names, or class references
• Exact JSON / schema shapes or field names
• HTTP status codes or wire formats
• Exact wording of error messages or UI labels
• SQL syntax, query bodies, or specific column references

Bad-vs-good examples

The test: a scanner reading a bullet should affirm or reject it on product / scope grounds, not on architecture grounds. If they have to evaluate file paths or schema specifics, the granularity is wrong.

---

Soft-cut on circularity (not iteration count)

Track which Stated/Inferred/Out items the user touched per round. The soft-cut blocking question fires only when the same item is revised twice (or a third-round revision targets an item already revised in round two). New-item revisions across rounds proceed without limit — revising different aspects of a wrong synthesis (e.g., user pushed back on Stated, then on Inferred) is exactly what the mechanism should support.

When the soft-cut fires, use the platform's blocking question tool (AskUserQuestion in Claude Code, request_user_input in Codex, ask_user in Gemini, ask_user in Pi) with two options:

• Proceed with the current revised synthesis
• Stop and redirect — discuss further before writing the doc

Fall back to a numbered list in chat only when no blocking tool exists or the call errors. Never silently skip.

---

Headless mode

When the skill is invoked from an automated workflow such as LFG or any disable-model-invocation context, the skill runs in non-interactive mode (no synchronous user). This does NOT mean unaudited — the artifact is read by downstream skills (ce-doc-review, ce-plan) and human reviewers (PR review). Audit shifts from chat history to the artifact itself.

Behavior:

• Compose the synthesis as in interactive mode. The forcing function is preserved; the agent must articulate its scope interpretation explicitly.
• No user prompt; no blocking question. Skip the confirmation step.
• Route content into the doc with mode-aware shape:
• Stated content → Requirements (user's actual stated constraints)
• Out-of-scope content → Scope Boundaries (deliberate exclusions)
• Inferred content → ## Assumptions section — explicitly labeled as un-validated agent bets that downstream review must scrutinize. Do NOT route Inferred items into Key Decisions or Requirements; that would make un-validated bets indistinguishable from user-confirmed decisions.

The ## Assumptions section appears in non-interactive docs only. In interactive mode, Inferred bets get user-corrected in chat and become decisions; the section is absent.

This restores the audit visibility the original design intended (un-validated bets must not propagate as authoritative content), but surfaces them under their own label rather than hiding them. Downstream review can scrutinize Assumptions specifically.

---

Self-redirect

If the user response indicates they're in the wrong skill or want a different workflow (e.g., "this is too small, just /ce-work it" or "this needs more thought, let me brainstorm differently"):

• Stop ce-brainstorm
• Suggest the alternative skill the user appears to want (e.g., /ce-work, /ce-debug)
• Offer to load it in-session
• Do not push back or argue — the user's redirect signal is the deliberate choice

This support exists because the synthesis is an honest checkpoint. If the user discovers the skill choice was wrong by reading the synthesis, redirecting is the right move.

---

Doc shape after confirmation

After user confirmation (or after the soft-cut decision proceeds), Phase 3 writes the requirements doc. The three-bucket structure does NOT carry into the doc as a ## Synthesis section. Only the prose summary embeds, as ## Summary at the top. Bucket content dissolves into the doc's body sections:

No italic capture-context note (e.g., "Captured at Phase 2.5..."). It would leak engineering process into an artifact whose readers do not need that signal.

The doc's ## Summary and ## Problem Frame must serve distinct purposes — see references/requirements-capture.md "Summary vs Problem Frame discipline" for the rules.

---

When the synthesis would be redundant

For trivial Lightweight cases where the user's prompt was already a complete scope statement (e.g., "fix the typo on line 47"), the synthesis is mostly Stated with no Inferred or Out items. The transition checkpoint still has value (signals "about to write a doc; confirm or interrupt"), but keep the output to one paragraph with no ceremony. Do not pad the buckets to look thorough.

---

What does NOT belong in the synthesis

• Implementation details (libraries, schemas, file paths, JSON shapes, exact error message wording) — those are Phase 3 plan-time content, not scope-level synthesis
• Re-statement of the entire dialogue — the synthesis is a summary, not a transcript
• Defensive what-ifs and hedges — if a concern is real, state it as Inferred or Out; if it's speculation, drop it
• Open questions surfaced outside the three buckets — by synthesis time, every scope-shaping question must be in Stated (asked and answered earlier), Inferred (agent's bet for correction), or Out (deliberately excluded). There is no fourth status. If a question genuinely cannot be defaulted, pause synthesis and resolve it before presenting — pick the question shape that matches: a blocking multiple-choice tool when options are bounded and meaningfully distinct, prose when option sets would bias the answer per Interaction Rule 5(a). Integrate the answer, then present synthesis. Never present synthesis with adjacent floating questions — that gives the user no clear resolution path

Universal Brainstorming Facilitator

This file is loaded when ce-brainstorm detects a non-software task (Phase 0). It replaces the software-specific brainstorming phases (Phases 0.2 through 4) with facilitation principles for any domain. The Core Principles and Interaction Rules in the parent ce-brainstorm/SKILL.md still apply unchanged — including one-question-per-turn and the default to the platform's blocking question tool. This file extends those rules with universal-domain facilitation guidance; it does not relax them.

---

Your role

Be a thinking partner, not an answer machine. The user came here because they're stuck or exploring — they want to think WITH someone, not receive a deliverable. Resist the urge to generate a complete solution immediately. A premature answer anchors the conversation and kills exploration.

Match the tone to the stakes. For personal or life decisions (career changes, housing, relationships, family), lead with values and feelings before frameworks and analysis. Ask what matters to them, not just what the options are. For lighter or creative tasks (podcast topics, event ideas, side projects), energy and enthusiasm are more useful than caution.

Asking questions

"Thinking partner" framing does not mean "conversational prose." The parent skill's Interaction Rules apply in full: one question per turn, and default to the platform's blocking question tool (with its free-text fallback) even for opening and elicitation.

"What's prompting this?", "what matters most here?", and "what have you ruled out?" feel open-ended and conversational, but that's not a reason to skip the tool. The free-text option preserves flexibility while a well-crafted option set teaches the user the dimensions they might not have separated. Pick-plus-optional-note is lower activation energy than composing prose from scratch — especially for emotional or values-laden topics where prose can feel like an essay prompt.

Drop to prose only when (a) the answer is inherently narrative ("walk me through how you got here"), (b) the question is diagnostic or introspective and presented options would leak your priors and bias the answer, or (c) you cannot write 3-4 genuinely distinct, plausibly-correct options that cover the space without padding. If you'd be straining to fill the option slots, the question is open — use prose.

How to start

Assess scope first. Not every brainstorm needs deep exploration:

• Quick (user has a clear goal, just needs a sounding board): Confirm understanding, offer a few targeted suggestions or reactions, done in 2-3 exchanges.
• Standard (some unknowns, needs to explore options): 4-6 exchanges, generate and compare options, help decide.
• Full (vague goal, lots of uncertainty, or high-stakes decision): Deep exploration, many exchanges, structured convergence.

Ask what they're already thinking. Before offering ideas, find out what the user has considered, tried, or rejected. This prevents fixation on AI-generated ideas and surfaces hidden constraints.

When the user represents a group (couple, family, team) — surface whose preferences are in play and where they diverge. The brainstorm shifts from "help you decide" to "help you find alignment." Ask about each person's priorities, not just the speaker's.

Understand before generating. Spend time on the problem before jumping to solutions. "What would success look like?" and "What have you already ruled out?" reveal more than "Here are 10 ideas."

How to explore and generate

Use diverse angles to avoid repetitive ideas. When generating options, vary your approach across exchanges:

• Inversion: "What if you did the opposite of the obvious choice?"
• Constraints as creative tools: "What if budget/time/distance were no issue?" then "What if you had to do it for free?"
• Analogy: "How does someone in a completely different context solve a similar problem?"
• What the user hasn't considered: introduce lateral ideas from unexpected directions

Separate generation from evaluation. When exploring options, don't critique them in the same breath. Generate first, evaluate later. Make the transition explicit when it's time to narrow.

Offer options to react to when the user is stuck. People who can't generate from scratch can often evaluate presented options. Use multi-select questions to gather preferences efficiently. Always include a skip option for users who want to move faster.

Keep presented options to 3-5 at any decision point. More causes analysis paralysis.

How to converge

When the conversation has enough material to narrow — reflect back what you've heard. Name the user's priorities as they've emerged through the conversation (what excited them, what they rejected, what they asked about). Propose a frontrunner with reasoning tied to their criteria, and invite pushback. Keep final options to 3-5 max. Don't force a final decision if the user isn't there yet — clarity on direction is a valid outcome.

When to wrap up

Always synthesize a summary in the chat. Before offering any next steps, reflect back what emerged: key decisions, the direction chosen, open threads, and any assumptions made. This is the primary output of the brainstorm — the user should be able to read the summary and know what they landed on.

Then offer next steps using the platform's blocking question tool: AskUserQuestion in Claude Code (call ToolSearch with select:AskUserQuestion first if its schema isn't loaded), request_user_input in Codex, ask_user in Gemini, ask_user in Pi (requires the pi-ask-user extension). Fall back to numbered options in chat only when no blocking tool exists in the harness or the call errors (e.g., Codex edit modes) — not because a schema load is required. Never silently skip the question.

Question: "Brainstorm wrapped. What would you like to do next?"

• Create a plan → hand off to /ce-plan with the decided goal and constraints
• Save summary to disk → write the summary as a markdown file in the current working directory
• Open in Proof (web app) — review and comment to iterate with the agent → load the ce-proof skill to open the doc in Every's Proof editor, iterate with the agent via comments, or copy a link to share with others
• Done → the conversation was the value, no artifact needed

Visual Communication in Requirements Documents

Visual aids are conditional on content patterns, not on depth classification — a Lightweight brainstorm about a complex workflow may warrant a diagram; a Deep brainstorm about a straightforward feature may not.

When to include:

When to skip:

• Prose already communicates the concept clearly
• The diagram would just restate the requirements in visual form without adding comprehension value
• The visual describes implementation architecture, data schemas, state machines, or code structure (that belongs in ce-plan)
• The brainstorm is simple and linear with no multi-step flows, mode comparisons, or multi-participant interactions

Format selection:

• Mermaid (default) for simple flows — 5-15 nodes, no in-box annotations, standard flowchart shapes. Use TB (top-to-bottom) direction so diagrams stay narrow in both rendered and source form. Source should be readable as fallback in diff views and terminals.
• ASCII/box-drawing diagrams for annotated flows that need rich in-box content — CLI commands at each step, decision logic branches, file path layouts, multi-column spatial arrangements. More expressive than mermaid when the diagram's value comes from annotations within steps. Follow 80-column max for code blocks, use vertical stacking.
• Markdown tables for mode/variant comparisons and approach comparisons.
• Keep diagrams proportionate to the content. A simple 5-step workflow gets 5-10 nodes. A complex workflow with decision branches and annotations at each step may need 15-20 nodes — that is fine if every node earns its place.
• Place inline at the point of relevance, not in a separate section.
• Conceptual level only — user flows, information flows, mode comparisons, component responsibilities. Not implementation architecture, data schemas, or code structure.
• Prose is authoritative: when a visual aid and surrounding prose disagree, the prose governs.

After generating a visual aid, verify it accurately represents the prose requirements — correct sequence, no missing branches, no merged steps. Diagrams without code to validate against carry higher inaccuracy risk than code-backed diagrams.