brainstorming

name	brainstorming
description	Use when starting any new feature, significant change, or architectural decision. Explores requirements and options before any implementation begins.

Brainstorming

Core Rule

NO IMPLEMENTATION BEFORE DESIGN APPROVAL.

Do not write code, scaffold files, or invoke any implementation action until the user has explicitly approved an approach.

The Process

1. Understand the goal

Ask clarifying questions one at a time. Prefer multiple-choice questions over open-ended ones. Stop when you understand:

• What problem this solves and for whom
• What success looks like concretely
• Hard constraints: tech stack, existing patterns, things that must not break

Cap at 3 questions. If you need more, the scope is likely too large to design in one session — say so and propose breaking it down.

2. Explore what already exists

Before proposing anything, look at the codebase:

• Find related files with Glob and Grep
• Understand existing patterns and conventions
• Identify what can be reused vs. what needs to be built

Never propose a solution that ignores what's already there.

3. Propose 2–3 approaches

For each approach, state:

• What it is — one sentence
• Why you'd choose it — the key advantage
• The tradeoff — what you give up or complicate
• Scope — small / medium / large

Apply YAGNI ruthlessly. Do not propose approaches that add complexity for hypothetical future requirements.

4. Get approval

Present the approaches. Ask the user to pick one or suggest modifications. Do not start anything until they confirm.

5. Summarize before proceeding

Once an approach is approved, write a brief summary:

• What we're building
• The chosen approach and why
• Key constraints or decisions made
• What we're explicitly not building

Then ask whether to proceed directly to implementation or plan it out first.

If the approved approach has multiple distinct phases or will span several sessions, note those phases explicitly — they're good candidates for a ROADMAP.md. Suggest using /bender:roadmap to capture them before implementing.

Rules

• One question per message during clarification — do not ask multiple questions at once
• Never propose more than 3 approaches
• Never begin implementation without explicit user approval
• YAGNI: if it isn't needed this week, don't design for it