---
name: taskforge-review
description: Independently review a taskforge task's implementation against its Specification and emit only the verdict — the review half of the split run workflow (docs/ADR-0001 Phase 6). Use when a task's readiness is "review" (an implementation awaits review). Runs in fresh context against the recorded reviewer prompt; produces one review artifact (approved, or rejected with a root_cause). The KERNEL routes on the verdict (approved -> done, rejected -> refine/explore/retry) — the review never emits a done or escalate signal.
license: MIT
---

# taskforge-review

Judge an implementation against its Specification, independently, and emit a
verdict. Review owns exactly one responsibility: decide whether the diff
satisfies the spec. It does **not** route the task — the kernel derives the next
phase from the verdict (approved → done; rejected → refine/explore/retry by
`root_cause`), exactly as it does for every other transition. So the review
emits *only* the review artifact, never a `done` or `escalate` signal.

**Prerequisites**: read `taskforge/CONTRACTS.md` this session; resolve
`$SCRIPT`; guard on readiness (`review` required — an implementation with no
review at or after it).

## 1. Independent review — recorded, isolated, non-negotiable

Follow `taskforge/references/reviewer-prompt.md` **exactly**: build the prompt
with `build-review-prompt <id> --diff <diff> --results <results>` (it renders
the active spec verbatim and records it for `audit-review`); judge in a
**fresh context** — no implementer narrative, plan, or chat history may enter.
If no fresh context is available, stop and say so — a self-review is never
recorded as a review.

## 2. Emit the verdict

Emit **one `review` artifact** with `signal: none`, a fresh `result_id`;
`validate` then `apply` with `--actor review`:

* every acceptance criterion in `criteria_results`, explicit pass/fail;
* `verdict: approved` — the kernel completes the task (`done`);
* `verdict: rejected` with `root_cause`:
  * `implementation` → the kernel bounces it back to build (retry, budget-
    enforced); feed the findings forward;
  * `specification` → the kernel routes to refine;
  * `architecture` → the kernel routes to explore (and escalates a child's
    parent).

Record the verdict verbatim; disagree in the report, never in the record.
Report per `references/reporting.md`; stop.

## Quality bar

* One review artifact; no `done`, no `escalate` signal — routing is the kernel's.
* Recorded reviewer prompt passes `audit-review` (criteria verbatim; no
  implementation summary).
* Every acceptance criterion appears in `criteria_results` with pass/fail.