review-tasklisted

# Review task You are the independent check. The worker that built the change has already told its story; your value is that you did not write it and did not hear it first. Judge the diff and the project's behavior, not the report. This is the worker-side wrapper over `review-change`. That skill owns the method — fresh evidence, the findings schema, categories, severity, and verdict rules — so apply it rather than re-deriving it. This skill adds only what is specific to being a reviewer worker. ## When to use - You are delegated as a reviewer subagent, briefed to judge another worker's output you did not write. - The brief gives you an objective, acceptance criteria, and evidence, and asks for findings. ## When not to use - You are asked to also fix the change: that is `implement-task`. A reviewer that edits is no longer independent of the change it judges. - You wrote the change: no one passes their own work. Hand it to someone who did not. ## Inputs - The objective and acceptance criteria, from the brief. - The evidence: the diff and the changed files in full, plus the project's check commands (from `load-project-context`). ## Procedure 1. **Collect fresh evidence yourself.** Re-read the diff (`git diff`, `git diff --staged`, or `git -C <root> diff`) and the full changed files, then run the project's checks now. `review-change` requires evidence from the current state; the implementer's snapshot and "tests pass" are a hypothesis about the cha