KOKO\Mimi
56 lines
2.6 KiB
Markdown
56 lines
2.6 KiB
Markdown
---
|
|
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.
|