Review Implementation

Read an implementation reference READ-ONLY (a git ref, a diff, or a commit range) ALONGSIDE the spec it was supposed to deliver and emit a references-first review record to the active thread's implementation/reviews/ folder. This skill reads both inputs, maps each of the spec's acceptance criteria to the matching diff hunks, runs the five fidelity axes against the pair, drafts the report end-to-end, and writes one record per review run. By default it runs end-to-end without walking findings with the user one at a time, but it honors an invocation that asks it to check in or walk the findings interactively; it does not commit.

What This Review Verifies — the Spec's Acceptance Criteria, Not the Plan

The implementation is checked against the spec's acceptance criteria — the contract — NOT against the plan. The plan is a disposable compiler-IR that the human never needs to read; the spec plus its acceptance criteria are the audited artifact. The human may review the implementation, but they never need to review the plan. So every finding traces back to one question: "does the implementation deliver what the spec's acceptance criteria promised?" A finding tethered to the plan rather than the spec is the wrong contract — re-anchor it to the spec's acceptance criteria or cut it.

If the implementation was produced from a plan, the plan is at most a navigational aid for locating which diff hunks map to which acceptance criterion. It is never the bar. Where the plan and the spec diverge, the spec wins — the divergence is a plan fault that the plan adherence review owns, not a finding this skill should raise against the implementation.

Inputs

This skill requires TWO inputs. Both are mandatory.

Input 1: An implementation reference

The implementation reference is the code output being reviewed. Accepted forms: