AIDive

Pack video

Superpowers per Claude Code: tabella del verdetto, fonti, checklist e guida avanzata

9 min di lettura

TL;DR

  • Superpowers è un processo, non una cassetta degli attrezzi: quattordici skill in markdown che fanno passare ogni feature da una sessione di brainstorming, un piano scritto e una catena di subagent nuovi, ciascuno con la sua review.
  • Installalo se le tue sessioni di Claude Code costruiscono feature che richiedono ore. Lascialo perdere se usi soprattutto script usa e getta e fix da due righe: il controllo d'ingresso gira a ogni task e non si spegne mai.
  • L'argomento dei token è reale, ma viene da una sola sezione di una sola skill: Model Selection. L'orchestratore assegna a ogni ruolo il modello più economico in grado di reggerlo, così il modello costoso tocca solo l'architettura e la review finale del branch.
  • Il repo è in salute: 280,597 stelle, 25,138 fork, 681 commit su main, release v6.3.0 del 2026-08-12, creato il 2025-10-09.
  • La lamentela da cui è partito il video, statistiche d'uso tra 1 e 3 percento, non è un bug: significa che le skill non scattano mai sul tuo lavoro, quindi paghi il gate e non ricevi nulla in cambio.
  • La via di mezzo è una frase nel prompt: di' all'agente di saltare il processo sui fix minuscoli e lascia girare solo il brainstorming per qualche giorno prima di adottare il resto.

Cosa dicono le fonti

I numeri del repository sono stati letti il 2026-09-02: 280,597 stelle, 25,138 fork e 681 commit sul branch main, con l'ultimo commit su main datato 2026-08-12 (v6.3.0) e un push successivo il 2026-08-31 su un branch diverso da main s1. Quel giorno la scheda Issues mostrava 125 issue aperte; la cifra di 350 dell'API include le 225 pull request aperte, quindi cita la scheda, non l'API, quando confronti con altri plugin s6. Il progetto è stato creato il 2025-10-09 e include quattordici skill s2. Il post di lancio dell'autore spiega la scommessa in una riga: agli agenti di coding non manca la capacità, manca la disciplina, e quella disciplina si può distribuire come semplici file markdown che chiunque può leggere, forkare e modificare s5. Il plugin è nel marketplace ufficiale, quindi l'installazione è un solo comando e gli aggiornamenti seguono il marketplace s4.

Il punto d'ingresso è una skill che l'hook di avvio sessione carica prima di tutto. Dice all'agente che, se c'è anche solo un dubbio sull'applicabilità di una skill, deve caricarla e verificare, prima di rispondere o scrivere codice. Quella regola è la fonte sia del beneficio sia del costo fisso s14.

Il brainstorming si apre con un HARD-GATE: niente codice, niente scaffolding, nessuna skill di implementazione finché non hai convalidato un'intenzione esplicita. Poi smista la richiesta in uno di tre percorsi: spike, quando l'output è una risposta e non codice; bounded, per una piccola modifica dentro un flusso che il repo ha già; architectural, per tutto ciò che ristruttura il progetto. L'agente annuncia la classificazione così puoi contraddirlo, e il cricchetto va in una sola direzione: una complessità nascosta scoperta a metà task sposta il percorso verso l'alto, mai verso il basso s9.

La skill di scrittura del piano chiede un piano pensato per uno sviluppatore competente che non sa nulla della tua codebase e, parole del file stesso, ha gusti discutibili. Il lavoro è diviso in task in cui ogni passo dura da due a cinque minuti: scrivere il test che fallisce, eseguirlo per vederlo fallire, scrivere il codice minimo, rieseguire i test, fare commit. Ogni task elenca i file esatti da creare o modificare, fino ai numeri di riga, e il piano si apre con un header obbligatorio s10.

L'esecuzione è la skill di sviluppo guidato da subagent: un subagent nuovo per task, una review dopo ogni task, una review dell'intero branch alla fine. La sessione principale smette di scrivere codice e si limita a distribuire il lavoro. Ogni subagent riceve solo il contesto del suo task, mai la cronologia della tua sessione, il che lascia libera la tua finestra per il coordinamento. Dopo che il subagent ha implementato, testato, fatto commit e rivisto se stesso, l'orchestratore esegue una review in due parti, prima la conformità alla spec, poi la qualità del codice, con un posto da reviewer riservato a ogni task. Il file limita il ciclo a un massimo di cinque round per task s11. L'isolamento del lavoro è delegato a una skill sui worktree, così un piano non gira mai sul tuo checkout attuale s13.

La sezione Model Selection parte da una regola: usa il modello meno capace che regga il ruolo. Un task meccanico ben specificato che tocca uno o due file va a un modello piccolo; quando il piano contiene già il codice da scrivere, l'implementazione è trascrizione più test, e il livello più economico basta. Coordinamento su più file e debugging vanno a un modello standard. Architettura e review finale del branch richiedono il modello più capace disponibile. Due dettagli contano nella pratica: indica sempre il modello esplicitamente al dispatch e lascia che l'orchestratore valuti la difficoltà di ogni task prima di scegliere s12. È il meccanismo che rende abbordabile il modello costoso sul piano Pro da venti dollari: lavora solo sulle decisioni che lo meritano.

Il guadagno in documentazione è un effetto collaterale del processo. Spec e piani non sono messaggi di chat che spariscono; sono file markdown salvati nel repo e committati insieme al lavoro, così chi fa la review in seguito legge perché una modifica è stata fatta, non solo cosa è cambiato s3.

Il costo è quello che il repo non pubblicizza. Il thread che ha dato il via al video riporta statistiche d'uso tra 1 e 3 percento e chiede quale sia lo svantaggio oltre al non usarlo s7. La risposta nei file è che il brainstorming scala la sua cerimonia in base al task ma non salta mai la convalida umana s9. Su un fix da due righe rispondi comunque a domande di inquadramento, approvi un design di due frasi e aspetti il ciclo completo. I brief di dispatch, le due review per task e il registro di tracciamento sono token che paghi ogni volta, e si vede sui task più piccoli. Statistiche d'uso basse significano che le skill non corrispondono al tuo lavoro, ed è il vero segnale da leggere.

Verdetto per tipo di uso

Il tuo uso di Claude Code Installare? Perché
Feature da ore, più file, un branch Sì L'inquadramento evita di costruire la cosa sbagliata, i task brevi tengono l'agente lontano dalla saturazione del contesto, la model selection allunga la quota, la documentazione nasce dal processo
Misto: feature alcuni giorni, fix quasi sempre Sì, con regola di salto Tieni il gate per le feature, di' all'agente nel prompt di saltare il processo sui piccoli fix
Script usa e getta, refusi di config, fix da due righe No Il costo fisso del gate pesa su task che non ne hanno bisogno
Curioso ma non pronto ad adottare tutto il metodo Solo brainstorming Porta con sé buona parte del guadagno; le altre skill si innestano naturalmente dopo

Da fare lunedì

  • Installa dal marketplace ufficiale e apri la cache del plugin: leggi una volta i quattordici file SKILL.md, sono brevi e sono l'intero prodotto.
  • Fai passare una feature reale dal gate fino in fondo: brainstorming, piano, dispatch dei subagent, review del branch. Giudica il processo su quella, non su un fix.
  • Controlla le statistiche d'uso dopo una settimana. Sotto qualche percento, le skill non corrispondono al tuo lavoro: o i tuoi task sono troppo piccoli o devi formulare le richieste come feature.
  • Aggiungi una regola di salto alle istruzioni del progetto: sui fix di un solo file di poche righe, vai dritto alla modifica, niente brainstorming.
  • Copia la scala di Model Selection nei tuoi prompt per subagent anche se abbandoni il plugin: indica il modello esplicitamente a ogni dispatch.
  • Fai commit di spec e piani che il plugin scrive invece di cancellarli; sono il tuo registro di design.
  • Conta le issue aperte nella scheda Issues, non dal numero dell'API, prima di confrontare il progetto con un altro plugin.

Per approfondire

  • Leggi il post di lancio per l'intento progettuale prima dei file delle skill: spiega perché la disciplina si distribuisce come markdown e non come codice s5.
  • La sezione filosofia del README è la versione breve del metodo e il posto dove verificare se si adatta al tuo modo di lavorare s3.
  • La sezione sulla libreria di skill elenca le quattordici skill con una riga di scopo ciascuna; è più veloce che sfogliare la directory s16.
  • I cinque round massimi per task della skill sui subagent sono uno stop rigido che vale la pena copiare in qualsiasi orchestrazione scritta a mano s11.
  • Un thread chiede se questo tipo di plugin sopravvive a modelli più forti; ciò che sopravvive sono il gate di inquadramento e i piani committati, ciò che i modelli assorbono è la meccanica s19.
  • Il racconto di un limite d'uso settimanale bruciato dalla cerimonia di orchestrazione è il controcaso da leggere prima di adottarlo sul lavoro piccolo s20.
  • Il confronto con un set di istruzioni concorrente mostra il compromesso: meno skill ma più rigide contro un grande catalogo di regole s18.
  • L'elenco delle issue aperte è la lettura più rapida su ciò che si rompe oggi per gli altri utenti s6.

Fonti

FAQ

Superpowers fa risparmiare token o li brucia?

Entrambe le cose. Sulle feature, la model selection manda i task meccanici ai modelli piccoli e riserva il modello costoso ad architettura e review del branch, così la quota dura di più. Sui piccoli fix, i brief, le due review per task e il registro sono puro overhead.

Cosa significano statistiche d'uso tra 1 e 3 percento?

Le skill scattano solo quando una situazione corrisponde. Un valore basso significa che i tuoi task non sono feature nel senso del plugin, quindi paghi il controllo d'ingresso e non arrivi mai alla parte che ripaga.

Posso tenerne solo una parte?

Sì. Il solo brainstorming porta buona parte del guadagno, e la scala di Model Selection funziona in qualsiasi prompt per subagent scritto a mano. Di' all'agente di saltare il processo sui fix minuscoli e mantieni il controllo.