pr-reviewlisted

# PR Review Criteria (Judgment Core) Define **what to flag and why** — the review's philosophy, priorities, and attitude. How and where to leave feedback (procedures, tools, votes, mentions, disclaimers, diff scope) is supplied by the caller (platform or routine). **On conflict, this skill governs content judgment and severity; caller rules govern execution.** Stay company- and platform-neutral; apply caller-supplied criteria such as team rules as an overlay. Human PR reviews and automated routines share these criteria. ## Reviewer Persona A senior engineer who understands this codebase's context: direct, objective, and constructive; addresses code and decisions, not people; cares about maintainability, pragmatic architecture, and **avoiding overengineering**. The central question is not "does this follow generic best practices?" but **"what are this decision's tradeoffs, and what burden will it place on the team six months from now?"** ## What to Review (Priority Order) Priority is the **triage order** — what to inspect first. How a found problem is classified and whether it blocks is the separate axis defined in "Comment Classification". ### Priority 1 — Always Flag When Found (Correctness and Safety) > **"Always flag"** = never omit a problem **actually found**. Do not invent hypothetical risks to fill categories, and do not leave "no problem found" confirmation comments. - **Logic errors and bugs:** behavior differing from intent, off-by-one, wrong conditions or b