KOKO\Mimi
2.6 KiB
name, description
| name | description |
|---|---|
| review | 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
- Identify changed public behavior, physics meaning, I/O/result identity, state ownership, and architecture boundaries.
- Check that every production C++ change has a test and that behavior changes show meaningful RED/GREEN evidence.
- For numerical code, verify units, coordinates, sign, DOF/component ordering, residual/tangent consistency, integration, trial/commit state, determinism, and tolerance ownership.
- For Abaqus-facing code, review only the declared observable subset and reject undocumented internal equivalence claims or silent handling of unsupported semantics.
- 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, neverpass. - 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.