PR Review-Prep — paste a diff, get a review-ready pull request package

Reviewers approve faster when a PR tells them what changed, why, what could break, and where to look first. This skill takes a git diff you paste and writes the PR body for you — plus a self-review checklist and a reviewer attention map so the risky parts get read first, not last.

It is built for the everyday developer loop: you (or your coding agent) finished a change, you run git diff or compare against the base branch, you paste the output here, and you get a pull request description you can drop straight into GitHub, GitLab, Bitbucket, or Azure DevOps.

⚠️ Before you start (please read)

• The output is text you paste into your PR (a Markdown description plus checklists). This skill does not open a PR, does not touch your repository, does not run git, and does not connect to any API or hosting service.
• It reads only the diff and notes you provide. It never invents a behavior, migration, config change, or test that the diff does not show. Anything it cannot infer from the input is marked [FILL IN] for you to complete.
• It is not a substitute for code review. The risk callouts and attention map are an assistive triage that helps a human reviewer; they are not an approval, a security audit, or a correctness guarantee.
• No API key, no account, no personal data. Do not paste real secrets, tokens, internal hostnames, or customer data inside the diff — redact them first. If the skill spots something that looks like a live secret in the pasted diff, it stops and asks you to remove it before continuing.

What you get

How to use

1. Generate the diff. Any of these work:
   • git diff main...HEAD (branch vs. base), or git diff --staged, or a plain git diff.
   • A GitHub/GitLab "Files changed" copy, or a unified-diff patch file.
   • If you don't have a diff, paste the list of changed files plus a few sentences on what you did — you'll get a lighter package with more [FILL IN] markers.
2. Paste it here. Optionally add: the base branch, the linked issue/ticket ID, and one line on why you made the change (this fills the "Why" section instead of leaving it [FILL IN]).
3. Optionally say your target platform (GitHub / GitLab / Bitbucket / Azure DevOps) so the checklist markdown matches, and whether your repo uses a PR template you want the output shaped to.
4. Read back the package, adjust anything marked [FILL IN], and paste the description into your PR.

How it works (the review-prep workflow)

Step 1 — Parse the diff into a change model

Read the unified diff and build a structured picture before writing anything:

• Group hunks by file and by area (source / tests / config / docs / migrations / dependencies / generated).
• Classify each file's change: added, deleted, renamed/moved, modified.
• Note volume signals (large additions, large deletions, many files) — these drive the attention order, not the prose.
  If the input is only a file list plus notes, build a partial model and mark the missing detail [FILL IN] rather than guessing hunks.

Step 2 — Derive title and summary

Pick the dominant change (the one the rest support) and write an imperative title. The summary is one paragraph a busy reviewer can read in ten seconds: what this PR does and the single most important thing to know about it. Never oversell ("massive refactor", "huge improvement") — describe, don't advertise.

Step 3 — Write "What changed" and "Why"

• What changed: bullets grouped by area, each tied to real files/functions from the diff. Concrete ("adds retryWithBackoff to UploadClient and wraps the three network calls"), not vague ("improves reliability").
• Why: use the reason you provided, or infer a plausible motivation only if the diff makes it obvious; otherwise write Why: [FILL IN — reason for this change]. Do not fabricate a rationale.

Step 4 — Risk callouts (the part reviewers care about)

Scan the diff specifically for change types that break things in production, and surface each one explicitly:

• Schema / data migrations — irreversible or long-running migrations, column drops.
• Public API / contract changes — changed function signatures, endpoints, response shapes, exported types.
• Config / feature flags / defaults — a changed default value is a silent behavior change; call it out.
• Dependency changes — added/removed/upgraded packages, especially major-version bumps.
• Deletions — removed functions/files that may still have callers (recommend a callers check).
• Auth / permissions / secrets handling — any edit near authentication, authorization, or secret loading.
• Leftover markers — TODO, FIXME, XXX, console.log/debug prints, commented-out code shipped in the diff.
  Each callout is one line: what it is, and what the reviewer/author should verify.

Step 5 — Reviewer attention map

Order the changed files/hunks so the reviewer reads the highest-risk, highest-leverage parts first (migrations, contract changes, auth edits, large deletions), and the low-risk parts (docs, formatting, generated files) last. One reason per entry. This is triage guidance, not a verdict.

Step 6 — Self-review checklist tailored to the diff

Generate concrete checks from what the diff actually contains, for example:

• "New env var UPLOAD_TIMEOUT is documented in the README/.env.example."
• "Deleted parseLegacy() has no remaining references (grep clean)."
• "Migration 0042_add_index is reversible / has a down."
• "New public method has a test covering the failure path."
• "No secret, token, or internal hostname left in the diff."
  Only include checks that map to something in the input.

Step 7 — Breaking-change / rollout note

If Step 4 found a public-interface, stored-format, or default-value change, add a short backward-compatibility and rollout note (e.g. "old clients still work because the field is optional"; or "requires the migration to run before deploy"). If nothing breaking was found, state that plainly.

Guardrails (this skill's own behavior)

• Uses only the pasted diff and notes. It never invents changed behavior, migrations, endpoints, tests, or a rationale the input does not support — unknowns are [FILL IN].
• Does not open, push, or modify anything. Output is text for the human to place into their PR.
• Risk callouts and the attention map are assistive triage, not an approval or a security audit. The skill states this and does not imply the change is safe to merge.
• No hype. Titles and summaries describe the change; they do not claim performance, safety, or quality outcomes the diff can't prove.
• Requests no personal data and no live credentials. If the pasted diff appears to contain a real secret or token, the skill stops and asks the author to redact it before producing the package.
• If the input is too thin to write a real description (e.g. an empty or truncated diff), it says so and asks for a fuller diff instead of padding a fake one.