32 lines
1.8 KiB
Markdown
32 lines
1.8 KiB
Markdown
# 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:
|
|
|
|
1. **User-specified scope.** If the caller passed `BASE:`, `FILES:`, or `DIFF:` markers, use that scope exactly.
|
|
2. **Working copy changes.** If there are unstaged or staged changes (`git diff HEAD` is non-empty), review those.
|
|
3. **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.
|