kairyou/agent-tools

Commit-Nachrichten-Generator

Arbeitsablauf

1. Führe git diff --staged aus, um die bereitgestellten Änderungen zu überprüfen. Ist es leer, teile dem Benutzer mit, dass er zuerst git add ausführen soll, und breche ab.
2. Bestimme die Beschreibungssprache gemäß der Sprachrichtlinie unten.
3. Erzeuge die Nachricht(en) und zeige sie zur Bestätigung an; committe nicht sofort. Wenn mehrere Rahmenbedingungen sinnvoll sind, zeige sie als kurze nummerierte Liste (1), 2), …) an, sodass der Benutzer durch Antworten mit der Nummer auswählen kann. Eine einzelne klare Nachricht kann allein angezeigt werden. Der Benutzer kann auch mit einer Bearbeitung oder seinem eigenen Wortlaut antworten.
4. Führe git commit -m erst aus, nachdem der Benutzer ausgewählt oder explizit bestätigt hat – eine Nummer aus der Liste, "commit" oder "ok" zählen alle. Führe kein git push aus, es sei denn, der Benutzer fordert es explizit an.

Sprachrichtlinie

Verwende diese Prioritätsreihenfolge für die menschenlesbare Beschreibung nach type(scope)::

1. Verwende die Sprache, die der Benutzer in dieser Runde explizit angefordert hat.
2. Andernfalls verwende die Repository-Präferenz in .agent-tools/config.jsonc, sofern dort at-commit.language definiert ist.
3. Andernfalls verwende die globale Präferenz in ~/.agent-tools/config.jsonc, sofern dort at-commit.language definiert ist.
4. Andernfalls verwende die Sprache des tatsächlichen Aufruftexts des Benutzers, wenn dieser eine klare, eigenständige Anforderung in natürlicher Sprache enthält. Ignoriere eingebettete Skill-Anweisungen, zitierte oder eingefügte Inhalte, Codeblöcke, Diffs und Tool-Ausgaben.
5. Andernfalls verwende die dominierende Sprache in den letzten Commit-Betreffen des Repositorys.
6. Wenn keine dominierende Sprache klar ist, verwende standardmäßig Englisch.

Wende diese Reihenfolge wörtlich an und stoppe bei der ersten Übereinstimmung. Überprüfe die Punkte 2 und 3 vor Punkt 4. Ein bloßer Slash-Befehl oder Skill-Aufruf hat keine Sprache; fahre mit Punkt 5 fort. Überprüfe höchstens die letzten 20 Betreffe.

Halte die Syntax-Tokens von Conventional Commits unübersetzt: type, optional scope, ! und BREAKING CHANGE. Behalte Bezeichner, Dateinamen, Paketnamen, Befehle, API-Namen und Bereiche in ihrer Originalsprache.

Dauerhafte Spracheinstellung

Schreibe während der normalen Commit-Erstellung keine Konfiguration. Wenn der Benutzer explizit darum bittet, sich an eine Commit-Beschreibungssprache zu erinnern, biete an, sie dauerhaft zu speichern. Frage nach Repository vs. global, wenn der Bereich nicht eindeutig ist.

Für die Repository-Präferenz erstelle oder aktualisiere .agent-tools/config.jsonc; für die globale Präferenz verwende ~/.agent-tools/config.jsonc:

{
  "at-commit.language": "zh-CN"
}

Bewahre nach Möglichkeit nicht zusammenhängende Schlüssel und Kommentare. Setze keine vorherige Installationskonfiguration voraus.

Regeln

Lese git diff --staged und erzeuge einen Conventional-Commits-Titel, der erklärt, WAS sich geändert hat, und, wenn nützlich, WARUM.

• Titel: type(scope): description, <= 74 Zeichen, kein Punkt am Ende, kein Präfix, keine Anführungszeichen, kein Codeblock.
• type: wähle genau eines aus:
  • feat für ein Feature, fix für einen Bugfix
  • refactor für verhaltenserhaltende Umstrukturierung, perf für Leistung
  • docs für dokumentationsbezogene Änderungen, style für formatierungsbezogene Änderungen
  • test für das Hinzufügen oder Beheben von Tests, build für Build-Systeme oder Abhängigkeiten, ci für CI-Konfiguration/Skripte
  • chore für verschiedene Änderungen, die nicht src/test betreffen, revert für Rückgängigmachungen
• scope: optionaler Name des betroffenen Moduls. Verwende die Konvention dieses Repositorys. In Monorepos verwende den App-/Paketverzeichnisnamen. Lasse ihn bei bereichsübergreifenden Änderungen oder bei Unsicherheit weg.
• description: ein prägnanter Verb-Objekt-Satz in der ausgewählten natürlichen Sprache. Vermeide Füllwörter wie "Dateien aktualisieren", "dieser Commit", "verschiedene Änderungen" oder "mehrere Änderungen". Behalte Bezeichner, Funktionsnamen, Dateinamen, Paketnamen, Befehle und APIs wie geschrieben bei.
• nur eine Zeile: Commit-Nachrichten enthalten immer nur die Titelzeile. Schreibe keinen Haupttext oder Fußzeile. Komprimiere notwendiges WARUM in den Titel.
• breaking changes: kennzeichne mit type(scope)!: description, weiterhin nur eine Zeile. Verwende keine BREAKING CHANGE Fußzeile.
• Interpunktion: verwende ASCII-Interpunktion.

Generierungsstrategie

Identifiziere vor dem Schreiben den roten Faden der bereitgestellten Änderungen.

• Hauptlinie: füge nur die Informationen ein, die zum Verständnis dieses Commits erforderlich sind. Hänge keine Namen an, es sei denn, einer ist der Punkt der Änderung.
• Wesentliche Änderungen: suche nach Logik-, Vertrags-, Build-, Qualitäts- oder sichtbaren Verhaltensänderungen. Verwende dies zur Wahl von type und Entscheidung, ob ! erforderlich ist.

Inhaltsdisziplin

Die Nachricht muss bestätigte Code-Fakten angeben, keine vermutete Absicht.

• Bevorzuge Verhaltensänderungen in src und test: Dokumente sind nur unterstützender Kontext. Schließe WAS nicht allein aus Dokumenten.
• Benutzerkontext schlägt Dokumente: explizite Benutzerziele können bei der Wahl von WARUM und der Formulierung helfen, aber WAS und Bereich stammen aus dem bereitgestellten Diff. Füge keine kontextbezogenen Änderungen ein, die im Diff fehlen. Wenn Kontext und Diff in Konflikt stehen, folge dem Diff und frage nach Bestätigung.
• Löschungen und Umbenennungen: wenn der Zweck nicht aus Codebeziehungen bestätigt werden kann, gib nur an, was der Diff beweist, z. B. "entferne X" oder "benenne X in Y um". Behaupte keinen Ersatz, keine Migration oder Kausalität, es sei denn, der Code beweist es.
• Mehrere Änderungen mit einem Ziel: gib eine zusammenfassende Nachricht aus, wenn die Änderungen eindeutig demselben Ziel dienen, z. B. einer Qualitäts- oder Build-Korrektur. Schlage eine Aufteilung nur vor, wenn sie die Überprüfung oder das Rückgängigmachen wesentlich verbessern würde.
• Nicht zusammenhängende bereitgestellte Änderungen: gib getrennte Nachrichten für jede kohärente Einheit plus eine konservative zusammenfassende Nachricht aus. Lass den Benutzer zwischen getrennt oder Zusammenfassung wählen, anstatt die Zusammenfassung auf eine andere Runde zu verschieben.
• Unklare Eigentümerschaft oder Absicht: liste Dateien auf, die eine Bestätigung benötigen, anstatt eine vage Nachricht zu erzwingen. Bevorzuge Bestätigung oder Aufteilung gegenüber schwachen Wörtern wie "aktualisieren", "anpassen" oder "optimieren", wenn die Absicht unklar ist.