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.

```text
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