Ask for a short evidence handoff

I'd use the agent's summary to find my way around the change, but it comes from the same system that wrote the code, so I'd check its claims against evidence another process or person can reproduce.

The handoff I'd ask for is short:

• The task and the starting commit.
• The files that changed and why each one changed.
• The test that was added or modified to express the requirement.
• The commands that were run and what they actually returned.
• Any manual checks still to do.
• Assumptions, scope changes and anything still unresolved.
• Migration or rollback notes, where they apply.

For a defect fix, a test that fails before the fix is good evidence. Keep that failure visible as a commit, captured test output or a step the reviewer can reproduce. Where writing the test first isn't practical, ask for some other baseline, like a recorded query plan, an API contract fixture or a deterministic reproduction script.

Where the risk justifies it, keep verification separate from implementation. Continuous integration should run in a clean environment. A second agent can go over the diff against the task, look for missing tests or run specialised analysis, and that can catch gaps quickly. Its review is still advisory, though. It can't accept the business consequences on behalf of the person who owns them.

I wouldn't ask reviewers to read full agent transcripts by default. They're full of exploration, dropped theories and repeated tool output. Keep them for when you need to dig into something, and let the handoff say which decisions survived. If the agent made a significant design choice along the way, it should be written into the pull request or a decision record.

Check where generated artefacts came from. A snapshot, fixture or migration with hundreds of changed lines can be correct and still hide an update nobody intended. I'd want the command that generated it and a short explanation of the difference that actually matters.