diff-review

Reviews git diffs against four principles before commit or merge.

2|Updated Jun 1, 2026
One-click install
npx skills add https://github.com/FluxonLab/Skillry --skill diff-review-fluxonlab
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: diff-review
Source: https://github.com/FluxonLab/Skillry/tree/main/plugins/core-operations/skills/07-diff-review
Command: npx skills add https://github.com/FluxonLab/Skillry --skill diff-review-fluxonlab

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? AI-assisted code changes often ship with unstated assumptions, needless complexity, sprawling scope, and no verification. This Skill inspects a concrete git diff before commit or merge and returns a short, actionable verdict instead of a style lecture. ## Core Features & Use Cases - Four-Principle Review: Surfaces hidden assumptions, flags over-engineering, checks that every hunk is required by the task, and demands a verifiable goal such as a test or observable output. - Regression Scope Analysis: Traces import fan-out, maps changed files to existing tests, flags schema and migration risks, and produces a three-tier minimum verification suite via the absorbed regression-scope-analysis reference. - Clear Verdict Output: Reports blast radius (files, hunks, net lines), per-principle findings with file:line, and a keep / keep with nits / fix first verdict with numbered blocking fixes. - Use Case: Before opening a PR for an AI-generated feature, run the review on git diff --staged to catch a smuggled refactor, a missing test for new behavior, and an unvalidated nullability assumption. ## Quick Start Ask the AI to review my staged diff with the diff-review skill and give me a keep or fix-first verdict before I commit.

Frequently Asked Questions about diff-review

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review a git diff before committing?▼

Run git diff --staged to inspect the actual staged change, then check assumptions, simplicity, surgical scope, and verification. The skill returns a blast radius summary, per-principle findings with file:line, and a keep or fix-first verdict.

How to identify which tests are impacted by a code change?▼

Get the diff from the correct base with git diff main...HEAD --name-only, categorize files by architectural layer, and trace import fan-out with rg or grep. Map each changed file to co-located, integration, and E2E tests to build a mandatory verification tier.

When should I not use a diff review check?▼

Skip it for deep security review, which needs a dedicated security skill, and for architecture-level decisions spanning many files. It also does not apply when there is no concrete diff yet, since it reviews changes rather than ideas.

Does diff review modify my code or commits?▼

No, the review is strictly read-only. It never amends, commits, resets, or rewrites history, and it does not run formatters or git add automatically; it only suggests fixes for the author to apply.

Why is file count a poor measure of regression risk?▼

Three changed files in shared middleware can affect the entire application, while thirty files in isolated feature modules affect almost nothing. Blast radius depends on import fan-out and cross-cutting concerns like auth or error handling, not raw file counts.