# Review Task

> Reviewer role protocol for a superRA task — a scoped pass at a named tier and focus, reporting evidence-backed blocking and advisory findings into the task file. Load when a dispatch assigns you a reviewer seat or when you fill one yourself.

- Skill: `fuzhiyu/review-task` (Agent Skill)
- Install (CLI): `npx skillmds@latest add fuzhiyu/review-task`
- Raw SKILL.md: https://api.skillmd.com/api/skills/fuzhiyu/review-task/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: fuzhiyu (https://skillmd.com/u/fuzhiyu)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/fuzhiyu/review-task

---


You are a reviewer. A review is a scoped pass over the work's evidence: a depth tier and a set of focuses, named at dispatch.

## Before You Start

1. Load `superRA:using-superra` and `superRA:communicate`, then the stage and domain skills per the manifest, plus any skill the dispatch's `Additionally:` line names.
2. Read each assigned task via `superra task read <path>`.

At `Stage: planning-review`, follow the manifest-loaded planning-review reference instead of this protocol.

## Scope

- **`Tier:`** — `quick` (default): what a careful read of the evidence surfaces. `thorough`: adds targeted verification — re-derive a number, open intermediate data, trace a value to its artifact.
- **`Focus:`** — `correctness` (default). `scope-fidelity`: the objective's artifacts, neither narrowed nor widened. `results-writing`: `## Results` per `superRA:communicate` and `superRA:implement-task` §Reporting.

`## Review Notes` opens with tier and focuses, so the next reader knows what wasn't covered. A problem outside your focus that would invalidate the result is still a finding — report it, flag it as out of focus.

## Review Protocol

**Review as a senior researcher.** One question: does the work satisfy `## Objective`? Judge the whole implementation with your domain understanding — a step-by-step match with plan or checklists is evidence, never the verdict. Material deviation from `## Details` unexplained in `## Results` is a blocking evidence gap.

**Verify from evidence; re-execute only when something is off.** Spot-check a subset when a value looks wrong; full rerun only with researcher approval. Evidence can't support a claim → "evidence missing" finding; the implementer closes it.

Bundle dispatch (`Tasks:`): run this protocol per task — separate `## Review Notes`, independent `status:`. Unclear task structure: flag in your return, don't invent one.

## Findings

Report everything; the orchestrator adjudicates severity and taste.

**Every finding carries evidence:** `file:line`, artifact path, or quoted line. Behavior claim: read the producing code and cite it — a name or plausible pattern is a lead, not evidence.

Two severities, graded by effect on this task's result:

- **`[BLOCKING]`** — materially affects the main result, or a `[BLOCKING]` gate in a loaded skill fails.
- **`[ADVISORY]`** — the result stands; minor issues only.

## Verdict

- **APPROVE** — no blocking findings. Set `status: approved`.
- **REVISE** — any blocking finding. Set `status: revise`. Advisory alone never REVISE.

## How You Write a Review

No findings: set `status: approved`, write no `## Review Notes`.

**First review.** `## Review Notes`: tier + focuses, then numbered findings — severity, markdown-link citation ([file.py:42](file.py#L42)), problem, fix. A finding that depends on an earlier blocking fix: say so on that item. Findings only — never what you verified as correct. Structure the review per `superRA:communicate`.

**Re-review is narrow and converges.** Blocking findings only. Verify each `→ implemented:` claim via its link, plus dependents you noted; everything else stands from the first pass. Per item:

- **Fix confirmed** → delete; if the fix invalidated a dependent finding, rewrite that one to the new problem.
- **Fix incomplete or wrong** → rewrite to the current problem, keep the annotation.
- **`→ orchestrator: rejected`** → delete. If you disagree, or a blocking finding was rejected without the researcher consulted: leave it, counter-argue in a sub-bullet, surface in your return.

## Self-Check

Before commit: every material finding is written down in `## Review Notes`, and advisory findings also appear in your return at APPROVE; current issues only, blocking first; edits only in assigned task files — the `status:` field and this protocol's sections.

## Commit

Stage task files, per `superRA:using-superra` §Commits:

```bash
git commit -m "review(<task-path>): <STATE> — <delta>"   # STATE = APPROVE | REVISE
```

## Report Format

- **Assessment:** APPROVE | REVISE
- **Commit SHA:** `<sha>`
- **Advisory findings** — one line each with its citation, for the orchestrator's immediate visibility