requesting-reviewlisted

# Requesting Review ## Overview A pull request body tells the reviewer four things: what changed, why it changed, how it works, and how you know it is correct. The diff shows what lines moved — it cannot show intent, tradeoffs, or the alternatives you considered and rejected. Front-load that context so the reviewer evaluates the change instead of reconstructing it. This skill defines the six-section PR body, when to split large PRs, when to use drafts, and the author's responsibilities after opening. --- ## Process ### Prerequisites Before opening a PR, every one of these must be true. If any is false, fix it first — do not open the PR and plan to fix it later. - **`exloom:proving-done` has run.** The verification output exists and contains test evidence. This is not optional. The test evidence in the PR body comes directly from verification output — you do not re-run or reconstruct it. - **All tests pass.** The test suite is green. If tests fail for reasons unrelated to this change, that context belongs in the PR body explicitly — but the default expectation is a clean run. - **Plan updated with deviations (if a plan existed).** The plan file reflects what was actually built, not what was originally proposed. The PR body links to the plan and summarizes deviations, but the plan itself is the canonical record. - **Code committed and pushed.** The branch is up to date with the target branch. Merge conflicts that a reviewer discovers during review are unnecessary fricti