Brainstorm Workflow

Thin design-to-plan host. Design dialogue is owned by external Superpowers brainstorming; implementation planning is owned by in-repo solve-workflow「制定计划」. This host owns prerequisite checks, path prompt, terminal override (no writing-plans), and hard handoff.

Not a stricter solve-workflow. Bug root-cause / evidence-driven diagnosis → use solve-workflow or opsx-solve-workflow.

Output templates: reference.md.

Positioning

Prerequisite skill check

At startup, verify every frontmatter dependencies entry. If any is missing, abort with the install table in reference.md — no silent degradation.

Must not vendor: do not add skills/brainstorming/ to this repository.

Triggers and modes

Mode detection: trigger contains「自动」→ auto; else manual. Mid-run: 「切换自动模式」/「切换手动模式」.

Flow (host orchestration only)

0 Prerequisite check (brainstorming + solve-workflow)
1 Intent gate — if bug root-cause primary → redirect to solve / opsx-solve; abort this host
2 Load brainstorming — follow it for context → clarify → approaches → sectional design → write spec → self-review → user reviews written spec
   Host overrides (MUST win over brainstorming defaults):
   - Before write: ask save path; recommend docs/design/YYYY-MM-DD-<topic>-design.md
   - After written-spec approval: do NOT invoke writing-plans
3 Hard handoff — load solve-workflow at「制定计划」(Make a Plan); skip solve stages 1–4; pass design path + summary
4 Stop at solve stage-5 exit (plan confirmation) — further execute/verify is solve-workflow, not this host

Host exits

Stage details

0–1. Gate

1. Run prerequisite check.
2. If the user’s primary goal is locating/fixing a defect in existing behavior (root cause), redirect to solve-workflow / opsx-solve-workflow and abort this host (do not start brainstorming as a substitute for analysis-core).

2. Delegate design to brainstorming

Load brainstorming and follow its checklist (explore context, one question per turn, 2–3 approaches, sectional design approval, write design doc, spec self-review, user review of the written spec).

Overrides (host wins):

1. Save path — Before writing the design file, ask where to save. Recommend: docs/design/YYYY-MM-DD-<topic>-design.md. User preference overrides. Do not silently use docs/superpowers/specs/ unless the user chooses that path.
2. Terminal — After the user approves the written spec, do not invoke writing-plans. Go to hard handoff (§3).

Visual Companion and other brainstorming optional tools remain as defined by that skill (intent-only; no platform-tool hardcoding in this host).

3. Hard handoff to solve-workflow Make a Plan

1. Load solve-workflow.
2. Enter Stage 5 — Make a Plan only (skip stages 1–4 for this work item).
3. Supply handoff inputs (reference.md § Handoff payload): approved design path, short summary (goal, chosen approach, constraints, non-goals).
4. Produce the plan per solve-workflow Stage 5. This host MUST NOT write business/production code.

After the plan is confirmed, the user continues inside solve-workflow (「执行计划」…) if they want implementation — that is outside this host’s success criteria.

Red flags

• Starting design dialogue when the ask is bug root-cause analysis
• Invoking writing-plans after design approval
• Writing the design doc without a path question (unless auto accepted the announced default)
• Re-running solve stages 1–4 after a successful handoff for the same design
• Silent degrade when brainstorming or solve-workflow is missing
• Vendoring brainstorming into this repo