Review Change

The quality gate for a change: get every review that applies — and skip the ones that don't — in one synthesized, classified report. Findings only; never edits or refactors.

When to use

• Mandatory before every merge — every unit (feature, single-pass, or fix) gets a

review-change pass; it's never skipped. execute-phase hands off to it every 2 phases and once more at the end.

• When you want the right reviews for this change without running irrelevant

passes (e.g. accessibility on a backend change).

Scope

Default target is the current change (branch diff vs the default branch); accept a path/glob to widen or narrow. State the scope at the top of the report.

Step 0 — Discover the project & the change (always first)

Per the agent guide's Workflow conventions + documentation map, then decide which axes apply from two inputs:

1. Project nature — from the guide/map: is there a UI (docs/frontend/

present)? Is it web, mobile, console/CLI, library/SDK, or backend/infra? Note the companion review skills the project expects (its init-workspace records them).

1. Change footprint — what the diff actually touches (UI components? an API?

infra? domain logic?). An axis applies only if both the project has it and the change touches it.

Applicability matrix (default; the project's docs refine it)

Process

1. Findings engine. Run review-implementation over the scope → its classified

decision table (fix-now / postpone / ignore / intentional-tradeoff).

1. SPEC drift check. Locate the governing SPEC (feature or fix) and compare

the diff against its scope and acceptance criteria: flag work that contradicts the SPEC, silently exceeds it, or leaves a claimed criterion untouched. Findings get axis spec-drift in the table. Catching drift at a phase checkpoint is far cheaper than at the audit-pr merge gate. (No SPEC found → note it and skip.)

1. Applicable externals. For each axis the matrix + footprint mark as relevant,

invoke the project's review skill for it (code-review, security-review, verify, design-review, accessibility-review, brand-review, tech-debt, the perf/SEO skills). Skip the rest and say which you skipped and why.

1. Missing companions. If an applicable skill isn't installed, note the gap and

do a best-effort inline pass for that axis rather than failing.

1. Synthesize. Merge all findings into one decision table, deduped by

file:line. Keep review-implementation's columns (Sev, Class, WHY, impl risk, long-term impact, premature-opt?, route) and add an Axis column.

1. Manual-verification checklist. List what automated review cannot confirm

and a human must check — visual correctness, real-device/locale behavior, UX feel, perf under load, anything marked verify. Be explicit so the dev has zero doubt about what to eyeball.

1. Triage everything not fixed now. For every finding you don't route to

fix-now (postpone / ignore / intentional-tradeoff), run it through triage-issue (compose in-turn — equal tier) to decide and record its home: a tracked issue with a trigger, a documented decision (decisions.md / a comment), or a justified drop. No non-fix-now finding may end without a destination — the point is to never silently lose one, and to catch the few that actually deserve an issue or a doc note.

1. Next step. Close with the suggested next command (clean → /audit-pr;

fix-now open → fold them, then re-review).

Example output (generic)

For a change to a backend export module (no UI surface):

Scope: branch diff vs main (src/export/**). Skipped: design / a11y / SEO / brand — no UI surface.

Manual-verification (automation can't confirm): - The exported file opens cleanly in a spreadsheet app. - An empty result set still produces a valid (header-only) file.

Routing

Every non-fix-now finding is routed through `triage-issue` (step 7) so its disposition is a decision, not a default:

• fix-now → plan-fix → execute-phase --fix, or fold into the current phase

if it's unmerged work.

• postpone → triage-issue → open a tracked issue with a trigger.
• intentional-tradeoff → triage-issue → record it (comment / decisions.md / issue).
• ignore → triage-issue → note the rationale (or confirm it truly needs nothing).

Guardrails

• Findings + tables only. Never refactor or edit code.
• Run only applicable axes; never an irrelevant pass (no a11y/SEO/brand for

CLI/lib/infra). Always report what was skipped and why.

• Honor the project's Workflow conventions (docs-language, evidence): cite

file:line, mark uncertainties verify.

Relationship to other skills

• Composes review-implementation (engine), triage-issue (every non-fix-now

finding — equal tier, in-turn), and the project's companion review skills.

• Sits in Stage 4 of the feature workflow; execute-phase hands off to it every 2

phases and for the mandatory end review (it runs in its own turn). fix-now → plan-fix; everything else → triage-issue.

• audit-pr is the PR-level gate it feeds; product-audit the periodic full sweep.

Done when

• One synthesized, classified decision table across all applicable axes exists,

the skipped axes are listed with reasons, and the manual-verification checklist is explicit.

• Every finding has a destination: fix-now routed, and every non-fix-now finding

put through triage-issue (issue / documented decision / justified drop) — none silently lost.

• The next step is printed (clean → /audit-pr), and no code changed.