Commit-meldingen som matcher diffen, benchmarket

En commit-melding er en påstand om en diff. «legg til rate limiting på innlogging» sier at diffen la til rate limiting på innlogging — og enten gjorde den det, eller den rørte også tre andre filer meldingen aldri nevner, eller den «forbedrer ytelsen» ingen har målt. Du kan ikke se hvilket ved å lese meldingen. Du må lese diffen, og nesten ingen gjør det. Vi driver en katalog som benchmarker Claude-skills til daglig, så vi gjorde det kjedelige: fikk Claude til å skrive commit-meldinger for 15 ekte open source-differ, to ganger hver, og sjekket hver melding mot de faktiske stagede endringene.

Resultatet er commit-discipline, og den kommer med før/etter-tallene festet på: diff-dekningen gikk fra 83 % til 97 %, emnelinjer holdt seg under 50 tegn på 15 av 15 differ (opp fra 6 av 15), og oppdiktede påstander falt fra 1 til 0. Den er gratis og MIT-lisensiert: github.com/Skillproofdev/commit-discipline.

Gapet: alle sjekker formatet, ingen sjekker sannheten

Før vi skrev en eneste linje kartla vi 80 commit-fokuserte skills i vår indeks på 16 682 skills, pluss de frittstående commit-skillene publisert for Claude Code. Formatlaget er et overfylt, løst felt. Conventional Commits-samsvar er universelt. Imperativ form, 50-tegns emnelinjer, BREAKING CHANGE:-fotnoter — vanlig, godt dokumentert, en selvfølge. Vil du bare ha type(scope): emne formatert riktig, gjør dusinvis av skills allerede det.

Det ingen av dem håndhever, er laget under: om meldingen er sann mot diffen. Tar den høyde for hver logiske endring som er staget? Dikter den ingenting opp — ingen gjettet motivasjon, ingen umålt «forbedrer ytelsen», ingen beskrevet endring som ikke faktisk er der? Det er ærlighetslaget, og det var ubestridt i feltet. Hver konkurrent kjører enten git diff --cached som et uhåndhevet forslag, eller jobber åpent ut fra fillister — filnavn, som forteller deg hvor noe endret seg, men aldri hva eller hvorfor. commit-discipline gjør det å lese hele diffen til regel 1 og forbyr filnavn-snarveien fullstendig.

Åtte regler, fire av dem kodifiserer ingen andre

Skillen er et sett med harde regler (hele SKILL.md). De kjente delene er strengt gjennomført: en type utledet fra hva diffen gjør med oppførselen, et scope som må kunne utledes fra stiene (aldri oppdiktet), et ≤50-tegns imperativt emne, brytende endringer i en fotnote. Delene ingen andre håndhever:

1. Diff-dekning-fullstendighet. Etter utkastet, gå gjennom diffen mot meldingen: hver logisk endring tatt høyde for, ingenting beskrevet som ikke er staget. Hallusinasjonskontroll for commit-meldinger.
2. Les hele den stagede diffen, aldri filnavn. Regel 1, med snarveien forbudt. Meldingen beskriver diffen, så diffen — hele den — er input.
3. En konkret forbudt-vaghet-liste. update, fix stuff, improve, misc, cleanup uten objekt, wip, address feedback — blokkert som bærende ord, hver med et erstatningsmønster (update deps → bump axios 1.6→1.7).
4. En utdata-kontrakt. Leveransen er meldingen alene i én kodeblokk — ingen innledning, ingen diff-gjennomgang, ingen overraskende Co-Authored-By-fotnote.

Pluss en brødtekst som forklarer hvorfor og konsekvens i stedet for å gjenfortelle diffen (med en slettetest: om en linje kunne rekonstrueres bare ved å lese diffen, kutt den), og en split-anbefaling for differ med flere anliggender — konkrete filgrenser og et emneutkast per commit — i stedet for én paraplymelding som dekker over to endringer.

Benchmarken: 15 ekte differ, originale meldinger fjernet

Vi hentet 15 fixtures fra curl, redis, express, fastapi, eslint, django, rust-analyzer og astro ved fastlåste SHA-er: funksjoner, feilrettinger, refaktoreringer, to ekte brytende endringer, to plantede differ med flere anliggender, docs- og CI-rutineoppgaver, og commits på over 400 linjer i mange filer. Hver diff gikk til to Claude Sonnet-agenter med identiske prompter. Den eneste forskjellen: den ene leste denne SKILL.md-en først, den andre gjorde ikke det. Vi scoret på tre måter — mekanisk Conventional-Commits-samsvar via script, diff-dekning mot en forhåndsregistrert fasit-endringsliste, og blind A/B-preferansedømming.

Metrikk	Baseline	Med skill
Spesifikasjonssamsvar (7 mekaniske sjekker, snitt)	91.4 %	98.1 %
— emne ≤ 50 tegn	40 % (6/15)	100 % (15/15)
Diff-dekning (mot fasit-endringslister, snitt)	83.2 %	96.7 %
Oppdiktede påstander (totalt over 15)	1	0
Brytende-endring-gjenfinning (2 fixtures)	2/2	2/2
Split-deteksjon (2 plantede differ med flere anliggender)	0/2	2/2
Blind A/B-preferanse (skill mot baseline)	—	9 seier / 4 tap / 2 uavgjort

To ting skiller seg ut. For det første var mekanisk samsvar allerede sterkt ved baseline — riktige typer, imperativ form, brytende-fotnoter og ikke-vage verb kom ut av boksen. Hele formatgapet var emnelengde: baseline sprengte 50 tegn på 9 av 15 differ; skillen gjorde det aldri. For det andre er den reelle forskjellen dekning. Baseline droppet rutinemessig sekundære endringer — de tilføyde testene, changelog-oppføringen, det andre anliggendet som gjemte seg i en «enkelt» diff — mens skillen tok høyde for dem. Det hoppet fra 83 % til 97 % er der de fleste preferanse-seirene kom fra, og det er noe ingen formatsjekker kan gi deg.

Split-deteksjon er den tydeligste illustrasjonen. På de to plantede differene med flere anliggender (t05, t12) skrev baseline én paraplymelding hver gang; skillen foreslo splitten begge gangene. På t07 — en curl-commit som fjerner TLS-SRP — fanget skillen til og med en urelatert seks-setopt-hunk som baseline stille absorberte inn i meldingen sin, som var baselinens ene oppdikting i kjøringen: en oppfunnet fjerningsbegrunnelse («nesten ubrukt») som diffen ikke støttet. Skillen flagget den hunken som et spørsmål til brukeren i stedet for å gjette.

Der skillen tapte — publisert likevel

Vår metodikk krever at tapene vises ved siden av seirene, og dette var ikke en ren seier over hele linjen.

Baseline slo skillen på tre fixtures. På t03 (redis), t13 (rust-analyzer) og t15 (fastapi) — alle stramt avgrensede differ — fanget baseline en spesifikk detalj skillen overså: en utvidet &mut dyn SourceDatabase-trait-grense (t13), en _build_dependant-dedup-uttrekking (t15), og én av to diff-tellingsalgoritmer (t03). Skillens fullstendighetspress er reelt, men ikke absolutt; på små enkeltfil-differ matcher eller slår baseline den.

Skillens split-disiplin overreagerte én gang. På t14 splittet den en to-linjers CI-pluss-avhengighet-commit — legg Node 26 til i matrisen, oppgrader mocha — i to, forsvarlig etter bokstaven i «én commit, ett anliggende», men noe de fleste reviewere ville beholdt som én ci:-commit. Tre riktige splitter, én oversplitting. Telt som et preferansetap og flagget.

Og forbeholdet som betyr mest: n=15 er retningsgivende, ikke statistisk signifikant, og dekning- og preferansedømmingen ble gjort av en dommer fra samme modellfamilie — ingen dommer fra en annen modellfamilie av GPT-klasse var konfigurert på testmaskinen. Preferanse bærer spesielt en selvfavorisering-risiko: skriveren og dommeren deler modellfamilie. Vi stokket etikettene med et forhåndsregistrert frø og fjernet blindingen etter scoringen, men vi later ikke som en 9-4-2-preferansetelling fra en dommer i samme familie er en fasit. Det er et signal. Hele protokollen, per-fixture-scorene og avsløringen av dømmemetoden finner du i bench/results/verdict.md.

Installasjon

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

Start Claude Code på nytt. Den trigger på «commit dette», «skriv en commit-melding», commit av stagede endringer, og meldings-review eller opprydningsforespørsler — og holder seg unna git-operasjoner som ikke handler om meldinger: branching, rebasing, konfliktløsning. Den inngår i vår disiplin-serie sammen med token-discipline, som kutter hva en økt koster, og research-discipline, som kutter hva et svar bommer på. Denne kutter hva en commit-melding overser.

Ofte stilte spørsmål

Skriver ikke Claude allerede greie commit-meldinger? For format, ja — det var overraskelsen i benchmarken. Baseline traff type, form og brytende-fotnoter ut av boksen. Der den kom til kort, var dekning: den droppet sekundære endringer på over halvparten av differene med flere anliggender og flere filer, og sprengte 50-tegns-emnet på 9 av 15. Skillens jobb er det gapet, ikke formatet alle allerede får riktig.

Er dette bare en Conventional Commits-linter? Nei, og det er poenget. Conventional Commits-samsvar er et overfylt, løst felt — dusinvis av skills gjør det. commit-discipline håndhever laget under: at meldingen tar høyde for hver logiske endring i diffen og dikter ingenting opp. Format er en selvfølge her; ærlighet mot diffen er produktet.

Vil den committe eller pushe for meg? Nei. Å skrive meldingen er jobben; å kjøre git commit er en separat instruks skillen ikke tar på egen hånd. Den legger heller ikke til Co-Authored-By- eller «Generated with»-fotnoter med mindre prosjektets logg eller dine egne instrukser viser at du vil ha dem.

Bør jeg stole på 9-4-2-preferansetallet? Behandle det som retningsgivende, ikke en fasit. Det ble dømt av en agent fra samme modellfamilie med blindede etiketter, fordi ingen dommer fra en annen familie var tilgjengelig på testmaskinen — så det bærer en selvfavoriseringsrisiko, og n=15 er ikke statistisk signifikant. Dekningstallene (83 %→97 %) hviler på en forhåndsregistrert fasit-endringsliste og er det mer bærende resultatet; de tre fixturene skillen tapte er navngitt over.