ponytail: lo stesso lavoro con metà del codice

Cos'è e perché conta

Chiedi a Claude un calendario per scegliere una data, e lui ne costruisce uno da zero: 335 righe da leggere e da sistemare quando si rompono. Eppure il tuo progetto aveva già il suo campo di testo, e ogni browser ha già un calendario. Bastavano 10 righe.

ponytail mette nel tuo Claude un programmatore senior pigro, nel senso buono. Prima di scrivere legge il codice che la modifica tocca e cerca cosa c'è già: nel progetto, nel browser o nel linguaggio, nelle librerie che hai installato. Poi scrive solo quello che manca. I controlli però non li taglia, e dove ci sono soldi o sicurezza lascia un piccolo test.

È un prompt (una skill, cioè un file di istruzioni per Claude) più un plugin che lo carica a ogni sessione. Gratuito, licenza MIT, più di 180.000 stelle su GitHub a fine ottobre. Chi l'ha scritto l'ha misurato su 39 compiti: in media il 53% di righe e il 26% di costo in meno. Come leggerli, al passo 6. È per chi costruisce da solo con Claude Code e non vuole rileggere codice inutile.

1. Installalo in Claude Code

Apri Claude Code e manda queste due righe come due messaggi separati: in uno solo, dice la guida d'installazione, non funziona.

/plugin marketplace add DietrichGebert/ponytail

/plugin install ponytail@ponytail

La prima aggiunge il marketplace, il catalogo da cui Claude Code prende il plugin. La seconda apre la scheda del plugin: leggi cosa installa e scegli «Install for you», così vale in tutti i tuoi progetti. Nell'app desktop, scheda Code, scrivi le stesse righe nel campo del prompt.

Per controllare che sia acceso:

1. In /plugin, scheda Installed, c'è ponytail.
2. All'avvio di ogni sessione ponytail scrive il livello attivo.
3. /ponytail da solo ti dice il livello; se era spento, lo accende.

Altri agenti: copia il file AGENTS.md del repo nel tuo progetto (regole sempre attive, senza comandi) o segui INSTALL.md.

2. Come ragiona: la scala prima di scrivere

Il cuore di ponytail è una scala. Legge il compito e il codice che tocca, poi si ferma al primo gradino che risolve tutto:

1. Serve davvero? Quello che nessuno ha chiesto lo salta, e te lo dice in una riga.
2. C'è già nel progetto? Un componente o una funzione che usi altrove: usa quello.
3. Lo fanno il linguaggio o il browser? Usa quello, ma un componente del progetto viene prima.
4. Lo fa una libreria già installata? Mai una libreria nuova per poche righe.
5. Basta una riga chiara? Una riga.
6. Solo allora il minimo codice che funziona, con un piccolo test se c'è logica.

Il calendario viene dal suo benchmark, con la richiesta «aggiungi un selettore di date». Senza ponytail 335 righe. Con ponytail 10, che riusano il componente Input del progetto con type="date": il calendario lo porta il browser. Onestamente: è il caso più estremo dei 39 compiti. Su tanti compiti piccoli la differenza è poca o nessuna.

Per vederlo lavorare, chiedi così (cambia le parti tra [ ]):

Aggiungi [un selettore di date] a [il form di prenotazione]. Prima di scrivere, dimmi cosa c'è già nel progetto, nel browser o nelle librerie installate che fa questo lavoro, e a quale gradino ti sei fermato.

3. I tre livelli di intensità, e off

Parte da solo, al livello full. Lo cambi con /ponytail e il livello, fino a fine sessione.

• lite: fa quello che hai chiesto e in una riga ti propone la versione più piccola. Lo uso quando la richiesta è già decisa.
• full: la scala del passo 2, con il test dove serve. È quello che tengo quasi sempre.
• ultra: in più mette in discussione la richiesta e, prima di costruire, ti dice cosa il bisogno non giustifica. Lo uso all'inizio di un progetto.
• off: lo spegne. Basta anche un messaggio con solo «stop ponytail».

/ponytail ultra

Per cambiare il livello di partenza di tutte le sessioni, scrivilo in ~/.config/ponytail/config.json (su Windows in %APPDATA%\ponytail):

{ "defaultMode": "lite" }

Oppure c'è la variabile d'ambiente PONYTAIL_DEFAULT_MODE, che vince sul file. Con "off" non parte da solo: lo accendi tu con /ponytail.

4. I due comandi di revisione

Tutti e due scrivono un report e non toccano il codice. Ogni problema è numerato e dice cosa fa quel codice, cosa va storto, come si sistema e cosa succede se lo lasci. Il report di solito è in inglese semplice.

/ponytail-review: la modifica che hai appena fatto

Da solo guarda le modifiche non ancora in un commit, o l'ultimo commit se non ce ne sono. Legge anche il codice che le usa, perché una modifica può rompere un file che non hai toccato. Per scegliere cosa guardare aggiungi una parola: uncommitted, staged (pronte per il commit), branch o il link di una PR.

/ponytail-review branch

Poi rispondi con i numeri:

Sistema la 1 e la 3 con la correzione più piccola che hai proposto. Le altre lasciale.

/ponytail-audit: tutto il progetto, in ordine

Stessi controlli, su tutto il repo o sulla cartella che gli nomini. Prima fa la mappa: da dove entrano i dati, dove finiscono, quanto carico deve reggere. Poi mette in fila al massimo 20 problemi, dal più grave, e ti dice da quale partire. Io lo lancio su un progetto che non apro da mesi.

/ponytail-audit

Se nel menu di Claude Code vedi i comandi con il nome del plugin davanti, tipo /ponytail:ponytail-review, usa quella forma.

5. Le scorciatoie segnate e la fascia sopra il prompt

Quando sceglie una scorciatoia con un limite noto, ponytail lo scrive nel codice con un commento shortcut: seguito dal limite e da quando cambiarla. Per esempio una lista in memoria che regge finché gli utenti sono pochi. Sono decisioni, non errori, ma vanno rilette: /ponytail-debt le raccoglie in un registro e segnala quelle che non dicono quando rivederle.

/ponytail-debt

Scrivi questo registro in PONYTAIL-DEBT.md.

Con un Claude Code recente, nel terminale e nell'app desktop, sopra il prompt c'è una fascia: quanto consuma il compito, il tempo dell'agente, quanto codice ha riusato, se i test sono passati. /ponytail band la nasconde e la rimette.

6. I numeri, letti onestamente

Sono numeri di chi l'ha scritto: 39 compiti, Claude Code con Opus, 5 prove per compito. Metodo e script sono nel repo.

• Righe di codice: il 53% in meno in media (tra il 41% e il 63%).
• Costo: il 26% in meno a prezzo di listino (tra il 16% e il 36%). Con un abbonamento non paghi meno: consumi meno del tuo limite.
• Un test dove la logica lo chiede: 98% delle volte, contro il 68% senza ponytail.
• Correttezza, sui 18 compiti con controlli nascosti: alla pari. Meno codice non ha tolto sicurezza, ma non ne ha neanche aggiunta.

Nel benchmark l'agente non poteva lanciare comandi: misura cosa scrive, non come lavora nel tuo progetto. E ponytail resta un prompt: Claude può sbagliare lo stesso, e le scorciatoie le rileggi tu.

Gli errori più comuni

• Mandare le due righe d'installazione in un messaggio solo.
• Installarlo da una copia: l'originale è solo DietrichGebert/ponytail su GitHub (o @dietrichgebert/ponytail su npm) e non contiene mai file .exe o .dll.
• Non avere Node.js: le istruzioni funzionano, ma a ogni messaggio compare l'errore «node: command not found».
• Lasciare i commenti shortcut: senza leggerli: il limite che scrivono prima o poi arriva.

Checklist

• Ho mandato le due righe d'installazione come due messaggi separati
• Scrivendo /ponytail vedo il livello attivo
• Ho provato /ponytail-review su una mia modifica vera
• Ho letto le scorciatoie con /ponytail-debt

Domande frequenti