Skill: Review Diff
Purpose
Review the current change alone (git diff: staged + unstaged + optionally untracked files) across 5 dimensions: intent / impact, regression / correctness, breaking change / compatibility, side effects / idempotency, observability. Produce a scope-only findings list that feeds the scope step of orchestrate-code-review for aggregation.
No architecture / security / language / framework-specific analysis — those belong to the matching atomic skills.
Core Objective
Primary goal: produce a findings list across the 5 dimensions for the diff scope alone (untracked files included).
Success criteria (all of them must hold):
- ✅ Diff scope only: review the change set alone; do not open repository-level / architecture / security / language-specific checks
- ✅ All 5 dimensions covered: intent / impact, regression / correctness, breaking change / compatibility, side effects / idempotency, observability
- ✅ Format conformant: every finding carries location / category=
scope / severity / title / description / suggestion, per specs/findings-list.md
- ✅ Precise locations: every finding cites a concrete
file:line or @@ hunk
- ✅ Bug fix verified: a bug-fix diff must have its fix verified for correctness, with any leftover or partial problem flagged
Scope Boundaries
This skill owns:
- The current git diff (staged + unstaged)
- Untracked files in the change set (included by default, treated as a whole-file add)
- Analysis across 5 dimensions: intent / impact, regression / correctness, breaking / compatibility, side effects / idempotency, observability
This skill does not own:
- Repository-level or snapshot-level review →
review-codebase
- The full orchestrated review →
orchestrate-code-review
- The architecture / security / performance / testing cognitive dimensions → the matching cognitive atomic skills
- Language- / framework-specific conventions → the matching atomic skills
Handoff point: once the findings are out, they feed the scope step of orchestrate-code-review for aggregation, or go to orchestrate-repair-loop for a fix iteration.
Use Cases
- pre-commit / pre-PR gate: a quick look at what the change introduces before committing
- As the scope step of orchestrate-code-review: this one or
review-codebase, never both
- Focused review: the user says "look at the change only"
Behavior
Scope resolution
- What gets analyzed: the files in the change set — the diff (staged + unstaged) plus the untracked files included by default
- Untracked file handling: the caller passes the path and the full content; treat it as a whole-file add, apply the same 5-dimension checklist, and cite file:line
- What does not get analyzed: files that are unchanged or outside the change set
The 5-dimension checklist
For each changed file, produce findings on these dimensions:
- Intent and impact: what changed and why; the effect on callers / data / configuration / deployment
- Regression and correctness: whether a new bug or a missed edge case was introduced; whether a bug-fix diff fixes the whole thing
- Breaking change and compatibility: whether an API / data / configuration contract breaks; backward compatibility; versioning / deprecation
- Side effects and idempotency: unintended side effects, data corruption, risk on repeated execution, idempotency problems
- Observability: whether the change adds or repairs the logs, metrics and error messages needed to debug in production
Special cases
- A bug-fix diff: verify the fix is correct, and record any leftover or partial problem
- A formatting- / comment-only diff: emit one minor finding, "formatting / comments only, no behavior change"; where a comment contradicts the code, emit a finding with a suggestion
Input and Output
Input
- git diff: the staged + unstaged changes of the current branch against HEAD
- Untracked files (included by default): path + full content
Output
- Findings list: the standard format (
location / category=scope / severity / title / description / suggestion)
- Every finding must carry a file:line or @@ hunk reference
- Every finding must carry an actionable suggestion (the direction of the fix + the exact location)
Restrictions
Hard boundaries
- Do not review files outside the diff
- Emit no finding that lacks a file:line reference
- Use no vague language ("might be a problem", carrying neither a type nor a direction → delete it)
- Run no security / architecture / language / framework check (stay inside the scope dimension)
Skill boundaries
Not done here (other atomic skills own it):
- Repository-level / snapshot-level review →
review-codebase
- Full-dimension orchestration →
orchestrate-code-review
- Security →
review-security
- Architecture →
review-architecture
- Language / framework → the matching atomic skills
Self-Check
Examples
Example 1: an API change
- Input: a diff that adds a query parameter and reshapes the response
- Expected: findings covering intent / impact (on callers), backward-compatibility risk, and a breaking-change suggestion (versioning or deprecation, say); citing the exact lines or @@ hunks; no security / architecture finding (those go to the matching atomic skills)
Example 2: a bug fix
- Input: a diff that fixes a null pointer and an error code
- Expected: findings confirming the fix, plus a check of whether similar null pointer / error code problems remain; the observability dimension (logs / errors); citing the changed lines; category=scope
Example 3: formatting / comments only
- Input: a diff carrying only indentation / whitespace / comment changes
- Expected: either no finding, or one minor finding, "formatting / comments only, no behavior change"; where a comment contradicts the code, emit a finding with a suggestion
Example 4: a new (untracked) file in the change set
- Input: the diff plus an untracked file (path + full content)
- Expected: the new file is reviewed as a whole-file add; the 5-dimension checklist applies; location=the path with line references; category=scope
1---2name: review-diff3description: Review only git diff for impact, regression, correctness, compatibility, and side effects. Scope-only atomic skill; output is a findings list for aggregation.4license: MIT5---67# Skill: Review Diff89## Purpose1011Review the **current change** alone (git diff: staged + unstaged + optionally untracked files) across 5 dimensions: intent / impact, regression / correctness, breaking change / compatibility, side effects / idempotency, observability. Produce a scope-only findings list that feeds the scope step of `orchestrate-code-review` for aggregation.1213No architecture / security / language / framework-specific analysis — those belong to the matching atomic skills.1415---1617## Core Objective1819**Primary goal**: produce a findings list across the 5 dimensions for the diff scope alone (untracked files included).2021**Success criteria** (all of them must hold):22231. ✅ **Diff scope only**: review the change set alone; do not open repository-level / architecture / security / language-specific checks242. ✅ **All 5 dimensions covered**: intent / impact, regression / correctness, breaking change / compatibility, side effects / idempotency, observability253. ✅ **Format conformant**: every finding carries location / category=`scope` / severity / title / description / suggestion, per [specs/findings-list.md](../../specs/findings-list.md)264. ✅ **Precise locations**: every finding cites a concrete `file:line` or `@@` hunk275. ✅ **Bug fix verified**: a bug-fix diff must have its fix verified for correctness, with any leftover or partial problem flagged2829---3031## Scope Boundaries3233**This skill owns**:3435- The current git diff (staged + unstaged)36- Untracked files in the change set (included by default, treated as a whole-file add)37- Analysis across 5 dimensions: intent / impact, regression / correctness, breaking / compatibility, side effects / idempotency, observability3839**This skill does not own**:4041- Repository-level or snapshot-level review → `review-codebase`42- The full orchestrated review → `orchestrate-code-review`43- The architecture / security / performance / testing cognitive dimensions → the matching cognitive atomic skills44- Language- / framework-specific conventions → the matching atomic skills4546**Handoff point**: once the findings are out, they feed the scope step of orchestrate-code-review for aggregation, or go to `orchestrate-repair-loop` for a fix iteration.4748---4950## Use Cases5152- **pre-commit / pre-PR gate**: a quick look at what the change introduces before committing53- **As the scope step of orchestrate-code-review**: this one or `review-codebase`, never both54- **Focused review**: the user says "look at the change only"5556---5758## Behavior5960### Scope resolution6162- **What gets analyzed**: the files in the change set — the diff (staged + unstaged) plus the untracked files included by default63- **Untracked file handling**: the caller passes the path and the full content; treat it as a whole-file add, apply the same 5-dimension checklist, and cite file:line64- **What does not get analyzed**: files that are unchanged or outside the change set6566### The 5-dimension checklist6768For each changed file, produce findings on these dimensions:69701. **Intent and impact**: what changed and why; the effect on callers / data / configuration / deployment712. **Regression and correctness**: whether a new bug or a missed edge case was introduced; whether a bug-fix diff fixes the whole thing723. **Breaking change and compatibility**: whether an API / data / configuration contract breaks; backward compatibility; versioning / deprecation734. **Side effects and idempotency**: unintended side effects, data corruption, risk on repeated execution, idempotency problems745. **Observability**: whether the change adds or repairs the logs, metrics and error messages needed to debug in production7576### Special cases7778- **A bug-fix diff**: verify the fix is correct, and record any leftover or partial problem79- **A formatting- / comment-only diff**: emit one minor finding, "formatting / comments only, no behavior change"; where a comment contradicts the code, emit a finding with a suggestion8081---8283## Input and Output8485### Input8687- **git diff**: the staged + unstaged changes of the current branch against HEAD88- **Untracked files** (included by default): path + full content8990### Output9192- **Findings list**: the standard format (`location` / `category=scope` / `severity` / `title` / `description` / `suggestion`)93- Every finding must carry a file:line or @@ hunk reference94- Every finding must carry an actionable suggestion (the direction of the fix + the exact location)9596---9798## Restrictions99100### Hard boundaries101102- Do not review files outside the diff103- Emit no finding that lacks a file:line reference104- Use no vague language ("might be a problem", carrying neither a type nor a direction → delete it)105- Run no security / architecture / language / framework check (stay inside the scope dimension)106107### Skill boundaries108109**Not done here** (other atomic skills own it):110111- Repository-level / snapshot-level review → `review-codebase`112- Full-dimension orchestration → `orchestrate-code-review`113- Security → `review-security`114- Architecture → `review-architecture`115- Language / framework → the matching atomic skills116117---118119## Self-Check120121- [ ] Only the change set was reviewed (the diff plus the untracked files included)122- [ ] All 5 dimensions are covered123- [ ] Every finding conforms to the format (all 6 fields)124- [ ] Every finding carries a file:line or @@ hunk reference125- [ ] Every finding carries an actionable suggestion126- [ ] The fix in a bug-fix diff was verified for correctness127128---129130## Examples131132### Example 1: an API change133134- **Input**: a diff that adds a query parameter and reshapes the response135- **Expected**: findings covering intent / impact (on callers), backward-compatibility risk, and a breaking-change suggestion (versioning or deprecation, say); citing the exact lines or @@ hunks; no security / architecture finding (those go to the matching atomic skills)136137### Example 2: a bug fix138139- **Input**: a diff that fixes a null pointer and an error code140- **Expected**: findings confirming the fix, plus a check of whether similar null pointer / error code problems remain; the observability dimension (logs / errors); citing the changed lines; category=scope141142### Example 3: formatting / comments only143144- **Input**: a diff carrying only indentation / whitespace / comment changes145- **Expected**: either no finding, or one minor finding, "formatting / comments only, no behavior change"; where a comment contradicts the code, emit a finding with a suggestion146147### Example 4: a new (untracked) file in the change set148149- **Input**: the diff plus an untracked file (path + full content)150- **Expected**: the new file is reviewed as a whole-file add; the 5-dimension checklist applies; location=the path with line references; category=scope