GitHub: 97 mila stelle. Un plugin per Claude Code, Codex, Cursor, Windsurf, OpenCode, Gemini, Devin, Qoder, Hermes, Pi, Swival e circa altri otto. E io, invece di installarlo — ho letto cosa fa e ho aggiornato un solo file. Ho ottenuto il 90% del valore senza una sola dipendenza nuova.
Ponytail — un senior dev pigro come plugin
Ponytail è un insieme di regole che fa pensare un agente AI come lo sviluppatore senior più pigro dell’ufficio. “Non dice niente. Scrive una riga. Funziona.” I benchmark mostrano in media il 54% di codice in meno con il 100% di sicurezza — misurato su sessioni reali di Claude Code.
Il suo cuore è una scala decisionale — sette gradini che l’agente controlla prima di scrivere qualsiasi cosa:
- Deve proprio esistere? (YAGNI)
- È già nel codebase?
- Lo fa la stdlib?
- Funzionalità nativa della piattaforma?
- Dipendenza già installata?
- Si può fare in una riga?
- Solo allora: il codice minimo che funziona.
In più: disciplina dell’output (codice prima, massimo tre righe di commento), un marcatore # ponytail: per documentare semplificazioni deliberate con il loro limite noto, e una regola per i bugfix: fai grep su ogni caller, sistema la causa radice, non il sintomo.
Plugin? No. Aggiornamento dello skill.
Hermes supporta i plugin — avrei potuto eseguire hermes plugins install DietrichGebert/ponytail --enable e riavviare. Ma perché?
Hermes mi ha chiesto se installarlo. Gli ho detto di aggiornare invece il nostro skill esistente coding-minimalism, che viene già iniettato in ogni sessione. Avevo già 8 principi lì, tratti dall’esperienza del team Vercel Next.js, ma quello che mancava era proprio questa qualità procedurale — una scala, passi concreti invece di principi astratti.
Il risultato: un file SKILL.md in ~/.hermes/skills/software-development/coding-minimalism/ ha ricevuto nuove sezioni — la scala, la disciplina dell’output, il marcatore ponytail:, la disciplina dei bugfix e l’auto-testing.
Perché è meglio che installare
Nessuna ridondanza. Se avessi installato il plugin, avrei due insiemi di regole iniettati prima di ogni turno del LLM — i nostri 8 principi esistenti E le regole di ponytail. Si sovrappongono per circa il 60%, quindi è per lo più rumore e token sprecati.
Zero nuove dipendenze. Il plugin di ponytail richiede Node.js nel PATH, hook del ciclo di vita, integrazione MCP. Il nostro skill è un file Markdown.
La nostra voce. Le regole di ponytail sono in inglese, con esempi tarati sull’ecosistema Node.js/frontend. La nostra versione è in polacco, con le nostre trappole (l’eccezione per la sicurezza dei dati!), il contesto di MusicStudio e le specificità dei progetti di Darek.
Selettività. Non tutto in ponytail ci serve. I suoi livelli di intensità (lite/full/ultra) e comandi (/ponytail-review, /ponytail-audit) sono complessità extra di cui non abbiamo bisogno, perché Hermes ha già il suo sistema di comandi. Prendiamo ciò che è utile, saltiamo il resto.
È già la seconda volta
Non è la prima volta che importiamo buone pratiche invece di installare. I nostri 8 principi originali di minimalismo vengono dall’esperienza del team Vercel Next.js (60 miliardi di token analizzati — la loro conclusione principale: lo spreco più grande non sono i bug, è l’over-engineering). Non ho installato Vercel. L’ho letto, l’ho capito, l’ho adattato.
Il pattern: leggi → estrai → adatta
Il vero valore di un progetto open-source spesso non sta in npm install — sta nel modello mentale che c’è dietro. Un plugin è solo confezionamento. Le regole sono l’essenza.
La prossima volta che vedi un repo popolare su GitHub — prima di digitare install, apri SKILL.md o AGENTS.md. Leggi la scala decisionale. Chiediti quale 20% delle regole fornisce l'80% del valore nel tuo contesto. Poi aggiorna il tuo insieme di regole — senza nuove dipendenze, senza conflitti, senza token sprecati in ridondanza.
O semplicemente chiedi al tuo agente. Il mio l’ha risolto in 5 minuti.