| name | local-review |
| description | Act as a senior engineer and review all uncommitted changes in the local git branch — both staged and unstaged, including new untracked files — before they get committed. Use this skill whenever the user wants pre-commit feedback on work in progress — phrases like "review my changes", "review my diff", "code review before I commit", "look over what I changed", "is this ready to commit?", "check my local changes", or asking for feedback on the correctness, security, performance, tests, or style of uncommitted work. Pairs with the create-commit skill: review first, commit after. Produces feedback anchored to file paths and line numbers plus a 0–10 score and an APPROVE / REQUEST_CHANGES style recommendation.
|
Local Review
Review all uncommitted changes in the local git branch — staged, unstaged, and
new untracked files — as a senior engineer would, before they become a commit. The
value of a pre-commit review is that problems are cheapest to fix now — while
nothing is in history yet and the author still has full context. So the goal isn't
to run a generic checklist; it's to judge these changes against how this codebase
actually works and catch the things that would bite later.
0. Same-session by default
Run this review in the current session. It is the pre-commit gate, so it fires
often — frequently once per commit across a longer piece of work — on diffs that
are usually small and freshly written. Dispatching each of those to a subagent
pays the context rebuild every time (the reviewer must re-read conventions,
neighbouring code, and the diff from nothing) for changes the session can already
see, and it slows the tight loop where fast feedback is the point.
Reach for a subagent when the change is big enough to be worth cold eyes —
many files, unfamiliar territory, a change the session has been deep inside for a
long time, or when the user asks for maximum independence. A fresh context reads
the diff without the authoring session's assumptions, and the session that wrote
the code "knows what it meant", which is exactly what a reviewer must not assume.
The dispatch is read-only and single-shot: it may run read-only inspection
commands (diffs, file reads) but changes no files.
When you do dispatch, the subagent gets this skill, not a vague ask: include
these instructions (or point at this file) and the exact diff scope in the
dispatch prompt, and require the report to meet the output contract below —
findings anchored to file paths and line numbers, a 0–10 score, and a
recommendation. A bare "review my changes" dispatch produces a generic review and
silently degrades the gate.
Blocked by policy is not the same as unavailable. Some sessions permit
subagents but instruct that they only be used when the user asks. When this
review warrants cold eyes and that restriction applies, surface the decision
rather than quietly taking the weaker path: say the review would be stronger run
with fresh eyes, ask whether to dispatch one, and wait for the answer. If they
agree, dispatch exactly as this section describes; if they decline, review
same-session — a weakened gate the user chose is fine; one they never heard
about is not.
1. Gather all local changes
Work from the real changes, not an assumption about what changed. You want the full
picture of uncommitted work, regardless of whether it's been git add-ed yet.
- See everything at a glance first:
git --no-pager status --short lists staged,
unstaged, and untracked files together so you know the full scope.
- Tracked changes (staged + unstaged):
git --no-pager diff HEAD shows every
modification to already-tracked files relative to the last commit. (If you need to
distinguish them, git --no-pager diff --staged is the staged set and
git --no-pager diff is the unstaged set.)
- New untracked files: these don't appear in any diff — identify them from
git status and read them in full with the file tools, since the whole file is new.
- In Cursor, the
@diff context is a convenience view, but confirm it covers the
changes you intend to review (it may only show the staged set); prefer the git
commands above when in doubt.
- Unset the pager first. Git's pager can hang a non-interactive shell and, worse,
make git interpret pager tokens as filenames. Either run
unset PAGER once or use
git --no-pager … on each call.
- If there are no changes at all, stop. Report that the working tree is clean and
ask what to review — don't fall back to reviewing already-committed history, since
the user asked about what they're about to commit.
2. Understand the change in context
A diff on its own is easy to misjudge. Before forming opinions, read enough of the
surrounding code to know what "good" looks like here:
AGENTS.md, README.md, and anything under /docs for project rules and intent.- The files being changed in full (not just the diff hunks) and their close neighbours,
to see the patterns, naming, and error-handling style already in use.
- Library behaviour when a change hinges on an external API — pull current docs via
the context7 MCP rather than guessing at signatures or defaults.
3. What to look for
Evaluate each changed file across these lenses, roughly in priority order — a
correctness or security defect matters far more than a style nit:
- Correctness & edge cases — does it do what it intends, including empty/null,
boundary, and error paths?
- Security — untrusted input, injection, secrets, authz gaps, unsafe defaults.
- Error handling — failures surfaced and handled, not swallowed or left to crash.
- Performance — needless work, N+1s, or hot-path allocations that will matter at scale.
- Tests — is the new behaviour covered, and does it follow the repo's testing conventions?
- Consistency — does it match the architecture, patterns, and style already present?
- Readability & maintainability — will the next person understand it without archaeology?
4. Give actionable feedback
For every issue, make it easy to act on:
- Anchor it to the file path and line number(s) from the diff.
- Explain why it's a problem and what the impact is — not just that it's "wrong".
- Give a concrete fix or example, not a vague direction.
- Point to an existing pattern in the codebase the change should follow, when one exists.
Separate blocking issues (must fix before commit) from nits (optional polish) so
the user knows what actually gates the commit. If the change is clean, say so plainly
rather than inventing problems.
5. Score and recommendation
Close with a single score out of 10 and the matching recommendation:
| Score | Recommendation |
|---|
| 9–10 | APPROVE |
| 7–8 | APPROVE WITH MINOR SUGGESTIONS |
| 5–6 | REQUEST_CHANGES |
| 3–4 | MAJOR_CHANGES_NEEDED |
| 1–2 | REJECT |
Then state clearly whether these changes should be committed, tying the verdict to the
specific findings above (correctness, security, tests, and alignment with project
standards) rather than a general impression. When the verdict is APPROVE, it's natural to
stage anything still unstaged and hand off to the create-commit skill next.
