Name: commit-message
Author: JohnMarvin237

Imported from JohnMarvin237/claude-code-toolkit (skills/SKILL.md). Install upstream with npx skills add JohnMarvin237/claude-code-toolkit --skill skills. Copyright stays with the author.

Commit message

Generate a Conventional Commits-compliant message from the ACTUAL git diff, not from memory.

Core principle

The message describes what the diff contains — nothing more, nothing less. If the diff shows a bug fix, the message is fix:, even if the conversation was about a feature. Read the diff first.

Execution

Run git diff --staged to see what's staged.
If nothing is staged, run git diff to see unstaged changes and ask the user whether to stage them first (suggest git add -p for selective staging).
Classify the change type using the table in references/types.md.
Identify the scope — the module, feature, or area most affected (lowercase, single word or hyphenated).
Write the subject line: type(scope): imperative-mood summary under 72 chars.
Decide if a body is warranted (see "When to add a body" below).
Propose the message to the user; do not run git commit until they confirm.

Subject line rules

Imperative mood: "add", "fix", "remove" — not "added" / "adds" / "adding"
Lowercase after the colon, no period at the end
Under 72 characters (hard limit at 100)
One scope only; if the change crosses scopes, consider splitting the commit

When to add a body

Add a body (blank line after subject, then wrap at 72 chars) only if any of these apply:

The change is non-obvious from the diff (explain the "why")
There's a breaking change (use BREAKING CHANGE: footer)
The change fixes an issue (use Closes #123 footer)
The change references an ADR (use ADR: docs/adr/NNNN-slug.md footer)

For trivial changes (typo fix, dependency bump, formatting), the subject line alone is sufficient.

Type selection

See references/types.md for the full table. The most common:

feat: new user-facing capability
fix: bug correction
refactor: code restructuring without behavior change
perf: performance improvement
test: adding or fixing tests
docs: documentation only
chore: tooling, deps, CI, build config
revert: reverting a prior commit

Special cases

Schema/migration changes: type is feat or fix depending on intent, scope is db or the entity name. Add migration name in body.
Security fixes: type is fix, scope is security. Keep the subject vague if the bug is undisclosed; put detail in a private issue.
Breaking changes: add ! after scope (feat(api)!: ...) AND include BREAKING CHANGE: footer with migration instructions.

Presenting the result

Format:

Proposed commit message:

<type>(<scope>): <subject>

<body if any>

<footers if any>

Run: git commit -m "<subject>" [-m "<body>"]

Ask: "Commit with this message? Any adjustments?"

What NOT to do

Do not invent changes that aren't in the diff.
Do not write WIP messages in production branches (if current branch looks like main/master/develop, flag it).
Do not run git commit without the user's confirmation.
Do not use --amend or --force flags without explicit instruction from the user.
Do not write sign-offs like "Generated by Claude" — the git author metadata suffices.

References

references/types.md — full type table with examples
references/examples.md — before/after examples of good vs bad messages

{ "ocm": "1", "id": "johnmarvin237-claude-code-toolkit-skills", "kind": "skill", "name": "commit-message", "description": "Use this skill when the user asks to \"write a commit message\", \"commit these changes\", \"stage and commit\", \"what should the commit say\", or after any substantive code change where a commit is the logical next step. Generates Conventional Commits-compliant messages from the actual staged diff — never from Claude's memory of what changed.", "publisher": "JohnMarvin237", "version": "1.0.0", "capabilities": { "domains": [ "coding", "data_analysis" ], "tags": [ "skill-md", "github" ], "languages": [ "en" ] }, "quality_prior": 0.6, "examples": [ "Use this skill when the user asks to \"write a commit message\", \"commit these changes\", \"stage and commit\", \"what should the commit say\", or after any substantive code change where a commit is the logical next step. Generates Conventional Commits-compliant messages from the actual staged diff — never from Claude's memory of what changed." ], "primary": false, "metadata": { "source": { "provider": "github", "repository": "https://github.com/JohnMarvin237/claude-code-toolkit", "path": "skills/SKILL.md", "ref": "d3845b052a8db03f7c5700bf7ee2dd8c5e9069be", "url": "https://github.com/JohnMarvin237/claude-code-toolkit/blob/d3845b052a8db03f7c5700bf7ee2dd8c5e9069be/skills/SKILL.md", "key": "JohnMarvin237/claude-code-toolkit/skills/SKILL.md" } }, "instructions": "# Commit message\n\nGenerate a Conventional Commits-compliant message from the ACTUAL git diff, not from memory.\n\n## Core principle\n\nThe message describes what the diff contains — nothing more, nothing less. If the diff shows a bug fix, the message is `fix:`, even if the conversation was about a feature. Read the diff first.\n\n## Execution\n\n1. Run `git diff --staged` to see what's staged.\n2. If nothing is staged, run `git diff` to see unstaged changes and ask the user whether to stage them first (suggest `git add -p` for selective staging).\n3. Classify the change type using the table in `referenc", "cost": { "context_tokens": 820 } }

commit-message

About