---
name: review
description: Review repository changes for structural FEM correctness, architecture boundaries, safety, tests, and evidence without modifying them.
---

# Repository Review

Review the requested diff, or the current working-tree changes when no range is given. This skill is
read-only: do not fix findings unless the user separately asks for implementation.

## Required context

Read `AGENTS.md`, `docs/ARCHITECTURE.md`, `docs/ADR.md`, and the feature contracts directly affected by
the diff. Read `docs/TOLERANCE.md` for numerical or comparison changes. Use repository configuration to
discover actual build/test commands; do not assume a solver target exists.

## Review order

1. Identify changed public behavior, physics meaning, I/O/result identity, state ownership, and
   architecture boundaries.
2. Check that every production C++ change has a test and that behavior changes show meaningful RED/GREEN
   evidence.
3. For numerical code, verify units, coordinates, sign, DOF/component ordering, residual/tangent
   consistency, integration, trial/commit state, determinism, and tolerance ownership.
4. For Abaqus-facing code, review only the declared observable subset and reject undocumented internal
   equivalence claims or silent handling of unsupported semantics.
5. Run the smallest relevant checks, then the configured full build/test when available. Record exact
   commands and exit codes. An unavailable or skipped check is `not verified`, never `pass`.
6. Check that reference inputs/results and tolerance artifacts were not changed to fit implementation
   output, and that unrelated working-tree files are untouched.

## Findings

Report actionable defects first, ordered `critical`, `high`, `medium`, `low`. Each finding must contain:

- file and line
- violated contract or observable risk
- concrete evidence or reproduction
- smallest credible correction

Do not report style preferences without a project rule or meaningful maintenance risk. Do not infer a
defect solely because an external solver uses a different private implementation.

After findings, summarize:

| Gate | Result | Evidence or gap |
| --- | --- | --- |
| Requirements/architecture | pass/fail/not verified | details |
| Numerical and physical contract | pass/fail/not applicable/not verified | details |
| Tests and TDD evidence | pass/fail/not verified | details |
| Build/toolchain | pass/fail/not available/not verified | details |
| Reference/tolerance integrity | pass/fail/not applicable/not verified | details |
| Scope and repository safety | pass/fail/not verified | details |

If no defect is found, say so explicitly and list residual risks or checks that could not be executed.