brainstorming

name

brainstorming

description

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.

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

# [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

// 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

// 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