# Brainstorming

> Advanced brainstorming protocol with 2026 Modern Web Guidance. Use this skill whenever the user wants to ideate, plan, architect, or design a new feature, product, or system — especially for web applications. Trigger on phrases like "brainstorm", "let's plan", "how should I approach", "help me design", "what's the best way to build", "I want to create", "give me ideas for", "design document", "technical spec", or "architecture for". Also trigger when the user is starting a new project and needs a structured Design Document (DD) output. Covers RSC, PPR, Server Actions, AI integration, Passkeys, and structured output templates.

- Skill: `roedyrustam/brainstorming-2` (Agent Skill)
- Install (CLI): `npx skillmds@latest add roedyrustam/brainstorming-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/roedyrustam/brainstorming-2/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: roedyrustam (https://skillmd.com/u/roedyrustam)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/roedyrustam/brainstorming-2

---


# Advanced Brainstorming Protocol

Structured ideation and design for modern web products — 2026 stack guidance included.

---

## How to Run a Brainstorming Session

### Phase 1: Understand the Problem Space

Before generating solutions, extract clarity on:

1. **What** — What is being built? (feature, product, system)
2. **Who** — Target users / personas
3. **Why** — Core problem being solved / jobs to be done
4. **Constraints** — Budget, timeline, team size, existing stack
5. **Success metrics** — How will we know it worked?

Ask targeted questions. Do NOT generate solutions until you have at least 3–4 of these answers.

---

### Phase 2: Explore Solution Space

Generate ideas across multiple dimensions:

#### Diverge (generate broadly)
- List 5–10 approaches without filtering
- Include unconventional or ambitious options
- Consider: simplest possible solution, most scalable, most user-delightful

#### Converge (evaluate & select)
Use a simple scoring matrix:

| Approach | Effort (1-5) | Impact (1-5) | Risk (1-5) | Score |
|----------|-------------|-------------|------------|-------|
| Option A | 2 | 4 | 2 | 8 |
| Option B | 4 | 5 | 3 | 6 |

Score = Impact - (Effort × 0.5) - (Risk × 0.3)

---

### Phase 3: Design Document Output

After convergence, produce a structured Design Document (DD):

---

## Design Document Template

```markdown
# [Feature/Product Name] — Design Document

**Version**: 1.0.0
**Date**: YYYY-MM-DD
**Author**: [Name]
**Status**: Draft | Review | Approved

---

## 1. Overview

### Problem Statement
[1–3 sentences describing the problem]

### Proposed Solution
[1–3 sentences describing what we're building]

### Goals
- [ ] Goal 1
- [ ] Goal 2

### Non-Goals
- NOT doing X
- NOT doing Y

---

## 2. User Stories

| ID | As a... | I want to... | So that... | Priority |
|----|---------|-------------|------------|----------|
| U1 | visitor | sign in with passkey | skip passwords | P0 |
| U2 | user | see AI-suggested content | discover faster | P1 |

---

## 3. Technical Architecture

### Stack Decision
| Layer | Choice | Reason |
|-------|--------|--------|
| Framework | Next.js 15 | App Router, RSC, PPR |
| Database | PostgreSQL + Drizzle | Type-safe, migrations |
| Auth | Clerk / Passkeys | WebAuthn, MFA |
| AI | Vercel AI SDK + Claude | Streaming, tool use |
| Cache | Redis (Upstash) | Serverless-safe |
| Deployment | Vercel | Zero-config, edge |

### System Diagram (describe components)
```
[Browser]
  │ HTTPS
  ▼
[Next.js Edge Middleware]  ← auth check, geo, A/B
  │
  ├── [RSC Pages] ← DB queries, no JS shipped
  │     └── [Client Components] ← interactive islands
  │
  ├── [Server Actions] ← mutations, form handling
  │
  └── [API Routes] ← webhooks, external integrations
        │
        ├── [PostgreSQL] ← primary data
        ├── [Redis] ← cache, sessions, queues
        └── [BullMQ Workers] ← async jobs
```

### Data Models
```typescript
// Core entities
type User = {
  id: string
  email: string
  // ...
}
```

---

## 4. Feature Breakdown

### [Feature 1 Name]
**Description**: [What it does]
**User flow**: [Step by step]
**Technical notes**: [How it works under the hood]
**Edge cases**: [What can go wrong]

---

## 5. API Design

### Endpoints
| Method | Path | Auth | Description |
|--------|------|------|-------------|
| GET | /api/items | Required | List items |
| POST | /api/items | Required | Create item |

### Server Actions
| Action | Input | Output | Side Effects |
|--------|-------|--------|-------------|
| `createItem` | `FormData` | `{ id, slug }` | revalidate `/items` |

---

## 6. Security Considerations

- [ ] Input validation (Zod on all boundaries)
- [ ] Rate limiting on public endpoints
- [ ] CSRF protection (Server Actions have built-in protection)
- [ ] RLS policies on database
- [ ] Secrets in environment variables only
- [ ] Passkeys / MFA for sensitive operations

---

## 7. AI Integration (if applicable)

### Model & SDK
- Use `claude-sonnet-4-6` via Vercel AI SDK
- Streaming responses for UX responsiveness

```typescript
// Example AI integration
import { streamText } from 'ai'
import { anthropic } from '@ai-sdk/anthropic'

export async function POST(request: Request) {
  const { messages } = await request.json()

  const result = await streamText({
    model: anthropic('claude-sonnet-4-6'),
    system: 'You are a helpful assistant.',
    messages,
    maxTokens: 1000,
  })

  return result.toDataStreamResponse()
}
```

### AI Features Checklist
- [ ] Streaming responses (never block waiting for full response)
- [ ] Tool use / function calling (for structured outputs)
- [ ] Fallback for AI failures (degrade gracefully)
- [ ] Rate limiting per user
- [ ] Cost attribution per user/tenant

---

## 8. Passkeys / WebAuthn (if applicable)

### Flow
1. **Registration**: User creates passkey bound to device + domain
2. **Authentication**: Browser signs challenge with private key; server verifies with stored public key
3. **No passwords stored** — only public keys in DB

### Implementation
- Use `@simplewebauthn/server` + `@simplewebauthn/browser`
- Or Clerk (handles WebAuthn automatically)
- Store: `{ credentialId, publicKey, userId, deviceName, createdAt }`

---

## 9. Partial Prerendering (PPR) Strategy

```typescript
// next.config.ts
export default {
  experimental: {
    ppr: 'incremental', // opt-in per route
  },
}

// app/dashboard/page.tsx
export const experimental_ppr = true

// Static shell renders instantly at edge
export default function Dashboard() {
  return (
    <div>
      <StaticHeader />        {/* Prerendered — instant */}
      <Suspense fallback={<Skeleton />}>
        <DynamicFeed />       {/* Streams in after */}
      </Suspense>
      <Suspense fallback={<Skeleton />}>
        <PersonalizedSidebar /> {/* Streams in after */}
      </Suspense>
    </div>
  )
}
```

**PPR Decision Guide**:
- Use PPR when: page has mix of static shell + dynamic content
- Skip PPR when: entire page is dynamic (dashboard with user-specific data)
- Always use PPR when: marketing/product pages with personalization

---

## 10. Performance Targets

| Metric | Target | Measurement |
|--------|--------|-------------|
| LCP | < 2.5s | Core Web Vitals |
| FID/INP | < 200ms | Core Web Vitals |
| CLS | < 0.1 | Core Web Vitals |
| TTFB | < 800ms | Lighthouse |
| Bundle size | < 200KB JS | `next build` output |

---

## 11. Milestones & Rollout

| Phase | What | Timeline |
|-------|------|----------|
| M0 | Design doc approved | Week 1 |
| M1 | Core data model + auth | Week 2–3 |
| M2 | MVP feature complete | Week 4–6 |
| M3 | Beta testing | Week 7 |
| M4 | GA launch | Week 8 |

---

## 12. Open Questions

- [ ] Q: [Question needing answer]
  - Owner: [Name]
  - Due: [Date]

---

## 13. Alternatives Considered

| Alternative | Why Rejected |
|-------------|-------------|
| Option X | Too complex for current team size |
| Option Y | Doesn't support multi-tenancy |
```

---

## 2026 Modern Web Guidance Cheat Sheet

| Concern | Recommended Approach |
|---------|---------------------|
| **Rendering** | PPR (static shell + streaming dynamic) |
| **State** | Server state via RSC + `useOptimistic` for UI |
| **Mutations** | Server Actions + `useActionState` |
| **Auth** | Passkeys (WebAuthn) + Clerk |
| **AI** | Vercel AI SDK + streaming + tool use |
| **Data** | Drizzle ORM + PostgreSQL + Redis cache |
| **Search** | Postgres full-text or Typesense |
| **Files** | Vercel Blob or S3 |
| **Emails** | Resend + React Email |
| **Payments** | Stripe + webhooks via BullMQ |
| **Monitoring** | Sentry + Vercel Analytics |
| **Deployment** | Vercel (primary) or Fly.io (Docker) |

---

## Brainstorming Anti-Patterns to Avoid

❌ **Premature convergence** — Don't pick the first solution; explore at least 3  
❌ **Gold-plating** — Don't design for 10M users when you have 10  
❌ **Technology-first thinking** — Start with the problem, then pick tools  
❌ **Missing non-goals** — Explicitly state what you're NOT building  
❌ **No success metrics** — Every design doc needs measurable outcomes  
❌ **Skipping security section** — Auth, input validation, RLS always needed  
❌ **No fallback for AI** — AI calls can fail; always degrade gracefully