TL;DR
Don’t paste a long audit into a coding agent and hope. Compress it to a 1-page brief (title, scope, top 3 findings, severity counts), extract 3-5 concrete action items with a mini-spec each, feed the brief plus action items, and verify every PR against the original finding. The bottleneck is never the agent’s context window — even Cursor’s truncated ~100K usable tokens swallow a 42-page PDF. The bottleneck is that a wall of findings gives the model no priority signal, so it picks the easiest item and reports “general improvements.”
Why dumping the whole report backfires
A long report is mostly observations, not commands. When you paste 18 findings into one prompt, the agent has no way to know which three matter, so it optimizes for the cheapest plausible edit. You get a PR that touches six files, fixes one minor lint warning from page 31, and leaves the N+1 query from page 4 untouched. Technically it “addressed the report.” Practically it wasted a review cycle.
This is not a token-limit problem. As of June 2026, the agents people actually use have room to spare:
| Agent | Default model | Context window | Usable after overhead |
|---|---|---|---|
| Claude Code | Opus 4.7 / Sonnet 4.6 | 1M tokens (GA, no beta flag) | ~830K (compacts near 83.5%) |
| Codex CLI | GPT-5.5 | 400K tokens | ~330-360K |
| Cursor (Agent) | Sonnet 4.6 / GPT-5.5 / Gemini 3.1 Pro | 200K advertised | ~70-120K after truncation |
| Aider | bring-your-own model | model-dependent | model-dependent |
A typical 20-page PDF is roughly 10,000-15,000 tokens, so a 42-page audit fits in any of these. The agent can read the whole thing. What it can’t do is triage it. That’s your job, and this pattern is how you do it fast.
Who this is for
Developers running coding agents (Claude Code, Codex, Cursor Agent, Aider) on real projects: post-audit cleanup, dependency-upgrade reports, accessibility audits, performance reviews, security findings. It’s most valuable when the report came from a different tool than the one fixing it — a Lighthouse run, an LLM audit, or a human consultant — so the findings aren’t already in the agent’s working memory.
Skip this if the report is already under one page and tightly scoped, or if it’s mostly narrative with no action items. In the latter case, rewrite it as a checklist first; loose prose does not survive contact with any agent.
The pattern, step by step
1. Compress the report to a 1-page brief
Not a rewrite — a brief. It contains exactly four things:
- The audit title and date.
- The scope (what was reviewed).
- The top 3 findings, in plain language.
- A count of total findings by severity (e.g., “3 critical, 7 major, 8 minor”).
If you can’t fit it on one page, the audit is too broad to act on in one pass — split it by area.
2. Extract 3-5 action items
Pull out the findings the agent can actually do something about and drop the rest into a follow-up.md file. Five concrete actions beat fifteen vague ones. You are triaging; the agent is executing. Never hand the model the full list and let it choose — it will choose by effort, not by impact.
3. Write a mini-spec for each action
The mini-spec is the unit of work the agent reads. Same shape every time:
Action 1: Replace deprecated request.json() with await request.json()
- Files: src/api/*.ts
- Source finding: report section 3.2
- Acceptance: existing tests pass, no console warningsThe acceptance line is the part people skip and the part that decides whether the PR is reviewable. Without it the agent has no definition of done and will declare victory early.
4. Feed the brief plus action items — not the full report
Give the agent the 1-page brief and the mini-specs. Reference the full report only for a specific action that needs the surrounding context (a flagged code block, a stack trace). Most items execute from the mini-spec alone.
For a genuinely huge report on Claude Code, delegate the read to a subagent so the raw findings stay in its context window and your main session keeps a clean working set. Watch the /context command — it breaks usage down by system prompt, tools, memory files, and conversation history, so you can see exactly when the report is crowding out the code.
5. One atomic PR per action
Have the agent open one PR per action item, or one PR with one commit per item. Atomic PRs review faster and revert cleanly. A single mega-PR for the whole audit is the second-most-common way this goes wrong, right after dumping the report.
6. Verify each PR against its original finding
Close the loop. Read the original finding, then read the PR: did the action address that finding, or a near-miss next to it? Run the full test suite, not just the touched files — performance and security audits routinely surface findings with no existing test, so ask the agent to propose one.
Worked example: a 42-page performance audit
Report: “Performance review of the checkout flow,” 42 pages, 18 findings.
Brief:
Performance audit, May 2026
Scope: /checkout/*
Severity: 2 critical, 6 major, 10 minor
Top 3:
1. Unnecessary re-renders in CheckoutForm (critical)
2. N+1 query in cart.ts (critical)
3. Missing image lazy-loading in OrderSummary (major)Action items: just the top 3, each with a mini-spec naming files, acceptance criteria, and report section number. Result: three small PRs, each verifiable against one finding. The remaining 15 findings stay in follow-up.md for the next sprint. Track your hit rate — if fewer than 70% of the findings you specced reach a PR, the briefs are too aggressive and you’re losing context the agent needed.
Common mistakes
- Dumping the entire report into one prompt. The agent reads it, gets no priority signal, and produces “general improvements.”
- Findings without action items. A finding is an observation; an action item is a command. Translate before you send.
- Skipping severity ranking. The agent picks the easiest item, which is rarely the one that matters.
- Letting the agent triage. You decide what gets fixed; the agent decides how.
- One mega-PR for the whole audit. It reviews slowly and reverts badly.
- No mini-spec acceptance criteria. Without a definition of done, the agent stops at the first plausible edit.
- Forgetting the follow-up file. Findings you don’t ship today evaporate unless they land in
follow-up.mdbefore you merge.
FAQ
- What if the report is a PDF or slide deck?: All four agents accept PDFs directly, and a 20-page PDF is only ~10-15K tokens, so size is not the issue. Still convert to plain text or Markdown when you can — the compress-and-extract steps are far easier to do on text you can grep.
- Should the agent that ran the audit also do the fixes?: It can. Claude Code can audit and fix in one session, which is fast. For higher-stakes work, separate the auditor and the fixer so the verification step is genuinely independent.
- Can I just rely on the 1M-token window and paste everything?: You can paste it — the window holds it. But context size doesn’t create priority. The brief exists to give the model a triage signal it can’t infer from a flat list, and it doubles as a sanity check on the audit itself.
- What if a finding turns out to be wrong?: Verify findings before you act. The brief step is your filter — writing the top 3 in plain language is where a bogus finding usually falls apart.
- How big should the brief be?: One page, hard cap. If it won’t fit, the audit’s scope is too wide to act on in a single pass; split it by area and run the pattern per slice.
Related
For the underlying mechanics of how Claude manages its context window during long sessions, see Anthropic’s Claude Code context docs.
Tags: #AI coding #Tutorial