Lar
ce-commit
everyinc/compound-engineering-plugin
Crie um commit do git com uma mensagem clara que comunique valor. Utilize quando o usuário solicitar a confirmação/salvamento de alterações em estágio ou não em estágio, com uma mensagem adequada ao repositório e que comunique valor.
...Expandir tudoSobre ce-commit
Um fluxo de trabalho para criar um único commit do git bem elaborado a partir da árvore de trabalho atual, produzindo uma mensagem que comunique valor e siga as convenções do repositório quando existirem, ou o formato de commit convencional caso contrário. Ele é ativado quando o usuário solicita a criação de um commit, o salvamento de alterações ou a geração de um commit a partir de alterações em estágio (staged) ou não em estágio (unstaged). No Claude Code, ele consome seções de status do git pré-preenchidas, diff da árvore de trabalho, ramo atual, commits recentes e o ramo padrão do repositório remoto diretamente; em outras plataformas, ele executa um único comando de fallback para coletar o mesmo contexto.
O fluxo de trabalho é executado em cinco etapas. A Etapa 1 coleta o contexto e lida com casos extremos: uma árvore limpa significa que não há nada para commitar, e um HEAD desanexado (detached HEAD) solicita ao usuário, por meio da ferramenta de pergunta bloqueante da plataforma, sobre a criação de um ramo de recurso (feature branch). A Etapa 2 determina a convenção da mensagem por prioridade, preferindo as convenções documentadas do repositório, em seguida um padrão inferido dos dez commits mais recentes e, por fim, commits convencionais na forma tipo escopo descrição, com tipos como feat, fix, docs, refactor, test, chore, perf, ci, style e build; quando tanto fix quanto feat se aplicam, o padrão é fix. A Etapa 3 considera levemente a divisão de preocupações claramente distintas em commits separados, agrupando apenas ao nível do arquivo, sendo dois ou três commits lógicos considerados o ponto ideal.
A Etapa 4 realiza o staging e o commit; se o ramo atual for main, master ou o ramo padrão resolvido, ele cria automaticamente um ramo de recurso primeiro, em vez de commitar diretamente no ramo padrão. As mensagens usam um sujeito imperativo conciso focado no porquê em vez do o quê, com um corpo opcional para alterações não triviais; o staging prefere nomear arquivos específicos em vez de usar git add all para evitar incluir arquivos sensíveis; os commits são escritos com um heredoc para preservar a formatação. A Etapa 5 confirma o sucesso executando git status e relatando os hashes dos commits resultantes e as linhas de assunto.
Perguntas Frequentes
Qual formato de mensagem de commit ele usa por padrão?
Ele prefere as convenções documentadas do repositório, em seguida um padrão inferido dos dez commits mais recentes e, caso contrário, recorre aos commits convencionais na forma tipo escopo: descrição.
Ele commitará diretamente no ramo principal?
Não. Se o ramo atual for main, master ou o ramo padrão resolvido, ele cria automaticamente um ramo de recurso primeiro antes de realizar o commit.
Quando ele escolhe fix em vez de feat?
Quando ambos parecem se aplicar, o padrão é fix, tratando uma alteração que corrige comportamento quebrado ou ausente como fix e reservando feat para capacidades genuinamente novas.
Ele divide as alterações em múltiplos commits?
Ele analisa levemente a existência de preocupações claramente distintas e pode criar commits separados agrupados apenas ao nível do arquivo, sendo dois ou três commits lógicos considerados o ponto ideal.
Como ele evita commitar arquivos sensíveis?
Ele prefere realizar o staging de arquivos específicos por nome em vez de usar git add -A ou git add ., para evitar incluir acidentalmente arquivos como .env ou credenciais.
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).
Todos os arquivos
0 arquivosInstalar ce-commit
Baixe e extraia os arquivos de habilidade para o diretório .claude/skills/.
Baixar ZIPClone o repositório e copie os arquivos da habilidade para o seu projeto.
git clone https://github.com/EveryInc/compound-engineering-plugin/blob/main/skills/ce-commit/SKILL.md # Copy SKILL.md to your .claude/skills/ directory
Copiar
