Commit messages

Skill shinzoxD/knackbox/skills/coding/commit-messages

Curated, auditable, benchmark-ready Agent Skills library for Claude Code, Codex, OpenCode, Cursor, and more.

Install

npx -y skills add shinzoxD/knackbox --skill commit-messages

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

29 days oldThe repository was created 29 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
0 stars0 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

Write clear, conventional git commit messages from diffs or descriptions of changes. Use whenever the user asks for a commit message, is about to commit changes, mentions "git commit", shares a diff or staged changes that need summarizing, or finishes a coding task that will be committed — even if they don't ask about message formatting.

The file declares its own license as Apache-2.0. 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.5 KB, 489 tokens by cl100k_base, as published. Nobody here has run it

Commit Messages

Produce commit messages in Conventional Commits style that explain why a change exists, not just what changed. A reader six months from now should understand the intent without opening the diff.

Format

<type>(<optional scope>): <summary in imperative mood, ≤50 chars>

<optional body: what and why, wrapped at 72 chars>

<optional footer: BREAKING CHANGE, issue refs>

Types: feat, fix, refactor, perf, docs, test, build, ci, chore.

Rules

Summary line uses the imperative mood: "add", not "added" or "adds". Test: the line should complete the sentence "If applied, this commit will ___".
Never end the summary with a period.
Choose the type by intent, not by files touched: a bug fix that adds a test is fix, not test.
Add a body only when the diff doesn't speak for itself — explain constraints, trade-offs, or the bug's root cause. Skip it for trivial changes.
Breaking changes get a ! after the type/scope and a BREAKING CHANGE: footer describing the migration.
One logical change per message. If the diff contains unrelated changes, say so and propose splitting it into separate commits.

Examples

Good:

fix(auth): prevent session fixation on login

Regenerate the session ID after successful authentication.
Previously the pre-login session ID was reused, allowing an
attacker who set a victim's cookie to hijack the session.

Closes #482

Bad (vague, past tense, wrong type):

chore: updated some auth stuff and fixed bugs.

Edge cases

No diff provided: ask for git diff --staged output or a short description of the change; don't invent specifics.
Huge mixed diff: summarize the dominant change as the commit, list the unrelated changes, and recommend separate commits for them.
User's repo has its own convention (visible from git log): match the existing convention instead of this one, and say you're doing so.

What ships with it: 1 file

1.8 KB alongside SKILL.md

benchmarks/

prompts.json1.8 KB