Review Implementation (internal scope/classification engine)

The classification engine the review/audit skills compose: it consumes the synthesized findings table (the fused output of the applicable per-axis passes), verifies every applicable axis is represented, and returns the classified decision table — then stops. Never refactors or edits code. It owns the scope/axis-coverage contract and the classification rubric (the current-unit contract + routing) that review-change, audit-pr, and product-audit reference instead of restating.

It does not scan the diff: every finding concern has exactly one owning pass (see the axis ownership map) — the per-axis passes (review-code, review-security, review-verify, review-perf, design/a11y/brand/SEO) find, and this engine classifies. No broad findings scan here.

When to use

• Invoked by review-change (the user-facing review entry) as its classification engine, over the fused findings table.
• The audit skills reference its rubric and coverage contract.

Scope

The caller's scope statement (the branch diff vs. the default branch, or the passed path/glob) is authoritative; the synthesized table was gathered over it. State the scope at the top of the classified report.

Step 0 — Discover the project (always first)

Per the agent guide's Workflow conventions + documentation map, read what THIS skill needs: the architecture/layering rules, the testing philosophy, and any runtime/platform, security, money, i18n/SEO/a11y and bundle rules. Pull the project's specific risk axes from its guardrail skills where present. The FIND.md axis map is the default; the project's docs refine which axes are applicable.

Step 1 — Verify axis coverage (the synthesized table)

For the declared scope, confirm every applicable axis is represented in the synthesized findings table — one finding owner per axis, per the FIND.md map: an axis the change touches that the table says nothing about is a missing-axis finding (axis coverage), not a silent pass. Overlapping signals from different passes on the same defect collapse into one row during synthesis — the table must contain neither duplicates nor gaps. State which axes were applicable and confirm each appears.

Step 2 — Classify (the current-unit contract)

Read Classify and route and classify every row of the synthesized table without reopening source files: ignore first (the claim), then the current-unit contract (fix-now / replan-in-unit / decision-required for in-scope work), then proposal for genuinely independent future capabilities. One pass — no per-pass or per-reviewer classification.

Context budget

The input is the synthesized table, not the diff. Read at most 10 non-diff files in full for surrounding context (callers, contracts, SPEC); targeted reads (≤ 50 lines of a named range) and grep/glob results don't count. Record each classification as its table row immediately and drop raw file content.

Guardrails

• Findings + table only. Never refactor or edit code in this skill.
• One classifier. Classification happens HERE, once, over the fused table — never per-reviewer, never re-litigated in the per-axis passes.
• Honor the dead-code exception — staged/planned code is not dead code.
• Don't inflate severity; separate "correctness/security" from "taste".
• Don't deflate either: current-unit work is never postpone/tradeoff/ wontfix/disputed and never a new issue — size routes to replan-in-unit, not to a downgrade (current-unit contract in CLASSIFY.md).
• Otherwise per the project's Workflow conventions (docs-language, evidence): cite file:line, mark uncertainties verify.

Relationship to other skills

• Classification engine of review-change — the user-facing review skill runs the applicable per-axis passes (the finders), fuses their tables, then composes this engine to classify. audit-pr and product-audit reuse this rubric.
• Sits in Stage 4 of the feature workflow (verification & review).
• fix-now folds into the current unit; replan-in-unit runs node scripts/unit-route.mjs <unit>, whose route: replan line names the planner that appends user-confirmed phases before execute-phase; decision-required blocks for the user; independent work becomes proposals the user routes to triage-issue (D3).

Done when

• A synthesized table consumed, axis coverage verified (no applicable axis missing, no duplicate rows), every finding classified with reasoning and routed — and no code changed.