review-changelisted

# Review change Review the work, not the summary. A report is a claim; the diff and the project's own checks are the evidence. This is the shared, read-only method. It changes nothing: no fixes, no commits, no pushes, no comments on a remote. `verify-evidence` defines what counts as evidence. ## When to use - A completed change — a local diff, a branch, or a patch — must be checked against acceptance criteria. - The primary must verify a change before approval. ## When not to use - The task is still running: the primary waits for it to return (`monitor-agents`). - The assignment includes fixing the change: that is implementation, not review. - You are deciding whether to review, delegating a reviewer, or driving rework: that coordination is the primary's (`review-work`), not this method. ## Inputs - The goal and acceptance criteria for the change. - The change itself: a local diff, a branch, or a patch. - The project's check commands (from `load-project-context`). ## Fresh evidence Collect evidence now. Never review from memory or reuse a diff snapshot from an earlier iteration; the working tree may have moved. 1. Establish intent: the goal, every acceptance criterion, and the constraints from the request or brief. If criteria are missing, derive them from the goal and say what you assumed. 2. Read the diff — `git diff` and `git diff --staged`; for another agent's working copy use `git -C <root> diff`. As the primary, `python3 scripts/tm.py diff -