opción

Crea un commit de git con un mensaje claro que comunique valor. Utilízalo cuando el usuario solicite realizar un commit o guardar cambios en el área de preparación (staged) o no preparados (unstaged) con un mensaje adecuado al repositorio que comunique valor.

...Expandir todo
15
Tiempo actualizado 26 de agosto de 2026

Acerca de ce-commit

Un flujo de trabajo para crear un único commit de git bien elaborado a partir del árbol de trabajo actual, produciendo un mensaje que comunique valor y siga las convenciones del repositorio cuando existan, o el formato de commit convencional en caso contrario. Se activa cuando el usuario solicita realizar un commit, guardar cambios o crear un commit a partir de trabajo en fase de preparación (staged) o sin preparar (unstaged). En Claude Code consume secciones de estado de git pre-poblado, diferencias del árbol de trabajo, rama actual, commits recientes y rama predeterminada remota directamente, y en otras plataformas ejecuta un único comando de respaldo para recopilar el mismo contexto.

El flujo de trabajo se ejecuta en cinco pasos. El paso 1 recopila el contexto y maneja casos extremos: un árbol limpio significa que no hay nada que comprometer, y una HEAD desvinculada solicita al usuario, a través de la herramienta de pregunta bloqueante de la plataforma, sobre la creación de una rama de función. El paso 2 determina la convención del mensaje por prioridad, preferiendo las convenciones documentadas del repositorio, luego un patrón inferido de los diez commits más recientes, y luego commits convencionales de la forma tipo alcance descripción con tipos como feat, fix, docs, refactor, test, chore, perf, ci, style y build; donde fix y feat encajan ambos, por defecto se opta por fix. El paso 3 considera ligeramente dividir preocupaciones claramente distintas en commits separados, agrupando solo a nivel de archivo, con dos o tres commits lógicos considerados el punto óptimo.

El paso 4 prepara y compromete, y si la rama actual es main, master o la rama predeterminada resuelta, crea automáticamente una rama de función primero en lugar de comprometerse en la rama predeterminada. Los mensajes utilizan un sujeto imperativo conciso centrado en el porqué sobre el qué, con un cuerpo opcional para cambios no triviales, y la preparación prefiere nombrar archivos específicos en lugar de git add all para evitar incluir archivos sensibles; los commits se escriben con un heredoc para preservar el formato. El paso 5 confirma el éxito ejecutando git status e informando los hashes de commit resultantes y las líneas de asunto.

Preguntas frecuentes

¿Qué formato de mensaje de commit utiliza por defecto?

Prefiere las convenciones documentadas del repositorio, luego un patrón inferido de los diez commits más recientes, y en caso contrario recurre a commits convencionales en la forma tipo alcance : descripción.

¿Realizará commits directamente en la rama principal?

No. Si la rama actual es main, master o la rama predeterminada resuelta, crea automáticamente una rama de función primero antes de comprometerse.

¿Cuándo elige fix frente a feat?

Cuando ambos parecen encajar, por defecto se opta por fix, tratando un cambio que remedia un comportamiento roto o faltante como fix y reservando feat para capacidades genuinamente nuevas.

¿Divide los cambios en múltiples commits?

Escanea ligeramente en busca de preocupaciones claramente distintas y puede crear commits separados agrupados solo a nivel de archivo, considerando dos o tres commits lógicos como el punto óptimo.

¿Cómo evita comprometer archivos sensibles?

Prefiere preparar archivos específicos por nombre en lugar de usar git add -A o git add ., para evitar incluir accidentalmente archivos como .env o credenciales.

Ver en GitHub

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.

CommandPurposeNon-zero / empty means
git statusWorking-tree stateNot a git repo — stop
git diff HEADUncommitted changesUnborn repo / no commits yet
git branch --show-currentCurrent branchEmpty = detached HEAD
git log --oneline -10Recent message styleUnborn repo — no history
git rev-parse --abbrev-ref origin/HEADRemote default branchNo 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/trunktrunk). Use that bare name for all “on the default branch?” checks — never compare against origin/<name>.

Workflow

  1. Gather — run every Context command above (own shell call each), then continue.

  2. Nothing to commit — if git status shows no staged, modified, or untracked files, report that and stop. Do not use git diff HEAD alone as cleanliness (it misses untracked files).

  3. 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-read git 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.

  4. Convention — match project commit conventions already in context; else match the recent log pattern; else conventional commits (type(scope): description). When using conventional commits and fix/feat both fit, default to fix: (remedying broken or missing behavior); reserve feat: for new capabilities. User override wins.

  5. 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.

  6. 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)
  7. Stage and commit — stage named files only (never git add -A or git add .). Honor exclude:<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.

  1. Confirm — git status; report hash(es) and subject(s).

Todos los archivos

0 archivos

Instalar ce-commit

Descarga y extrae los archivos de habilidades en tu directorio .claude/skills/.

Descargar ZIP

Clona el repositorio y copia los archivos de la habilidad a tu proyecto.

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 Copiar
Configuración rápida: Copia la carpeta de la habilidad a .claude/skills/Claude detectará y utilizará automáticamente la habilidad

Habilidades relacionadas

github-project-management
Tiempo actualizado 29 de junio de 2026
using-git-worktrees
Tiempo actualizado 29 de junio de 2026
readme-blueprint-generator
Tiempo actualizado 5 de julio de 2026
finishing-a-development-branch
Tiempo actualizado 29 de junio de 2026
OR