pr-reviewlisted

# PR Review Produce a high-signal review: findings a reviewer would act on, classified and ordered, ending in a clear verdict. The kit instructions (`instructions/secure-coding.md`, `instructions/testing-standards.md`) define what counts as blocking. ## Scope the diff - Reviewing an existing PR: fetch the diff and description from the configured host (`prHost` in `.claude/dev-kit.json`). **github:** `gh pr diff <pr>` + `gh pr view <pr>`. **bitbucket:** `GET /2.0/repositories/{ws}/{repo}/pullrequests/{id}/diff` and `/pullrequests/{id}` (REST, token from env). **gitlab:** `glab mr diff <id>` + `glab mr view <id>`. - Reviewing the working tree (self-review before PR): `git diff` against the base branch, including staged changes. - Read the linked ticket's acceptance criteria — a diff can be flawless and still not do what the story asked. - Write the **PR intent** — one line on what this PR is for and what it deliberately leaves alone. It's the ruler for scope: a real defect *inside* the intent blocks; a valid concern *outside* it is a note or a follow-up, not a reason to expand the PR. ## Review dimensions (in priority order) 1. **Acceptance criteria**: does the change actually satisfy each criterion? List any criterion not covered. 2. **Correctness**: behavioral regressions, broken edge cases, wrong logic. Read the code, don't skim the diff. 3. **Contract drift**: routes, payloads, enums, schemas, validation, status codes — every side that depends on the contract updated t