review-pr

name	review-pr
description	Review a Hazma pull request against its project task or ad-hoc scope using one focused lens: generalist, completeness, logic, document consistency, or numerics. Use when a user asks for a PR review or when a Codex review cycle assigns a single reviewer lens.

Review one pull request

Review one PR and return one structured verdict. Do not implement fixes or orchestrate other reviewers; use $review-cycle for the bounded multi-agent loop and $review-plan for a pre-implementation plan.

Gather a fresh PR view

Normalize a PR number, URL, or pushed branch. Fetch its metadata and fresh head ref; do not judge the ambient checkout:

git fetch origin pull/<N>/head:refs/remotes/origin/pr/<N>

Verify that SHA against gh pr view <N>. Treat a truncated gh pr diff as incomplete; read changed files from the fetched ref. Parse project branches as <agent>/<slug>/<task> for both agent prefixes. For project work, read lessons.md, the PLAN's numerical-impact section, optional rules, target phase, task note, relevant ADRs, and upstream learnings. For ad-hoc work, review against AGENTS.md, the PR guidelines, and the change itself.

Read every changed non-trivial file in full context. Check common diff omissions: public exports, sibling dispatch tables, Cython rebuild evidence, stale Sphinx references, package data registration, and ignored tests.

Apply one lens

Read the assigned section of docs/agents/review-lenses.md and apply its baseline duties before the lens rubric. Reproduce PR-body claims, check a real pytest collection/result, run changed examples or observable claims, and require a rebuild after Cython edits.

• default: public API, units/docstrings, layering, broadcasting, debug residue, task completion, and PR conventions.
• completeness: explicit Exit-Criterion-to-pinning-test map and scope.
• logic: adversarial mutation, boundary/error cases, and test validity.
• doc-consistency: execute every applicable check in docs/agents/doc-consistency.md with line-numbered evidence.
• numerics: measure public before/after values, dimensional analysis, limiting cases, stability, integration/interpolation bounds, tolerance, and hot-path performance.

Use REQUEST CHANGES for any blocking finding and APPROVE otherwise. COMMENT is only for a standalone advisory review. On a verification pass, classify every prior comment as RESOLVED, PARTIALLY RESOLVED, or UNRESOLVED.

## Verdict
<APPROVE | REQUEST CHANGES | COMMENT>

## Issues (<lens> Focus)
### Blocking
<numbered, file-and-line-specific findings or None>
### Non-blocking
<numbered findings or None>

## Cross-cutting
<only clearly blocking issues outside the lens>

## Lens-Specific Observations
<required evidence for the selected lens>

If a required command or dependency cannot run, report the verification gap; never invent a result or turn environment noise into a code defect.