pull-request-authoringlisted

# Pull request authoring Review quality is mostly decided **before anyone reads your code**. A reviewer given 2000 lines with a one-word description will comment on variable names, because that is all a human can do with that. The same reviewer given 200 focused lines and a clear intent will find the concurrency bug. You control the review you get. ## Size **Small PRs get real reviews.** Beyond a few hundred lines of substantive change, defect-finding drops sharply while approval rates stay high — reviewers rubber stamp what they cannot hold in their head. Optimise for reviewability, not for your convenience in assembling it. Split by: - **Concern** — refactor and behaviour change never travel together. A rename touching 40 files hides the three lines that changed logic. Ship the rename first, alone, then the change. - **Layer or step** — schema migration, then the code that uses it, then the feature flag flip. - **Risk** — isolate the dangerous part so it gets the attention it needs. When a change genuinely cannot be split, say so in the description and tell the reviewer the order to read it in. ## Description The description answers what the diff cannot: **why**. ```markdown ## Why Finance re-keys report numbers by hand every month close; two errors in Q1. (Or: fixes #482 — export returns 500 for reports over 50k rows.) ## What Adds a CSV export to the revenue report. Sync under 50k rows, async + email above that. ## How to verify 1. Open /reports/revenue,