Superpowers: 311.000 stelle per una metodologia in Markdown

Il repository con più stelle nella classifica GitHub di questa settimana non è un modello, un framework o l'open source civetta di una startup. È una cartella di file Markdown che spiega al tuo coding agent come comportarsi.

Superpowers, di Jesse Vincent, sta intorno alle 311.000 stelle con circa 5.900 aggiunte nell'ultima settimana. La sua descrizione: una metodologia di sviluppo software completa per i tuoi coding agent, costruita su un insieme di skill componibili più alcune istruzioni iniziali che fanno in modo che l'agente le usi davvero.

Trecentomila stelle per una metodologia sono una cosa strana da guardare. O la più grande schiera di sviluppatori del decennio ha deciso all'unisono di volere processi, o la stella è diventata un segnalibro per «dovrei pensarci su». Probabilmente entrambe. Ma la cosa in sé merita di essere presa sul serio, perché è la risposta più schierata che qualcuno abbia pubblicato alla domanda su cosa debba fare un agente prima di scrivere codice.

La prima mossa è non iniziare

Ecco il flusso come lo descrive il README. Appena l'agente capisce che stai costruendo qualcosa, non si butta a scrivere codice. Fa un passo indietro e chiede cosa stai cercando di fare davvero.

Una volta tirata fuori una specifica dalla conversazione, te la mostra a pezzi abbastanza corti da leggere. Non un muro di requisiti. Pezzi. Dopo il tuo via libera produce un piano di implementazione abbastanza dettagliato, parole del README, perché possa seguirlo «un ingegnere junior entusiasta, con cattivo gusto, nessun giudizio, nessun contesto di progetto e avversione ai test».

Quella frase è la cosa migliore del repository. È anche una descrizione precisa di cosa sia un LLM nelle giornate storte, e scrivere il piano per quel lettore è una disciplina che molti ingegneri saltano perché diamo per scontato che il lettore condivida il nostro contesto.

Poi, quando dici vai, parte lo sviluppo guidato da sub-agenti: gli agenti affrontano ogni task, ispezionano e rivedono il proprio lavoro e proseguono. Il README dice che non è raro che l'agente lavori in autonomia per un paio d'ore senza deviare dal piano.

Cosa c'è davvero nella scatola

Una quindicina di skill, raggruppate per funzione.

Il testing ne ha una, ed è quella che conta: test-driven-development, il ciclo red-green-refactor, con un documento di riferimento sugli anti-pattern dei test. Il debug ha systematic-debugging, un processo in quattro fasi per la causa radice con tecniche di tracciamento, difesa in profondità e attesa basata sulle condizioni, più verification-before-completion, il cui unico compito è impedire all'agente di dichiarare vittoria su qualcosa che non è risolto.

La collaborazione è dove sta il peso vero: brainstorming per far emergere l'intento, writing-plans, executing-plans, dispatching-parallel-agents, requesting e receiving code review, using-git-worktrees, finishing-a-development-branch, e subagent-driven-development con la sua review in due stadi, prima la conformità alla specifica, poi la qualità del codice.

Due meta-skill chiudono il cerchio: writing-skills, per crearne di nuove, e using-superpowers, l'introduzione che spinge il modello a caricare il sistema all'inizio di una conversazione. Dato che le skill si attivano da sole, in teoria non devi ricordarti niente. Il tuo agente ce l'ha e basta.

Installazione, per harness, sedici volte

Questa è la parte che ti dice quanto è frammentato il mercato degli strumenti per agenti. Superpowers distribuisce istruzioni per Claude Code, Antigravity, l'app e la CLI di Codex, Cursor, Devin CLI, Factory Droid, Gemini CLI, GitHub Copilot CLI, Grok Build, Kimi Code, OpenCode, Pi, Qwen Code, Hermes e Muse.

Claude Code, dal marketplace ufficiale:

/plugin install superpowers@claude-plugins-official

Oppure dal marketplace di Vincent:

/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

Cursor, nella chat dell'agente: /add-plugin superpowers. Gemini CLI: gemini extensions install https://github.com/obra/superpowers. Copilot CLI: registri il marketplace, poi copilot plugin install superpowers@superpowers-marketplace. Antigravity: agy plugin install https://github.com/obra/superpowers. Devin: devin plugins install obra/superpowers. Factory Droid: registri, poi installi. L'app e la CLI di Codex passano entrambe dal marketplace ufficiale dei plugin.

Se usi più di un harness, lo installi separatamente per ognuno. Il che significa che le stesse dodici skill esistono in dodici copie senza un percorso di aggiornamento condiviso, e il consiglio del README per aggiornare è «dipende un po' dal coding agent, ma spesso è automatico». Non è una critica a questo progetto. È lo stato attuale dell'ecosistema, e vedere un repository di metodologia farci i conti è davvero istruttivo.

La politica sui contributi è l'indizio

Sepolto nella sezione contributi: in genere non accettano contributi di nuove skill, gli aggiornamenti alle skill devono funzionare su tutti gli agenti supportati, e non accettano PR scritte da agenti che correggono issue aperte da altri se non le ha chieste un maintainer, anche quando hai lo stesso problema.

Pensa a cosa serve quell'ultima regola. Il modo ovvio in cui un repository così fallisce è essere sepolto da skill dall'aria plausibile generate proprio dagli agenti che le skill dovrebbero governare. Vincent l'ha visto arrivare e l'ha prevenuto, al costo di sembrare poco amichevole.

C'è anche un'implicazione più sottile. Se il tuo agente può generare una skill per qualsiasi cosa, la risorsa scarsa smette di essere la skill e diventa il giudizio su quali skill valga la pena avere. Quel giudizio è ciò che il repository vende davvero, e non è aperto alle pull request.

Dove la metodologia si rompe

Quattro cose, in ordine di quanto spesso le ho viste mordere.

Il processo non aggiusta il gusto. Un piano eseguito alla perfezione per una funzione concepita male produce una versione ben testata della cosa sbagliata. La skill di brainstorming aiuta chiedendoti cosa vuoi davvero, ma non ti dirà che l'idea è banale.

Economia dei token. Specifica, review a pezzi, piano, dispatch dei sub-agenti, review in due stadi per ogni task, verifica prima della chiusura. Su un task piccolo è una quantità spettacolare di sovraccarico. La metodologia è pensata per lavori misurati in giorni, e su una correzione da una riga sembrerà assurda.

I piani derivano. Due ore di lavoro autonomo su un piano scritto al minuto zero vanno bene se il piano era giusto. Quando il terzo task rivela che il secondo si basava su un'assunzione sbagliata, ottieni due ore di lavoro sicuro nella direzione sbagliata, e la review è l'unica cosa tra te e un diff enorme.

E quella onesta: le skill sono prompt, e i prompt sono suggerimenti. Tutto qui dipende dal fatto che il modello scelga di seguire la skill invece delle altre cinque cose che sa. È per questo che using-superpowers esiste come bootstrap: è un prompt il cui lavoro è far caricare altri prompt.

A chi serve

Se rilasci codice da cui dipendono altre persone, e hai visto un agente segnare con sicurezza come fatto qualcosa che non lo era, questo è un insieme ragionevole di guardrail e provarlo costa un comando. Inizia da test-driven-development e verification-before-completion e ignora il resto per una settimana. Sono quelle due che cambiano di più il comportamento.

Se stai prototipando, lascia perdere. La metodologia è ottimizzata per non rilasciare spazzatura, che è un obiettivo diverso dal capire se l'idea funziona.

Trecentomila stelle non sono un verdetto sulla metodologia. Sono un verdetto sul momento: molte persone hanno ora agenti che scrivono codice più in fretta di quanto riescano a supervisionarli, e cercano qualcosa che renda la supervisione più economica. Superpowers è una risposta. Il fatto che sia fatta di Markdown è la parte più interessante.