Heim
ce-commit
everyinc/compound-engineering-plugin
Erstellen Sie einen Git-Commit mit einer klaren, wertvermittelnden Nachricht. Verwenden Sie diese Funktion, wenn der Benutzer auffordert, zwischengespeicherte oder nicht zwischengespeicherte Änderungen mit einer repository-gerechten, wertvermittelnden Nachricht zu committen/speichern.
...Alle erweiternÜber ce-commit
Ein Workflow zum Erstellen eines einzelnen, sorgfältig gestalteten Git-Commits aus dem aktuellen Arbeitsbaum, der eine Nachricht erzeugt, die Wert vermittelt und Repository-Konventionen befolgt, sofern diese vorhanden sind, andernfalls das konventionelle Commit-Format. Er wird aktiviert, wenn der Benutzer darum bittet, zu committen, Änderungen zu speichern oder ein Commit aus stehenden oder nicht stehenden Arbeiten zu erstellen. Auf Claude Code werden vorbefüllte Abschnitte mit Git-Status, Arbeitsbaum-Diff, aktuellem Branch, jüngsten Commits und Remote-Standardbranch direkt verarbeitet; auf anderen Plattformen wird ein einzelner Fallback-Befehl ausgeführt, um denselben Kontext zu sammeln.
Der Workflow läuft in fünf Schritten ab. Schritt 1 sammelt Kontext und behandelt Randfälle: Ein sauberer Baum bedeutet, dass nichts zu committen ist, und ein detached HEAD fordert den Benutzer über das blockierende Frage-Tool der Plattform auf, die Erstellung eines Feature-Branches zu prüfen. Schritt 2 ermittelt die Nachrichtenkonvention nach Priorität: Zuerst dokumentierte Repository-Konventionen, dann ein aus den zehn jüngsten Commits abgeleitetes Muster, andernfalls konventionelle Commits im Format Typ Bereich Beschreibung mit Typen wie feat, fix, docs, refactor, test, chore, perf, ci, style und build; wenn sowohl fix als auch feat passen, wird standardmäßig fix gewählt. Schritt 3 berücksichtigt leicht das Aufteilen klar unterschiedlicher Anliegen in separate Commits, gruppiert nur auf Dateiebene, wobei zwei oder drei logische Commits als ideal angesehen werden.
Schritt 4 stehet und committet, und wenn der aktuelle Branch main, master oder der aufgelöste Standardbranch ist, wird automatisch zuerst ein Feature-Branch erstellt, anstatt direkt auf dem Standardbranch zu committen. Nachrichten verwenden einen prägnanten imperativen Betreff, der sich auf das Warum statt auf das Was konzentriert, mit einem optionalen Textkörper für nicht-triviale Änderungen; beim Staging wird bevorzugt, spezifische Dateien nach Namen zu benennen, anstatt git add all zu verwenden, um das unbeabsichtigte Einschließen sensibler Dateien zu vermeiden; Commits werden mit einem Here-Dokument geschrieben, um die Formatierung zu erhalten. Schritt 5 bestätigt den Erfolg, indem git status ausgeführt und die resultierenden Commit-Hashes sowie Betreffzeilen gemeldet werden.
FAQ
Welches Commit-Nachrichtenformat wird standardmäßig verwendet?
Es bevorzugt dokumentierte Repository-Konventionen, dann ein aus den zehn jüngsten Commits abgeleitetes Muster, und andernfalls wird auf konventionelle Commits im Format Typ Bereich: Beschreibung zurückgegriffen.
Wird direkt auf dem main-Branch committet?
Nein. Wenn der aktuelle Branch main, master oder der aufgelöste Standardbranch ist, wird automatisch zuerst ein Feature-Branch erstellt, bevor committet wird.
Wann wird fix versus feat gewählt?
Wenn beide passen, wird standardmäßig fix gewählt, wobei eine Änderung, die defektes oder fehlendes Verhalten behebt, als fix behandelt wird und feat für wirklich neue Funktionen reserviert bleibt.
Werden Änderungen in mehrere Commits aufgeteilt?
Es scannt leicht nach klar unterschiedlichen Anliegen und kann separate Commits erstellen, die nur auf Dateiebene gruppiert sind, wobei zwei oder drei logische Commals als ideal angesehen werden.
Wie wird vermieden, sensible Dateien zu committen?
Es bevorzugt das Staging spezifischer Dateien nach Namen statt der Verwendung von git add -A oder git add ., um das unbeabsichtigte Einschließen von Dateien wie .env oder Anmeldeinformationen zu vermeiden.
Create well-crafted local commit(s) from the current working tree. No push, no PR — use ce-commit-push-pr for the full ship flow.
Done when: each logical change is committed with an explicit file list and a message that states the outcome, and git status is clean of those changes. Stop when: the tree is clean (nothing to commit).
Context
Gather context with each command as its own shell tool call (program + args only). Do not join with ;, &&, ||, pipes, $(...), or redirects — that syntax fails under Windows PowerShell. A non-zero exit is a normal state to interpret, not a failure to suppress.
| Command | Purpose | Non-zero / empty means |
|---|---|---|
git status | Working-tree state | Not a git repo — stop |
git diff HEAD | Uncommitted changes | Unborn repo / no commits yet |
git branch --show-current | Current branch | Empty = detached HEAD |
git log --oneline -10 | Recent message style | Unborn repo — no history |
git rev-parse --abbrev-ref origin/HEAD | Remote default branch | No origin/HEAD / bare HEAD — try gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name', else main |
Treat this as a snapshot. Re-read branch and staged set immediately before committing if anything may have changed.
Default branch name: strip a leading origin/ from origin/HEAD (so origin/trunk → trunk). Use that bare name for all “on the default branch?” checks — never compare against origin/<name>.
Workflow
Gather — run every Context command above (own shell call each), then continue.
Nothing to commit — if
git statusshows no staged, modified, or untracked files, report that and stop. Do not usegit diff HEADalone as cleanliness (it misses untracked files).Branch first — if detached HEAD, or on the default branch (
main/master/ the bare default name above), create a feature branch from the change content (git checkout -b <name>), then re-readgit branch --show-current. Do not ask — commit-only still must not leave work only on a detached HEAD or the default branch. If the derived name exists, pick a non-conflicting suffix.Convention — match project commit conventions already in context; else match the recent log pattern; else conventional commits (
type(scope): description). When using conventional commits andfix/featboth fit, default tofix:(remedying broken or missing behavior); reservefeat:for new capabilities. User override wins.Logical commits — if changed files clearly split into distinct concerns, make separate commits (file level only, 2–3 max, no
git add -p). If ambiguous, one commit.Message — subject is imperative and names the outcome (what is now possible or fixed), not the file list. Body only when motivation or trade-offs are not obvious from the subject. When a plan Implementation Unit ID is already in hand for this commit (conversation, caller, or the files belong to one unit), append that unit's U-ID in parentheses —
(U3)means unit 3. Do not hunt for a plan. Omit when the commit spans units, the unit is unclear, or no plan is in hand.- Bad:
Update checkout.rb/Add tests and fix stuff - Good:
Fix double-submit on checkout - Good:
Add per-subscription mute (U3)
- Bad:
Stage and commit — stage named files only (never
git add -Aorgit add .). Honorexclude:<paths>when the invocation carries it: those files stay uncommitted no matter what else changed; say in the report that they were left out. Prefer one shell call per commit group:
git add file1 file2 file3 && git commit -m "$(cat <<'EOF'type(scope): subject line hereOptional body when the why is not obvious from the subject.EOF)" -- file1 file2 file3
The trailing path list on git commit is load-bearing: a bare git commit takes the whole index, so anything already staged before this run (a caller's exclude: paths, or work the user staged and did not name) would ride into the commit. Naming the paths commits exactly the group and leaves other index entries alone.
- Confirm —
git status; report hash(es) and subject(s).
Alle Dateien
0 Dateience-commit installieren
Laden Sie die Skill-Dateien herunter und extrahieren Sie diese in Ihr .claude/skills/-Verzeichnis.
ZIP herunterladenKlonen Sie das Repository und kopieren Sie die Skill-Dateien in Ihr Projekt.
git clone https://github.com/EveryInc/compound-engineering-plugin/blob/main/skills/ce-commit/SKILL.md # Copy SKILL.md to your .claude/skills/ directory
Kopieren
