---
name: brainstorming
description: >-
  Enforces design-before-implementation discipline. Hard gate: no code
  without approved design. Ensures collaborative brainstorming with
  structured questioning, approach proposals, and spec review.
type: behavioral
trigger-patterns:
  - design discussion
  - brainstorming session
  - spec creation
  - approach selection
discipline: rigid
category: design
tags:
  - brainstorming
  - design
  - spec
  - gate
agents:
  - gmd-discuss-phase
  - gmd-planner
---

# Brainstorming

## The Iron Law

```
NO IMPLEMENTATION WITHOUT DESIGN APPROVAL
```

If you don't have an approved spec, you don't write code. Period.

No "quick prototypes." No "I'll design as I go." No "the design is obvious."

If someone asks you to implement without an approved CONTEXT.md or spec: STOP. Run the brainstorming flow first. No exceptions.

## What Is Design Skipping?

Design skipping is the tendency to jump straight to code when the solution feels "obvious." It happens automatically -- your brain sees a problem, generates a plausible implementation, and the urge to start typing overwhelms the discipline to think first.

You don't decide to skip design. It happens because:
- The problem seems simple (it never is)
- You already have a solution in mind (your first solution is rarely the best)
- Writing code feels productive (writing the wrong code is worse than writing nothing)
- The user seems impatient (the user wants the right solution, not a fast wrong one)

The only defense is the hard gate: check for an approved spec BEFORE any implementation work begins. Every time.

## Hard Gate Protocol

Before ANY implementation work, ask yourself:

**1. Is there an approved CONTEXT.md or spec for this work?**
- If NO: STOP. You cannot proceed. Run the brainstorming flow.
- If YES: Proceed to check 2.

**2. Is the spec unambiguous for the work you're about to do?**
- If NO: Flag the ambiguities. Do not guess at the user's intent. Ask.
- If YES: Proceed to implementation.

**3. Does this work fall within the spec's scope?**
- If NO: The spec needs revision before you can proceed.
- If YES: Implement exactly what the spec says.

### Hard Gate Applies To

- New features
- Architectural changes
- Complex refactors
- Multi-component changes
- Workflow modifications

### Hard Gate Does NOT Apply To

- Bug fixes (existing behavior is the spec)
- Configuration changes (no design needed)
- Simple CRUD following established patterns (pattern is the spec)
- Documentation updates
- Dependency updates

When in doubt, the gate applies. "This doesn't need design" is rationalization.

## Brainstorming Discipline

When running a brainstorming session, follow these rules without exception:

### One Question at a Time

Never dump a questionnaire. Ask one question, wait for the answer, then ask the next. Each question should build on the previous answer.

Why: Questionnaire dumps overwhelm users and produce shallow, unconsidered answers. One question at a time forces thoughtful engagement.

### Propose Approaches with Trade-offs

Never ask "how should we build this?" Instead, propose 2-3 concrete approaches with clear trade-offs. Let the user choose from informed options.

Why: Users aren't architects. Transferring technical decisions to them produces suboptimal designs. Your job is to present options with honest trade-offs so they can make informed choices.

### Present Sections for Approval

Don't write the entire spec and ask for a rubber stamp. Present each major section (scope, approach, decisions, constraints) individually for approval before moving on.

Why: Early disagreement is cheap. Late disagreement means rework. Progressive approval catches misalignment early.

### Capture Decisions in Structured Format

Every decision must be one of:
- **Locked** -- User explicitly approved. Cannot change without user consent.
- **Discretion** -- User trusts the implementer's judgment. Can adapt during implementation.
- **Deferred** -- Explicitly not decided now. Will revisit later.

Why: Ambiguous decision status causes implementers to guess. Guessing causes drift. Drift causes rework.

## Domain Rationalization Prevention

These domain-specific patterns extend the universal rationalization-prevention skill. If you catch yourself thinking any of these, you are rationalizing:

| Thought | Reality |
|---------|---------|
| "The design is obvious" | If it were obvious, you wouldn't be building it. Obvious things already exist. |
| "This is just a small change" | Small changes to complex systems need design. Small is not simple. |
| "I already know what the user wants" | You know what you THINK they want. Ask. |
| "We can design as we go" | That's called hacking, not engineering. Design first. |
| "The tests will catch any issues" | Tests verify implementation, not design intent. Wrong design passes wrong tests. |
| "The spec is close enough" | Close enough for what? If you're guessing, the spec needs work. |
| "This is too simple for a spec" | Simple work has simple specs. Write it anyway. |
| "The deadline doesn't allow for design" | Implementing the wrong thing wastes more time than designing the right thing. |

## Anti-Pattern Table

| Anti-Pattern | Why It Fails | Instead |
|-------------|-------------|---------|
| Questionnaire dump | Overwhelms user, gets shallow answers | One question at a time with context |
| "How should we build X?" | Transfers technical decisions to non-technical user | Propose approaches, let user choose |
| Designing in the PR | Design is locked, code is the implementation | Design THEN implement |
| Skipping spec review | Drift accumulates undetected | Always run spec review gate |
| Rubber-stamp approval | User approves without understanding | Present sections individually, explain trade-offs |
| Scope creep during brainstorm | Session never converges | Define phase boundary first, hold the line |
| Premature solution fixation | First idea wins regardless of quality | Always present alternatives before committing |
| Assuming context | Prior decisions silently override new ones | Explicitly check STATE.md for conflicts |

## Skill Activation

This skill activates for:
- `discuss-phase` -- brainstorming a new phase's design
- `new-project` -- initial project brainstorming (mandatory)
- `new-milestone` -- milestone boundary brainstorming (mandatory)

**Co-requires:** rationalization-prevention (per rigid discipline contract). When this skill is loaded, rationalization-prevention MUST also be loaded. Both the universal red flag table and the domain-specific table above apply simultaneously.

## The Bottom Line

Design is not overhead. Design is the work.

Code without design is a guess. Guesses compound into systems nobody understands, nobody can change, and nobody trusts.

The hard gate exists because the moment you think "I don't need to design this" is the moment you need design most.

Follow the gate. Every time. No exceptions.
