A packet works because it changes what the reviewer does first. Given a 900-line diff and a confident description, the opening task is reconstruction: infer the intent, then read every hunk to find the three that matter [1][5]. Given a packet, the opening task is routing: read the risk rating and the "human review focus" line, then open those files [3][9]. The guide's claim is not that review gets skipped, it is that the search step moves off the reviewer's desk [9].
The weak joint is section 2. It asks for files changed, APIs and routes changed, schema changes, background jobs and queues, and permissions, billing or tenant logic touched [4]. All of that is derivable from the diff. The thing the diff cannot tell you appears in the guide's own diagnosis: the reviewer does not know which files the agent inspected before editing [5]. Files read but not modified are the evidence that the agent looked at the caller it was about to break, and no field asks for them [13]. An agent already has that list, because it is the read path of its tool log. In my context I would add the field and treat a packet without it as unfinished.
Section 3 is where a template turns into policy. The guide types it out: a ReviewRisk of low, medium or high, and a ChangeSignal carrying touchesAuth, touchesBilling, touchesTenantData, hasMigration, changesBackgroundJob, lacksTests and behindFeatureFlag [7]. Six of the seven name a hazard or a gap; one names a mitigation [12]. The supplied text breaks off inside the function signature, so the weights and thresholds are not in it [17]. That is the part you could not copy anyway. Deciding that a migration plus missing tests lands in the slow lane, while a feature flag pulls it back, is a statement about your rollback speed and your on-call rota.
Adoption cost lands on generation. The guide offers two routes: paste the sections into a PR template, or generate them from the coding agent [10]. Those are not equivalent. A human typing out edge cases and commands run is doing review work before review starts. The packet has to come out of the agent's transcript and then get spot-checked, because a fabricated packet is worse than none: it reads like evidence.
Treat the guide as a hypothesis rather than a result. It reports no review-time measurement and no defect data, and the only number in it is the illustrative 900 lines [14]. It also prints the long-tail keywords it is targeting, including "pull request evidence template" [11], which tells you what genre you are reading. The structure still earns a trial, because the field list is cheap to add and the failure it targets is specific: a polished diff whose design is wrong, with tests that cover the happy path and miss tenant, permission and latency behaviour [5]. Small team, one reviewer deep on billing, no slack in the rota: that is my context, and in it the routing information is worth the tooling. A team with three reviewers per service will price it differently.
