Review against one fixed point. Keep the axes independent so strength in one cannot hide failure in another:

Each applicable axis gets an isolated reviewer. Aggregate their reports without merging or globally reranking findings.

Use the fixed point supplied by the user. Otherwise infer it from repository evidence: prefer the pull request's base branch, then a documented target branch, then the repository's default branch. Use their merge-base with as the fixed point. If no target branch can be identified, use ; for a root commit, use the empty tree. State the inferred point and the evidence for choosing it in the review. Do not ask the user to choose the comparison point.

Resolve it with , then capture these exact views once:

git diff <fixed-point>...HEAD
git log <fixed-point>..HEAD --oneline

The three-dot diff compares with the merge-base. Stop on an invalid ref or an empty diff.

Read repository instructions first. Require all three sources:

An explicit pointer in , , , or equivalent repository documentation may replace any canonical path. The pointed-to document is authoritative.

If any source is absent, stop before review dispatch, list the missing sources, and suggest that the user explicitly invoke . Do not invoke the setup skill autonomously and do not substitute an implicit baseline.

Read when present, then follow its pointers to relevant context and ADR files. Existing repository rules override generic review heuristics.

is optional. Read it, or an explicit normative pointer that replaces it, when present. It may add critical paths, representative workloads, budgets, benchmarks, or acceptance rules; its absence never blocks the Performance review. The universal performance baseline still applies.

Follow . Look in this order:

Ask for the source only after exhausting repository evidence. If the user confirms there is no spec, mark the Spec axis .

Find repository documents that govern changed code, such as , , , and scoped coding standards. Also read the smell baseline. Repository rules override the baseline, and tooling-enforced rules do not need manual findings.

Use for each review assignment. Before or alongside dispatch, tell the user the concrete model and reasoning effort for every reviewer, including any substitution. Start as many reviewers concurrently as capacity permits and queue the rest; never combine axes in one reviewer context.

Give every reviewer:

Each reviewer returns one of:

Use these axis briefs:

Provide every standards source and paste the smell baseline in full. Report documented rule breaches with a file-and-rule citation. Label smell findings as judgement calls, name the smell, and cite the changed hunk. Repository rules can be hard requirements; smells never are.

Provide the spec path and contents. Report missing or partial requirements, unrequested scope, and implementation that appears to satisfy a requirement incorrectly. Quote or precisely cite the controlling spec passage for each finding.

Provide the spec, the universal performance baseline in full, any repository performance source, and every available author-authored acknowledgement from the current chat, pull request, issue, or spec. First determine whether the diff changes runtime, build, tests, distribution, or a development feedback loop. Return when it changes none of them; return only after reviewing an applicable change.

Apply every relevant baseline and repository rule. Cite the changed hunk and controlling rule, preserve the baseline's evidence and acknowledgement labels, and give the user the complete causal explanation rather than leaving the mechanism for them to infer. Use only after checking the supplied evidence and other acknowledgement sources accessible in the reviewer context.

Provide the complete authoritative observability document. First determine whether the diff changes runtime behavior, failure modes, operational dependencies, or diagnostic paths. Apply every relevant repository requirement. Look especially for lost failure visibility, unusable signal context or correlation, unsafe data exposure, unbounded cardinality or volume, and operational behavior that cannot be verified. Cite the specific baseline rule for every finding; do not invent requirements absent from it.

Provide the complete authoritative accessibility document. First determine whether the diff changes a user-facing surface, content, interaction, accessibility API, or assistive-technology behavior. Apply every relevant repository requirement across the whole affected journey, including states and errors. Cite the specific baseline rule for every finding; do not treat automated checks as proof of requirements that need human or assistive-technology verification.

Present reports grouped by classification severity rather than by axis. Use the following headers in order:

Under each header, list the findings from all reviewers that match that classification. For each finding, preserve the reviewer's meaning and note which axis (Standards, Spec, Performance, Observability, Accessibility) it originated from. Do not deduplicate findings if they cover different aspects of the same issue. Lightly clean wording only.

End with a brief summary of the finding counts per classification.