Stop asking Claude Code to "review my code". Give it a process instead.

"Review my code" is a weak prompt. You get a list. Some items are real. Some sound real. A few are wrong in a way that costs you 20 minutes to check.

The model is not the problem. The process is. A human senior reviewer does not just read the diff and talk. They check who calls the changed method. They try to prove their own finding wrong before they post it. They ask "did anyone run this?"

So I wrote those steps down as Claude Code skills, and published them as ShipKit: 24 skills and 2 git hooks, MIT licensed, any stack.

This post shows four of them, what each one forces Claude to do, and how to install them in two commands.

Install

Inside Claude Code:

/plugin marketplace add parvez-ahammed/shipkit
/plugin install shipkit@shipkit

For most skills you do not need to remember any command. Ask in plain words, and Claude loads the skill whose description matches. Three long or personal ones (deliver-issue, show-usage, fill-timesheet) run only when you type their command, so they cost nothing until you need them. You can also run any skill directly, for example /shipkit:review-branch.

Want only one skill? Each one is a self-contained folder. Copy plugins/shipkit/skills/<name> into ~/.claude/skills/.

1. fix-bug: no fix before the root cause

The usual agent loop for a bug is: read the error, guess, patch, done. It often works. When it does not, you get a fix for the symptom and the bug comes back next week.

fix-bug blocks that shortcut. The order is fixed:

1. Reproduce the bug.
2. Find the root cause and write it down as one testable sentence, with the file and line.
3. Prove it. "This line could cause it" is not proof.
4. Fix the cause, not the symptom, with the smallest change.
5. Add a regression test that fails without the fix and passes with it.
6. Re-verify, and look for the same bug next door.

Step 5 is the one people skip. A test that passes before and after your fix tests nothing.

What you type:

this endpoint returns 500 since yesterday, fix it

2. review-branch: findings that survive a refutation pass

review-branch runs your branch past six reviewer seats: backend, frontend, architecture, tests, QA and text. A seventh seat checks the licence of any new dependency.

Then the part that matters: every finding goes through a refutation pass. A separate check tries to prove the finding wrong. Is the "missing null check" handled by the caller? Is the "unused method" called from a file the diff did not touch? Findings that do not survive are dropped.

You get one ranked punch list and an HTML report. Optional comment mode posts the findings to GitHub, GitLab or Azure DevOps, but only after it re-checks each one and you say yes.

review my branch before I open the PR

The rule behind it: a reviewer who posts five real findings is worth more than one who posts twenty and makes you check all of them.

3. test-branch: run the app, not the diff

"The code path does X" and "I ran it and saw X" are two different claims. The first one is an argument. The second one is evidence.

test-branch starts from the running app. It seeds the data the change needs, predicts the result with a query, drives the API and the browser, and writes an HTML report with screenshots that a product owner can read. It compares the base branch with your branch, and it lists only what is still open.

test this branch against the running app and give me a report for the PO

4. grill-feature: is the promise real?

Your landing page says "users can export everything". Can they? Including archived items? With more than 10,000 rows?

grill-feature takes a promise and checks it in the code. The answer is one of three:

• BULLETPROOF: the promise holds in the code, with the file and line.
• CRACKED: it works, but here is the real gap or risk.
• FAKE: the code does not deliver it: a stub, a mock or a no-op.

is checkout really bulletproof?

The rest of the kit

Area	Skills
Review and fix	review-branch, fix-bug, build-story, test-branch, grill-feature
Plan and deliver	groom-issue, deliver-issue, price-product
QA and UX	audit-app, find-ux-gaps
Refactor	refactor, enforce-clean-architecture, find-shared-code, simplify-code, trim-comments
Ship and operate	deploy-to-vps (with honest health checks), add-mcp-server, boost-seo
Create and document	make-video, make-demo, write-user-guide, write-plainly
Insight	show-usage, fill-timesheet

Plus two git hooks: secret-hygiene blocks a commit that adds a secret, and safe-commit checks commit messages.

Three rules every skill follows

Evidence or nothing. Findings cite a file and line. If a skill could not see it, the report says UNKNOWN. It does not guess.

Ask before anything leaves your machine. Posting a PR comment, filing a ticket, pushing a branch, attaching a file: the skill shows you what it will send and waits.

Any stack, any OS. No framework lock-in. Where a script needs a shell, there is a bash and a PowerShell version.

One thing I learned while building it

ShipKit had 30 skills. I tested every skill against a plain agent with no skill. Six of them found nothing the plain agent missed, so I folded them into other skills. Later I folded a seventh.

The skills that passed all had the same shape: they do not teach the model facts. They force the steps it skips.

Before the release I applied the same rule to every skill: no sentence said twice, and detail needed at one step moved to a file that is read only at that step.

Try it

/plugin marketplace add parvez-ahammed/shipkit
/plugin install shipkit@shipkit

• Repo: github.com/parvez-ahammed/shipkit
• Website: parvez-ahammed.github.io/shipkit
• Every skill: plugins/shipkit/skills

If it saves you time, a star on GitHub helps other developers find it.

Which step does your agent skip most often? Tell me in the comments. If it is a common one, it is probably the next skill.