GitHub: 97 tysięcy gwiazdek. Plugin do Claude Code, Codex, Cursor, Windsurf, OpenCode, Gemini, Devin, Qoder, Hermesa, Pi, Swival i jeszcze z ośmiu innych. A ja zamiast instalować — przeczytałem, co robi, i zaktualizowałem jeden plik. Dostałem 90% wartości bez ani jednej nowej zależności.
Ponytail — leniwy senior dev jako plugin
Ponytail to zestaw reguł, który sprawia, że agent AI myśli jak najbardziej leniwy senior developer w firmie. “On nic nie mówi. Pisze jedną linijkę. Działa.” Benchmarki pokazują średnio 54% mniej kodu przy 100% bezpieczeństwie — mierzone na rzeczywistych sesjach Claude Code.
Jego serce to drabina decyzyjna — siedem szczebli, które agent sprawdza zanim cokolwiek napisze:
- Czy to w ogóle musi istnieć? (YAGNI)
- Już jest w codebase?
- Stdlib to robi?
- Natywna funkcja platformy?
- Już zainstalowana zależność?
- Da się w jednej linii?
- Dopiero wtedy: minimalny kod
Do tego dyscyplina outputu (kod pierwszy, maksymalnie 3 linijki komentarza), znacznik # ponytail: do oznaczania świadomych uproszczeń i ich sufitu, oraz zasada bugfixów: przegrepuj wszystkie call sites, napraw root cause, nie symptom.
Plugin? Nie. Aktualizacja skilla.
Hermes obsługuje pluginy — mógłbym zrobić hermes plugins install DietrichGebert/ponytail --enable i restart. Tylko po co?
Hermes zapytał mnie, czy instalować. Odpowiedziałem, żeby zamiast tego zaktualizował nasz istniejący skill coding-minimalism, który i tak jest wstrzykiwany do każdej sesji. Miałem już tam 8 zasad z doświadczeń zespołu Vercel Next.js, ale brakowało właśnie tej proceduralności — drabiny, konkretnych kroków zamiast ogólnych zasad.
Efekt: jeden plik SKILL.md w ~/.hermes/skills/software-development/coding-minimalism/ dostał nowe sekcje — drabinę, dyscyplinę outputu, znacznik ponytail:, sekcję o bugfixach i samosprawdzalności.
Dlaczego to lepsze niż instalacja
Brak redundancji. Gdybym zainstalował plugin, miałbym dwa zestawy reguł wstrzykiwane przed każdą turą LLM — nasze istniejące 8 zasad ORAZ reguły ponytaila. Pokrywają się w ~60%, więc to głównie szum i marnowanie tokenów.
Zero nowych zależności. Plugin ponytaila wymaga Node.js na PATH, hooków lifecycle, integracji z MCP. Nasz skill to jeden plik Markdown.
Własny głos. Reguły ponytaila są po angielsku, z konkretnymi przykładami dla ekosystemu Node.js/frontend. Nasza wersja jest po polsku, z naszymi pułapkami (bezpieczeństwo danych!), kontekstem MusicStudio i projektów Darka.
Selektywność. Nie wszystko z ponytaila pasuje do nas. Jego poziomy intensywności (lite/full/ultra) i komendy (/ponytail-review, /ponytail-audit) to dodatkowa złożoność, której nie potrzebujemy, bo Hermes i tak ma własny system komend. Bierzemy to, co wartościowe, resztę pomijamy.
To już drugi raz
Nie pierwszy raz importujemy dobre praktyki zamiast instalacji. Nasze oryginalne 8 zasad minimalizmu pochodzi z doświadczeń zespołu Vercel Next.js (60 miliardów tokenów przeanalizowanych — ich główny wniosek: największe marnotrawstwo to nie bugi, tylko over-engineering). Nie instalowałem Vercela. Przeczytałem, zrozumiałem, zaadaptowałem.
Wzorzec: czytaj → wyciągnij → zaadaptuj
Prawdziwa wartość projektu open-source często nie leży w npm install, tylko w mentalnym modelu, który za nim stoi. Plugin to tylko opakowanie. Reguły to istota.
Jak następnym razem zobaczysz popularne repo na GitHubie — zanim wpiszesz install, otwórz SKILL.md albo AGENTS.md. Przeczytaj drabinę decyzyjną. Zastanów się, które 20% reguł daje 80% wartości w Twoim kontekście. I zaktualizuj własny zestaw zasad — bez nowych zależności, bez konfliktów, bez marnowania tokenów na redundancję.
Albo po prostu zapytaj swojego agenta. Mój to ogarnął w 5 minut.