context overflow on generated lockfile diffs broke the review agent

TL;DR: Exclude lockfiles and generated files from the review input entirely, and feed the model a compact summary instead (packages added, removed, version-bumped). Lockfile diffs are huge, repetitive, and low-signal per token. The review-relevant facts compress to a few dozen lines, but only if something does the compressing before the model sees the diff.

context overflow on generated lockfile diffs broke the review agent

1. Identify generated files in the diff by path: lockfiles, minified bundles, generated protobuf or schema outputs, vendored code. Expected: a filtered list of files the model should not read raw.

2. Remove those files from the review input entirely. Expected: token usage drops dramatically.

3. Summarize what changed in each excluded file with a diff stat: packages added, removed, and version-bumped, with old and new versions. Expected: a compact summary of tens of lines instead of tens of thousands.

4. Feed only the summary to the model and ask it to flag suspicious changes: new dependencies from unknown publishers, major version jumps, packages with known advisories. Expected: the review still catches risky dependency changes.

5. For lockfiles, cross-check the summary against the manifest diff (package.json) so the two agree. Expected: every lockfile change traces back to a manifest change, or it gets flagged.

6. Document the exclusion in the posted review so humans know generated files were summarized, not skipped. Expected: the review notes which files were summarized.

Use this when

• lockfile or generated-file diffs dominate the PR
• the agent truncates or produces empty reviews on dependency-update PRs
• the token budget is being spent on machine-generated text

Not for this skill when

• the lockfile change is the subject of the review (read it with proper tooling, not the model)
• the diff is small overall (no budget problem to solve)
• the generated files are hand-edited (treat them as source)

Variant phrasings

package-lock.json diff ate the whole context window

review agent choked on a yarn.lock diff

generated files crowding real code out of the review

Why it happens

Lockfiles and generated code are enormous and almost entirely repetitive. A model reading them raw burns the budget on thousands of near-identical lines before it ever reaches the real code. Dependency-update PRs are the classic case: the entire meaningful change is "bumped X from 1.2 to 1.3", buried in 20,000 lines of resolved URLs and hashes.

Edge cases

• A malicious dependency can hide in a lockfile-only change; the summary must include publisher and version, not just the name.
• Some repos check in generated code that humans do review (migrations, schema snapshots); exclude by path pattern, not by instinct.
• Different lockfile formats need different summarizers; make sure yours handles each format in the repo.
• If the manifest and the lockfile disagree, that disagreement itself is the finding.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_EsKMwPiU74wBxDUv7jZpZA