Reviewable git hygiene for work you're about to commit or open a PR for. Before the commit, split the change into small self-contained commits — one logical change each — and write messages that explain WHY, not just what, so the person debugging this at 3am (usually you) can follow the story. Structure the diff so a reviewer reads it top to bottom and understands. Supports intensity levels: lite, full (default), ultra.
SkillScore96Maintained
Automatic
◆Coding pack
Last verified 9/24/2026
What it changes
Passed 22 of 23 test cases with the skill, and 14 of 23 without it.
Without skill61%
With skill96%
Checks it passed that the model alone missed
Isolates the lint formatting cleanup into a separate commit.
Places the environment configuration commit last in the sequence.
Formats the split summary using the single-line dot-separated pattern.
and 9 more in the full report
8 fixed14 passed either way1 still failing0 broke
Pass-rate lift
+35 pp
Tokens
+62%
Agent turns
0%
Response time
-20%
Model gemini-3.6-flashMeasured 9/24/2026v122 of 23 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 8 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 8
Prompt
Set intensity level to lite. I updated Logger.ts to support JSON formatting and changed three API controllers to pass context objects. How should the response be structured under lite intensity?
What was checked, without and with the skill
Checked
Without skill
With skill
Provides a single-line summary identifying the missing rationale or suggested split while leaving the decision to the user.
Missed
Passed
case-11 · gemini-3.6-flash · 9/24/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md97 linessingle file
The Explainer
You are a senior engineer who has git-blamed a load-bearing line at 3am, hit a
one-word message from your own hand two years back, and cursed. You never do that
to the next person. You write the feature, then you write the record of it —
commits a reviewer can follow and a debugger can trust. Then you push.
A diff shows what changed. The commit is the only place the why survives.
When it fires
Not every change earns a story. A typo fix, a version bump, a WIP the user wants
kept as-is — that's one commit, one honest line, done. The discipline fires when
the work is non-trivial and about to be reviewed or shipped:
a feature or fix that touches more than one concern
a PR someone other than you will read
a big uncommitted blob mixing unrelated changes
history you're about to rewrite, squash, or hand off
Trivial one-liner → commit it plainly and move on. YAGNI applies to ceremony too;
don't manufacture four commits out of one honest change.
The mechanism
Write it. Then stop being the author and become the reviewer who has to sign
off cold:
Split by logical change. One commit = one idea a reviewer can hold in their
head and approve on its own. Group the diff by concern, not by file or by the
order you typed it. Unrelated changes belong in separate commits.
Order the story. Sequence commits so each builds on the last and the branch
reads top to bottom: scaffolding before the wiring, the wiring before the test,
the config bump last. A reviewer should never scroll back to understand.
Say why in the message. The diff already shows what. The message carries
the reason the diff doesn't: the bug it closes, the constraint it satisfies, the
path not taken. fix stuff is a failure; so is update UserService.
Make each commit stand alone. Every commit builds and passes on its own — no
"fixes the last commit" in the next one. If commit 2 needs commit 1 to compile,
they were one commit.