pr

Structure the PR body into three sections: a Summary with a small diagram or diff showing the change shape, Evidence with before-and-after proof such as test runs or screenshots, and Merge Danger describing reversibility and blast radius. Keep prose brief and skip preambles.

Pick the smallest view that makes the key point clear. Use pseudocode for logic, call trees for runtime flow, component trees for UI structure, file trees for refactors, Mermaid sequence diagrams for interactions, and diffs when the surrounding shape already exists.

Show concrete before-and-after proof. Screenshots are strongest for visual changes, while execution-based evidence like test results and console output works for logic changes. Show the exact test that failed before and passes after.

A two-way door change is cheap to roll back, making it lower risk to merge. A one-way door involves destructive actions or hard-to-reverse decisions that cannot be undone. PR bodies should state which type applies and describe the blast radius.

Use a diff when the point is what changes and the surrounding structure already exists. Show the whole block when most of it is new, when omitted context would hide ownership or ordering, or when reviewers need a copyable target shape.