Five-axis code review

Review

HEAD

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

Standards: repository rules plus the heuristic smell baseline below.
Spec: fidelity to the originating requirement.
Performance: concrete regression risks, measured regressions, and consciously accepted performance trade-offs.
Observability: fidelity to the repository's operational baseline.
Accessibility: fidelity to the repository's accessibility baseline.

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

1. Pin the comparison

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

HEAD

as the fixed point. If no target branch can be identified, use

HEAD^

; 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

git rev-parse <fixed-point>

, then capture these exact views once:

text

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

The three-dot diff compares

HEAD

with the merge-base. Stop on an invalid ref or an empty diff.

2. Require repository configuration

Read repository instructions first. Require all three sources:

```
docs/agents/issue-tracker.md
```
```
OBSERVABILITY.md
```
```
ACCESSIBILITY.md
```

An explicit pointer in

AGENTS.md

CLAUDE.md

CONTRIBUTING.md

, 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

$setup-beto-frega-skills

. Do not invoke the setup skill autonomously and do not substitute an implicit baseline.

Read

docs/agents/domain.md

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

PERFORMANCE.md

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.

3. Resolve the spec

docs/agents/issue-tracker.md

. Look in this order:

Issue or merge-request references in
```
git log <fixed-point>..HEAD --oneline
```
.
A spec path or issue supplied by the user.
A matching file under
```
docs/
```
,
```
specs/
```
, or
```
.scratch/
```
.
Pull-request metadata when the current branch identifies a pull request.

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

N/A — no spec available

4. Resolve standards

Find repository documents that govern changed code, such as

AGENTS.md

CLAUDE.md

CONTRIBUTING.md

, and scoped coding standards. Also read the smell baseline. Repository rules override the baseline, and tooling-enforced rules do not need manual findings.

5. Dispatch isolated reviewers

Use

model-selection

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:

the fixed point, full diff command, and commit-list command;
the changed-file list and applicable repository instructions;
its authoritative source documents or contents;
this finding format: classification, location, evidence, impact, and smallest credible correction;
the classification must be exactly one of:
- PR Blocker: Causes a defect or regression if merged. Alters production behavior contrary to spec. Must be fixed before approval.
- Feature Blocker: Prevents the feature from working as specified, but is behind a feature flag (no prod regression). Can be fixed in the PR, or must generate a ticket blocking the feature and its flag activation. Infer feature flags from diff patterns (e.g.,
```
if (isFeatureEnabled(...))
```
  ) or PR/Spec metadata.
- Tech Debt: No functional/non-functional regression, but significantly reduces maintainability.
- Improvement: Optional maintainability improvement.
a limit of 400 words, findings ordered by classification severity;
the constraint to report only actionable defects introduced or materially exposed by the diff, without praise, pass lists, or speculative hardening.

Each reviewer returns one of:

findings;
```
No findings
```
;
```
N/A — <brief evidence-backed reason>
```
when the axis does not apply.

Use these axis briefs:

Standards reviewer

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.

Spec reviewer

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.

Performance reviewer

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

N/A

when it changes none of them; return

No findings

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

Author acknowledgement: Not found

only after checking the supplied evidence and other acknowledgement sources accessible in the reviewer context.

Observability reviewer

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.

Accessibility reviewer

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.

6. Aggregate by classification

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

```
## PR Blockers
```
```
## Feature Blockers
```
```
## Tech Debt
```
```
## Improvements
```

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.

code-review

NPX Install

Tags

SKILL.md Content