| name | flow-brainstorm |
| description | Design phase — refine an idea into an approved spec through structured one-question-at-a-time dialogue, propose 2-3 approaches, present the design section by section, write the spec, and hand off to flow:plan. Works headless over any channel. |
flow:brainstorm — Design Phase (OpenClaw)
Turn an idea into a fully-formed spec through structured dialogue, then hand off to flow:plan.
Do NOT invoke flow:plan, write code, scaffold files, or take any implementation action until
the spec is written, self-reviewed, and the user has explicitly approved it.
Process
- Explore context. Read
CLAUDE.md (conventions, spec output path — that path always wins),
key project files, and git log --oneline -10.
- Assess scope BEFORE details. If the request names multiple independent subsystems, stop and
help decompose into sub-projects; brainstorm the first one. Don't ask detail questions about a
project that needs decomposition.
- Clarifying questions — one per message, multiple-choice preferred (2–4 options + a default).
Focus on purpose, users, constraints, success criteria. 3–5 questions is usually enough.
- Propose 2–3 approaches. Lead with your recommendation + one-sentence why; state trade-offs.
Don't present unequal options as equal.
- Present the design section by section (architecture, data model/interfaces, data flow, error
handling, testing). Scale each to its complexity. After each: "Does this section look right?"
- Write the spec to the CLAUDE.md path or
docs/specs/<YYYY-MM-DD>-<topic>.md. Include goal,
context, decisions, data model, behaviors, error handling, acceptance criteria, out-of-scope.
- Self-review (placeholder scan, internal consistency, scope, ambiguity). Fix inline.
- User review gate. "Spec written to
<path>. Review and tell me of any changes before
planning." Wait for explicit approval; revise + re-review on request.
- Hand off to flow:plan with the spec path.
OpenClaw notes
- Works headless: all questions are text-first and route through whatever channel the session uses
(CLI, Telegram, etc.). A visual companion is optional and additive, never required.
- This is a coordinator skill — it runs in the main agent, not a spawned specialist.
When NOT to brainstorm
Use flow:quick for one-sentence changes under 3 files (bug fix, rename, typo, config value).
Use brainstorm for new features, architectural changes, or anything spanning multiple files.
