mcpField
M
make-pr-easy-to-review

make-pr-easy-to-review

github.com/michael-denyerDevelopment3.6k819 installsUpdated today
Repository

About make-pr-easy-to-review

A repository skill for preparing pull requests so reviewers can understand their intent, key files, and risks. It emphasizes review notes and safe improvements without changing behavior, and requires agreement before history rewrites.

Key features

  1. 01Inspect PR commits, diffs, paths, and description
  2. 02Identify reviewability problems
  3. 03Propose plans before history rewrites
  4. 04Improve descriptions and reviewer guidance
  5. 05Verify code content after changes

Use cases

  1. 01Prepare a PR for a faster review
  2. 02Clarify generated and mechanical changes
  3. 03Document risks, rollout, and test coverage
  4. 04Decide when to split an oversized PR

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/michael-denyer/pstack-claude --skill make-pr-easy-to-review

After installing, type/make-pr-easy-to-reviewin Claude Code to confirm it loaded.

Details

From the project README

Make PR Easy to Review

Prepare a PR so a reviewer can quickly understand the intent, important files, and risk. The default goal is reviewability without behavior changes.

Workflow

  1. Resolve the target PR from the user-provided URL or current branch.
  2. Inspect commits, diff size, changed paths, generated files, and PR description.
  3. Identify reviewability issues: noisy commits, stale description, unrelated changes, mixed mechanical and logic changes, missing tests, or unclear reviewer entry points.
  4. Propose a plan before rewriting history or force-pushing.
  5. Apply safe improvements, then verify the tree or diff still matches the intended code.

History Cleanup

Only rewrite history when the user asks for it or agrees to the plan. Before rewriting:

gh pr view <PR> --json title,headRefName,baseRefName,state,commits
git fetch origin <headRefName> <baseRefName>
ORIGINAL_TREE=$(git rev-parse origin/<headRefName>^{tree})

Good commit groupings usually follow dependency order:

  1. Schema/storage or generated API definitions.
  2. Core logic.
  3. Wiring and integration.
  4. UI or surface behavior.
  5. Tests.

After rewriting, verify content identity:

echo "Original tree: $ORIGINAL_TREE"
echo "Current tree:  $(git rev-parse HEAD^{tree})"
git diff origin/<headRefName> --stat

Do not push if the tree changed unintentionally.

Reviewer Guidance

When code behavior should stay untouched, prefer PR description and review notes:

  • Add a TL;DR that matches the actual diff.
  • Separate core files from generated or mechanical files.
  • Call out risky behavior changes, migration order, rollout plan, and test coverage.
  • Link issue trackers, dashboards, or design docs when they explain intent.

Guardrails

  • Never hide meaningful behavior changes inside "cleanup".
  • Do not bypass hooks unless the user explicitly asks.
  • If the PR is too large to make reviewable with notes, recommend splitting instead of polishing around the problem.

Comments

Markdown supported