Commit-beskeden der matcher diffen, benchmarket

En commit-besked er en påstand om en diff. "add rate limiting to login" siger, at diffen tilføjede rate limiting til login — og enten gjorde den det, eller den rørte også ved tre andre filer, beskeden aldrig nævner, eller den "improves performance," ingen har målt. Du kan ikke se hvilket ved at læse beskeden. Du er nødt til at læse diffen, og næsten ingen gør det. Vi driver et katalog, der benchmark-tester Claude-skills til daglig, så vi gjorde det kedelige: vi fik Claude til at skrive commit-beskeder for 15 rigtige open source-diffs, to gange hver, og tjekkede hver besked mod de faktiske stagede ændringer.

Resultatet er commit-discipline, og den leveres med tallene for/efter vedhæftet: diff-dækning gik fra 83% til 97%, emnelinjer holdt sig under 50 tegn på 15 af 15 diffs (op fra 6 af 15), og opdigtede påstande faldt fra 1 til 0. Den er gratis og MIT-licenseret: github.com/Skillproofdev/commit-discipline.

Hullet: alle tjekker formatet, ingen tjekker sandheden

Før vi skrev en eneste linje, gennemgik vi 80 commit-fokuserede skills i vores indeks på 16,682 skills, plus de selvstændige commit-skills udgivet til Claude Code. Formatlaget er et overfyldt, løst rum. Overholdelse af Conventional Commits er universel. Imperativ stemning, 50-tegns-emnelinjer, BREAKING CHANGE:-fodnoter — almindeligt, veldokumenteret, en selvfølge. Hvis alt du vil have, er type(scope): subject formet korrekt, gør snesevis af skills allerede det.

Det, ingen af dem håndhæver, er laget nedenunder: om beskeden er sand mod diffen. Dækker den enhver logisk ændring, der er staget? Opdigter den intet — intet gættet motiv, intet umålt "improves performance," ingen beskrevet ændring, der ikke rent faktisk er der? Det er ærlighedslaget, og det var ubestridt i feltet. Enhver konkurrent kører enten git diff --cached som et uhåndhævet forslag eller arbejder åbenlyst ud fra fillister — filnavne, der fortæller dig hvor noget ændrede sig, men aldrig hvad eller hvorfor. commit-discipline gør det til Regel 1 at læse hele diffen og forbyder filnavns-genvejen helt.

Otte regler, fire af dem kodificerer ingen andre

Skillen er et sæt hårde regler (fuld SKILL.md). De velkendte dele er strengt udført: en type udledt af, hvad diffen gør ved adfærden, et scope, der skal kunne udledes af stierne (aldrig opdigtet), en ≤50-tegns imperativ emnelinje, breaking changes i en fodnote. Delene ingen andre håndhæver:

1. Diff-dæknings-fuldstændighed. Efter udkastet: gennemgå diffen mod beskeden — enhver logisk ændring dækket, intet beskrevet, der ikke er staget. Hallucinationskontrol for commit-beskeder.
2. Læs hele den stagede diff, aldrig filnavne. Regel 1, med genvejen forbudt. Beskeden beskriver diffen, så diffen — hele den — er inputtet.
3. En konkret liste over forbudt vaghed. update, fix stuff, improve, misc, cleanup uden et objekt, wip, address feedback — blokeret som bærende ord, hver med et erstatningsmønster (update deps → bump axios 1.6→1.7).
4. En output-kontrakt. Leverancen er beskeden alene i én kodeblok — ingen optakt, ingen diff-gennemgang trin for trin, ingen overraskende Co-Authored-By-fodnote.

Plus en brødtekst, der forklarer hvorfor og konsekvens i stedet for at gengive diffen (med en sletningstest: kan en linje genskabes ved at læse diffen, skæres den), og en split-anbefaling for flerformåls-diffs — konkrete filgrænser og et udkast til emnelinje per commit — i stedet for én paraplybesked, der tildækker to ændringer.

Benchmarken: 15 rigtige diffs, originale beskeder fjernet

Vi hentede 15 fixtures fra curl, redis, express, fastapi, eslint, django, rust-analyzer og astro ved fastlåste SHA'er: features, fejlrettelser, refaktoreringer, to reelle breaking changes, to plantede flerformåls-diffs, dokumentations- og CI-opgaver og commits på over 400 linjer på tværs af mange filer. Hver diff gik til to Claude Sonnet-agenter med identiske prompts. Den eneste forskel: én læste denne SKILL.md først, den anden gjorde ikke. Vi scorede på tre måder — mekanisk Conventional-Commits-overholdelse via script, diff-dækning mod en forhåndsregistreret gylden ændringsliste, og blind A/B-præferencebedømmelse.

Metrik	Baseline	Med skill
Specifikationsoverholdelse (7 mekaniske tjek, gennemsnit)	91.4%	98.1%
— emnelinje ≤ 50 tegn	40% (6/15)	100% (15/15)
Diff-dækning (mod gylden ændringsliste, gennemsnit)	83.2%	96.7%
Opdigtede påstande (i alt på tværs af 15)	1	0
Breaking-change-genfinding (2 fixtures)	2/2	2/2
Split-detektion (2 plantede flerformåls-diffs)	0/2	2/2
Blind A/B-præference (skill vs baseline)	—	9 sejr / 4 tab / 2 uafgjort

To ting skiller sig ud. For det første var mekanisk overholdelse allerede stærk ved baseline — korrekte typer, imperativ stemning, breaking-fodnoter og ikke-vage verber kom ud af kassen. Hele formatgabet var emnelinjelængden: baselinen overskred 50 tegn på 9 af 15 diffs; skillen gjorde det aldrig. For det andet er den reelle adskillelse dækningen. Baselinen droppede rutinemæssigt sekundære ændringer — de tilføjede tests, changelog-linjen, det andet formål gemt i en "enkelt" diff — mens skillen dækkede dem. Det spring fra 83% til 97% er, hvor de fleste præferencesejre kom fra, og det er noget, ingen formattjekker kan give dig.

Split-detektion er den reneste illustration. På de to plantede flerformåls-diffs (t05, t12) skrev baselinen én paraplybesked hver gang; skillen foreslog splittet begge gange. På t07 — en curl-commit, der fjerner TLS-SRP — fangede skillen endda en urelateret seks-setopt-hunk, som baselinen stille absorberede i sin besked, hvilket var baselinens ene opdigtelse i kørslen: en opfundet fjernelsesbegrundelse ("virtually unused"), diffen ikke understøttede. Skillen flagede den hunk som et spørgsmål til brugeren i stedet for at gætte.

Hvor skillen tabte — udgivet alligevel

Vores metode kræver, at tabene står ved siden af sejrene, og det her var ikke en ren sejr over hele linjen.

Baselinen slog skillen på tre fixtures. På t03 (redis), t13 (rust-analyzer) og t15 (fastapi) — alle stramt afgrænsede diffs — fangede baselinen en specifik nuance, skillen glossede over: en udvidet &mut dyn SourceDatabase-trait-grænse (t13), en _build_dependant-dedup-udtrækning (t15) og en af to diff-tælle-algoritmer (t03). Skillens fuldstændighedspres er reelt, men ikke absolut; på små enkeltfil-diffs matcher eller slår baselinen den.

Skillens split-disciplin overfyrede én gang. På t14 splittede den en to-linjers CI-plus-afhængighed-commit — tilføj Node 26 til matrixen, opgrader mocha — i to, forsvarligt efter bogstaven i "én commit, ét formål," men noget de fleste anmeldere ville holde som én ci:-commit. Tre korrekte splits, ét oversplit. Talt som et præferencetab og flaget.

Og det forbehold, der betyder mest: n=15 er retningsgivende, ikke statistisk signifikant, og dæknings- og præferencebedømmelsen blev foretaget af en dommer fra samme modelfamilie — ingen kryds-familie GPT-klasse-dommer var konfigureret på testmaskinen. Præference bærer især selvfavoriseringsrisiko: skribenten og dommeren deler en modelfamilie. Vi blandede etiketterne med et forhåndsregistreret seed og fjernede blindingen efter scoring, men vi lader som om et 9-4-2-præferencetal fra en indenfor-familie-dommer er en endelig dom. Det er et signal. Den fulde protokol, scorer per fixture og oplysningen om bedømmelsesmetoden er i bench/results/verdict.md.

Installation

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

Genstart Claude Code. Den udløses af "commit this," "write a commit message," committing af stagede ændringer og besked-review- eller oprydningsanmodninger — og holder sig væk fra git-operationer, der ikke handler om beskeder: branching, rebasing, konfliktløsning. Den slutter sig til vores disciplin-serie sammen med token-discipline, som skærer i, hvad en session koster, og research-discipline, som skærer i, hvad et svar tager fejl om. Den her skærer i, hvad en commit-besked overser.

FAQ

Skriver Claude ikke allerede ordentlige commit-beskeder? Formatmæssigt, jo — det var overraskelsen i benchmarken. Baselinen ramte type, stemning og breaking-fodnoter ud af kassen. Hvor den kom til kort, var dækning: den droppede sekundære ændringer på mere end halvdelen af de flerformåls- og flerfil-diffs, og den overskred den 50-tegns emnelinje på 9 af 15. Skillens job er det hul, ikke formatet alle allerede rammer rigtigt.

Er det bare en Conventional Commits-linter? Nej, og det er pointen. Overholdelse af Conventional Commits er et overfyldt, løst rum — snesevis af skills gør det. commit-discipline håndhæver laget nedenunder: at beskeden dækker enhver logisk ændring i diffen og ikke opdigter noget. Format er en selvfølge her; ærlighed mod diffen er produktet.

Vil den committe eller pushe for mig? Nej. At skrive beskeden er jobbet; at køre git commit er en separat instruktion, skillen ikke selv tager. Den tilføjer heller ikke Co-Authored-By eller "Generated with"-fodnoter, medmindre dit projekts log eller dine egne instruktioner viser, at du vil have dem.

Skal jeg stole på 9-4-2-præferencetallet? Betragt det som retningsgivende, ikke en endelig dom. Det blev bedømt af en agent fra samme modelfamilie med blindede etiketter, fordi ingen kryds-familie-dommer var tilgængelig på testmaskinen — så det bærer selvfavoriseringsrisiko, og n=15 er ikke statistisk signifikant. Dækningstallene (83%→97%) hviler på en forhåndsregistreret gylden ændringsliste og er det mest bærende resultat; de tre fixtures, skillen tabte, er navngivet ovenfor.