Review Local Changes
Run a structured, agent-assisted review of your uncommitted local diff before you commit or open a PR.
Overview
Review Local Changes is an agent skill most often used in Ship (also Build) that conducts a structured review of uncommitted local diffs with impact-filtered issues and code-improvement suggestions.
Install
npx skills add https://github.com/neolabhq/context-engineering-kit --skill review-local-changesWhat is this skill?
- Systematic review of uncommitted local changes with optional focus aspects (e.g. security, performance)
- Configurable minimum impact filter with five levels: critical, high, medium, medium-low, low (default high)
- Optional JSON output alongside markdown for tooling and CI hooks
- Skips spec/ and reports/ by default unless you explicitly ask to include them
- Pairs with specialized review agents for improvement suggestions, not just defect listing
- Five minimum impact levels: critical, high, medium, medium-low, low
Adoption & trust: 538 installs on skills.sh; 1.1k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a pile of unstaged and staged edits and no consistent way to catch security, performance, or design problems before they land in git history.
Who is it for?
Solo builders batching commits who want agent-guided local diff review with severity filtering before push or PR.
Skip if: Teams that only review merged remote PRs, or repos where every change must include spec/ and reports/ folders in scope by default.
When should I use this skill?
You have local uncommitted changes and want a comprehensive structured review with optional aspects, --min-impact filtering, or --json output.
What do I get? / Deliverables
You get a prioritized, aspect-aware review of local changes with optional JSON export, ready to fix or commit with confidence.
- Markdown or JSON review report with impact-tiered issues and improvement suggestions
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Ship is where pre-commit quality gates live; local-change review is the canonical shelf before merge and release. Review subphase matches diff inspection, impact-tiered findings, and actionable fix suggestions on working-tree changes.
Where it fits
After implementing a UI slice, run a local review focused on accessibility and performance before staging files.
Before commit, scan the full working tree with default high minimum impact to catch regressions early.
Pass review-aspects security to prioritize auth and injection risks in uncommitted backend changes.
How it compares
Use for working-tree review before commit; use PR-focused review skills after you have pushed a branch.
Common Questions / FAQ
Who is review-local-changes for?
Indie and solo developers using Claude Code, Cursor, or Codex who commit from a local repo and want systematic feedback on diffs that are not yet on a remote PR.
When should I use review-local-changes?
During Ship before commit or during Build when finishing a feature slice; pass aspects like security or performance and tune --min-impact when you only want critical or high issues.
Is review-local-changes safe to install?
It reviews local files and may invoke review agents; check the Security Audits panel on this Prism page before enabling in sensitive repos and avoid pointing it at secrets in the diff.
SKILL.md
READMESKILL.md - Review Local Changes
# Local Changes Review Instructions You are an expert code reviewer conducting a thorough evaluation of local uncommitted changes. Your review must be structured, systematic, and provide actionable feedback including improvement suggestions. **User Input:** ```text $ARGUMENTS ``` **IMPORTANT**: Skip reviewing changes in `spec/` and `reports/` folders unless specifically asked. --- ## Command Arguments Parse the following arguments from `$ARGUMENTS`: ### Argument Definitions | Argument | Format | Default | Description | |----------|--------|---------|-------------| | `review-aspects` | Free text | None | Optional review aspects or focus areas for the review (e.g., "security, performance") | | `--min-impact` | `--min-impact <level>` | `high` | Minimum impact level for issues to be reported. Values: `critical`, `high`, `medium`, `medium-low`, `low` | | `--json` | Flag | `false` | Output results in JSON format instead of markdown | ### Flag Interaction When `--min-impact` and `--json` are used together, `--min-impact` filters which issues appear in the JSON output. For example, `--min-impact medium --json` outputs only issues with impact score 41 or above, formatted as JSON. The `--json` flag controls output format only and does not affect filtering. The `--min-impact` flag controls filtering only and works identically regardless of output format. ### Usage Examples ```bash # Review all local changes with default settings (min-impact: high, markdown output) /review-local-changes # Focus on security and performance, lower the threshold to medium /review-local-changes security, performance --min-impact medium # Critical-only issues in JSON for programmatic consumption /review-local-changes --min-impact critical --json ``` ### Impact Level Mapping | Level | Impact Score Range | |-------|-------------------| | `critical` | 81-100 | | `high` | 61-80 | | `medium` | 41-60 | | `medium-low` | 21-40 | | `low` | 0-20 | ### Configuration Resolution Parse `$ARGUMENTS` and resolve configuration as follows: ``` # Extract review aspects (free text, everything that is not a flag) REVIEW_ASPECTS = all non-flag text from $ARGUMENTS # Parse flags MIN_IMPACT = --min-impact || "high" JSON_OUTPUT = --json flag present (true/false) # Resolve minimum impact score from level name MIN_IMPACT_SCORE = lookup MIN_IMPACT in Impact Level Mapping: "critical" -> 81 "high" -> 61 "medium" -> 41 "medium-low" -> 21 "low" -> 0 ``` ## Review Workflow Run a comprehensive code review of local uncommitted changes using multiple specialized agents, each focusing on a different aspect of code quality. Follow these steps precisely: ### Phase 1: Preparation Run following commands in order: 1. **Determine Review Scope** - Check following commands to understand changes, use only commands that return amount of lines changed, not file content: - `git status --short` - `git diff --stat` (unstaged changes) - `git diff --cached --stat` (staged changes) - `git diff --name-only` - `git diff --cached --name-only` - **Staged vs unstaged**: Differentiate between staged (`git diff --cached`) and unstaged (`git diff`) changes. Review both by default. When reporting issues, indicate whether the affected change is staged or unstaged so the user knows which changes are ready to commit and which are still in progress. - Parse `$ARGUMENTS` per the Command Arguments section above to resolve `REVIEW_ASPECTS`, `MIN_IMPACT`, `MIN_IMPACT_SCORE`, and `JSON_OUTPUT` - If there are no changes, inform the user and exit 2. Launch up to 6 parallel Haiku agents to perform following tasks: - One agent to search and give you a list of file paths to (but not the conten