Die Commit-Message, die zum Diff passt – benchmarked

Eine Commit-Message ist eine Behauptung über einen Diff. „add rate limiting to login“ behauptet, der Diff habe Rate Limiting beim Login ergänzt – und entweder stimmt das, oder er hat auch drei weitere Dateien angefasst, die in der Message nie erwähnt werden, oder er „verbessert die Performance“, was niemand gemessen hat. Ob es stimmt, siehst du der Message nicht an. Du musst den Diff lesen, und das tut fast niemand. Wir betreiben ein Verzeichnis, das Claude-Skills beruflich benchmarkt, also haben wir das Naheliegende getan: Claude für 15 echte Open-Source-Diffs jeweils zweimal eine Commit-Message schreiben lassen und jede Message gegen die tatsächlich gestagten Änderungen geprüft.

Das Ergebnis heißt commit-discipline, und es liefert den Vorher-Nachher-Vergleich gleich mit: Diff-Abdeckung stieg von 83% auf 97%, Betreffzeilen blieben bei 15 von 15 Diffs unter 50 Zeichen (vorher 6 von 15), und erfundene Behauptungen fielen von 1 auf 0. Kostenlos und MIT-lizenziert: github.com/Skillproofdev/commit-discipline.

Die Lücke: alle prüfen das Format, niemand die Wahrheit

Bevor wir eine Zeile geschrieben haben, haben wir 80 commit-fokussierte Skills in unserem 16.682-Skills-Index gesichtet, plus die eigenständigen Commit-Skills für Claude Code. Die Format-Ebene ist ein überfüllter, gelöster Bereich. Conventional-Commits-Konformität ist universell. Imperativ, 50-Zeichen-Betreffzeilen, BREAKING CHANGE:-Fußzeilen – verbreitet, gut dokumentiert, Grundausstattung. Wer nur type(scope): subject korrekt formatiert haben will, hat schon Dutzende Skills zur Auswahl.

Was keines davon durchsetzt, ist die Ebene darunter: Stimmt die Message gegenüber dem Diff? Deckt sie jede gestagte logische Änderung ab? Erfindet sie nichts – kein geratenes Motiv, kein ungemessenes „verbessert Performance“, keine beschriebene Änderung, die gar nicht drin ist? Das ist die Ehrlichkeits-Ebene, und in diesem Feld hat sie niemand für sich beansprucht. Jeder Konkurrent lässt git diff --cached entweder als unverbindliche Empfehlung laufen oder arbeitet offen von Dateilisten aus – Dateinamen, die zeigen, wo sich etwas geändert hat, aber nie was oder warum. commit-discipline macht das Lesen des vollständigen Diffs zu Regel 1 und verbietet die Dateinamen-Abkürzung ausdrücklich.

Acht Regeln, vier davon kodifiziert sonst niemand

Das Skill ist ein Satz harter Regeln (vollständige SKILL.md). Die bekannten Teile werden strikt durchgezogen: ein Typ, der aus der Verhaltensänderung im Diff abgeleitet wird, ein Scope, der aus den Pfaden herleitbar sein muss (nie erfunden), ein ≤50-Zeichen-Imperativ-Betreff, Breaking Changes in einer Fußzeile. Die Teile, die sonst niemand durchsetzt:

1. Vollständigkeit der Diff-Abdeckung. Nach dem Entwurf wird die Message gegen den Diff abgeglichen: jede logische Änderung erfasst, nichts beschrieben, was nicht gestaged ist. Halluzinationskontrolle für Commit-Messages.
2. Den vollständigen gestagten Diff lesen, nie Dateinamen. Regel 1, mit verbotener Abkürzung. Die Message beschreibt den Diff, also ist der Diff – vollständig – der Input.
3. Eine konkrete Verbotsliste für Vagheit. update, fix stuff, improve, misc, cleanup ohne Objekt, wip, address feedback – gesperrt als tragende Wörter, jeweils mit Ersatzmuster (update deps → bump axios 1.6→1.7).
4. Ein Output-Vertrag. Die Lieferung ist die Message allein in einem Code-Block – keine Einleitung, kein Diff-Nacherzählen, keine überraschende Co-Authored-By-Fußzeile.

Plus ein Body, der Warum und Auswirkung erklärt statt den Diff nachzuerzählen (mit Löschtest: Lässt sich eine Zeile aus dem Diff rekonstruieren, wird sie gestrichen), sowie eine Split-Empfehlung bei Diffs mit mehreren Anliegen – konkrete Dateigrenzen und ein Betreffsentwurf pro Commit – statt einer Sammelmessage, die zwei Änderungen überdeckt.

Der Benchmark: 15 echte Diffs, Original-Messages entfernt

Wir haben 15 Fixtures aus curl, redis, express, fastapi, eslint, django, rust-analyzer und astro bei fixierten SHAs gezogen: Features, Bugfixes, Refactorings, zwei echte Breaking Changes, zwei platzierte Diffs mit mehreren Anliegen, Docs- und CI-Chores sowie über 400-zeilige Commits mit vielen Dateien. Jeder Diff ging an zwei Claude-Sonnet-Agenten mit identischen Prompts. Der einzige Unterschied: Einer hat vorher diese SKILL.md gelesen, der andere nicht. Wir haben auf drei Arten bewertet: mechanische Conventional-Commits-Konformität per Skript, Diff-Abdeckung gegen eine vorregistrierte Gold-Änderungsliste und blindes A/B-Präferenzurteil.

Metrik	Baseline	Mit Skill
Spec-Konformität (7 mechanische Checks, Mittelwert)	91,4%	98,1%
— Betreff ≤ 50 Zeichen	40% (6/15)	100% (15/15)
Diff-Abdeckung (vs. Gold-Änderungslisten, Mittelwert)	83,2%	96,7%
Erfundene Behauptungen (gesamt über 15)	1	0
Breaking-Change-Trefferquote (2 Fixtures)	2/2	2/2
Split-Erkennung (2 platzierte Mehrfach-Anliegen-Diffs)	0/2	2/2
Blinde A/B-Präferenz (Skill vs. Baseline)	—	9 Siege / 4 Niederlagen / 2 Unentschieden

Zwei Dinge stechen heraus. Erstens war die mechanische Konformität schon in der Baseline stark – korrekte Typen, Imperativ, Breaking-Fußzeilen und keine vagen Verben kamen von Haus aus. Die ganze Format-Lücke lag bei der Betreffslänge: Die Baseline überschritt 50 Zeichen bei 9 von 15 Diffs; das Skill nie. Zweitens liegt die eigentliche Trennlinie bei der Abdeckung. Die Baseline ließ regelmäßig Nebenänderungen fallen – die hinzugefügten Tests, den Changelog-Eintrag, das zweite Anliegen, das sich in einem „einzelnen“ Diff versteckt –, während das Skill sie erfasste. Dieser Sprung von 83% auf 97% ist die Quelle der meisten Präferenzsiege, und das ist etwas, das kein Format-Checker liefern kann.

Die Split-Erkennung ist das klarste Beispiel. Bei den zwei platzierten Mehrfach-Anliegen-Diffs (t05, t12) schrieb die Baseline jeweils eine Sammelmessage; das Skill schlug beide Male den Split vor. Bei t07 – einem curl-Commit, der TLS-SRP entfernt – erkannte das Skill sogar einen unabhängigen Sechs-Setopt-Hunk, den die Baseline stillschweigend in ihre Message aufnahm – das war die einzige Fabrikation der Baseline im ganzen Lauf: eine erfundene Entfernungs-Begründung („praktisch ungenutzt“), die der Diff nicht hergab. Das Skill markierte diesen Hunk stattdessen als Rückfrage an den Nutzer, statt zu raten.

Wo das Skill verloren hat – trotzdem veröffentlicht

Unsere Methodik verlangt, die Verluste neben die Gewinne zu stellen, und das war kein sauberer Durchmarsch.

Die Baseline schlug das Skill bei drei Fixtures. Bei t03 (redis), t13 (rust-analyzer) und t15 (fastapi) – alle eng abgegrenzte Diffs – fand die Baseline ein konkretes Detail, das das Skill überging: einen erweiterten &mut dyn SourceDatabase-Trait-Bound (t13), eine _build_dependant-Dedup-Extraktion (t15) und einen von zwei Diff-Zähl-Algorithmen (t03). Der Vollständigkeitsdruck des Skills ist echt, aber nicht absolut; bei kleinen Ein-Datei-Diffs zieht die Baseline gleich oder besser.

Die Split-Disziplin des Skills hat einmal überreagiert. Bei t14 hat es einen zweizeiligen CI-plus-Dependency-Commit – Node 26 zur Matrix hinzufügen, mocha anheben – in zwei aufgeteilt, was nach dem Buchstaben von „ein Commit, ein Anliegen“ vertretbar ist, aber die meisten Reviewer würden es als einen ci:-Commit belassen. Drei korrekte Splits, ein Über-Split. Als Präferenzverlust gezählt und markiert.

Und der Vorbehalt, der am meisten zählt: n=15 ist richtungsweisend, nicht statistisch signifikant, und die Abdeckungs- und Präferenzbewertung erfolgte durch einen Richter aus derselben Modellfamilie – kein modellübergreifender GPT-Klasse-Richter war auf der Testmaschine konfiguriert. Gerade bei Präferenz besteht Selbstbevorzugungsrisiko: Autor und Richter teilen sich eine Modellfamilie. Wir haben die Labels mit einem vorregistrierten Seed durchmischt und erst nach der Bewertung wieder aufgedeckt, aber wir tun nicht so, als wäre ein 9-4-2-Präferenzergebnis von einem modelleigenen Richter ein Urteilsspruch. Es ist ein Signal. Das vollständige Protokoll, die Werte pro Fixture und die Offenlegung der Bewertungsmethode stehen in bench/results/verdict.md.

Installation

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

Claude Code neu starten. Es greift bei „commit this“, „write a commit message“, dem Committen gestagter Änderungen und Anfragen zur Message-Überarbeitung oder -Bereinigung – und hält sich raus bei Git-Operationen, bei denen es nicht um Messages geht: Branching, Rebasing, Konfliktlösung. Es reiht sich in unsere Discipline-Serie ein, neben token-discipline, das senkt, was eine Session kostet, und research-discipline, das senkt, was eine Antwort falsch macht. Dieses hier senkt, was eine Commit-Message übersieht.

FAQ

Schreibt Claude nicht sowieso schon anständige Commit-Messages? Fürs Format ja – das war die Überraschung im Benchmark. Die Baseline traf Typ, Modus und Breaking-Fußzeilen schon von Haus aus. Wo sie schwächelte, war die Abdeckung: Sie ließ Nebenänderungen bei mehr als der Hälfte der Mehrfach-Anliegen- und Mehrdatei-Diffs fallen und überschritt bei 9 von 15 die 50-Zeichen-Grenze im Betreff. Genau diese Lücke ist der Job des Skills, nicht das Format, das ohnehin schon stimmt.

Ist das nur ein Conventional-Commits-Linter? Nein, und genau darum geht es. Conventional-Commits-Konformität ist ein überfüllter, gelöster Bereich – das können Dutzende Skills. commit-discipline setzt die Ebene darunter durch: dass die Message jede logische Änderung im Diff erfasst und nichts erfindet. Format ist hier Grundausstattung; Ehrlichkeit gegenüber dem Diff ist das Produkt.

Committet oder pusht es für mich? Nein. Die Message zu schreiben ist der Job; git commit auszuführen ist eine separate Anweisung, die das Skill nicht von sich aus übernimmt. Es fügt auch keine Co-Authored-By- oder „Generated with“-Fußzeilen hinzu, außer dein Projekt-Log oder deine eigenen Anweisungen zeigen, dass du sie willst.

Kann ich der 9-4-2-Präferenzzahl trauen? Behandle sie als richtungsweisend, nicht als Urteil. Sie wurde von einem Agenten derselben Modellfamilie mit verdeckten Labels bewertet, weil auf der Testmaschine kein modellübergreifender Richter verfügbar war – trägt also Selbstbevorzugungsrisiko, und n=15 ist statistisch nicht signifikant. Die Abdeckungszahlen (83%→97%) beruhen auf einer vorregistrierten Gold-Änderungsliste und sind das tragfähigere Ergebnis; die drei Fixtures, bei denen das Skill verloren hat, sind oben genannt.