About review-local-changes
review-local-changes is a code-review skill for examining all worktree changes, including commits, staged and unstaged edits, and untracked files. It uses parallel specialist reviews, verifies their findings, fixes valid in-scope issues, and reports the outcome.
Key features
- 01Reviews the complete local change set
- 02Runs three specialist reviews in parallel
- 03Verifies findings against current code
- 04Fixes valid in-scope findings
- 05Reports reviews and outcomes
Use cases
- 01Checking changes before opening a pull request
- 02Finding bugs and complexity in uncommitted work
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ falcondev-oss/ skills --skill review-local-changesAfter installing, type/review-local-changesin Claude Code to confirm it loaded.
Details
From the project READMEReview Local Changes
Review the local changes and report to the user. Completion is the report.
The local changes are everything in the working tree that the default branch lacks: commits since the merge-base with the default branch, plus staged, unstaged, and untracked files. Review them all, whichever session made them.
1. Review cold
Dispatch $code-review, $simplicity-review and $bug-review in parallel as subagents, each handed the diff of the local changes and nothing else.
One cold round. Treat findings as hypotheses:
- Verify each finding against the diff and current code.
- Fix every valid, in-scope finding.
- Record false positives and out-of-scope findings, leaving the change as it stands.
- Re-run the checks your fixes touched, and re-review the fixes alone.
2. Report to the user
Open with a simple explanation of the problem the local changes solve, then briefly explain the solution. Do not lead with an implementation inventory:
BAD
❌ Removed implicit workspace carry-over from every "new thread" entry point (cmd+n / cmd+shift+o, sidebar v1/v2 buttons, command palette). New threads inherit only the project from context; branch, worktree, and env mode always come from the configured defaults. Delete buildContextualThreadOptions, startNewThreadInProjectFromContext, and the v1 sidebar's seed-context machinery.
GOOD
✅ My "new worktree" default was ignored when starting new threads on existing worktrees. Super unintuitive. Now your preferences always apply.
Use the applicable sections from this structure in this exact order. Replace every placeholder and omit sections that have no content:
## 📝 Summary
<Explain the problem, then the solution in plain language. This should be short, concise, and human-readable.>
## 📦 Changes
- <Name user visible and main area changes>
## ✅ Verification
- `<command>`: <result>
## 🔍 Reviews
| Review | Found | Fixed |
| -------- | ------- | ------- |
| <review> | <count> | <count> |
<Tell the user what you changed during the review loop>
- <Every finding with its verdict: fixed, false positive, or out of scope, and why.>
## ⚠️ Needs attention
<List follow-up work, known limitations, or other issues that need the user's attention.>
List every review that ran, including reviews that found nothing. Never claim a check or review ran unless it did.