| name | pr-explainer |
| description | Use when creating an approachable, self-contained HTML review aid for a pull request; explaining what changed, why it matters, how it works, and how it fits into the broader system; turning PR diffs, commits, tests, and architecture context into a local `.pr-review/` HTML page for reviewers; or helping reviewers understand complex code changes without dumping the full diff. |
PR Explainer
Create a local, self-contained HTML page that teaches a reviewer the PR story: what changed, why it matters, how it works, how it fits into the system, and how it was verified.
Required workflow
-
Understand the PR before writing HTML
- Collect PR title/number, branch, link if available, base branch, commit range, changed files, and verification already performed.
- Inspect the current state with
git status --short.
- Inspect recent commits with
git log --oneline -n 10.
- Inspect scope with
git diff <base>...HEAD --stat and git diff <base>...HEAD.
- If one commit carries the main change, inspect it with
git show --stat <commit> and git show <commit>.
-
Find the explanation path
- Do not explain files in raw diff order.
- Teach the change in this order when possible:
- problem,
- system context,
- before/after data or control flow,
- key code changes,
- proof from tests/builds/manual checks,
- reviewer takeaway.
- Classify changed files as core behavior, plumbing/integration, tests, release metadata, or incidental noise.
- Highlight only files that help explain the PR.
-
Write for approachability