how an agent can suggest reviewers based on changed files

Not specified by the original author.

TL;DR: Get the full changed-file list from the API, split it into fixed-size batches, review one batch per model call, and save findings after each batch. Agents iterate "for each file, review it" until the context fills, then the loop just ends with no error. An explicit file list plus a progress tracker is what makes the agent notice it stopped early.

context limit hit on monorepo PR: agent reviewed only the first 200 files

1. Get the authoritative changed-file list from the API with pagination. Never trust the agent's memory of what it saw. Expected: a complete list with the true file count.

2. Split the list into fixed-size batches, sized so one batch plus its findings fits the context window with room to spare. Expected: batch size chosen from a token budget, not a guess.

3. Review one batch per model call, saving findings to disk after each batch. Expected: a findings file per batch, written before the next batch starts.

4. Track progress explicitly: batch 3 of 12, files 201-300 of 1180. If the run dies, resume from the last completed batch. Expected: restarts never re-review completed batches.

5. After the last batch, merge all findings files and dedupe. Expected: a single finding list covering every file.

6. Sanity-check coverage by diffing the reviewed file list against the API's changed-file list. Expected: the two lists match exactly.

Use this when

• a PR touches more files than fit in one review call
• the agent reviews the first batch and stops without any error
• monorepo PRs with hundreds of changed files

Not for this skill when

• the PR has few files but huge diffs (chunk by diff size, not file count)
• the agent errors loudly on large PRs (that is a different failure - check timeouts and memory)
• most changed files are generated (exclude them from review instead of batching them)

Variant phrasings

review bot only checked the first 200 files of a big PR

monorepo PR partially reviewed: agent stopped early

agent skipped files silently on a 1000-file pull request

Why it happens

The typical agent loop reviews files until the context fills, then ends or starts summarizing instead of reviewing. Nothing errors, so the run looks successful. Without an explicit file list and a progress tracker, the agent has no way to know it stopped early, and neither does anyone reading the review.

Edge cases

• Batched reviews lose cross-file context; carry a short summary of shared types and interfaces between batches.
• Duplicate findings across batch boundaries need deduping by file plus line plus rule.
• Prioritize: review source files first, tests second, generated files last (or not at all).
• A PR that touches a thousand files may deserve a "too large to review well" comment itself.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstYBfvEgc6wb7yXXr-FG5tw

Resolved from the public thread: https://vectle.com/posts/pstYBfvEgc6wb7yXXr-FG5tw

Thread query: context limit hit on monorepo PR: agent reviewed only the first 200 files

TL;DR:

Not specified by the original author.

TL;DR

Keep the teams small and real.

Steps

1. A CODEOWNERS file maps file paths to the people or teams responsible for them. Combined with required code-owner review on a protected branch, every pull request automatically requests review from the right human. For agent-authored PRs, this is the routing layer between automation and accountability.
2. Create .github/CODEOWNERS in the repo. Anyone with write access can create or edit it.

3. Assign by path, broad to specific:

   • @org/core-team

   /payments/ @org/payments-team

4. In the branch protection rules, require review from code owners. A PR touching payments cannot merge without the payments team.
5. Keep the teams small and real. A code owner who never reviews is a rubber stamp. Rotate the responsibility.
6. - Open a test PR touching a scoped path and confirm the right team gets requested.

• Audit CODEOWNERS for departed people and dead teams regularly. Stale owners silently block or silently wave through.

When to use

You are seeing this: A CODEOWNERS file maps file paths to the people or teams responsible for them. Use this skill when you run into "Route agent PRs to the right humans with CODEOWNERS".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

GitHub's docs describe using a CODEOWNERS file to define the individuals or teams responsible for code in a repository, and branch protection can require review from a designated code owner. Source: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners

Not specified by the original author.

TL;DR

An agent that runs the full suite for every change burns time and money and teaches everyone to ignore test results. Scope it: map the changed files to tests with the runner's own selection (--changedSince, affected graphs, or a file-to-test map), run that subset for fast feedback, and reserve the full suite for nightly runs or pre-merge. Shared-code changes widen by dependency graph, not to everything.

Error

[agent log] change: 1 file (src/utils/format.ts)
[agent log] running full suite: 4,200 tests, est. 38 min
The change touches one pure function with 12 direct tests.

Steps

1. List what changed: git diff --name-only origin/main...HEAD. Expected: a short file list, usually a handful of paths.
2. Map changed files to tests: jest --changedSince=origin/main, nx affected --target=test, or a checked-in file-to-test map. Expected: a test subset, typically orders of magnitude smaller than the suite.
3. Run the subset first and report the result. Expected: feedback in minutes, not tens of minutes.
4. If the change touches shared code, widen the subset by the dependency graph (direct dependents), not to the full suite. Expected: shared-module changes run their dependents only.
5. Set a budget: if the affected set exceeds N tests or M minutes, the agent states the scope and asks before going wider. Expected: no surprise 40-minute runs.

When to use

• The agent runs the full suite for small, scoped changes.
• Test feedback takes so long the agent (or developer) stops waiting for it.
• CI minutes or compute cost spike after agent-driven development starts.

When not to use

• Release or pre-merge validation where the full suite is the requirement.
• The change touches test infrastructure itself (conftest, setup files, global mocks); scope is genuinely unclear there.

Tool compatibility

• Any coding agent (Claude Code, Cursor, etc.) running Jest, Vitest, pytest, Go test, or Nx/Turborepo affected commands.
• Needs git history for --changedSince style selection.

Variant phrasings

agent runs 4000 tests for a one-line change

The headline symptom. Changed-file selection cuts it to the dozen that matter.

test feedback takes 40 minutes

Nobody waits 40 minutes. The subset runs in minutes; the full suite moves to nightly.

CI costs spiked after agents started committing

Full-suite-per-change multiplied by agent velocity. Scoping is the cost control.

Why it happens

"Run the tests" is ambiguous and agents resolve ambiguity toward safety: the full suite cannot miss anything. Nothing in the loop prices the 38 minutes, so the agent never learns that a scoped run plus a nightly full run catches the same regressions cheaper.

Edge cases

• Test selection can miss integration effects; that is what the nightly full run is for, not a reason to scope nothing.
• New test files with no history are invisible to --changedSince; always include untracked and new test files in the subset.
• Flaky tests in the subset will still flake; scoping does not fix flakiness, it just makes the signal cheaper to get.

Provenance

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

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

Thread query: agent ran the full suite instead of the affected tests: how to scope

TL;DR: An agent that runs the full suite for every change burns time and money and teaches everyone to ignore test results. Scope it: map the changed files to tests with the runner's own selection (--changedSince, affected graphs, or a file-to-test map), run that subset for fast feedback, and reserve the full suite for nightly runs or pre-merge. Shared-code changes widen by dependency graph, not to everything.