pr-reviewlisted

Expert code reviewer for Ruby on Rails and Node/TypeScript codebases. Use this skill whenever the user: asks to review a branch, PR, diff, or working-tree changes before merging; wants a second opinion on their own code before opening a PR; asks "what's wrong with this diff" or "is this ready to merge"; wants findings posted as PR comments; asks to check for correctness bugs, security or multi-tenant scoping gaps, missing test coverage against acceptance criteria, or violations of the repo's own conventions; asks whether a decision made in the change should have been documented (an ADR, a docs/ page, a README/CLAUDE.md update) or whether the diff makes an existing doc go stale; or wants a fix applied for review findings. Also use when the user says things like "review my branch", "look over this PR", "check this diff before I push", "should this have been documented", "does this need an ADR", or "did I miss anything here" — even if they don't name the skill.
eagerworks/skills · ★ 1 · Code & Development · score 67

Install: claude install-skill eagerworks/skills

# PR Review Skill Reviews a diff — a branch, a PR, staged changes, or working-tree changes — against five fixed lenses: correctness, security & data integrity, repo-convention conformance, test coverage, and documentation & decision capture. Returns structured, evidence-backed findings with severities. This is **not** a linter and does **not** replace CI: skip anything a linter or type checker already catches, and don't re-derive what a failing test already proves. By default this is a **read-only** review: no file is edited, no commit is made, nothing is pushed. See `references/workflow.md` if the user explicitly wants findings fixed automatically. ## Scope Detection — Do This First Before reading a single line of the diff, resolve exactly what is being reviewed. In order of how requests are usually phrased: ```bash # "review my branch" / "review this PR" — the normal case: full branch vs. its base git diff origin/<base-branch>...HEAD # note the THREE dots — diff since the branch forked # "review what I'm about to commit" git diff --staged # "review my uncommitted changes" git diff # "review PR #<N>" on GitHub gh pr diff <N> gh pr view <N> --json body,title # pull the description / acceptance criteria too ``` **Never guess the base branch.** If the user didn't name one, resolve it from evidence, in order: (1) the open PR for the branch under review — `gh pr view --json baseRefName` — which outranks the config file; (2) `.eagerworks/pr-review.json`'s `base