Prepare pull requests for instant maintainer approval

PR Merge Champion is a systematic four-step playbook for preparing, reviewing, and documenting pull requests so they need minimal review cycles: (1) pre-flight clean-up and rebase - rebasing the feature branch on the latest target branch to resolve conflicts early, removing untracked, temp, or swap files, and running local linters, formatters, and compilers; (2) a critical self-review of your own diff as if you were the reviewer, checking for leftover debugging statements (console.log, print, breakpoints, custom debug flags), unnecessary or whitespace-only changes, commented-out code, unresolved TODOs, and the correctness of error handling and edge cases; (3) local verification - running the project's automated test suite, checking coverage on new code, and manually testing critical paths; and (4) crafting a high-signal PR description with four fixed sections: Summary, Context/Why, Verification (test commands, screenshots, or reproduction steps), and a Checklist matching the repository's own contributing guidelines.

Use it when preparing to open a new pull request on GitHub or any Git hosting platform, when self-auditing a feature or bug-fix branch for cleanliness and consistency, or specifically to minimize review cycles and speed up integration. It does not replace project-specific CI/CD validation, automated testing, or domain-expert review - it is a self-audit playbook, not a substitute for the checks a project already runs. Best practice guidance runs both ways: keep PRs under roughly 200 changed lines (they get reviewed and merged noticeably faster), do a self-review before requesting one from a maintainer, and follow the repository's own CONTRIBUTING.md and PR template - but do not bundle unrelated refactors or bug fixes into a feature PR, and do not ignore failing CI (tests, linters, security scans) before requesting review.

Input is the feature or bug-fix branch itself, checked against the target branch (main or master) and the repository's own contributing guidelines and PR template. Output is a rebased, cleaned-up branch plus a structured PR description. A documented self-review command inspects the diff for accidental debug artifacts before committing:

### Check the names of files changed to ensure no unwanted files are staged
git status --porcelain

### Review the actual diff for any leftover print statements or debuggers
git diff | grep -E "(console\.log|debugger|print\(|var_dump|binding\.pry)"

Common pitfalls it documents: a PR sitting open due to minor formatting comments, fixed by running the repo's own formatter (Prettier, ESLint, or Black) before committing, and merge conflicts appearing right after opening a PR, fixed by pulling and rebasing or merging main into the branch daily.

It assumes a standard Git and GitHub-like workflow, though the core principles are stated to apply to GitLab, Bitbucket, and other Git hosting platforms as well. It names two related, separate skills for adjacent needs: @pr-writer for Sentry-specific PR writing guidelines, and @clean-code for code quality checks before submission.

Developers who want their pull requests merged with the fewest possible review round-trips - especially useful before opening a PR against a team or open-source maintainer whose time is scarce, or when self-auditing your own feature or bug-fix branch before asking anyone else to look at it.