Maison
ce-commit
everyinc/compound-engineering-plugin
Créez un commit git avec un message clair et porteur de valeur. Utilisez cette option lorsque l'utilisateur demande à valider (commiter) ou enregistrer des modifications préparées ou non préparées, en fournissant un message adapté au dépôt et communiquant clairement la valeur des changements.
...Développer toutÀ propos de ce-commit
Un flux de travail permettant de créer un seul commit Git soigné à partir de l'arbre de travail actuel, produisant un message qui communique de la valeur et respecte les conventions du dépôt lorsqu'elles existent, ou le format de commit conventionnel dans le cas contraire. Il s'active lorsque l'utilisateur demande de valider, d'enregistrer les modifications ou de créer un commit à partir de travaux indexés ou non indexés. Sur Claude Code, il consomme directement les sections pré-remplies de statut Git, de différence de l'arbre de travail, de branche actuelle, de commits récents et de branche par défaut du dépôt distant, et sur d'autres plateformes, il exécute une seule commande de secours pour recueillir le même contexte.
Le flux de travail s'exécute en cinq étapes. L'étape 1 recueille le contexte et gère les cas limites : un arbre propre signifie qu'il n'y a rien à valider, et une tête détachée invite l'utilisateur, via l'outil de question bloquante de la plateforme, à créer une branche de fonctionnalité. L'étape 2 détermine la convention de message par priorité, en privilégiant les conventions documentées du dépôt, puis un motif déduit des dix commits les plus récents, puis les commits conventionnels de la forme type étendue description avec des types tels que feat, fix, docs, refactor, test, chore, perf, ci, style et build ; lorsque fix et feat conviennent tous deux, il par défaut sur fix. L'étape 3 examine légèrement la possibilité de diviser les préoccupations clairement distinctes en commits séparés, en regroupant uniquement au niveau des fichiers, deux ou trois commits logiques étant considérés comme le point idéal.
L'étape 4 indexe et valide, et si la branche actuelle est main, master ou la branche par défaut résolue, elle crée automatiquement une branche de fonctionnalité au préalable plutôt que de valider sur la branche par défaut. Les messages utilisent un sujet impératif concis axé sur le pourquoi plutôt que le quoi, avec un corps optionnel pour les modifications non triviales, et l'indexation privilégie le nommage de fichiers spécifiques plutôt que git add all pour éviter d'inclure des fichiers sensibles ; les commits sont écrits avec un heredoc pour préserver le formatage. L'étape 5 confirme le succès en exécutant git status et en rapportant les hachages de commit résultants et les lignes de sujet.
FAQ
Quel format de message de commit utilise-t-il par défaut ?
Il privilégie les conventions documentées du dépôt, puis un motif déduit des dix commits les plus récents, et sinon, il se rabat sur les commits conventionnels sous la forme type étendue : description.
Validera-t-il directement sur la branche main ?
Non. Si la branche actuelle est main, master ou la branche par défaut résolue, il crée automatiquement une branche de fonctionnalité au préalable avant de valider.
Quand choisit-il fix plutôt que feat ?
Lorsque les deux semblent convenir, il par défaut sur fix, traitant une modification qui corrige un comportement cassé ou manquant comme fix et réservant feat pour des capacités véritablement nouvelles.
Divise-t-il les modifications en plusieurs commits ?
Il scanne légèrement la présence de préoccupations clairement distinctes et peut créer des commits séparés regroupés uniquement au niveau des fichiers, deux ou trois commits logiques étant considérés comme le point idéal.
Comment évite-t-il de valider des fichiers sensibles ?
Il privilégie l'indexation de fichiers spécifiques par leur nom plutôt que l'utilisation de git add -A ou git add ., afin d'éviter d'inclure accidentellement des fichiers tels que .env ou des identifiants.
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).
Tous les fichiers
0 fichiersInstaller ce-commit
Téléchargez et extrayez les fichiers de compétences dans votre répertoire .claude/skills/.
Télécharger le ZIPClonez le dépôt et copiez les fichiers de compétence dans votre projet.
git clone https://github.com/EveryInc/compound-engineering-plugin/blob/main/skills/ce-commit/SKILL.md # Copy SKILL.md to your .claude/skills/ directory
Copier
