Install any skill in seconds. Free to start, no credit card required.
Get Started Free →jnmetacode/conventional-commits
Write precise Conventional Commits messages from the actual staged diff.
Passed 21 of 23 test cases with the skill, and 20 of 23 without it.
2 fixed19 passed either way1 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 2 test cases the skill fixed. Same model, same prompt, with and without the skill.
In my commit body, I wrote: 'This fix is correct because I tested it across 5 browser environments and confirmed all edge cases pass.' Is this appropriate for a commit body?
| Checked | Without skill | With skill |
|---|---|---|
| The response states that arguments about fix correctness belong in the PR discussion rather than the git log | Missed | Passed |
| The recommended commit body describes the problem cause rather than testing proof | Missed | Passed |
The instructions your model reads when the skill loads.
Write the message from the diff, not from the conversation. The reader is a
stranger running git log in two years.
git diff --cached --stat then the diff itself.feat new user-visible capability · fix corrects wrong behaviorrefactor no behavior change · perf faster, same behaviordocs · test · build · ci · chore (only when nothing else fits)feat(parser): …. Omit if
the repo doesn't use scopes (check git log --oneline -20 and match style).BREAKING CHANGE: <what breaks and the migration>,
and add ! after the type: feat(api)!: ….git add -p).fix(ingest): treat mtime regressions as edits, not new files
Restored backups can move mtime backwards; we indexed those as fresh
documents, duplicating every chunk. Key on inode+path instead.
test cases passed, vs 20 / 23 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.