Commit

Skill KonH/ClaudeTools/plugins/k/skills/commit

Claude Code plugin with skills shared across project

Install

npx -y skills add KonH/ClaudeTools --skill commit

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

24 days oldThe repository was created 24 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.
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

Create a git commit for the staged changes, branching off the default branch first if needed

SKILL.md

1.6 KB, 352 tokens by cl100k_base, as published. Nobody here has run it

Create a git commit for the staged changes.

Pre-commit step: branch selection

Before committing, check the current branch:

git branch --show-current
Determine the repository's default branch (main or master — e.g. via git symbolic-ref --short refs/remotes/origin/HEAD, falling back to whichever of main/master exists locally).
If the current branch is the default branch: create and switch to a new branch via git checkout -b feature/<short-kebab-description>, where <short-kebab-description> is a meaningful slug derived from the change being committed (e.g. feature/province-division-config). Do this before staging/committing anything else.
If it is anything other than the default branch (i.e. already on a feature branch or other non-default branch): leave the branch as-is — do not create or switch branches.

Rules

Subject line: short, imperative, no period
Explain why, not what — the diff already shows what changed
No bullet-point summaries of changed files
Always add a Co-Authored-By trailer for the model in use, e.g. Co-Authored-By: Claude Fable 5 <[email protected]>
If a project-specific pre-commit step bumps a version number, only ever increment the minor/patch segment. The major (or milestone) segment is a human decision — never bump it automatically, and never let an overflowing minor segment roll over into it. If a project's version-bump instructions are ambiguous about this, stop and ask a human rather than guessing.

Gives 0 of the 12 instructions most pr commit review skills give in 352 tokens

Counted across 888 of the 1,342 authors here whose files we hold, read 2026-08-06

use conventional commits formatin 123 of 888, across 110 files
keep subject line under 72 charactersin 60 of 888, across 46 files
delete branches after mergein 50 of 888, across 37 files
use imperative mood in subject linein 50 of 888, across 41 files
use imperative mood in commit messagesin 45 of 888
generate a conventional commit messagein 42 of 888
make atomic commitsin 37 of 888, across 25 files
run tests before committingin 36 of 888, across 24 files
run project test suite to verify clean baselinein 35 of 888, across 7 files
run detected project setup commandsin 34 of 888, across 6 files
wrap commit body at 72 charactersin 32 of 888, across 25 files
split unrelated changes into separate commitsin 32 of 888, across 27 files

Said here and by no other author read

create a git commit for staged changes
determine the repository default branch
leave the branch as-is if already on a feature branch
increment only the minor or patch version segment
ask a human if version-bump instructions are ambiguous

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.