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 rev

SKILL.md

GitHub

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 every skill the manifest assigns, 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.

Check a result from retained code against the superRA:reproducibility gates: registration (references/designing-the-graph.md), the claim (§Recording a Result), each step not fresh (references/rerun-or-accept.md). Evidence: read-only superra repro status <targets> and the committed repro-lock.json and repro-acceptance/ records.

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), 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:

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