Commit message, który pasuje do diffa — zbenchmarkowany

Commit message to twierdzenie o diffie. „add rate limiting to login” mówi, że diff dodał rate limiting do logowania — i albo tak było, albo dotknął też trzech innych plików, o których wiadomość nigdy nie wspomina, albo „poprawia wydajność”, której nikt nie zmierzył. Nie da się tego rozróżnić, czytając samą wiadomość. Trzeba przeczytać diff, a prawie nikt tego nie robi. Na co dzień prowadzimy katalog, w którym benchmarkujemy skille Claude, więc zrobiliśmy nudną rzecz: kazaliśmy Claude napisać commit message dla 15 prawdziwych diffów open source, dwa razy każdy, i sprawdziliśmy każdą wiadomość względem faktycznie zastaged'owanych zmian.

Efektem jest commit-discipline, dostarczany razem z załączonymi liczbami przed/po: pokrycie diffa wzrosło z 83% do 97%, temat zmieścił się w 50 znakach w 15 z 15 diffów (wcześniej 6 z 15), a sfabrykowane twierdzenia spadły z 1 do 0. Jest darmowy, na licencji MIT: github.com/Skillproofdev/commit-discipline.

Luka: wszyscy sprawdzają format, nikt nie sprawdza prawdy

Zanim napisaliśmy pierwszą linijkę, przejrzeliśmy 80 skilli skupionych na commitach w naszym indeksie 16 682 skilli, plus samodzielne skille do commitów opublikowane dla Claude Code. Warstwa formatu to zatłoczona, rozwiązana przestrzeń. Zgodność z Conventional Commits jest powszechna. Tryb rozkazujący, tematy do 50 znaków, stopki BREAKING CHANGE: — powszechne, dobrze udokumentowane, standard branżowy. Jeśli chcesz tylko poprawnie ukształtowanego type(scope): subject, robi to już kilkanaście skilli.

Czego żaden z nich nie egzekwuje, to warstwa pod spodem: czy wiadomość jest prawdziwa względem diffa. Czy uwzględnia każdą logiczną zmianę, która jest zastaged'owana? Czy niczego nie zmyśla — żadnego zgadywanego motywu, żadnej niezmierzonej „poprawy wydajności”, żadnej opisanej zmiany, której tam faktycznie nie ma? To warstwa uczciwości i była w tej niszy nieobsadzona. Każdy konkurent albo uruchamia git diff --cached jako niewymuszoną sugestię, albo wprost pracuje z listy plików — nazw plików, które mówią, gdzie coś się zmieniło, ale nigdy co ani dlaczego. commit-discipline czyni czytanie pełnego diffa Regułą 1 i wprost zakazuje skrótu z nazwami plików.

Osiem reguł, czterech nie kodyfikuje nikt inny

Skill to zestaw twardych reguł (pełny SKILL.md). Znajome elementy są zrobione ściśle: typ wynikający z tego, co diff robi z zachowaniem, zakres, który musi dać się wyprowadzić ze ścieżek (nigdy zmyślony), temat w trybie rozkazującym ≤50 znaków, breaking changes w stopce. Elementy, których nikt inny nie egzekwuje:

1. Kompletność pokrycia diffa. Po napisaniu szkicu przejdź diff względem wiadomości: każda logiczna zmiana uwzględniona, nic opisanego, czego nie ma w staged. Kontrola halucynacji dla commit message'y.
2. Czytaj pełny zastaged'owany diff, nigdy nazw plików. Reguła 1, ze skrótem pod zakazem. Wiadomość opisuje diff, więc diff — cały — jest inputem.
3. Konkretna lista zakazanych ogólników. update, fix stuff, improve, misc, cleanup bez obiektu, wip, address feedback — zablokowane jako słowa nośne, każde z wzorcem zamiennym (update deps → bump axios 1.6→1.7).
4. Umowa co do wyniku. Deliverable to sama wiadomość w jednym bloku kodu — bez wstępu, bez relacji z diffa krok po kroku, bez niespodziewanej stopki Co-Authored-By.

Do tego treść, która wyjaśnia dlaczego i jaki wpływ, zamiast powtarzać diff (z testem usuwalności: jeśli linijkę dałoby się odtworzyć, czytając diff, wytnij ją), oraz rekomendacja podziału dla diffów z wieloma wątkami — konkretne granice plików i szkic tematu na każdy commit — zamiast jednej parasolowej wiadomości maskującej dwie zmiany.

Benchmark: 15 realnych diffów, oryginalne wiadomości usunięte

Wyciągnęliśmy 15 fixture'ów z curl, redis, express, fastapi, eslint, django, rust-analyzer i astro przy przypiętych SHA: featury, poprawki bugów, refaktory, dwie prawdziwe breaking changes, dwa podrzucone diffy z wieloma wątkami, prace nad dokumentacją i CI oraz commity liczące ponad 400 linii i wiele plików. Każdy diff trafił do dwóch agentów Claude Sonnet z identycznymi promptami. Jedyna różnica: jeden czytał najpierw ten SKILL.md, drugi nie. Oceniliśmy na trzy sposoby — mechaniczną zgodność z Conventional Commits przez skrypt, pokrycie diffa względem z góry zarejestrowanej złotej listy zmian i ślepą ocenę preferencji A/B.

Metryka	Baseline	Ze skillem
Zgodność ze specyfikacją (7 kontroli mechanicznych, średnia)	91,4%	98,1%
— temat ≤ 50 znaków	40% (6/15)	100% (15/15)
Pokrycie diffa (vs złote listy zmian, średnia)	83,2%	96,7%
Sfabrykowane twierdzenia (razem na 15)	1	0
Recall breaking changes (2 fixture'y)	2/2	2/2
Wykrycie potrzeby podziału (2 podrzucone diffy z wieloma wątkami)	0/2	2/2
Ślepa preferencja A/B (skill vs baseline)	—	9 wygranych / 4 porażki / 2 remisy

Dwie rzeczy się wyróżniają. Po pierwsze, zgodność mechaniczna była już mocna w baseline — poprawne typy, tryb rozkazujący, stopki breaking i niewymijające czasowniki wyszły od razu. Cała luka formatu to długość tematu: baseline przekraczał 50 znaków w 9 z 15 diffów; skill nigdy. Po drugie, prawdziwym rozdzielaczem jest pokrycie. Baseline rutynowo gubił zmiany drugorzędne — dodane testy, wpis do changeloga, drugi wątek ukryty w „pojedynczym” diffie — podczas gdy skill je uwzględniał. Ten skok 83%→97% to źródło większości wygranych w preferencjach, i to jest coś, czego żaden checker formatu nie da.

Wykrywanie podziału to najczystsza ilustracja. Przy dwóch podrzuconych diffach z wieloma wątkami (t05, t12) baseline napisał po jednej parasolowej wiadomości; skill zaproponował podział za każdym razem. Przy t07 — commit z curl usuwający TLS-SRP — skill złapał nawet niepowiązany hunk z sześcioma setopt, który baseline po cichu wchłonął do swojej wiadomości, co było jedyną fabrykacją baseline'u w tym przebiegu: zmyślone uzasadnienie usunięcia („praktycznie nieużywane”), którego diff nie potwierdzał. Skill oflagował ten hunk jako pytanie do użytkownika zamiast zgadywać.

Gdzie skill przegrał — i tak to publikujemy

Nasza metodologia wymaga pokazywania porażek obok zwycięstw, a to nie było czyste zwycięstwo na całej linii.

Baseline pobił skill na trzech fixture'ach. Przy t03 (redis), t13 (rust-analyzer) i t15 (fastapi) — wszystkie to diffy o wąskim zakresie — baseline złapał konkretny smaczek, który skill zbagatelizował: poszerzone ograniczenie trait &mut dyn SourceDatabase (t13), ekstrakcję deduplikacji _build_dependant (t15) i jeden z dwóch algorytmów liczenia diffów (t03). Presja kompletności skilla jest realna, ale nie absolutna; na małych diffach dotyczących jednego pliku baseline dorównuje mu lub go bije.

Dyscyplina podziału skilla raz strzeliła za bardzo. Przy t14 podzielił dwuliniowy commit CI-plus-zależność — dodanie Node 26 do macierzy, podbicie mocha — na dwa, co da się obronić literą zasady „jeden commit, jeden wątek”, ale większość reviewerów zostawiłaby to jako jeden commit ci:. Trzy poprawne podziały, jeden nadmiarowy. Policzone jako porażka w preferencjach i oflagowane.

A zastrzeżenie, które liczy się najbardziej: n=15 jest kierunkowe, nie istotne statystycznie, a ocenę pokrycia i preferencji zrobił sędzia z tej samej rodziny modeli — na maszynie testowej nie skonfigurowano sędziego z innej rodziny klasy GPT. Preferencja w szczególności niesie ryzyko samopreferencji: piszący i sędzia dzielą rodzinę modeli. Przetasowaliśmy etykiety z góry zarejestrowanym seedem i odsłoniliśmy je po ocenie, ale nie będziemy udawać, że wynik preferencji 9-4-2 od sędziego z tej samej rodziny to werdykt. To sygnał. Pełny protokół, wyniki dla każdego fixture'a i ujawnienie metody oceny są w bench/results/verdict.md.

Instalacja

git clone https://github.com/Skillproofdev/commit-discipline ~/.claude/skills/commit-discipline

Zrestartuj Claude Code. Uruchamia się na „commit this”, „write a commit message”, commitowanie zastaged'owanych zmian oraz prośby o review lub porządkowanie wiadomości — i nie wtrąca się w operacje gita niezwiązane z wiadomościami: branchowanie, rebase, rozwiązywanie konfliktów. Dołącza do naszej serii dyscyplin obok token-discipline, który tnie to, ile sesja kosztuje, i research-discipline, który tnie to, w czym odpowiedź się myli. Ten tnie to, co commit message przeocza.

FAQ

Czy Claude nie pisze już przyzwoitych commit message'y? Jeśli chodzi o format — tak, i to była niespodzianka w benchmarku. Baseline od razu trafił typ, tryb i stopki breaking. Gdzie zawiódł, to pokrycie: gubił zmiany drugorzędne w ponad połowie diffów z wieloma wątkami i wieloma plikami, i przekraczał 50-znakowy temat w 9 z 15. Praca skilla dotyczy właśnie tej luki, nie formatu, który wszyscy już robią dobrze.

Czy to tylko linter Conventional Commits? Nie, i o to chodzi. Zgodność z Conventional Commits to zatłoczona, rozwiązana przestrzeń — robi to kilkanaście skilli. commit-discipline egzekwuje warstwę pod spodem: że wiadomość uwzględnia każdą logiczną zmianę w diffie i niczego nie zmyśla. Format to tutaj standard branżowy; produktem jest uczciwość względem diffa.

Czy zrobi za mnie commit albo push? Nie. Napisanie wiadomości to zadanie skilla; uruchomienie git commit to osobna instrukcja, której skill nie podejmie sam. Nie doda też stopek Co-Authored-By ani „Generated with”, chyba że log twojego projektu albo twoje własne instrukcje pokazują, że ich chcesz.

Czy powinienem ufać wynikowi preferencji 9-4-2? Traktuj go jako kierunkowy, nie jako werdykt. Oceniał go agent z tej samej rodziny modeli z zaślepionymi etykietami, bo na maszynie testowej nie było dostępnego sędziego z innej rodziny — więc niesie ryzyko samopreferencji, a n=15 nie jest istotne statystycznie. Liczby pokrycia (83%→97%) opierają się na z góry zarejestrowanej złotej liście zmian i są wynikiem bardziej nośnym; trzy fixture'y, które skill przegrał, są wymienione powyżej.