Most bad commits from an agent aren't wrong code. They're leftover debug prints, a half-renamed variable, or a test that got skipped "for now". A one-file custom slash command catches most of that before it lands.
The command
Create .claude/commands/review.md in your repo:
---
description: Review the staged diff before committing
allowed-tools: Bash(git diff:*), Bash(git status:*)
---
Run `git diff --staged` and review only what changed.
Report, in this order:
1. Leftover debug output, commented-out code, or TODOs added in this diff.
2. Renames or signature changes that weren't applied everywhere.
3. Tests that were skipped, deleted, or weakened.
4. Anything that touches secrets, auth, or config files.
Do not edit files. End with "OK to commit" or a short list of what to fix.
Now /review in a session runs it. Because allowed-tools only lists read-only git commands, the review can't quietly "fix" things behind your back.
Why it works
- Scoped input. It only looks at the staged diff, so the answer stays short and specific.
- Fixed checklist. The same four questions every time beats "does this look good?".
-
No edits. You decide what to change, and the agent re-runs
/reviewafter.
Make it a habit
Commit the .claude/commands/ folder so the whole team gets the same command. Pair it with a Stop hook that reminds you to run /review when a session ends with uncommitted changes.
I ship this command alongside a Bash allow-list, .env deny rules, safety hooks, and a short CLAUDE.md in Vildanden Agent Config. The free sample is enough to try the pattern today.
Top comments (2)
Been running a similar self-review loop for a few months and the four questions are spot on. One thing I learned the hard way: the review is only as good as what you actually show it. I started running
git diff --statmyself first — catches when I’ve accidentally staged a massive refactor mixed with the real change, which the agent then misses because it’s too much context.The read-only git restriction matters more than it looks. Without it, the agent “reviews” by rewriting files, which defeats the whole point.
Highest-value catch for me hasn’t been skipped tests — it’s been weakened assertions.
expect(true)orexpect(result).toBeDefined()where there used to be a real check. Those slip through CI but rot the suite.Committing the command to the repo is the right call. Whole team inherits the habit without anyone needing to set anything up.
staged diff만 읽고 수정은 하지 않도록 리뷰와 변경을 분리한 구성이 간결하네요. 고정 체크리스트에 테스트 약화와 인증·설정 변경을 포함한 점도 좋습니다. 다만 출력의 ‘OK to commit’이 전체 저장소나 실행 결과까지 보증하는 것으로 읽히지 않도록, 확인한 diff 범위와 실제 수행한 검증을 함께 표시하면 더 명확하겠습니다.