‹ Back to the directory

Git Commit Writer

Writes commit messages from the actual staged diff — imperative subject, why-first body — whenever changes are ready to commit.

by Quarrylight·0 installs
gitcommitsdocumentation
T

Create a free shareskills account to install Git Commit Writer into Claude.

Create a free account

Git Commit Writer

Commit messages are the only documentation guaranteed to survive as long as the code does. This skill writes them from the actual staged diff — never from memory of what the work was supposed to be — so the subject line says what changed and the body says why it was needed and what a reader might wrongly assume. It favors small, separable commits over one omnibus message, and it will say so when the staged changes ought to be split.

When to use this skill

  • The user asks for a commit message, or says "commit this"
  • The agent has just finished a change and is about to commit it
  • Rewording a poor message before it is pushed or shared
  • Reviewing a branch whose history needs cleanup before merge

Instructions

  1. Run git diff --staged --stat, then read the full staged diff. If nothing is staged, look at the working tree and propose what to stage. Never write a message for changes you have not read.
  2. Check for mixed concerns. If the diff contains two unrelated changes (a feature plus a drive-by rename, a fix plus a formatting sweep), recommend splitting into separate commits and say exactly which files or hunks belong in each.
  3. Write the subject line: imperative mood, at most 65 characters, specific over general. "Fix pagination skipping the final partial page" beats "Fix pagination bug" beats "Fix bug". Check git log --oneline -15 first and match the repository's existing conventions (area prefixes, ticket tags) rather than imposing your own.
  4. Write the body in one to three short paragraphs answering, in order: why the change was needed, what approach was taken, and what a reader might wrongly assume — side effects, behavior that deliberately did not change, follow-up work intentionally left out.
  5. Wrap body lines near 72 characters. Reference an issue identifier only if the history already uses them and one exists; never invent one.
  6. Do not describe the diff mechanically ("changed X to Y") when the diff already shows that. Spend the words on what the diff cannot show: intent, constraints, rejected alternatives.
  7. Read the final message once as a stranger running git blame two years from now. If it would not help them, rewrite the body.

Output format

<subject: imperative, <=65 chars, no trailing period>

<why the change was needed — the problem, not the solution>

<what was done and any non-obvious decision, e.g. "kept the old
column populated for one release so rollback stays safe">

Omit the body only for genuinely trivial changes (typo fixes, comment corrections) where the subject carries everything.

Guardrails

  • The message must be reconstructible from the diff alone. If it claims a behavior change the diff does not contain, it is fiction; delete the claim.
  • No filler verbs: "update", "improve", and "enhance" are banned from subjects, and "refactor" is allowed only when the commit truly preserves behavior.
  • One logical change per commit. An "and" in the subject line is the smell of two commits.
  • Do not commit, amend, or rebase unless the user asked for that action; writing the message and performing git surgery are separate decisions.

Worked example

Staged diff: a retry loop added around one outbound call, plus a new test.

Retry transient failures when fetching exchange rates

The rates provider drops roughly one request in fifty with a
connection reset, which aborted the whole invoicing run. Retry up
to three times with exponential backoff, then fail the single
invoice instead of the batch.

Deliberately not retrying on HTTP 4xx: those are our bug, and
retrying would hide them.
Git Commit Writer — AI skill by Quarrylight | shareskills