Stats
Actions
Tags
From project-management
Generate descriptive commit messages by analyzing git diffs. Use when the user asks for help commiting code, writing commit messages, or reviewing staged changes.
How this skill is triggered — by the user, by Claude, or both
Slash command
/project-management:git-commit-helperThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Commit messages are trust artifacts. A well-written commit should give the reader enough context to decide whether they need to review the code at all. Capture intent, decisions, and verification — not just what files changed.
Commit messages are trust artifacts. A well-written commit should give the reader enough context to decide whether they need to review the code at all. Capture intent, decisions, and verification — not just what files changed.
Before drafting the message, collect:
# What's staged
git diff --staged --stat
git diff --staged
# Recent commits for tone and convention
git log --oneline -5
Read the diff carefully. Understand why the change was made, not just what changed. If you made the changes yourself, you already have this context — use it.
<type>(<scope>): <summary>
Why: <problem solved or request fulfilled>
Approach: <what was done and key decisions made>
Verified: <how correctness was confirmed>
[Tradeoffs: <alternatives considered, things intentionally left out>]
[Breaking: <what breaks and migration path>]
Follow conventional commits. Keep the summary under 50 characters, imperative mood.
Types: feat, fix, docs, style, refactor, test, chore
One or two sentences explaining the motivation. What was broken, missing, or requested? This should make sense to someone who wasn't in the conversation where the work was discussed.
What you did and, critically, why you did it that way. Include:
This is where agent context gets preserved. If you chose approach A over approach B, say so. That reasoning exists in your working memory right now and will be lost after the session ends.
How you know the change is correct. Be specific:
If verification was limited, say that too: "No existing test suite — verified by running the script against sample input." Honest verification is more useful than vague confidence.
Include when you made a deliberate choice between reasonable alternatives. Skip for straightforward changes where there was one obvious path.
If the change breaks existing behavior, state what breaks and how to migrate. Use the ! suffix in the header too: feat(api)!: restructure response format
Match message depth to change significance. A dependency bump doesn't need a Tradeoffs section. A major architectural change deserves every section plus maybe an ADR. Use judgment.
git commit -m "<header>" -m "<body>"
For longer messages, prefer writing to a temp file:
cat > /tmp/commit-msg.txt << 'EOF'
<full message>
EOF
git commit -F /tmp/commit-msg.txt
Before committing:
npx claudepluginhub thurstonsand/ansiblonomicon --plugin project-managementGenerates clear, conventional commit messages from git diffs. Useful when writing commit messages, reviewing staged changes, or preparing commits.
Generates descriptive commit messages following conventional commits format by analyzing git diffs. Useful when writing commit messages or reviewing staged changes.
Generates conventional git commit messages by analyzing staged changes, categorizing types like feat/fix, adding scopes, and matching project history style.