make-pr-easy-to-review

make-pr-easy-to-review is a workflow skill that prepares a pull request so a reviewer can quickly grasp its intent, key files, and risk — without changing code behavior. It addresses the common problem of PRs that are hard to review: noisy commit history, stale descriptions, unrelated changes mixed in, and mechanical edits tangled with logic changes. The stated default goal is improving reviewability while leaving behavior untouched.

The workflow resolves the target PR from a URL or the current branch, inspects commits, diff size, changed paths, generated files, and the existing description, then identifies reviewability issues and proposes a plan before making changes. For history cleanup it uses `gh` and `git` to capture the original tree hash, suggests dependency-ordered commit groupings (schema, core logic, wiring, UI, tests), and verifies content identity after any rewrite by comparing tree hashes — refusing to push if the tree changed unintentionally. For behavior-preserving improvements it favors PR-description and reviewer-note edits: a TL;DR matching the diff, separation of core versus generated files, and callouts for risky changes, migration order, and test coverage.

It targets software engineers and teams using GitHub who want cleaner, more reviewable PRs. Its guardrails are notable: it only rewrites history when the user asks or agrees, never hides behavior changes inside "cleanup", does not bypass hooks unless explicitly requested, and recommends splitting a PR rather than polishing around one that is too large. History rewriting and force-pushing are inherently sensitive but are gated behind explicit user consent and tree-verification.