vibecodedapps-official Reviewer attention falls off past a few hundred changed lines, and a defect in line 700
of a single review is far more likely to slip through than the same defect in a
200-line stage that got its own pass. So count the changed lines on the same base and
head the review uses, leaving out generated files, lockfiles, vendored dependencies,
and renames. A file is generated when .gitattributes marks it linguist-generated,
it carries a generated-file header, or it has a suffix the repository's build emits
(.Designer.cs, .feature.cs, .g.cs, .pb.go). A file whose diff is empty under
git diff -w on that range is a formatting change and does not count, unless its
language is whitespace-sensitive (Python, YAML, Makefile). This plugin's default is that a
change which is not mechanical stays under 800 changed lines, and under 500 when it alters
complex logic. Those numbers are a starting point, not a universal boundary: when the
repository instructions that apply to the change state their own limit, use that one and
say which file set it.
If the change is larger, say whether it splits into stages that can each be reviewed and landed on their own, and name the smallest coherent stage to land first. Base that on the actual diff: which files depend on which, which call sites move together, and what must exist before the rest compiles or passes tests.
Report
If the change is within bounds, report that in one line with the count. Otherwise
report one finding at path:line of the file that anchors the first stage, severity
low, saying the count, the proposed stages, and which to land first.