Brainstorming skill: divergent thinking guidato con Claude Code

Quando chiedi a un LLM di risolvere un problema di design, succede una cosa fastidiosa: il modello converge sulla prima soluzione plausibile e poi la difende. Non perché sia la soluzione migliore, ma perché è la prima che ha generato. La skill brainstorming di Superpowers esiste per forzare un comportamento diverso: divergere prima, convergere dopo, e dichiarare il passaggio fra le due fasi in modo esplicito.

Disclaimer di indipendenza: non sono affiliato a obra né ad Anthropic. Quanto leggi è esperienza diretta di circa un anno con la skill brainstorming installata da Superpowers, usata su tutte le decisioni di design del mio portfolio brownfield.

Il problema: convergence bias dei LLM

Senza una skill di brainstorming attiva, una conversazione tipica con Claude su una decisione di design sembra questa:

1. Utente: "Come dovrei strutturare X?"
2. Modello: "Pattern A. [proposta dettagliata]"
3. Utente: "Ho dubbi su Y nel pattern A."
4. Modello: "[difesa del pattern A + piccoli aggiustamenti]"

Quello che non succede: il modello considera spontaneamente pattern B, C, D, valuta i tradeoff, e poi raccomanda quale è meglio nel contesto. Non lo fa perché è ottimizzato per essere immediato e assertivo. La risposta arriva in due secondi anche quando la domanda meriterebbe due minuti di esplorazione.

Risultato: decisioni prese sulla prima opzione plausibile, con difese a posteriori ben articolate. Sui sei mesi iniziali del mio portfolio ho preso almeno tre decisioni di architettura che ho dovuto riconsiderare entro un quarto, perché la "prima opzione plausibile" si è rivelata fragile in produzione. Una skill di brainstorming attiva avrebbe portato sul tavolo le alternative che a posteriori erano migliori.

Cosa fa la skill brainstorming

La skill brainstorming di Superpowers (riassunto del body tipico - non copia integrale) impone una procedura in tre fasi:

1. Diverge - genera N alternative (tipicamente 5-8) senza valutarle. La regola esplicita è "qui sospendiamo il giudizio".
2. Evaluate - per ogni alternativa, elenca pro/contro/contesto-dove-funziona/contesto-dove-fallisce.
3. Converge - raccomanda una (o due, se il tradeoff è genuinamente in equilibrio) basandosi sull'evaluation.

La differenza pratica: dove senza skill avresti una proposta di pattern A con difesa, con skill hai una mappa di 5-8 pattern, ognuno valutato, con raccomandazione finale ragionata. Il numero di parole in output cresce di 3-5x. Il numero di decisioni sbagliate cala (sul mio campione personale, da 3-4 decisioni "to-be-reconsidered" su 20 in un trimestre, a 0-1 su 20 dopo aver adottato la skill).

Esempio illustrativo: scelta del pattern di scheduling articoli

Riassunto (non literal transcript) di una sessione brainstorming reale del mio portfolio. Domanda: "Come dovrei implementare lo scheduling di articoli con publishedAt futuro su Angular SSR + backend Spring Boot?"

Fase 1 - Diverge (alternative generate)
  A) Cron job backend che promuove articoli a "published" a scadenza
  B) Filtering runtime Express SSR (publishedAt > now() -> 410 Gone)
  C) Build-time prerender filtering (rebuild on schedule changes)
  D) ISR-like cache con Redis (TTL su publishedAt)
  E) GraphQL resolver-level filter (publishedAt filter at query time)
  F) Client-side hide (publishedAt > now() -> hidden via CSS)
  G) Hybrid: filtering runtime Express + cron housekeeping notturno

Fase 2 - Evaluate
  [per ogni opzione: pro / contro / quando-funziona]

Fase 3 - Converge
  Raccomandazione: G (hybrid Express runtime + cron housekeeping).
  Rationale: Express runtime garantisce pubblicazione "al secondo" senza
  rebuild; cron notturno gestisce promozione database + invalidazione cache.

Senza skill avrei probabilmente preso A (cron backend) come prima opzione ovvia e l'avrei difeso. La fase Diverge ha portato sul tavolo G, che è effettivamente quello che ho poi implementato e che funziona bene da mesi.

Quando NON usare brainstorming

La skill ha un costo (3-5x token + slowdown decisionale). Tre situazioni in cui è meglio non invocarla:

1. Decisione tattica con un'unica scelta sensata. Esempio: "Quale nome dare a questa variabile?" Brainstorming è overkill; c'è solo una convenzione corretta.
2. Decisione con vincolo esterno duro. Esempio: "Devo usare PostgreSQL o MongoDB?" se hai già PostgreSQL in produzione e nessuna ragione concreta di cambiare. Il vincolo "esistente" rende la divergenza accademica.
3. Decisione che hai già preso e devi solo implementare. Esempio: "Implementa il pattern Repository per UserRepository". Stai chiedendo esecuzione, non design.

Regola pratica: invoca brainstorming quando esistono almeno 3-4 alternative ragionevoli e la scelta ha conseguenze che durano mesi (non giorni).

Anti-pattern: brainstorming senza fase evaluate

Senza la fase Evaluate esplicita, la divergenza degenera in lista shopping: 8 alternative, nessuna analizzata, raccomandazione "potresti provare A, oppure B, dipende dal contesto". Inutile.

Il valore della skill è che obbliga il passaggio Evaluate prima della Convergenza. Se invochi brainstorming e ricevi raccomandazione vaga, controlla nel body della SKILL.md della tua installazione: forse hai una versione che non include esplicitamente la fase Evaluate, e conviene scriverla tu (variant custom).

Integrazione con discuss-phase di GSD

Pattern operativo che uso sul portfolio: ogni nuova fase GSD inizia con una sessione brainstorming sulle decisioni macro, l'output Evaluate va direttamente nel CONTEXT.md della fase via /gsd-discuss-phase N.

Pipeline tipica:

1. /gsd-phase 21 "Add OAuth Google login + Stripe webhook"
2. Invoca skill brainstorming sulle 2-3 decisioni macro
   ("OAuth provider? Stripe webhook auth method? Token refresh strategy?")
3. /gsd-discuss-phase 21 -> CONTEXT.md raccoglie decisioni convergenti
4. Le alternative scartate vanno in CONTEXT.md "Deferred Ideas"
5. /gsd-plan-phase 21 -> planner riceve CONTEXT con decisioni motivate

Il vantaggio dell'integrazione: le "Deferred Ideas" del CONTEXT non sono ipotesi astratte, sono alternative valutate e scartate per ragioni esplicite. Sei mesi dopo, quando rileggi il CONTEXT per una fase collegata, capisci immediatamente perché avevi preso quella strada.

Trappole cognitive evitate dalla skill

Brainstorming strutturato evita (almeno parzialmente) cinque trappole cognitive che colpiscono sia gli umani sia i LLM:

1. Anchoring: ancorarsi alla prima idea. La fase Diverge impone N alternative prima di valutare, quindi nessuna idea ha il privilegio di "essere stata pensata per prima".
2. Confirmation bias: cercare ragioni per la propria scelta iniziale. La fase Evaluate impone pro/contro per ogni alternativa, non solo per quella preferita.
3. Premature convergence: chiudere una decisione prima di esplorare il problema. La separazione esplicita delle tre fasi impedisce di saltare da Diverge a Converge senza Evaluate.
4. Sunk cost fallacy: difendere una decisione perché ci hai già investito tempo. La skill istruisce il modello a valutare ogni alternativa come se non avesse familiarità con nessuna.
5. Authority bias: scegliere il pattern raccomandato dai "guru". La skill istruisce esplicitamente a considerare pattern reali in produzione (non solo pattern blog-friendly), e a includere alternative meno popolari quando il contesto lo giustifica.

Variante custom: brainstorming con vincoli espliciti

Una variante che ho aggiunto al brainstorming sul mio portfolio: prima della fase Diverge, dichiaro i vincoli duri (es. "deve girare su Ollama on-prem", "no AWS", "no nuove dipendenze npm runtime"). La skill filtra le alternative escludendo quelle che violano i vincoli, ma le cita comunque nella fase Evaluate per spiegare perché sono fuori scope. Esempio illustrativo:

Vincoli duri:
  - Stack on-prem (no SaaS esterni)
  - No nuove dipendenze runtime > 50KB bundle impact
  - Compatibilità Angular SSR (no client-only)

Diverge (alternative):
  A) Algoritmo X [accettabile]
  B) Algoritmo Y [accettabile]
  C) SaaS terza parte Z [SCARTATA per vincolo 1]
  ...

Evaluate (solo accettabili A e B + nota su C):
  A: pro X1 X2, contro X3
  B: pro Y1, contro Y2 Y3
  C: scartata per vincolo on-prem (rationale completo per traceability)

Converge: A

L'inclusione di C anche se scartata serve a documentare la decisione. Sei mesi dopo, se ti chiedi "perché non abbiamo usato il SaaS Z?", la risposta è nel CONTEXT.md.

Sessione tipica: tempi e costi

Sul mio portfolio, una sessione brainstorming tipica (decisione di design medium-complexity) ha questi parametri approssimativi:

• Durata: 5-10 minuti di interazione attiva (vs. 1-2 minuti senza skill).
• Token consumati: 8-15k in/out (vs. 2-4k senza skill).
• Numero di alternative generate: 5-8.
• Output: 800-1500 parole strutturate (Diverge + Evaluate + Converge).

Costo monetario: in euro la differenza è 0,05-0,15 per sessione (Sonnet tariffa standard). Trascurabile per il valore: una decisione di design sbagliata costa giorni di rework, mentre dieci minuti di brainstorming strutturato costano centesimi.

Quando brainstorming è meglio di "scrivi due opzioni e vediamo"

C'è una via di mezzo che molti usano: chiedere al modello "scrivimi due opzioni e poi decido io". Funziona, ma manca due cose rispetto a brainstorming strutturato:

1. Solo due opzioni: si perde la "long tail" di alternative meno ovvie ma a volte migliori.
2. Nessuna fase Evaluate forzata: il modello può proporre due opzioni superficiali senza analizzare i tradeoff in profondità.

Brainstorming come skill formalizza il processo. Le due opzioni informali sono una versione light del pattern; la skill è la versione completa. Per decisioni minori il light è sufficiente; per decisioni che durano mesi, la skill paga il costo.

Cosa ho imparato scrivendo questo articolo

La cosa che mi ha sorpreso è quanto fosse difficile distinguere "brainstorming reale" da "lista di alternative". Per i primi mesi pensavo di "fare brainstorming" semplicemente chiedendo al modello di proporre tre opzioni. Quando ho confrontato i miei output con quelli della skill formale, ho realizzato che mancavo sistematicamente la fase Evaluate: producevo liste, non analisi.

La seconda lezione è sul rapporto fra LLM bias e umano bias. Pensavo che l'LLM avesse più bias di convergenza precoce di un umano. In realtà è uguale, ma più visibile: l'umano prende decisioni in silenzio mentre l'LLM le scrive, e la decisione mal motivata si vede. Brainstorming strutturato è utile anche al pair umano: la stessa skill applicata a una decisione presa "a istinto" da te ti costringe a giustificarla, e qualche volta a cambiarla.

Anti-pattern evitati

• Brainstorming a posteriori: invocare la skill dopo aver già deciso, sperando di "confermare". Il modello capisce che hai deciso (lo dici nel prompt o nel context) e tende a produrre fase Evaluate orientata alla conferma. Brainstorming va invocato prima della decisione, non dopo.
• Brainstorming senza output persistito: la sessione finisce, l'output va via, sei mesi dopo non sai più perché hai scelto A invece di B. Il pattern integrato con discuss-phase risolve questo: l'output Evaluate va nel CONTEXT.md della fase e resta accessibile.

Una storia ricevuta che vale la pena condividere

Sezione segnaposto. Se hai un esempio di decisione di design dove la skill brainstorming ti ha portato a una soluzione diversa da quella iniziale, scrivimi a federico@federicocalo.dev. Con il tuo consenso esplicito (pseudonimizzato) la storia entra nel cluster successivo.

← Cluster precedente: Skill design pattern Prossimo cluster: Debugging skill →