Commit-meddelandet som matchar diffen, benchmarkat

Ett commit-meddelande är ett påstående om en diff. "lägg till hastighetsbegränsning på inloggning" säger att diffen lade till hastighetsbegränsning på inloggning — och antingen gjorde den det, eller så rörde den också tre andra filer meddelandet aldrig nämner, eller så "förbättrar den prestanda" ingen mätt. Du kan inte avgöra vilket genom att läsa meddelandet. Du måste läsa diffen, och nästan ingen gör det. Vi driver en katalog som benchmarkar Claude-skills på heltid, så vi gjorde det tråkiga: vi lät Claude skriva commit-meddelanden för 15 riktiga open source-diffar, två gånger vardera, och kontrollerade varje meddelande mot de faktiska stagade ändringarna.

Resultatet är commit-discipline, och den kommer med siffrorna för före/efter bifogade: diff-täckningen gick från 83% till 97%, ämnesraderna höll sig inom 50 tecken på 15 av 15 diffar (upp från 6 av 15), och fabricerade påståenden gick från 1 till 0. Den är gratis och MIT-licensierad: github.com/Skillproofdev/commit-discipline.

Luckan: alla kontrollerar formatet, ingen kontrollerar sanningen

Innan vi skrev en enda rad kartlade vi 80 commit-fokuserade skills i vårt index på 16 682 skills, plus de fristående commit-skills som publicerats för Claude Code. Formatlagret är ett fullt, löst fält. Efterlevnad av Conventional Commits är universell. Imperativ form, ämnesrader på 50 tecken, BREAKING CHANGE:-fotnoter — vanligt, väldokumenterat, en självklarhet. Om allt du vill ha är type(scope): subject korrekt formaterat, gör dussintals skills redan det.

Det ingen av dem tvingar fram är lagret under: om meddelandet är sant mot diffen. Redovisar det varje logisk ändring som är stagad? Hittar det på ingenting — ingen gissad motivation, ingen omätt "förbättrar prestanda," ingen beskriven ändring som inte faktiskt finns? Det är ärlighetslagret, och det var obestritt i fältet. Varje konkurrent kör antingen git diff --cached som ett icke-tvingat förslag eller jobbar öppet från fillistor — filnamn, som talar om var något ändrades men aldrig vad eller varför. commit-discipline gör att läsa hela diffen till Regel 1 och förbjuder filnamnsgenvägen helt.

Åtta regler, fyra som ingen annan kodifierar

Skillen är en uppsättning hårda regler (hela SKILL.md). Det välbekanta görs strikt: en typ som härleds från vad diffen gör mot beteendet, ett scope som måste kunna härledas från sökvägarna (aldrig hittat på), en ≤50-tecken imperativ ämnesrad, breaking changes i en fotnot. Delarna ingen annan tvingar fram:

1. Fullständig diff-täckning. Efter utkastet, gå igenom diffen mot meddelandet: varje logisk ändring redovisad, inget beskrivet som inte är stagat. Hallucinationskontroll för commit-meddelanden.
2. Läs hela den stagade diffen, aldrig filnamn. Regel 1, med genvägen förbjuden. Meddelandet beskriver diffen, så diffen — hela — är indatan.
3. En konkret lista över förbjudna luddiga ord. update, fix stuff, improve, misc, cleanup utan objekt, wip, address feedback — blockerade som bärande ord, var och en med ett ersättningsmönster (update deps → bump axios 1.6→1.7).
4. Ett kontrakt för utdata. Leveransen är meddelandet ensamt i ett kodblock — ingen inledning, ingen genomgång av diffen steg för steg, ingen överraskande Co-Authored-By-fotnot.

Plus en brödtext som förklarar varför och konsekvens istället för att återge diffen (med ett raderingstest: om en rad kan återskapas genom att läsa diffen, stryk den), och en rekommendation om uppdelning för diffar med flera bekymmer — konkreta filgränser och ett ämnesradsutkast per commit — istället för ett paraplymeddelande som täcker över två ändringar.

Benchmarket: 15 riktiga diffar, originalmeddelanden strippade

Vi hämtade 15 exempel från curl, redis, express, fastapi, eslint, django, rust-analyzer och astro vid fastnaglade SHA:er: funktioner, buggfixar, refaktoreringar, två äkta breaking changes, två planterade diffar med flera bekymmer, dokumentation och CI-städ, och commits på 400-plus rader över många filer. Varje diff gick till två Claude Sonnet-agenter med identiska prompter. Enda skillnaden: en läste denna SKILL.md först, en gjorde inte det. Vi poängsatte på tre sätt — mekanisk efterlevnad av Conventional Commits via skript, diff-täckning mot en förregistrerad facitlista och blind A/B-preferensbedömning.

Mått	Baslinje	Med skill
Regelefterlevnad (7 mekaniska kontroller, medel)	91,4%	98,1%
— ämnesrad ≤ 50 tecken	40% (6/15)	100% (15/15)
Diff-täckning (mot facitlistor, medel)	83,2%	96,7%
Fabricerade påståenden (totalt över 15)	1	0
Träffgrad breaking change (2 exempel)	2/2	2/2
Upptäckt av behov att dela upp (2 planterade diffar)	0/2	2/2
Blind A/B-preferens (skill mot baslinje)	—	9 vinst / 4 förlust / 2 oavgjort

Två saker sticker ut. För det första var mekanisk efterlevnad redan stark i baslinjen — rätt typer, imperativ form, breaking-fotnoter och icke-luddiga verb kom ur lådan. Hela formatgapet var ämnesradens längd: baslinjen sprängde 50 tecken på 9 av 15 diffar; skillen gjorde det aldrig. För det andra, den riktiga skillnaden är täckning. Baslinjen tappade rutinmässigt sekundära ändringar — de tillagda testerna, changelog-posten, det andra bekymret som gömde sig i en "enda" diff — medan skillen redovisade dem. Det hoppet från 83% till 97% är där de flesta preferensvinsterna kom ifrån, och det är sådant ingen formatkontroll kan ge dig.

Upptäckt av uppdelningsbehov är den tydligaste illustrationen. På de två planterade diffarna med flera bekymmer (t05, t12) skrev baslinjen ett paraplymeddelande vardera; skillen föreslog uppdelningen båda gångerna. På t07 — en curl-commit som tar bort TLS-SRP — fångade skillen till och med en orelaterad sex-setopt-hunk som baslinjen tyst sög in i sitt meddelande, vilket var baslinjens enda fabrikation i körningen: ett påhittat borttagningsskäl ("praktiskt taget oanvänd") som diffen inte stödde. Skillen flaggade den hunken som en fråga till användaren istället för att gissa.

Där skillen förlorade — publicerat ändå

Vår metodik kräver att förlusterna redovisas bredvid vinsterna, och det här var ingen ren svepseger.

Baslinjen slog skillen på tre exempel. På t03 (redis), t13 (rust-analyzer) och t15 (fastapi) — alla snävt avgränsade diffar — fångade baslinjen en specifik detalj skillen glansade över: en breddad &mut dyn SourceDatabase-traitgräns (t13), en dedup-extraktion i _build_dependant (t15), och en av två diff-räknande algoritmer (t03). Skillens fullständighetstryck är riktigt men inte absolut; på små enfilsdiffar matchar eller slår baslinjen den.

Skillens uppdelningsdisciplin sköt över målet en gång. På t14 delade den en tvårads CI-plus-beroende-commit — lägg till Node 26 i matrisen, uppgradera mocha — i två, försvarbart enligt bokstaven i "en commit, ett bekymmer" men något de flesta granskare skulle behålla som en enda ci:-commit. Tre korrekta uppdelningar, en överdelning. Räknat som en preferensförlust och flaggat.

Och förbehållet som betyder mest: n=15 är riktningsgivande, inte statistiskt signifikant, och täcknings- och preferensbedömningen gjordes av en domare från samma modellfamilj — ingen tvärfamilj GPT-klass-domare var konfigurerad på testmaskinen. Preferens bär särskilt risk för egen-favorisering: skribenten och domaren delar modellfamilj. Vi blandade etiketterna med ett förregistrerat frö och avblindade efter poängsättning, men vi låtsas inte att en 9-4-2-preferenssiffra från en domare inom familjen är ett facit. Det är en signal. Hela protokollet, poängen per exempel och avslöjandet om bedömningsmetoden finns i bench/results/verdict.md.

Installation

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

Starta om Claude Code. Den triggas av "committa det här," "skriv ett commit-meddelande," committande av stagade ändringar och begäranden om meddelandegranskning eller städning — och håller sig undan från git-operationer som inte handlar om meddelanden: branching, rebasing, konflikthantering. Den ansluter till vår disciplinserie tillsammans med token-discipline, som minskar vad en session kostar, och research-discipline, som minskar vad ett svar har fel om. Den här minskar vad ett commit-meddelande missar.

FAQ

Skriver inte Claude redan hyfsade commit-meddelanden? För format, ja — det var överraskningen i benchmarket. Baslinjen fick till typ, form och breaking-fotnoter ur lådan. Där den kom till korta var täckning: den tappade sekundära ändringar på mer än hälften av diffarna med flera bekymmer eller filer, och den sprängde 50-teckensgränsen på 9 av 15. Skillens jobb är det gapet, inte formatet alla redan fixar rätt.

Är det här bara en Conventional Commits-linter? Nej, och det är poängen. Efterlevnad av Conventional Commits är ett fullt, löst fält — dussintals skills gör det. commit-discipline tvingar fram lagret under: att meddelandet redovisar varje logisk ändring i diffen och inte hittar på något. Format är en självklarhet här; ärlighet mot diffen är produkten.

Kommer den committa eller pusha åt mig? Nej. Att skriva meddelandet är jobbet; att köra git commit är en separat instruktion skillen inte tar på egen hand. Den lägger inte heller till Co-Authored-By eller "Generated with"-fotnoter om inte ditt projekts logg eller dina egna instruktioner visar att du vill ha dem.

Ska jag lita på siffran 9-4-2? Behandla den som riktningsgivande, inte ett facit. Den bedömdes av en agent inom samma modellfamilj med blindade etiketter, eftersom ingen tvärfamiljsdomare fanns tillgänglig på testmaskinen — så den bär risk för egen-favorisering, och n=15 är inte statistiskt signifikant. Täckningssiffrorna (83%→97%) vilar på en förregistrerad facitlista och är det mer bärande resultatet; de tre exemplen skillen förlorade namnges ovan.