@fro.bot/systematic 2.6.0 → 2.6.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fro.bot/systematic",
-  "version": "2.6.0",
+  "version": "2.6.1",
   "description": "Structured engineering workflows for OpenCode",
   "type": "module",
   "homepage": "https://fro.bot/systematic",

package/skills/ce-brainstorm/references/handoff.md

@@ -0,0 +1,127 @@
+# 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 (`question` in OpenCode — call `ToolSearch` with `select:question` 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:systematic` / `Systematic`
+- **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:
+
+```text
+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:
+
+```text
+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.
+```

package/skills/ce-brainstorm/references/requirements-capture.md

@@ -0,0 +1,243 @@
+# 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
+
+| Section | Lightweight | Standard / Deep-feature | Deep-product |
+|---|---|---|---|
+| Summary | Required (1-3 line prose; skip only for truly-trivial cases — synthesis ≤ 2 bullets that echo the prompt) | Required (1-3 line prose) | Required (1-3 line prose) |
+| Problem Frame | Required | Required | Required |
+| Assumptions | Non-interactive only, when Inferred bets exist | Non-interactive only, when Inferred bets exist | Non-interactive only, when Inferred bets exist |
+| Actors | Omit unless triggered | Triggered (see below) | Triggered (see below) |
+| Key Flows | Omit unless triggered | Triggered (see below) | Expected by default |
+| Requirements | Required | Required (with R-IDs) | Required (with R-IDs) |
+| Acceptance Examples | Required for behavioral-conditional requirements ("When X, Y" / "If X, Y"); otherwise omit unless triggered | Required for behavioral-conditional requirements; otherwise triggered (see below) | Required for behavioral-conditional requirements; otherwise triggered (see below) |
+| Success Criteria | Required | Required | Required |
+| Scope Boundaries | Required (single list) | Required (single list) | Required (split into "Deferred for later" and "Outside this product's identity") |
+| Key Decisions | Include when material | Include when material | Include when material |
+| Dependencies / Assumptions | Include when material | Include when material | Include when material |
+| Outstanding Questions | Include when material | Include when material | Include when material |
+
+## 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:
+
+| Section | Question it answers | Time direction | Length |
+|---|---|---|---|
+| `## Summary` | What is this doc proposing? | Forward-looking | 1-3 lines |
+| `## Problem Frame` | Why does this proposal exist? | Backward-looking / situational | Paragraphs |
+
+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.
+
+```markdown
+---
+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.

package/skills/ce-brainstorm/references/universal-brainstorming.md

@@ -0,0 +1,63 @@
+# 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: `question` in OpenCode (call `ToolSearch` with `select:question` 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