Commit message
Skill bjg4/bgskillz/bakeoff/live/v4/commit-message/commit-message
Build high-quality, portable Claude skills that trigger reliably and deliver real value.
npx -y skills add bjg4/bgskillz --skill commit-messageAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Assists developers with writing high-quality commit messages for version control. Use when committing changes, summarizing staged diffs, or preparing changelog entries. Supports conventional commits and descriptive subject lines.
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
2.1 KB, as published. Nobody here has run it
Commit Message Skill
Purpose
Good commit messages document what changed and why. Future readers (including future you) rely on history to understand decisions. This skill guides message writing so commits are searchable and meaningful.
Use Cases
- A developer wants to commit staged changes and needs a clear message.
- A team uses conventional commits and wants consistent formatting.
- Someone needs to summarize a complex diff in a readable subject and body.
Why Conventional Commits Help
Standard prefixes (feat, fix, docs, etc.) make history scannable and enable automated tooling. They are not mandatory for every repo but are a strong default when the team adopts them.
Guidelines
Write in imperative mood ("Add feature" not "Added feature") because each commit is a instruction to the repository: "if applied, this commit will..."
Keep the subject line concise — many teams aim for 50–72 characters. Add a body when the why is not obvious from the subject.
Reference issue trackers when the team uses them (e.g., Fixes #123).
Conventional Commit Types
| Type | Purpose |
|---|---|
| feat | New user-facing capability |
| fix | Bug fix |
| docs | Documentation only |
| refactor | Code change without behavior change |
| test | Tests only |
| chore | Maintenance, deps, tooling |
Process
- Read the diff or change summary the user provides.
- Identify the primary intent (feature, fix, docs, etc.).
- Draft subject line; add body if needed.
- Confirm format matches team conventions if known.
Error Handling
If no diff or summary is provided, ask for git diff --staged or a short description of changes.
Examples
Subject: feat(auth): add JWT login endpoint
Subject: fix(api): handle null user in profile lookup
Weak: update stuff — too vague for history search.