pre-pr-reviewlisted

Use before pushing a branch or opening a pull request - "is this ready?", "can I push?". Runs the repo's local checks, then reads the diff as if someone else wrote it, and fixes what it finds first. A review after the push is a review of something already published.
repository-standards/core · ★ 3 · Code & Development · score 76

Install: claude install-skill repository-standards/core

# Pre-PR review Run this before opening a pull request. Goal: catch the obvious defects locally, cheaply, in a fresh perspective - so the PR that reviewers (human or CI) see is already clean. This does NOT replace an independent CI review: it shares the author's blind spots and only fires when an agent that ran this skill opens the PR. Its value is tightening the loop early, not being the gate. (The gate is CI + human review.) ## Steps 1. **Scope the change.** `git fetch origin` then look at the full diff against the base branch: `git diff origin/main...HEAD`. Know exactly what you are shipping. 2. **Check the branch shape (R23).** Three things, all from `git log --oneline origin/main..HEAD`: - it sits on current `main` - `git merge-base --is-ancestor origin/main HEAD` exits 0; if not, rebase (never merge `main` in); - no merge commit rode in - `git log --merges origin/main..HEAD` is empty; - every commit listed belongs to *this* PR and stands on its own. Another PR's commits in that range means you are stacked on its branch: rebase onto `main`, or land the parent first. Squash the wip/fixup noise now (`git rebase -i origin/main`), before review, not after. 3. **Run the repo's local checks** (whatever this repo defines - do not invent): format, lint, typecheck, and the unit tests the repo expects before a PR. That includes the repo's **full audits**, not only diff-scoped checks - in a repo on the standard, run the exact invoca