baram2584/FESADev
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

update agent, skill and scripts

Browse Source
This commit is contained in:
KOKO\Mimi
2026-09-07 01:15:26 +09:00
parent 42a4847da5
commit d7e9629640
38 changed files with 476 additions and 2946 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.agents/skills/review/SKILL.md
+4 -47
View File
@@ -1,55 +1,12 @@
---
name: review
description: Review repository changes for structural FEM correctness, architecture boundaries, safety, tests, and evidence without modifying them.
description: Read-only review of requested repository changes for relevant FEM contracts, correctness, tests, and scope.
---
# 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.
Review the requested diff, or current working-tree changes when no range is supplied. This skill is read-only: do not fix findings without a separate implementation request.
## Required context
Read only the contracts and architecture sections affected by the diff; read `docs/TOLERANCE.md` for numerical/comparison changes. Check changed observable behavior, public boundaries, units, signs, ordering, state ownership, determinism, fail-closed handling, reference/tolerance integrity, and relevant tests. Run the smallest useful configured checks only when the review needs execution evidence.
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.
Report actionable findings first, ordered by severity. Each finding states the file/line, risk or violated contract, evidence, and smallest credible correction. Then summarize checks run, gaps, and residual risks. Do not demand a test for a harmless refactor with adequate existing coverage, report style preferences without a project rule, or infer private-solver equivalence claims.