Diff Scope Rules

These rules apply to every reviewer. They define what is "your code to review" versus pre-existing context.

Scope Discovery

Determine the diff to review using this priority order:

User-specified scope. If the caller passed BASE:, FILES:, or DIFF: markers, use that scope exactly.
Working copy changes. If there are unstaged or staged changes (git diff HEAD is non-empty), review those.
Unpushed commits vs base branch. If the working copy is clean, review git diff $(git merge-base HEAD <base>)..HEAD where <base> is the default branch (main or master).

The scope step in the SKILL.md handles discovery and passes you the resolved diff. You do not need to run git commands yourself.

Finding Classification Tiers

Every finding you report falls into one of three tiers based on its relationship to the diff:

Primary (directly changed code)

Lines added or modified in the diff. This is your main focus. Report findings against these lines at full confidence.

Secondary (immediately surrounding code)

Unchanged code within the same function, method, or block as a changed line. If a change introduces a bug that's only visible by reading the surrounding context, report it -- but note that the issue exists in the interaction between new and existing code.

Pre-existing (unrelated to this diff)

Issues in unchanged code that the diff didn't touch and doesn't interact with. Mark these as "pre_existing": true in your output. They're reported separately and don't count toward the review verdict.

The rule: If you'd flag the same issue on an identical diff that didn't include the surrounding file, it's pre-existing. If the diff makes the issue newly relevant (e.g., a new caller hits an existing buggy function), it's secondary.