Prepare pull requests for instant maintainer approval

PR Merge Champion is a systematic playbook for preparing, reviewing, and documenting pull requests so they are high quality, free of common oversights, and optimized for quick maintainer approval and merging. It optimizes pull requests through clean diffs, comprehensive self-reviews, and structured documentation.

The playbook has four steps:

1. Pre-flight clean up and rebase. Rebase the feature branch on top of the latest target branch such as main or master to resolve conflicts early, clean up untracked, temp, or swap files, and run local linters, formatters, and compilers so no stylistic or syntax errors remain.
2. Critical self-review. Review your own diff line by line as if you were the reviewer. Look for leftover debugging statements such as console logging, prints, and breakpoints; unnecessary changes, whitespace-only diffs, and commented-out code; incomplete TODO comments that should be resolved or turned into tracked issues; and the correctness of error handling and edge cases.
3. Local verification and test suite. Run the project's automated tests locally to check for regressions, check test coverage for new code, and manually test the critical paths and edge cases.
4. Craft the pull request description. A great description tells the story of the change with a summary, the context and why the change is necessary, verification details (test commands, screenshots, or reproduction steps), and a checklist that conforms to the repository's contributing guidelines.

Use it when preparing to open a new pull request on GitHub or another Git hosting platform, when self-auditing a feature or bug-fix branch for cleanliness and consistency, or when you want to minimize review cycles and speed up integration.

It does not replace project-specific CI and CD validation, automated testing, or domain-expert reviews. It assumes a standard Git and GitHub-like environment, though the core principles apply to GitLab, Bitbucket, and other platforms.

The input is a finished feature or bug-fix branch. The output is a cleaned branch and a structured pull request description. The example description is titled around implementing rate limiting on an authentication endpoint. It has a summary (an IP-based rate limiter using Redis to prevent brute-force attacks), a why section (a high volume of login attempts against single accounts), a verification section (unit tests run, and a manual check where sending 15 requests in under 60 seconds returns 429 Too Many Requests), and a checklist covering style guide, unit tests, and documentation.

For self-review, the skill offers commands to inspect the diff for accidental additions. The first lists changed files so no unwanted files are staged:

git status --porcelain

The second pipes the diff through a search for leftover print statements and debuggers.

It works with Git, GitHub or comparable platforms, and the repository's own linters and formatters such as Prettier, ESLint, and Black. The project's CONTRIBUTING file and pull request templates should be checked and followed strictly. Related skills are pr-writer, for Sentry-specific PR writing guidelines, and clean-code, to ensure code quality before submitting. It lists Claude, Cursor, Gemini, and Antigravity as tools.

Best practices: keep pull requests small and focused, since a pull request with fewer than 200 lines of changes gets reviewed and merged significantly faster, self-review first because finding your own bugs builds trust with maintainers, and respect repository guidelines. Do not bundle unrelated changes into a feature pull request, and do not ignore CI failures: fix failing tests, linters, or security scans before requesting review.

Common pitfalls and fixes: a pull request left open for a long time over minor formatting comments is avoided by running the repository's local formatter before committing, and merge conflicts right after opening are avoided by pulling the latest main branch and rebasing or merging it into your branch daily.

It is for contributors and developers who open pull requests, especially to projects with active maintainers, and want fewer review rounds and faster merges.