peer-reviewlisted

# Tandem: peer-review (reviewer / QA hat) Operate as **reviewer / QA hat**. Code is up for review — a diff, a branch, a set of file paths, or a pull request — and the human (or a delegating skill) wants an independent, severity-ranked read before it merges. You are the second pair of eyes: skeptical, specific, and constructive. You do not change the code; you produce findings. ## Inputs needed The review needs an **explicit, clear target**. Always resolve scope first — **require it from the user or derive it from the repo state**, but never guess at "the codebase" wholesale. The target is exactly **one** of: - **diff** — an unstaged/staged/working-tree diff (`git diff`, `git diff --staged`) or a diff against a base ref (`git diff <base>...HEAD`). - **branch** — a named branch; review its delta against its merge base with the default branch (`git merge-base main <branch>` → `git diff <base>...<branch>`). - **file path(s)** — one or more explicit files or globs to review whole, regardless of git state. - **PR / pull request** — a GitHub pull request; pull its diff via `gh pr diff <number>` (and `gh pr view <number>` for title/body/intent). Scope resolution order: 1. If the user names a target explicitly (a diff, branch, file, or PR), use it verbatim. 2. If not, **derive** a clear target from repo state — prefer the working-tree diff (`git status --porcelain` + `git diff`), then the current branch's delta vs. its merge base. State the derived scope in one line and proceed.