Verify Implementation Against Specification

Compare a named implementation scope with an authoritative specification. Produce a traceable conformance verdict without editing code, tests, or the specification. Respond in chat unless a report file is explicitly requested.

Route precisely

• Use this skill only when a specification and an implementation are both in scope and the user asks whether the code fulfills the spec.
• Use review-spec to assess a spec before implementation.
• Use review-arch to assess system structure without a requirement-by-requirement contract.
• Use code-review to find defects introduced by a diff; that review may cite a spec but does not imply exhaustive conformance.
• Use plan-review for a proposed implementation plan.

Fix the authority and scope

1. Identify the exact spec file or revision and the implementation paths, module, commit, or PR being checked. If either side is unavailable, report what is missing before assigning a verdict.
2. Read applicable repository instructions, binding architecture decisions, and the spec in full. Note conflicts between sources rather than silently choosing one. Treat an explicitly superseded spec as historical, not authoritative.
3. Extract each independently verifiable obligation into a stable ID. Preserve a short exact quote and source location; distinguish must, should, explanatory notes, and examples. Do not turn every sentence into a requirement or infer a target count from document length.
4. Find the implementation through named paths and symbols, then search relevant alternate paths before claiming absence. Inspect callers, configuration, migrations, and tests when a requirement depends on them.

Compare each obligation

Record one status per requirement:

Status	Meaning
PASS	Evidence shows the required behavior or contract.
PARTIAL	Some required aspects are present; others are not.
DRIFT	The implementation differs in a behaviorally meaningful way.
MISSING	A bounded search found no implementation of a required behavior.
CONFLICT	Observed behavior contradicts the requirement.
UNVERIFIED	Available code, runtime access, or evidence cannot settle the question.

For each non-PASS result, cite the spec quote, the current code or test evidence, the scenario affected, and the smallest correction or verification step. Use MISSING only after a documented search of plausible implementation paths. A passing test supports PASS only when its assertions cover the actual obligation. Do not invent a confidence percentage.

After the first pass, re-read every non-PASS requirement and its candidate code path. Check whether another mechanism satisfies it and whether the spec is outdated or internally inconsistent. Record a spec defect separately; do not silently excuse code divergence or treat an invalid spec as immutable truth.

Check cross-cutting contracts only when the spec imposes them: dependency direction, authorization, data safety, lifecycle, concurrency, recovery, and public interfaces. Mark inapplicable dimensions rather than filling them with generic concerns.

Report

Return the spec identity, implementation scope, evidence limits, and a compact requirement matrix: ID, short requirement, spec location, implementation evidence, status, and impact. Group actionable discrepancies by priority and give one verdict: CONFORMS (all applicable obligations supported), DEVIATES (confirmed material gap), or INDETERMINATE (essential evidence or authority is unresolved). A limited audit must say which requirements were not checked; never imply exhaustive coverage from a sampled matrix.