Before every commit you want the same disciplined review: correctness, security, compatibility, missing tests, unrelated changes. But doing it by hand each time means doing it differently and easily skipping it under deadline pressure. Discipline that rests on a person's memory eventually sags at exactly the moment it matters most. And a skip costs more the later it is found: a defect missed at review rides into the commit history, and getting it back out is a separate change of its own.
The naive move is to ask the agent in free form: "review my changes before I commit". It works once, but each next time is different: the review's boundaries drift, the checklist in your head changes, and the reviewing agent may well start editing along the way. A review with no fixed form is not a procedure but a mood.
It breaks on two things. A free-form review has no fixed checklist, so it is now thorough, now shallow. And it has no guarantee that the agent will not touch files: a reviewer that can write is no longer a reviewer. It can quietly "fix" what it flagged, and you lose the main value - an independent second look at an unchanged diff.
The solution is to package the review as a skill with trimmed permissions. In the frontmatter the skill is named precommit-review, its allowed-tools are limited to reading (read, grep, glob, exec), and its permissions allow only Exec(git diff) and Exec(git status) while explicitly denying edit and Write(**). triggers: user makes it a deliberate command rather than an automatically firing rule. Each field here carries meaning: allowed-tools outlines what the skill touches at all, permissions what of that is allowed without questions, and the user trigger guarantees that you start the review, not it on its own at an unexpected moment.
The body of the skill describes the review itself in words: read AGENTS.md and the staged diff; check correctness, security, compatibility, missing tests and unrelated changes; do not modify files; return findings by severity with a file:line reference, then residual risks and verification commands. This is a finished procedure with one clear output - a report, not an edit. The order of output is not accidental either: first findings by severity, so the important is on top, then residual risks the review does not close, and at the end the commands by which the result can be re-checked by hand.
The whole skill looks like this - and it is worth reading as a single piece: the frontmatter sets the boundaries, the body sets the work.
Why the restrictions matter more than the words. Tool restrictions make the intent verifiable, not merely stated. The phrase "do not change files" in the body is a wish; a deny on edit and Write(**) is enforcement: the skill physically cannot touch the working tree, so its verdict can be trusted as an independent look. The difference is exactly the one between a rule and a permission: the first asks, the second leaves no choice. And it is exactly this that makes the verdict valuable: a review that can change nothing is honestly separated from the code, so its findings are a look from the outside, not a side effect of its own edits.
Installation is simple. Put the file at .devin/skills/precommit-review/SKILL.md, commit it - so the skill appears for the whole team - and invoke /precommit-review before you form a commit. The optional focus argument narrows the pass to a specific area when you need a targeted look. Keeping the skill in the repository matters not only for convenience: this way the whole team has the same checklist, and the review stops depending on who exactly runs it today and in what mood.
The skill itself should be verified in a different way than it was written: run it on a diff into which a known defect was planted in advance. The skill should surface it in the findings by severity with file:line - and change nothing in the process. After the run, confirm the working tree is untouched: git status is clean as far as the skill's edits go. If the skill edited anything at all, the permissions are set wrong, and the "review" was in fact an intervention.
The typical failures are predictable. The review skill is given write tools and allowed to "fix" as it goes - and the independence of the look is lost. The file is not committed - and teammates simply do not have the skill. The findings are taken for completion without running the very verification commands the skill returned - and the review is closed on a word. The most vivid sign: the reviewer's own diff appears in your commit. Keep the reviewer strictly read-only, ship it in the repository, and bring its findings to a verified result yourself. And let the review stay what it was set up for - an independent check, not another author of edits in your commit.
---
name: precommit-review
description: Проверяет staged diff перед commit
argument-hint: "[focus]"
allowed-tools:
- read
- grep
- glob
- exec
permissions:
allow:
- Exec(git diff)
- Exec(git status)
deny:
- edit
- Write(**)
triggers:
- user
---
Прочитай AGENTS.md и staged diff.
Проверь correctness, security, compatibility,
missing tests и unrelated changes.
Не изменяй файлы.
Верни findings по severity с file:line,
затем residual risks и команды проверки.