Superpowers disciplina Claude Code, ma ha un costo fisso

Superpowers è un plugin per Claude Code scritto da Jesse Vincent, che pubblica strumenti open source per sviluppatori dagli anni 90. Lo ha rilasciato a ottobre e, meno di un anno dopo, il repository è a 280.000 stelle e 25.000 fork, con l'ultimo push arrivato due giorni prima della nostra registrazione. Il progetto è già alla sesta versione major con 681 commit sul branch main, quindi non è una raccolta di prompt che qualcuno ha abbandonato dopo il picco del lancio.

Segnale	Valore
Stelle GitHub	280.000
Fork	25.000
Versione major	6
Commit su main	681
Issue aperte	125

La scommessa di Vincent sta in una frase: agli agent di coding non manca la capacità, manca la disciplina. Quella disciplina arriva come semplici file markdown che chiunque può leggere, forkare e adattare. Abbiamo installato il plugin, letto tutte le quattordici skill riga per riga e osservato cosa cambia su quattro fronti: produttività, affidabilità del codice, spesa in token e documentazione.

Superpowers è un plugin gratuito e open source per Claude Code. Sta sul marketplace ufficiale dei plugin di Anthropic e si installa con un solo comando. La stessa metodologia esiste per più di una dozzina di altri harness, tra cui Cursor, Codex e Gemini, ognuno con il proprio percorso di installazione.

Il cuore sono quattordici skill: file markdown di istruzioni che l'agent carica ogni volta che una situazione corrisponde. Brainstorming, scrittura dei piani, sviluppo guidato da subagent, test-driven development e debugging sistematico codificano ciascuno un modo di lavorare completo, con le proprie checklist e i propri paletti. La skill di debugging vieta di proporre un fix prima di aver isolato la causa radice. Una skill di verifica costringe l'agent a dimostrare che un lavoro è finito invece di limitarsi a dichiararlo. Ogni skill si annuncia quando si carica, così sapete sempre in che modalità sta lavorando l'agent.

Un hook a inizio sessione costringe Claude a controllare, prima di ogni task, se una di queste skill si applica. La regola è scritta nella skill d'ingresso: se c'è anche solo l'uno per cento di probabilità che una skill sia pertinente, l'agent deve caricarla. Il risultato si comporta meno come una cassetta degli attrezzi e più come una metodologia di sviluppo iniettata nell'agent.

Vincent racconta le origini sul suo blog. Ha costruito le skill scavando in 2.249 file markdown di lezioni che i suoi stessi agent avevano imparato, poi ha messo alla prova le bozze contro quegli stessi archivi. La metodologia è stata estratta da veri fallimenti degli agent, non scritta a partire dalla teoria.

Il brainstorming è la skill da cui passa tutto. Nel momento in cui chiedete una feature, Claude la carica e si comporta da esperto di requisiti per tutta la durata della conversazione di inquadramento. L'intero metodo sta in un file leggibile.

Il file si apre con un blocco netto: niente codice, niente scaffolding, nessuna skill di implementazione di alcun tipo finché non avete approvato un intento esplicito. Niente viene costruito su un'intuizione, e il blocco vale per ogni task, per quanto piccolo sembri. La skill smista poi ogni richiesta in uno di tre percorsi.

Percorso	Definizione	Risultato
Spike	Una domanda di fattibilità	Una risposta, non codice da conservare
Bounded	Una piccola modifica a un flusso che esiste già nel repo	Una modifica delimitata
Architetturale	Tutto ciò che ristruttura il modo in cui il progetto sta insieme	Una spec che validate, poi un piano di implementazione

L'agent dichiara la sua classificazione ad alta voce, così potete correggerla, e il cricchetto gira in un solo senso: la complessità nascosta scoperta a metà task fa salire di livello il percorso, mai il contrario. Il file include una tabella di campanelli d'allarme, pensieri come "è troppo semplice per avere bisogno di un design", con la replica scritta accanto: i task semplici sono proprio il punto in cui le ipotesi non verificate costano di più. Anche uno spike tiene il suo paletto. Tutto ciò che l'agent costruisce per rispondere alla domanda resta etichettato come da buttare, e conservare quel codice diventa una nuova richiesta da classificare.

Durante il dialogo l'agent fa le domande che farebbe un lead engineer e presenta il suo design in sezioni digeribili. Sulla nostra pipeline questa fase ha già ucciso feature che avremmo costruito per niente.

La skill di scrittura dei piani si apre con un'istruzione che ne dà il tono: scrivi il piano per un bravo sviluppatore con zero contesto sulla tua codebase e, parole del file, gusto discutibile.

In concreto, il lavoro viene tagliato in task in cui ogni passo richiede da due a cinque minuti: scrivi il test che fallisce, eseguilo per verificare che fallisca, scrivi il codice minimo che lo fa passare, rilancia i test, commit. Un'azione, una verifica, e il lavoro avanza con commit frequenti. È il ciclo del test-driven development, imposto da un'altra skill del plugin, così ogni task porta con sé il proprio ciclo di test.

Ogni task elenca i file esatti da creare o toccare, fino al numero di riga. Il piano si apre con un'intestazione obbligatoria: l'obiettivo in una frase, l'architettura in due o tre, lo stack tecnico, un link alla spec e i vincoli globali del progetto copiati parola per parola. Se la spec copre più sottosistemi indipendenti, la skill esige piani separati, uno per sottosistema, ognuno con software testabile da solo.

Il dimensionamento dei task è il cuore dell'argomento sull'affidabilità. Un task breve significa un agent che finisce il suo lavoro con una finestra di contesto ancora quasi vuota. Non arriva mai al momento in cui la sessione trabocca, l'agent perde il filo e inizia a inventare funzioni che non esistono. Nessuna demo di cinque minuti mostra questo problema, ma decide tutto su un progetto reale: la qualità di un agent a fine sessione non ha niente a che vedere con la sua qualità al primo prompt. Meno contesto saturo significa, meccanicamente, meno allucinazioni, e codice che fa quello che diceva il piano.

In fase di esecuzione, una skill dedicata isola il lavoro in un worktree git, una copia di lavoro separata del repository, così il piano gira senza pestare quello che state facendo accanto.

La skill di esecuzione guida lo sviluppo tramite subagent. Il suo principio sta in una riga del file: un subagent nuovo per ogni task, una review dopo ogni task e una review ampia di tutto il branch alla fine. La vostra sessione principale diventa un orchestratore. Non scrive più codice, delega. Ogni subagent riceve esattamente il contesto che serve al suo task e mai la cronologia della vostra sessione, il che evita l'inquinamento del contesto e tiene la vostra finestra libera per il coordinamento.

Il subagent può fare domande prima di iniziare, poi implementa, testa, fa il commit e rivede il proprio lavoro. Quando ha finito, l'orchestratore esegue una review in due parti, prima la conformità alla spec e poi la qualità del codice, con un posto da reviewer dedicato per ogni task. Niente è improvvisato: la skill include un prompt modello per ogni ruolo (implementatore, reviewer del task e il reviewer che ricontrolla i fix) che l'orchestratore compila con il contesto del task.

Esito della review	Cosa succede
Passa	L'orchestratore registra il completamento in un registro e prosegue nel piano
Fallisce, round da 1 a 3	Riprende l'implementatore originale, che già conosce il codice e le proprie scelte
Fallisce, round 4	Viene mandato un nuovo implementatore su un modello più capace
Fallisce, round 5	Salta un interruttore e l'orchestratore decide da solo su ogni punto aperto

La skill evita anche l'eccesso opposto: una raffica di piccoli task meccanici parte come un unico gruppo, rivisto come una sola unità. Niente va in merge senza passare da un reviewer. Il risultato è quello che un team umano chiama processo di code review, solo che gira da solo, task dopo task.

Il sistema di delega apre la porta a un terzo vantaggio: l'economia dei token. La skill ha una sezione sulla scelta del modello che parte da una regola: usa il modello meno potente in grado di gestire ogni ruolo. L'orchestratore valuta la difficoltà di ogni task del piano e assegna il modello di conseguenza.

Task	Livello di modello
Task meccanico ben specificato che tocca uno o due file, oppure un piano che contiene già il codice da scrivere	Il livello più economico (implementare diventa trascrivere più testare)
Coordinamento tra più file, debugging	Un modello standard
Architettura, la review finale del branch	Il modello più capace disponibile

Il file aggiunge due finezze. Primo: indicate sempre il modello esplicitamente quando delegate. Un subagent senza modello eredita quello della vostra sessione, spesso il più costoso, il che annulla in silenzio tutta la sezione. Secondo: il numero di turni batte il prezzo dei token. I modelli più economici fanno più turni sui lavori con molti passaggi e finiscono per costare di più in totale, ed è per questo che reviewer e implementatori che partono da una prosa hanno un minimo un livello sopra, invece del fondo del catalogo.

Questo setup rende fattibile qualcosa di controintuitivo: far girare Opus o Fable, i modelli più costosi del catalogo, con il piano Pro da 20 dollari. Il modello costoso lavora solo sulle poche decisioni che lo meritano, e il resto del piano gira su modelli che consumano una frazione della vostra quota.

L'ultimo vantaggio è quello a cui nessuno pensa quando installa il plugin. Spec e piani non sono messaggi di chat che spariscono a fine sessione. Sono file markdown salvati dentro il repository e committati insieme al lavoro. La skill fissa la posizione: una cartella di piani datata, un file per feature, con l'obiettivo, l'architettura e il link alla spec nell'intestazione.

La spec viaggia con il piano, e i conflitti tra i due si risolvono a favore della spec: l'autorità è il documento, non la memoria dell'agent. La cronologia git non vi dice più solo cosa è cambiato. Vi dice perché, e cosa aveva deciso l'agent in quel momento. Sei mesi dopo, citare il file del piano in un prompt permette all'agent di riprendere subito il contesto della feature originale, e una nuova feature sullo stesso sottosistema si basa sulla spec esistente invece di riscoprire il terreno.

Non esistono più task non tracciati: tutto ciò che un agent ha fatto sulla codebase ha lasciato un documento, dal primo brainstorm all'ultimo commit. Il progetto riassume la sua filosofia in due principi, sistematico invece di ad hoc e prove invece di affermazioni. La documentazione nasce dal processo da sola.

Il limite è reale e il repository non lo pubblicizza: tutta questa disciplina ha un costo fisso, e quel costo non si spegne mai. La skill d'ingresso è diretta. Al minimo dubbio l'agent deve caricare la skill, e il file del brainstorming dichiara che il rituale si adatta al task, ma l'approvazione umana no, mai.

Su un fix di due righe, questo significa rispondere a domande di inquadramento, approvare un design di due frasi e poi aspettare il ciclo completo prima di vedere il fix. Per un refuso in un file di config, il processo completo è semplicemente più lento che correggerlo da soli. L'orchestrazione stessa consuma token: brief di delega, due review per task e il registro si pagano ogni singola volta, e lo sentite soprattutto sui task più piccoli.

C'è anche il sintomo opposto, e risponde direttamente alla domanda di Reddit. Se le statistiche d'uso mostrano il plugin a qualche punto percentuale, le vostre richieste non attivano quasi mai le skill, quindi pagate il controllo d'ingresso a ogni sessione senza mai toccare i vantaggi. Un ciclo di fix che arriva a cinque round fa cinque diff, altre cinque review e un arbitrato, per un task che doveva richiedere pochi minuti. Il progetto inoltre non sta mai fermo: è passato dalla prima versione alla sesta in meno di un anno e ha ancora 125 issue aperte, quindi le skill che leggete oggi saranno cambiate al prossimo update.

Il plugin prevede la propria uscita. Le sue istruzioni mettono le vostre direttive sopra le skill, quindi potete dire all'agent, esplicitamente, di saltare il processo. La nostra regola: Superpowers attivo di default per ogni lavoro su feature, e uno skip deliberato per i fix minuscoli.

Il vostro uso di Claude Code	Verdetto
Feature che richiedono ore	Installatelo: l'inquadramento vi evita di implementare la cosa sbagliata, i task brevi tengono l'agent lontano dalla saturazione del contesto, la scelta del modello allunga la vostra quota, ed ereditate documentazione che non avreste mai scritto
Script da buttare e piccoli fix	Passate oltre: paghereste il costo fisso del processo su task che non ne hanno bisogno
Nel mezzo	Installatelo e imparate a dire skip: una frase nel vostro prompt vi restituisce il controllo

Se volete provarlo senza adottare tutto, lasciate girare solo la skill di brainstorming per qualche giorno. Porta gran parte del vantaggio, e le altre skill si innestano poi da sole. Il plugin tiene le sue quattro promesse purché gli diate feature degne del suo rituale. Ora gira sui nostri progetti, e la fase di brainstorming è quella che non spegneremmo più. Il repository è gratuito e open source, con 280.000 persone in fila davanti a voi.