review-pr

# Review PR Review completed work along two independent axes: 1. requirements; 2. engineering quality. A change can succeed on one axis and fail on the other. Do not let good code excuse incorrect product behavior, or correct behavior excuse unsafe code. ## Process ### 1. Gather context Read: - the complete diff; - linked issue; - acceptance criteria; - approved spec when available; - relevant project instructions; - surrounding implementation where needed. Review the whole change, not isolated snippets. ### 2. Review requirements Check whether the implementation: - satisfies every acceptance criterion; - matches the approved spec; - preserves explicitly required behavior; - omits requested behavior; - adds behavior that was not requested; - handles required states and edge cases. Report requirement mismatches separately from code-quality findings. ### 3. Review engineering quality Check for: - correctness bugs; - regressions; - unsafe assumptions; - unnecessary complexity; - speculative abstractions; - unnecessary dependencies; - duplicate logic where an established project pattern already exists; - missing validation; - missing tests; - error handling that hides failures; - security or authorization mistakes; - data integrity problems; - accessibility regressions when UI changed. Respect documented project standards over generic preferences. Do not report stylistic preferences that tooling already enforces. ### 4. Evaluate verification Check whether the evidence actually demonstrates the changed behavior. Look for: - missing tests; - tests that only verify implementation details; - acceptance criteria with no verification; - checks claimed as passing without evidence. ### 5. Report findings Order findings by severity. For each finding include: - severity; - file or relevant location; - what is wrong; - concrete failure scenario or impact; - requirement or standard involved when applicable. Do not manufacture findings to make the review look thorough. If no actionable findings exist, say so. ### 6. Report residual risk After findings, note meaningful verification gaps or areas not exercised. Give a clear recommendation: - ready; - changes required. ## Review axes Keep these mentally separate: ### Requirements Did we build the right thing? ### Engineering Did we build it safely and maintainably? ## Rules - Findings first. - Evidence over preference. - Do not nitpick for volume. - Do not silently broaden the issue scope. - Do not treat generic best practices as project requirements. - Do not rewrite the implementation during review unless explicitly asked. - Do not invent defects without a plausible failure mode. ## Completion A review is complete when: - the full diff has been inspected; - requirements have been checked; - engineering quality has been checked; - verification gaps are identified; - actionable findings include evidence; - the final recommendation is clear.