Brainstorming

Brainstorming

When to Brainstorm vs When to Decide

Brainstorm when:

• Multiple valid approaches exist
• You don't yet know the constraints
• The cost of choosing wrong is high
• You want to surface blind spots

Decide immediately when:

• One approach is clearly better
• Time is critical and any reasonable option works
• The decision is easily reversible

Technique 1: Six Thinking Hats

Work through each lens sequentially before converging.

WHITE HAT — Facts & Data
  "What do we know for certain?"
  "What data do we have? What data do we need?"
  Example: "We have 10k users. P95 response time is 2s. Database has 1M rows."

RED HAT — Gut Feelings & Emotions
  "What feels wrong about this?"
  "What are we uncomfortable with?"
  Example: "This approach feels fragile. I'm not confident in the third-party service."

BLACK HAT — Critical Thinking & Risks
  "What could go wrong?"
  "What are the weaknesses?"
  Example: "If the cache fails, we hit the DB directly and it falls over."

YELLOW HAT — Optimism & Benefits
  "What's the best-case scenario?"
  "What does success look like?"
  Example: "If this works, we reduce load by 80% and can scale without upgrading the DB."

GREEN HAT — Creativity & Alternatives
  "What else could we do?"
  "Are there completely different approaches?"
  Example: "What if we precomputed this nightly? What if we used read replicas?"

BLUE HAT — Process & Facilitation
  "What's our decision process?"
  "What do we need to decide today vs later?"
  Example: "We need to pick an approach now for sprint planning. Cache vs CDN can be decided next sprint."

Technique 2: Diverge-Converge

DIVERGE (10 minutes — no judgment)
  Generate as many options as possible
  Crazy options are welcome — they often contain the seed of the real solution
  No evaluation, no "but", no "however"

CONVERGE (10 minutes — structured evaluation)
  Group similar options
  Apply constraints to eliminate non-starters
  Score remaining options on key criteria
  Select top 2-3 for detailed analysis

Technique 3: How Might We (HMW)

Reframe problems as opportunities.

Problem: "Users don't complete onboarding"
HMW: "How might we make onboarding feel like progress, not work?"
HMW: "How might we surface value before asking for effort?"
HMW: "How might we let users skip steps they've done elsewhere?"

Problem: "The API is slow under load"
HMW: "How might we reduce the number of DB queries per request?"
HMW: "How might we serve cached responses for read-heavy endpoints?"
HMW: "How might we move expensive work out of the request path entirely?"

Technique 4: Pre-Mortem

Imagine it's 6 months from now and the project failed spectacularly. Work backwards to find what caused it.

"It's October. The launch went badly. What happened?"

Participants each write 3-5 reasons it failed:
- "We underestimated the data migration complexity"
- "The third-party auth provider had an outage on launch day"
- "The mobile app wasn't tested on Android 12"
- "We shipped without rate limiting and got scraped"

Now: address the most plausible failure modes before you start.

Trade-off Analysis Matrix

// Template for comparing options on explicit criteria

interface Option {
  name: string
  scores: Record  // 1-5
}

interface Criterion {
  name:   string
  weight: number  // 0-1, sums to 1.0
}

function scoreOptions(options: Option[], criteria: Criterion[]): ScoredOption[] {
  return options.map(option => {
    const total = criteria.reduce((sum, criterion) => {
      const score = option.scores[criterion.name] ?? 0
      return sum + score * criterion.weight
    }, 0)
    return { ...option, total }
  }).sort((a, b) => b.total - a.total)
}

// Example: Choosing a caching strategy
const criteria: Criterion[] = [
  { name: 'Simplicity',      weight: 0.25 },
  { name: 'Performance',     weight: 0.35 },
  { name: 'Reliability',     weight: 0.25 },
  { name: 'Cost',            weight: 0.15 },
]

const options: Option[] = [
  {
    name: 'Redis (external)',
    scores: { Simplicity: 3, Performance: 5, Reliability: 4, Cost: 3 },
  },
  {
    name: 'In-memory (LRU)',
    scores: { Simplicity: 5, Performance: 5, Reliability: 2, Cost: 5 },
  },
  {
    name: 'Database query cache',
    scores: { Simplicity: 4, Performance: 3, Reliability: 5, Cost: 5 },
  },
]

Architecture Decision Template

## Problem
[One paragraph describing the problem clearly]

## Constraints
- Must integrate with existing TypeORM setup
- P95 response must be  C > B

API Design Brainstorm Checklist

When designing a new API endpoint, ask:

□ Who is the primary consumer? (frontend, mobile, third-party)
□ What's the simplest URL that makes sense? (noun, not verb)
□ What does a successful response look like? (shape, status code)
□ What are the failure modes? (validation error, not found, unauthorized)
□ What are the pagination needs? (cursor, offset, none)
□ What fields should be filterable/sortable?
□ What auth level is required? (public, authenticated, admin)
□ Will this be called frequently? (rate limiting, caching strategy)
□ What changes might break clients? (versioning strategy)
□ Is there an existing similar endpoint we should be consistent with?

Forbidden Patterns

• Never brainstorm for more than 25 minutes without converging — it becomes circular
• Never let the loudest voice shut down divergence — document all ideas before filtering
• Never confuse "brainstorming" with "deciding" — separate the two phases explicitly
• Never skip the trade-off analysis for architectural decisions — "it feels right" is not enough
• Never generate options without also defining the evaluation criteria

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: sabahattink
• Source: sabahattink/antigravity-fullstack-hq
• License: MIT
• Homepage: https://github.com/sabahattink/antigravity-fullstack-hq

Install and usage instructions live in the source repository linked above.