← ClaudeAtlas

git-committerlisted

Write and create commits matching this project's established convention. Use when the user asks to commit, or when a unit of work is finished and ready to record.
HeisenbergI8/provenly · ★ 0 · Code & Development · score 72
Install: claude install-skill HeisenbergI8/provenly
# Git Committer ## Read the log before writing anything ```bash git log -20 --format='%s%n%n%b%n---' ``` **The existing log is the convention.** `CONVENTIONS.md` records what is easy to get wrong; the log records what is actually done. When they disagree, follow the log and say so. Look for: subject format, whether a scope is used, whether bodies are expected, whether a ticket reference appears and in what form. ## Read the diff before describing it ```bash git status --porcelain git diff --staged ``` **Never describe a diff you have not read.** A commit message written from memory of what you intended describes the intention, not the change — and the two diverge exactly when it matters. ## The shape ``` <type>(<scope>): <what changed, imperative, under ~70 chars> <why — the paragraph that earns its place> <verification line: what you ran and what it said> <trailer, if this project uses one> ``` **The body explains WHY, not what.** The diff already says what. A body that narrates the change is noise; a body that says what was broken, what was tried, or what constraint forced this shape is worth reading in a year. **The verification line is concrete or absent.** "Tested" is worthless. `verify green, 42/42 unit` is evidence. If you did not run anything, say nothing rather than implying you did — the claim checker will block a green claim the ledger cannot support, and it is right to. ## Before committing Run the project's verify command. `guard-commit.mjs` check