Lightweight diff review

Lightweight Diff Review

Use this skill when the user asks for an independent review of recent code changes but does not request a repository-wide, security, or architecture audit.

Operating contract

This workflow is read-only by default.

Do not:

• modify code or configuration;
• install, update, or remove dependencies;
• run pip install, pip install -e ., uv sync, npm install, or environment rebuilds;
• fetch remotes or access the network unless the user explicitly asks;
• create worklogs, commits, branches, pull requests, or review comments;
• launch subagents, specialist reviewers, red teams, or automatic-fix loops;
• scan the whole repository merely for completeness.

Review only the requested change. Expand context only when a specific unresolved question requires it.

Default budget

Unless the user explicitly requests broader review, use these limits:

• no more than 8 changed source files;
• no more than 1,200 changed lines;
• no more than one direct caller or callee layer outside the diff;
• no more than one targeted test, check, or command after static review;
• do not repeat a read or test when the code and environment have not changed.

If the change exceeds these limits, review the highest-risk portion first, summarize current coverage, and ask before performing a broader audit.

Workflow

1. Establish the review target

Prefer an explicit file, commit, branch, pull request, or user-selected range.

For an ordinary local working-tree review, inspect only:

git status --short
git diff --stat
git diff --no-ext-diff

If staged changes are relevant, also inspect:

git diff --cached --stat
git diff --cached --no-ext-diff

Do not run git fetch. Do not infer a remote base branch unless the user requested branch or pull-request review.

If there is no relevant diff, report that and stop.

2. Read the diff before surrounding files

Read the complete relevant diff within the budget. Identify concrete questions before opening other files.

Examples of justified expansion:

• a changed function's contract is unclear;
• a public interface may have an unmodified caller;
• a new enum or status value may be consumed elsewhere;
• a schema or configuration key must be verified;
• a test assertion needs its implementation context.

Open only the closest code needed to answer that question. Do not perform open-ended repository exploration.

3. Review in risk order

Check only categories relevant to the diff.

Correctness and behavioral regression

• Does the implementation match the apparent requested behavior?
• Are boundary conditions, error paths, defaults, and return values correct?
• Can a changed branch silently alter existing behavior?
• Are resources and state cleaned up on failure?

Interface and data consistency

• Do signatures, callers, consumers, serialized fields, configuration keys, and schemas agree?
• When a value, enum, status, or option is added, do direct consumers handle it?
• Are types normalized at process, JSON, database, or UI boundaries?

Security and destructive behavior

Only when relevant, inspect for:

• command, SQL, template, path, or code injection;
• unsafe handling of credentials or untrusted external or LLM output;
• missing authorization or validation;
• unsafe overwrite, deletion, migration, or persistence behavior;
• race-prone read-check-write sequences.

Async, concurrency, and performance

Only when relevant, inspect for:

• blocking operations inside async code;
• missing await, cancellation, timeout, or synchronization handling;
• obvious N+1 queries or newly introduced unbounded work;
• repeated expensive work inside loops or render paths.

Tests and maintainability

• Do existing changed tests actually verify the intended behavior?
• Is an important negative or boundary path untested?
• Is code unreachable, contradictory, or unnecessarily complex?
• Ignore harmless style preferences and speculative edge cases unsupported by the actual input domain.

Do not manufacture findings to make the review appear thorough.

4. Run minimal validation

Static review comes first.

Run at most one existing check that is closest to the change, such as one test file, one test selector, a syntax check, type check on the changed target, or a small dry run.

Use concise output. Do not run the full test suite unless the user explicitly requests it or the diff clearly changes shared global behavior.

If validation requires missing dependencies or environment changes, report environment-limited and stop. Do not install anything.

5. Stop when evidence is sufficient

Stop reviewing when:

• the relevant diff has been examined;
• concrete questions have been resolved within one direct dependency layer;
• one proportionate validation has been completed or shown to be unavailable;
• further exploration would only add completeness rather than change the conclusion.

Finding standard

Report an item only when all are available:

1. a concrete location;
2. a plausible execution path or affected behavior;
3. the consequence;
4. a proportionate correction or next check.

Classify findings as:

• CONFIRMED: directly demonstrated by code, diff, or executed validation;
• HIGH-PROBABILITY: strongly supported but not executed end to end;
• NEEDS-CONTEXT: cannot be decided within the allowed scope;
• OPTIONAL: non-blocking maintainability improvement.

Do not present low-confidence speculation as a defect.

Output format

List actionable findings first, ordered by impact.

Lightweight Diff Review: <N> actionable finding(s)

[CONFIRMED | HIGH-PROBABILITY] <severity> — <file:line>
Problem: <specific defect and triggering path>
Impact: <observable consequence>
Recommendation: <minimal correction or verification>

Validation:
- <command or static-only review result>

Coverage:
- Reviewed: <diff/files/context>
- Not reviewed: <explicit exclusions>

If no substantive issue is found, say:

Lightweight Diff Review: No substantive issues found.

Then state the validation performed and the exact coverage limits. Do not add generic praise, lengthy process narration, or invented concerns.

Escalation

Recommend broader review only when the diff demonstrates a concrete reason, such as public API changes, data migration, authentication, concurrency, shared infrastructure, or a change too large for the default budget.

Explain what additional scope is needed and why. Wait for the user's approval before expanding.