Prepare a Code-Change Review Packet for a Teammate
You finished an AI-assisted fix and sent your teammate a bare diff — so they skim and approve, or burn an hour reconstructing the context you had. Prepare a code-change review packet: the intent, the must-not-change behavior, the risks, and the tests you didn't run.
Build the Review-Packet PromptThe diff you dropped on a teammate with no context
You finished an AI-assisted fix, it works locally, and you send it for review the way most changes get sent: a diff and a message that says "can you review this?" Your teammate opens it to a wall of changed lines with no idea what problem it solves, which parts you're unsure about, what behavior was supposed to stay the same, or what you did and didn't test. So they do one of two things — skim it and approve ("looks fine"), or spend an hour reverse-engineering the intent from the code before they can even start reviewing. Either way the review is worse than it should be: the first misses the risk, the second burns your teammate's afternoon on context you already had and could have just handed over.
A PR description helps, but most PR descriptions are written to be merged, not reviewed — they say what the change does, not where it might be wrong. What a reviewer actually needs is a review packet: the problem, the intended behavior, the behavior that must not change, the areas you're worried about, the tests you ran and the ones you didn't, and the specific questions you want a second pair of eyes on. AI is good at drafting that packet from your diff and notes — but only if you ask for the risk-aware version, not a tidy summary. This guide is how to prepare a code-change review packet for a teammate: get AI to package the change so a human can review it well, without hiding the uncertainty or claiming the change is safe. NewPrompt's Markdown Output Builder is where you build a prompt that returns the packet in a fixed set of sections. The boundary: NewPrompt doesn't connect to your repo, read your diff, run your tests, open a PR, or approve anything — it helps you build the prompt; you give it the diff and the real test results, and the packet is a draft your reviewer checks against the actual change, not a verdict that it's safe.
Why "summarize this diff" produces a summary a reviewer can't use
Ask AI to "summarize this diff for review" and it gives you a summary — fluent, confident, and aimed at the wrong reader. A summary describes what the change does for someone who'll accept it; a review packet describes what the change risks for someone whose job is to find the problem. Told only to summarize, the model does the agreeable thing and smooths the change into a clean story, which is exactly what a reviewer doesn't need. Here is what a bare summary leaves out:
- The risk, sanded off. "Fixed the validation bug" reads as done; it hides that the fix touches a shared selector and might catch inputs it shouldn't.
- The behavioral contract. A summary says what changed; it rarely says what must not change — the behavior a reviewer should confirm still works.
- The assumptions. The AI made choices (this selector, this scope, this edge case) on assumptions it doesn't state, so the reviewer can't check the ones that might be wrong.
- What wasn't tested. A summary implies the change works; it won't tell you which cases were exercised and which are untried unless you make it — and the untried ones are where the bug is.
- The invented confidence. Asked to summarize, a model will happily write "this is safe" or imply tests passed, whether or not you ran any — a claim it has no basis for.
- The reviewer's questions. A summary ends; a packet ends with "here's what I specifically want you to check," which is the difference between a review and a rubber stamp.
Step 1: State the problem and the intended behavior — plainly
Start the packet with the two things the diff can't tell the reviewer on its own: what problem this change solves, and what the code is now supposed to do. Not "improved validation" — the actual problem ("a required-document field kept firing a validation error even when its whole section was hidden") and the actual intended behavior ("required-document validation should only apply when the section is visible"). This is the context that lets a reviewer read the diff as a solution to a stated problem instead of guessing what it was for. Give the AI the issue summary and your intent in your own words; its job is to state them cleanly in the packet, not to invent a rationale you didn't provide.
Keep the "why" honest and specific, because a vague reason produces a vague review. "To fix a bug" tells the reviewer nothing about what to verify; "so that hidden required sections don't block submission, while visible ones still do" tells them exactly the behavior boundary to test. The reason is also where scope lives: if the change was meant to fix one thing, say so, so a reviewer can flag anything in the diff that goes beyond it. A packet that states a narrow intent turns "is this whole diff fine?" into the far more answerable "does this diff do exactly this and nothing more?"
Step 2: Write the behavioral contract — what changed, and what must not
The most useful section of a review packet is the one most summaries skip: the behavior before and after, plus the behavior that must not change. Before/after gives the reviewer the delta in plain terms ("before: a hidden required document still triggered an error; after: it doesn't"). The must-not-change list is the safety rail — the behaviors that were working and have to keep working: a visible required document still errors when it's empty, non-file required inputs are still validated, the ordinary hidden fields that business rules do require aren't accidentally skipped. That list is what turns a review from "does the fix work?" into "does the fix work without breaking the four things next to it?" — which is where behavior-changing bugs actually hide.
This is the same structure the Pull Request Review Template captures — a review brief with fields for the change summary, the changed files, the review criteria, and the risk areas, so a reviewer works from articulated concerns instead of deciding what to look for on the fly. Its own boundary is the one this guide keeps: it's built to inform a human review, not to be an automated merge gate, and a human still owns the merge. It's a template you fill and run in your own AI tool; it captures the packet's fields, it doesn't review the code.
Step 3: Surface the risky areas instead of hiding them
A review packet earns its keep on the section a summary is most tempted to omit: where this change might be wrong. Ask the AI to list the risk areas explicitly — the parts of the change that are subtle, broad, or easy to get wrong, each with why it's risky. A shared selector that might match more than intended; a jQuery validation cache that could hold stale state; a file input handled differently from a text input; a hidden-by-class check that behaves differently from a hidden-by-CSS one. Naming these does two things: it points the reviewer straight at the parts worth their attention, and it forces you (and the AI) to actually think about where the change could bite, rather than presenting it as uniformly safe.
The rule that keeps this section honest is that risk is surfaced, not smoothed. Tell the AI, in the prompt, not to hide uncertainty and not to call anything "safe" without evidence — to mark what it's assuming and what it isn't sure about, and to separate what the diff definitely does from what it thinks it probably does. A packet that says "the selector scope is the riskiest part; I assumed .control-group is the only wrapper, which the reviewer should confirm" is worth ten that say "looks good." The point of the risk section isn't to make the change look careful; it's to make the actual soft spots visible before they reach production.
Step 4: Report the tests you ran — and the ones you didn't
Two lists, and the second matters more. Tests run: the cases you actually exercised, with their results — the hidden-required-document case, the visible-required-document-missing-a-file case, the ordinary required input. Tests not run: the cases you didn't get to, which is where a reviewer should look hardest — multiple document controls in one group, a group whose visibility is toggled after the validation cache is built, a browser you didn't try. The tests-not-run list is the single most valuable line in a packet, because it converts "I think this works" into "here's exactly what I haven't confirmed," and it invites the reviewer to cover the gap instead of assuming there isn't one.
This is where the boundary bites hardest: the AI must report only the test results you give it, and never invent that tests passed. NewPrompt doesn't run your tests, read a CI result, or execute your code — so if you didn't run something, the packet says "not run," and if you did, the packet reports what you observed, not what the model assumes. A packet that lists green tests you never ran is worse than no packet, because it manufactures a confidence the change hasn't earned. Give the AI your real results and your real gaps; its job is to organize them and make the gaps prominent, not to fill them in with optimism.
Step 5: Hand the reviewer focus areas and open questions
End the packet with two things aimed straight at the reviewer: the focus areas and your open questions. Focus areas are where you want their attention — semantic equivalence (does the rewrite return the same result?), edge cases, validation, security or privacy, performance, concurrency, migration or config effects, compatibility — narrowed to the ones this change actually touches, so the reviewer spends their time where the risk is, not reading uniformly. Open questions are the decisions you're genuinely unsure about and want a second opinion on: "should this use .closest() instead of a wider parent traversal?"; "does clearing the validation cache affect the file-uploader rules?" A packet that ends with real questions gets a real review, because it gives the reviewer something to answer instead of just something to approve.
Then the packet goes to a person, and that's the point. NewPrompt gives you the prompts and the structure to package the change well; verifying it against the actual diff and the real test output, catching the risks the AI missed, and deciding whether the change is safe to merge all happen on your side and your reviewer's. The AI can draft a thorough-looking packet and still miss the risk that matters — it's working from your description, not the running system — so the packet is a tool that makes a human review better and faster, not a substitute for one. Opening the PR, running CI, and merging are your team's; the review itself is a human's, and for anything high-stakes, a senior reviewer's. The packet's job is to make sure that reviewer starts with everything you already knew.
Common mistakes
The habits that turn a review into a rubber stamp:
- Sending a diff with no packet. A wall of changed lines with "can you review this?" makes the reviewer reconstruct the context you already had; hand them the problem, the intent, and the risks.
- Writing a merge-oriented summary. "Changed X to improve Y" is written to be accepted, not reviewed; a packet names where the change might be wrong, not just what it does.
- Omitting the must-not-change list. Without the behaviors that have to keep working, the reviewer checks that the fix works and misses that it broke something next to it.
- Hiding the risky areas. The subtle, broad, or easy-to-get-wrong parts are exactly what the reviewer should see first; list them with why, instead of presenting the change as uniformly safe.
- Letting the AI claim tests passed. NewPrompt doesn't run tests or read CI — the AI must report only the results you give it and mark everything else "not run," or the packet hands the reviewer a green light the change never earned.
- Treating the packet as the review. A thorough packet can still miss the real risk; it helps a human review, it doesn't replace one, and the merge decision stays with your reviewer.
A worked example: a required-document validation fix
Watch "summarize this diff for review" produce a one-liner that hides the risk, then a review-packet prompt turn the same change into a brief a teammate can actually review — with the untested cases and the open questions front and center.
"Summarize this diff for review" returns a one-liner that hides the form, the behavior delta, the risky selector scope, and the fact that nothing was tested; a review-packet prompt returns behavior before/after, a must-not-change list, named risk areas, tests run vs NOT run, and open questions for the reviewer — a draft you check against the real diff and test output before handing it to a teammate who owns the mergeTHE CHANGE (AI-assisted fix):
Required-document validation was firing even when the document's
whole section was hidden. The fix skips the required check when the
parent .control-group is hidden.
THE WEAK ASK, AND WHAT IT GIVES BACK:
ask: "Summarize this diff for review."
answer: "Fixed required document validation so hidden fields are
ignored."
why a reviewer can't use it:
- which form / field? unknown
- before/after behavior? not stated
- what must still work? not stated
- which selector changed, and how broad is it? hidden
- tests? none mentioned
- risks (validation cache, file input, selector scope)? hidden
- nothing for the reviewer to actually check
A REVIEW-PACKET PROMPT:
Prepare a code-change review packet for a teammate. Do not approve
the change, do not call it safe, and report only the tests I give you.
Inputs I'm giving you: issue summary, the diff, my intended behavior,
tests I ran, tests I did NOT run, risks I already see.
Output these sections:
- Change summary + why it was needed
- Files touched
- Behavior before / after
- Behavior that must NOT change
- Risk areas (with why each is risky)
- Tests run (with results) / Tests NOT run (gaps)
- Reviewer focus areas
- Open questions for the reviewer
Rules: separate facts from assumptions; mark what you're unsure of;
never claim a test passed unless I gave you the result.
PART OF WHAT COMES BACK (a draft your reviewer checks):
behavior after: required-document check applies only when the parent
.control-group is visible (not .hide).
must NOT change: visible required document still errors with no file;
non-file required inputs still validate; hidden
business-required fields aren't accidentally skipped.
risk areas: selector scope (.parents vs .closest); stale jQuery
validation cache after toggling; file input vs text
input handling; .hide class vs CSS visibility.
tests run: hidden required doc (ok); visible required doc,
no file (errors, ok); ordinary required input (ok).
tests NOT run: two doc controls in one group; visibility toggled
AFTER the validation cache is built; Safari.
open questions: use .closest(".control-group") instead of a wider
parent traversal? does removeData() affect the file-
uploader's own rules?
NEXT: you check the packet against the real diff and your real test
output, fix anything the AI got wrong or assumed, then hand it to
your reviewer -- who checks the risks and owns the merge.Where this fits in NewPrompt
Preparing a review packet is a packaging job, and NewPrompt gives you the tools for the prompt, not a connection to your repo. The Markdown Output Builder builds a prompt that returns the packet in a fixed set of sections — summary, behavior contract, risks, tests, questions — so it comes back the same shape every time instead of a loose paragraph. The Pull Request Review Template is a worked example of the same fields (change summary, changed files, risk areas, review criteria) shaped as a review brief, with its own boundary intact: it informs a human review, it isn't a merge gate. And if you want an AI second-opinion pass over the change before you hand it off, the Code Review Prompt Generator builds a review prompt scoped to your diff or PR. Each builds a prompt or shows a pattern you run in your own AI tool, on the diff and test results you provide.
This guide sits in the software-development cluster as the one about handing a change to a human. Reviewing AI-generated code without missing risky changes is the other side of the table — how you, the reviewer, catch the risk; this is how the author packages the change so the reviewer can. Refactoring code without changing behavior produces the behavior contract this packet includes — the must-not-change list is exactly what a behavior-preserving change promises. Generating tests for AI-written code produces the results the packet reports, and the gaps it flags as "not run." And writing a rollback plan is the note this packet carries for a risky change. The through-line: the diff is what you did; the packet is everything the reviewer needs that the diff doesn't say.
A review packet is a maintenance logbook, not an airworthiness certificate. When a mechanic hands an aircraft to the next shift, they don't say "it's fine" — they write down what they changed, what they torqued and checked, and the one fitting they couldn't reach and didn't inspect, so the next person knows exactly where to look before they sign. That last line — the thing that wasn't checked — is the most important entry in the book, because it's the one that keeps a plane from flying on an assumption. A review packet is that logbook for a code change: here's what I changed, here's what I verified, here's the case I didn't get to. The AI can write a clean logbook faster than you can, and it can still miss a crack you'd have caught by hand — which is why you check its entries against the real work, and why a human, not the packet, signs the change off. The logbook makes the inspection thorough; it isn't the inspection.