← ClaudeAtlas

create-commit-messagelisted

Write a commit message for the currently staged changes, matching the project's conventions. Use when staged changes need a well-formed message -- on its own, or by an agent after it stages a commit. Reads the staged diff; does not stage or commit.
richardkmichael/claude-rodin · ★ 0 · Code & Development · score 72
Install: claude install-skill richardkmichael/claude-rodin
# Commit Message for Staged Changes Produce one commit message describing the currently staged changes, and nothing else. Do not stage, unstage, or commit -- the caller has already decided what belongs in this commit. Your input is the staged diff; your output is the message. ## 1. Read what is staged ```bash git diff --cached # the exact changes this message must describe git diff --cached --stat # files and scale, at a glance ``` The message must account for everything in the staged diff and nothing that isn't there. If the staged changes are plainly two unrelated concerns, say so rather than writing a message that papers over the mix -- that's a sign the caller should split the commit, not that the message should stretch to cover it. ## 2. Match the project's convention The existing history is the ground truth for format: ```bash git log --oneline -20 # subject style: prefixes, length, ticket refs git log -5 # full bodies: trailers, wrapping, tense ``` Match what you observe -- Conventional Commits (`feat(scope): ...`), subsystem prefixes (`net: ...`), ticket references (`[PROJ-123] ...`), subject length, body width, trailer format (`Signed-off-by:`, `Reviewed-by:`, `Fixes:`), capitalization, punctuation, tense. Honor a `CONTRIBUTING` file or a commit-lint config if one is present. With no discernible convention, fall back to an imperative subject under ~72 characters and a body wrapped at 72. ## The subject says what; the body says why