add skills

2026-06-04 15:03:03 +09:00
parent 1daf68afb9
commit 9b31adfd15
42 changed files with 1401 additions and 398 deletions
@@ -12,6 +12,9 @@ Mission:
 - Record command, exit code, duration, stdout/stderr summary, failed test names, and failure classification.
 - Keep the output aligned with AGENTS.md, docs/SOLVER_AGENT_DESIGN.md, scripts/validate_workspace.py, and the implementation plan/report.

+Skill references:
+- Use $fesa-cpp-msvc-tdd when running C++/MSVC/CMake/CTest validation, recording validation evidence, classifying build/test failures, or preparing build/test handoffs.
+
 Hard boundaries:
 - Do not edit source code.
 - Do not edit tests.
@@ -12,6 +12,11 @@ Mission:
 - Manage gate evidence, handoffs, blockers, rework loops, and user decision points.
 - Keep coordination aligned with docs/SOLVER_AGENT_DESIGN.md, AGENTS.md, and all available agent outputs.

+Skill references:
+- Use $fesa-requirements-baseline when intake, gate audit, or handoff work depends on requirements, acceptance criteria, verification quantities, tolerance decisions, or Requirement Verification Matrix evidence.
+- Use $fesa-reference-models when workflow state depends on reference model coverage, artifact bundle readiness, metadata provenance, tolerance mapping, or reference artifact blockers.
+- Use $fesa-release-readiness when coordinating release gate evidence, known limitations, release notes readiness, final workflow closure, or release blocker routing.
+
 Hard boundaries:
 - Do not implement code.
 - Do not edit source code.
@@ -12,6 +12,9 @@ Mission:
 - Apply the smallest source, header, test, or CMake change that restores the approved implementation plan and existing contracts.
 - Keep the output aligned with AGENTS.md, docs/SOLVER_AGENT_DESIGN.md, failure reports, implementation reports, and implementation plans.

+Skill references:
+- Use $fesa-cpp-msvc-tdd when triaging configure, compile, link, test, reference-comparison, harness, environment, or upstream-contract failures and applying minimal C++/MSVC/CMake/CTest corrections.
+
 Hard boundaries:
 - Do not change requirements.
 - Do not change formulations.
@@ -11,6 +11,10 @@ Mission:
 - Define the mathematical and algorithmic contract that Implementation Planning Agent and Implementation Agent can use later.
 - Keep the output aligned with docs/SOLVER_AGENT_DESIGN.md, docs/requirements/<feature-id>.md, and docs/research/<feature-id>-research.md.

+Skill references:
+- Use $fesa-formulation-spec when drafting or revising FEM formulation specifications, strong or weak forms, shape functions, element equations, numerical integration, Jacobian rules, or output recovery contracts.
+- Use $fem-theory-query when formulation work needs wiki-grounded FEM theory for element interpolation, B matrices, residual/tangent forms, constitutive integration, contact, dynamics, eigenproblems, or verification design.
+
 Hard boundaries:
 - Do not implement code.
 - Do not design C++ APIs or file ownership.
@@ -12,6 +12,9 @@ Mission:
 - Produce C++ source/header changes, C++ test changes, and CMake/CTest changes needed by the approved plan.
 - Keep the output aligned with AGENTS.md, docs/SOLVER_AGENT_DESIGN.md, and docs/implementation-plans/<feature-id>-implementation-plan.md.

+Skill references:
+- Use $fesa-cpp-msvc-tdd when writing C++17/MSVC tests first, verifying RED failures, implementing minimal solver code, registering CMake/CTest targets, running validation, or preparing implementation reports.
+
 Hard boundaries:
 - Do not change requirements, formulations, I/O contracts, numerical review reports, reference artifacts, or tolerance policies unless the user explicitly asks.
 - Do not change formulations directly to make implementation easier.
@@ -11,6 +11,12 @@ Mission:
 - Define implementation order, failing tests to write first, CMake/CTest registration needs, candidate files, and acceptance checklist.
 - Keep the output aligned with docs/SOLVER_AGENT_DESIGN.md, AGENTS.md, and related requirement, research, formulation, numerical review, I/O definition, and reference model documents.

+Skill references:
+- Use $fesa-formulation-spec when checking formulation inputs, output recovery contracts, or math-level algorithm handoff items.
+- Use $fesa-reference-models when checking reference model coverage, artifact bundle contracts, tolerance mapping, or tests that should fail first.
+- Use $fesa-cpp-msvc-tdd when creating TDD-first C++/MSVC implementation plans, test order, CMake/CTest plans, validation commands, or implementation handoffs.
+- Use $fem-theory-query when implementation planning needs wiki-grounded formulation, solver architecture, verification design, benchmark, or numerical-risk context without changing upstream contracts.
+
 Hard boundaries:
 - Do not implement code.
 - Do not write tests.
@@ -12,6 +12,10 @@ Mission:
 - Define the supported Abaqus keyword subset, internal solver model mapping, output request mapping, and comparison CSV schemas for each feature.
 - Keep the output aligned with docs/SOLVER_AGENT_DESIGN.md and related requirements, research, formulation, and numerical review documents.

+Skill references:
+- Use $fesa-io-contract when defining Abaqus .inp keyword subsets, internal model mapping, validation rules, result CSV schemas, units, coordinate systems, component naming, or ID matching contracts.
+- Use $fem-theory-query when I/O contracts need wiki-grounded solver manual evidence for Abaqus input syntax, output requests, element result quantities, coordinate systems, or verification CSV semantics.
+
 Hard boundaries:
 - Do not implement parsers.
 - Do not design C++ APIs or file ownership.
@@ -12,6 +12,10 @@ Mission:
 - Decide whether a formulation can move to Implementation Planning Agent.
 - Keep the output aligned with docs/SOLVER_AGENT_DESIGN.md and docs/formulations/<feature-id>-formulation.md.

+Skill references:
+- Use $fesa-numerical-review when reviewing formulation correctness, dimensional consistency, stability risks, patch tests, locking, hourglass, Jacobian handling, or implementation-planning readiness.
+- Use $fem-theory-query when review findings need wiki-grounded FEM theory, solver manual evidence, benchmark context, residual/tangent checks, constitutive integration checks, or verification references.
+
 Hard boundaries:
 - Do not implement code.
 - Do not edit formulations directly.
@@ -12,6 +12,10 @@ Mission:
 - Check whether the solver behavior is physically credible enough to hand off to Release Agent.
 - Keep the output aligned with docs/SOLVER_AGENT_DESIGN.md, reference verification reports, reference model contracts, requirements, formulations, numerical reviews, I/O definitions, and stored solver/reference CSVs.

+Skill references:
+- Use $fesa-physics-sanity when evaluating physical plausibility after reference verification, including global equilibrium, reaction consistency, displacement direction, symmetry, element force balance, stress sanity, rigid body mode symptoms, or model coverage.
+- Use $fem-theory-query when physics evaluation needs wiki-grounded evidence for equilibrium, reactions, stress/strain sanity, element force balance, benchmark expectations, or model coverage gaps.
+
 Hard boundaries:
 - Do not edit source code.
 - Do not edit tests.
@@ -12,6 +12,10 @@ Mission:
 - Define model purposes, Abaqus .inp requirements, required reference artifacts, metadata provenance, output CSV requirements, tolerance mapping, coverage matrix, and downstream handoff.
 - Keep the output aligned with docs/SOLVER_AGENT_DESIGN.md and related requirements, research, formulation, numerical review, and I/O definition documents.

+Skill references:
+- Use $fesa-reference-models when designing reference model portfolios, Abaqus input artifact bundles, metadata provenance, required reference CSV artifacts, coverage matrices, or implementation-planning handoffs.
+- Use $fem-theory-query when reference model design needs wiki-grounded benchmark, patch test, solver manual, formulation, verification quantity, or source-solver comparison evidence.
+
 Hard boundaries:
 - Do not implement code.
 - Do not implement parsers.
@@ -12,6 +12,10 @@ Mission:
 - Report tolerance-based verification outcomes for displacements, reactions, element forces, stresses, and approved optional quantities.
 - Keep the output aligned with docs/SOLVER_AGENT_DESIGN.md, reference model contracts, I/O definitions, build/test reports, implementation reports, generated solver result CSVs, and stored references/<feature-id>/<model-id>/ artifacts.

+Skill references:
+- Use $fesa-reference-comparison when comparing generated solver result CSVs with stored reference CSV artifacts, checking schema, units, ID matching, tolerance metrics, or reference verification status.
+- Use $fesa-io-contract when comparison is blocked by Abaqus input scope, output CSV schema, units, coordinate system, output location, component naming, or ID matching ambiguity.
+
 Hard boundaries:
 - Do not edit source code.
 - Do not edit tests.
@@ -12,6 +12,9 @@ Mission:
 - Prepare a release checklist, known limitations, and release notes draft for a solver feature.
 - Keep the output aligned with docs/SOLVER_AGENT_DESIGN.md, upstream gate reports, requirements, formulations, numerical reviews, I/O definitions, reference models, build/test evidence, reference verification reports, and physics evaluation reports.

+Skill references:
+- Use $fesa-release-readiness when auditing release readiness, upstream gate evidence, acceptance traceability, known limitations, release notes drafts, or final feature release verdicts.
+
 Hard boundaries:
 - Do not implement code.
 - Do not edit source code.
@@ -11,6 +11,9 @@ Mission:
 - Produce a Feature Requirement Specification and a Requirement Verification Matrix.
 - Keep the output aligned with docs/SOLVER_AGENT_DESIGN.md.

+Skill references:
+- Use $fesa-requirements-baseline when drafting or revising requirements, acceptance criteria, tolerance decisions, verification quantities, reference artifact requirements, or Requirement Verification Matrix entries.
+
 Hard boundaries:
 - Do not implement code.
 - Do not write finite element formulations.
@@ -11,6 +11,10 @@ Mission:
 - Produce a traceable research brief that downstream agents can use for formulation, numerical review, reference model design, and implementation planning.
 - Keep the output aligned with docs/SOLVER_AGENT_DESIGN.md and any docs/requirements/<feature-id>.md requirement baseline.

+Skill references:
+- Use $fesa-research-evidence when collecting research evidence, FEM theory sources, benchmark candidates, source reliability tiers, applicability limits, or downstream formulation/reference-model handoff evidence.
+- Use $fem-theory-query when answering FEM theory, structural solver, element formulation, benchmark, verification, or solver manual questions from the configured FEM wiki vault.
+
 Hard boundaries:
 - Do not implement code.
 - Do not finalize FEM formulations.
@@ -0,0 +1,141 @@
+---
+name: fem-theory-query
+description: Use when answering finite element method, structural analysis solver, element formulation, residual/tangent, constitutive integration, contact, dynamics, eigenproblem, or verification questions from a configured FEM wiki vault.
+---
+
+# FEM Theory Query
+
+Use this skill as a portable domain router for finite element method and structural solver theory questions. Ground answers in a configured FEM wiki vault, then compose sibling skills instead of reimplementing their workflows.
+
+## FEM Vault Resolution
+
+Resolve the FEM wiki vault in this order:
+
+1. Skill-local config file: `vault-path.txt` in this skill folder. Read the first non-empty, non-comment line as the vault root path.
+2. Current project instructions: `AGENTS.md`, `CLAUDE.md`, or an equivalent section named `FEM Solver Theory Wiki`.
+3. Environment variable: `FEM_THEORY_WIKI_VAULT`.
+
+If no valid vault is found, ask the user for the vault path. A valid vault must contain `wiki/hot.md` or `wiki/index.md`.
+
+Keep `vault-path.txt` PC-specific. When the vault moves, update that file instead of editing this skill body.
+
+## Companion Skill Protocols
+
+This skill is an orchestrator. Do not reimplement sibling skills. Use the sibling skill instructions as authoritative when available.
+
+### Companion skill path resolution
+
+After reading `vault-path.txt`, call that value `FEM_VAULT_ROOT`. Resolve companion skill files from that absolute vault root:
+
+- `FEM_VAULT_ROOT\skills\think\SKILL.md`: use for non-trivial FEM formulation, solver architecture, ambiguity, tradeoffs, verification design, or gap assessment.
+- `FEM_VAULT_ROOT\skills\wiki-query\SKILL.md`: use for normal wiki-grounded answers from the configured FEM vault.
+- `FEM_VAULT_ROOT\skills\autoresearch\SKILL.md`: use only when the user explicitly asks to research, find sources, update the wiki, or fill missing wiki coverage.
+
+If the runtime provides a skill activation mechanism, activate the companion skill by name. If not, read the absolute companion `SKILL.md` path constructed from `vault-path.txt` and follow its workflow. If an absolute companion path does not exist, tell the user which path is missing and ask them to fix `vault-path.txt`.
+
+### Relative paths inside companion skills
+
+When a companion skill refers to another file by a relative path, resolve that path from the absolute directory of the companion skill file under `FEM_VAULT_ROOT`, not from the caller project or current working directory. Normalize `..` segments after joining paths. Keep the resolved path inside `FEM_VAULT_ROOT` unless the companion skill explicitly requires an external path.
+
+Examples from `FEM_VAULT_ROOT\skills\autoresearch\SKILL.md`:
+
+- `../wiki-cli/SKILL.md` resolves to `FEM_VAULT_ROOT\skills\wiki-cli\SKILL.md`.
+- `../../wiki/references/transport-fallback.md` resolves to `FEM_VAULT_ROOT\wiki\references\transport-fallback.md`.
+- `references/program.md` resolves to `FEM_VAULT_ROOT\skills\autoresearch\references\program.md`.
+
+If a resolved companion-relative path is missing, report the missing absolute path and ask the user to fix `vault-path.txt` or install the full `skills/` bundle.
+
+### How to use `think`
+
+Use `think` as a compact internal preflight before answering FEM solver questions.
+
+Do:
+- Identify the user's real question: theory derivation, implementation design, verification, comparison, or missing source.
+- Check whether you are relying on memory instead of wiki evidence.
+- Decide whether the answer can be handled by wiki query or needs autoresearch.
+- For complex questions, surface the reasoning structure briefly in the answer.
+
+Do not:
+- Print all 10 stages for routine factual questions.
+- Use `think` as a substitute for reading wiki sources.
+- Skip the `ACCEPT` step when the wiki has insufficient coverage.
+
+### How to use `wiki-query`
+
+Use `wiki-query` for the default answer path.
+
+Follow this order:
+
+1. Resolve the FEM vault path.
+2. Read `wiki/hot.md`.
+3. If needed, use `wiki-retrieve` when provisioned: `python scripts/retrieve.py "<question>" --top 5`.
+4. If retrieval is not provisioned or fails, read `wiki/index.md`.
+5. Read 3-7 relevant wiki pages.
+6. Synthesize with Obsidian wikilink citations.
+
+Do:
+- Cite every core claim with `[[Page Name]]`.
+- Prefer vault evidence over model memory.
+- Say clearly when the wiki lacks enough evidence.
+
+Do not:
+- Answer a vault-specific question from training data alone.
+- Open many pages when 3-7 are enough.
+- Write to the wiki unless the user explicitly asks.
+
+### How to use `autoresearch`
+
+Use `autoresearch` only for explicit research or wiki-expansion requests.
+
+Trigger examples:
+- "Find sources and strengthen this wiki coverage."
+- "If the wiki does not cover this, research it."
+- "Research and file this topic."
+- "Create source and concept pages for this topic."
+
+Before starting:
+- Tell the user it will use web search/fetch and write new wiki pages.
+- Mention that fetched content is subject to the `autoresearch` web egress hygiene rules.
+- Ask for approval unless the user already gave explicit approval in the same request.
+
+Do:
+- Read `FEM_VAULT_ROOT\skills\autoresearch\SKILL.md` and `FEM_VAULT_ROOT\skills\autoresearch\references\program.md`.
+- File results into the configured FEM vault, not the caller project.
+- Use wiki locks and transport rules from the sibling skill.
+
+Do not:
+- Run autoresearch for ordinary Q&A.
+- Fetch web sources silently.
+- Write into `.raw/` or `wiki/` without explicit user intent.
+
+## Answer Contract
+
+Answer in the user's language. For Korean questions, translate the section headings naturally.
+
+Use this structure unless the user asks for another format:
+
+- Summary conclusion
+- Formulation
+- Solver implementation view
+- Verification and benchmarks
+- Evidence
+- Wiki gap
+
+Every core technical claim should trace to wiki evidence. Use Obsidian wikilinks such as `[[Finite Element Method]]`, `[[Solid Element Stiffness Integration]]`, or the relevant source page. If the wiki does not cover a point, label it as a gap instead of presenting model memory as vault knowledge.
+
+## FEM Query Expansion
+
+When a user asks a short FEM question, expand the retrieval intent before searching:
+
+- Element formulation: shape functions, DOFs, Jacobian, `B` matrix, integration, load vector, result recovery.
+- Nonlinear solve: residual, tangent, Newton update, convergence norms, load/time increments, cutback policy.
+- Constitutive update: stress update, material tangent, state variables, return mapping, history evolution.
+- Dynamics/eigen: mass, damping, time integration, modal extraction, normalization, residual checks.
+- Contact/constraints: gap, normal/tangential law, penalty or multiplier enforcement, search, tangent contribution.
+- Verification: patch tests, convergence, benchmark problems, matrix checks, residual norms, source-solver comparison.
+
+Keep expansion internal unless showing it helps the user understand the answer.
+
+## Deployment Notes
+
+Distribute this skill with the whole `skills/` bundle so sibling paths remain valid. After installing or symlinking the bundle into another agent, update `vault-path.txt` for that PC or set `FEM_THEORY_WIKI_VAULT`.
@@ -0,0 +1,4 @@
+interface:
+  display_name: "FEM Theory Query"
+  short_description: "Query FEM solver theory from wiki."
+  default_prompt: "Use $fem-theory-query to answer a finite-element structural solver formulation question from the wiki."
@@ -0,0 +1,3 @@
+# FEM wiki vault root path.
+# Edit this per PC. Use an absolute path to the vault that contains wiki/ and .raw/.
+D:\Obsidian\MultiPhysicsVault
@@ -0,0 +1,81 @@
+---
+name: fesa-cpp-msvc-tdd
+description: Use when planning, implementing, validating, or correcting FESA solver C++17 MSVC CMake CTest work with TDD, build/test failure triage, or implementation-plan handoffs.
+---
+
+# FESA C++ MSVC TDD
+
+Use this skill to keep FESA C++ implementation work test-first, MSVC-compatible, and bounded by approved upstream contracts.
+
+## Inputs
+
+Read these first:
+
+- `AGENTS.md`
+- `docs/SOLVER_AGENT_DESIGN.md`
+- `docs/implementation-plans/README.md`
+- `docs/build-test-reports/README.md`
+- `docs/corrections/README.md`
+- `docs/implementation-plans/<feature-id>-implementation-plan.md`
+- Related requirements, formulation, numerical review, I/O definition, and reference model documents
+
+## Workflow
+
+1. For planning, convert upstream documents into small ordered tasks and test ids.
+2. For implementation, follow `RED -> GREEN -> VERIFY`.
+3. RED: write the planned unit, integration, parser/I/O, or reference-comparison test first.
+4. RED: run the targeted test and verify the expected failure before production code.
+5. GREEN: implement the minimum C++17/MSVC-compatible code needed for the task.
+6. VERIFY: run the targeted command, then `python scripts/validate_workspace.py`.
+7. For C++ production changes, require a related C++ test file in the same patch or already present.
+8. For failure triage, classify as `configure | compile | link | test | reference-comparison | harness | environment | upstream-contract`.
+9. Fix implementation-owned failures only and keep changes traceable to the implementation plan.
+
+## Output Contract
+
+Produce one of these, depending on role:
+
+- `docs/implementation-plans/<feature-id>-implementation-plan.md`
+- Implementation report with RED/GREEN/VERIFY evidence
+- `docs/build-test-reports/<feature-id>-build-test.md`
+- `docs/corrections/<feature-id>-correction.md`
+
+Required validation commands:
+
+```powershell
+python -m unittest discover -s scripts -p "test_*.py"
+python scripts/validate_workspace.py
+ctest -C Debug -R <feature-or-label>
+```
+
+Default MSVC path:
+
+```powershell
+cmake -S . -B build/msvc-debug -G "Visual Studio 17 2022" -A x64
+cmake --build build/msvc-debug --config Debug
+ctest --test-dir build/msvc-debug --output-on-failure -C Debug
+```
+
+## Boundaries
+
+- Do not change requirements.
+- Do not change formulations.
+- Do not change I/O contracts.
+- Do not change numerical review reports.
+- Do not change reference artifacts.
+- Do not change tolerance policies.
+- Do not run Abaqus, Nastran, or any reference solver.
+- Do not generate reference CSVs.
+- Do not approve release readiness.
+
+## Quality Gate
+
+- Every `must` requirement maps to at least one task and one test.
+- Each test has a clear RED condition, GREEN condition, linked task, and command.
+- CMake/CTest plans remain compatible with MSVC x64 Debug validation.
+- Build/test reports record command, exit code, duration, stdout/stderr tail, and failure classification.
+- Correction attempts stop when repeated failure indicates upstream contract ambiguity.
+
+## Handoff
+
+Send passing build/test evidence to Reference Verification Agent. Send implementation-owned failures to Correction Agent. Send upstream-contract failures to the owning upstream agent through Coordinator Agent.
@@ -0,0 +1,4 @@
+interface:
+  display_name: "FESA C++ MSVC TDD"
+  short_description: "Plan and execute C++ TDD work"
+  default_prompt: "Use $fesa-cpp-msvc-tdd for FESA C++17 MSVC TDD implementation work."
@@ -0,0 +1,69 @@
+---
+name: fesa-formulation-spec
+description: Use when drafting FESA FEM formulation specifications, strong or weak forms, shape functions, element equations, numerical integration, Jacobian rules, and output recovery contracts.
+---
+
+# FESA Formulation Spec
+
+Use this skill to turn approved requirements and research evidence into an implementable math-level FEM contract.
+
+## Inputs
+
+Read these first:
+
+- `AGENTS.md`
+- `docs/SOLVER_AGENT_DESIGN.md`
+- `docs/formulations/README.md`
+- `docs/requirements/<feature-id>.md`
+- `docs/research/<feature-id>-research.md`
+
+## Workflow
+
+1. Confirm scope, assumptions, primary variables, DOFs, sign convention, units, and coordinate system.
+2. Write the Strong Form and boundary conditions.
+3. Write the Weak or Variational Form and natural boundary terms.
+4. Define Discretization: interpolation, shape functions, partition of unity, Kronecker delta checks, and nodal layout.
+5. Define Kinematics: strain-displacement relation, B matrix or kinematic operator, strain measure, and deformation assumptions.
+6. Define Constitutive Contract without creating C++ APIs.
+7. Define Element Equations: residual or internal force, external force, stiffness or tangent, mass or damping when applicable, and dimensions.
+8. Define Mapping and Numerical Integration: reference coordinates, isoparametric mapping, Jacobian, derivative transform, determinant checks, Gauss points, and weights.
+9. Define Output Recovery for displacement, reaction, element force, strain, stress, and nodal extrapolation.
+10. List Numerical Risks and downstream tests.
+
+## Output Contract
+
+Produce or revise `docs/formulations/<feature-id>-formulation.md` with:
+
+- Scope and Assumptions
+- Primary Variables and DOFs
+- Strong Form
+- Weak or Variational Form
+- Discretization
+- Kinematics
+- Constitutive Contract
+- Element Equations
+- Mapping and Numerical Integration
+- Output Recovery
+- Algorithm Pseudocode
+- Numerical Risks
+- Open Issues and Downstream Handoff
+
+## Boundaries
+
+- Do not implement C++ code.
+- Do not design C++ APIs.
+- Do not implement parsers.
+- Do not run Abaqus, Nastran, or any reference solver.
+- Do not generate reference CSVs.
+- Do not approve release readiness.
+
+## Quality Gate
+
+- Strong form, weak form, discretization, kinematics, constitutive contract, and element equations are distinct.
+- Shape functions include partition of unity and Kronecker delta checks when applicable.
+- Jacobian, determinant validity, derivative transform, integration rule, and output location are explicit.
+- Missing research or requirements become open issues, not assumptions.
+
+## Handoff
+
+Send the formulation to Numerical Review Agent first. After review, pass implementation-relevant pseudocode and acceptance quantities to Implementation Planning Agent, I/O needs to I/O Definition Agent, and benchmarkable checks to Reference Model Agent.
@@ -0,0 +1,4 @@
+interface:
+  display_name: "FESA Formulation Spec"
+  short_description: "Write FEM formulation specs"
+  default_prompt: "Use $fesa-formulation-spec to draft implementable FESA FEM formulation specs."
@@ -0,0 +1,63 @@
+---
+name: fesa-io-contract
+description: Use when defining FESA solver I/O contracts, Abaqus .inp keyword subsets, internal model mapping, validation rules, and CSV schemas for solver outputs or reference comparison.
+---
+
+# FESA I/O Contract
+
+Use this skill to define exactly what input and output data the solver feature accepts and produces.
+
+## Inputs
+
+Read these first:
+
+- `AGENTS.md`
+- `docs/SOLVER_AGENT_DESIGN.md`
+- `docs/io-definitions/README.md`
+- `docs/requirements/<feature-id>.md`
+- `docs/formulations/<feature-id>-formulation.md`
+- Numerical review and reference model documents when present
+
+## Workflow
+
+1. Define Abaqus Input Scope for the feature-specific `.inp` subset.
+2. Define Syntax Policy for keyword lines, data lines, comments, unsupported keywords, and diagnostics.
+3. Separate Model Data Mapping from History Data Mapping.
+4. Define supported keywords such as `*NODE`, `*ELEMENT`, `*MATERIAL`, `*ELASTIC`, `*BOUNDARY`, `*CLOAD`, `*STEP`, `*OUTPUT`, `*NODE OUTPUT`, and `*ELEMENT OUTPUT` only when required.
+5. Define Internal Model Contract at a semantic level without C++ APIs.
+6. Define Output and CSV Schemas for `displacements.csv`, `reactions.csv`, `element_forces.csv`, `stresses.csv`, and optional result files.
+7. Define units, coordinate system, component naming, output location, step/frame identity, and ID matching rules.
+8. Define validation rules and open issues.
+
+## Output Contract
+
+Produce or revise `docs/io-definitions/<feature-id>-io.md` with:
+
+- Abaqus Input Scope
+- Syntax Policy
+- Model Data Mapping
+- History Data Mapping
+- Internal Model Contract
+- Output and CSV Schemas
+- Validation Rules
+- Downstream Handoff
+
+## Boundaries
+
+- Do not implement parsers.
+- Do not design C++ APIs.
+- Do not claim full Abaqus compatibility.
+- Do not run Abaqus, Nastran, or any reference solver.
+- Do not generate reference CSVs.
+- Do not approve release readiness.
+
+## Quality Gate
+
+- Every supported keyword has a documented purpose, required data, and unsupported-case behavior.
+- CSV schemas carry units, coordinate system, component naming, output location, and ID matching rules.
+- Unsupported Abaqus input is explicit: unsupported, ignored-with-warning, or requires user decision.
+- The I/O contract is compatible with requirements, formulation, and reference comparison needs.
+
+## Handoff
+
+Send keyword and schema contracts to Reference Model Agent and Implementation Planning Agent. Send comparison schema, ID matching, and tolerance-source constraints to Reference Verification Agent.
@@ -0,0 +1,4 @@
+interface:
+  display_name: "FESA I/O Contract"
+  short_description: "Define solver I/O contracts"
+  default_prompt: "Use $fesa-io-contract to define Abaqus input and result CSV contracts."
@@ -0,0 +1,64 @@
+---
+name: fesa-numerical-review
+description: Use when independently reviewing FESA FEM numerical review evidence, formulation correctness, stability risks, patch tests, locking, Jacobian handling, and implementation planning readiness.
+---
+
+# FESA Numerical Review
+
+Use this skill to review a formulation as a numerical algorithm contract before implementation planning.
+
+## Inputs
+
+Read these first:
+
+- `AGENTS.md`
+- `docs/SOLVER_AGENT_DESIGN.md`
+- `docs/numerical-reviews/README.md`
+- `docs/formulations/<feature-id>-formulation.md`
+- Related requirements and research documents when needed
+
+## Workflow
+
+1. Lead with findings and required revisions.
+2. Check dimensional consistency, signs, DOF ordering, constrained/free assumptions, and coordinate transforms.
+3. Review B matrix or kinematic operator consistency.
+4. Review constitutive matrix or stress update contract.
+5. Review Jacobian rules, determinant checks, derivative transforms, and distortion handling.
+6. Review integration rule, Gauss points, weights, and full/reduced/selective integration policy.
+7. Check element residual, internal force, external force, stiffness, tangent, symmetry, and positive definiteness expectations.
+8. Assess rigid body modes, patch test readiness, hourglass, shear locking, volumetric locking, singular Jacobian, conditioning, and convergence risk.
+9. Decide status: `pass-for-implementation-planning`, `needs-formulation-revision`, `needs-research`, `needs-reference-model`, or `blocked`.
+
+## Output Contract
+
+Produce or revise `docs/numerical-reviews/<feature-id>-review.md` with:
+
+- Metadata and source formulation
+- Review Verdict
+- Critical Findings
+- Numerical Risk Assessment
+- Consistency Checks
+- Verification Readiness
+- Required Revisions
+- Downstream Handoff
+
+## Boundaries
+
+- Do not implement code.
+- Do not edit formulations directly.
+- Do not design C++ APIs or file ownership.
+- Do not run Abaqus, Nastran, or any reference solver.
+- Do not generate reference CSVs.
+- Do not approve release readiness.
+- Do not decide reference comparison success.
+
+## Quality Gate
+
+- `pass-for-implementation-planning` means implementation planning may begin, not that the feature is complete.
+- Confirmed defects, risks, open questions, and test recommendations are separated.
+- Missing derivations are returned to Formulation Agent instead of being silently fixed.
+- Evidence gaps are routed to Research Agent or Reference Model Agent.
+
+## Handoff
+
+Send pass results to Implementation Planning Agent and Reference Model Agent. Send math defects to Formulation Agent, source gaps to Research Agent, and blocked decisions to Coordinator Agent.
@@ -0,0 +1,4 @@
+interface:
+  display_name: "FESA Numerical Review"
+  short_description: "Review FEM numerical risks"
+  default_prompt: "Use $fesa-numerical-review to review FESA formulation numerical readiness."
@@ -0,0 +1,68 @@
+---
+name: fesa-physics-sanity
+description: Use when evaluating FESA solver physics and physical plausibility after reference verification, including equilibrium, reactions, displacement direction, symmetry, stress sanity, and model coverage.
+---
+
+# FESA Physics Sanity
+
+Use this skill to determine whether reference-passing solver outputs are physically credible enough for release evaluation.
+
+## Inputs
+
+Read these first:
+
+- `AGENTS.md`
+- `docs/SOLVER_AGENT_DESIGN.md`
+- `docs/physics-evaluations/README.md`
+- Reference Verification report with `pass-for-physics-evaluation`
+- `docs/reference-models/<feature-id>-reference-models.md`
+- Requirements, formulation, numerical review, and I/O definition documents
+- Stored solver and reference CSVs as read-only evidence
+
+## Workflow
+
+1. Evaluate only documented physical expectations.
+2. Require a reference verification status of `pass-for-physics-evaluation`.
+3. Check global equilibrium when loads, reactions, and sign conventions are documented.
+4. Check reaction consistency for constrained DOFs.
+5. Check displacement direction against loads, boundary conditions, and expected deformation mode.
+6. Check symmetry or expected zero conditions when the model defines them.
+7. Check element force balance and element internal force sign conventions when documented.
+8. Check stress/strain component naming, coordinate system, output location, and sign.
+9. Check rigid body mode symptoms, nonfinite values, energy/residual evidence, and model coverage.
+10. Classify failures and route them to the owning agent.
+
+## Output Contract
+
+Produce or revise `docs/physics-evaluations/<feature-id>-physics-evaluation.md` with:
+
+- Metadata
+- Input Evidence
+- Physics Checks
+- Failure Classification
+- Evaluation Verdict
+- Handoff Recommendation
+- No-Change Assertion
+- Open Issues
+
+## Boundaries
+
+- Do not edit source code.
+- Do not edit tests.
+- Do not edit CMake files.
+- Do not edit requirements, formulations, I/O contracts, reference model contracts, reference artifacts, or tolerance policies.
+- Do not run Abaqus, Nastran, or any reference solver.
+- Do not generate reference CSVs.
+- Do not approve release readiness.
+- Do not approve reference tolerance success.
+
+## Quality Gate
+
+- A physics pass requires documented expectations and reference verification pass evidence.
+- Use `needs-upstream-decision` when physical expectations, sign convention, or model purpose is missing.
+- Use `needs-reference-model` when the model does not cover the claimed feature.
+- `pass-for-release-agent` means Release Agent can audit release readiness; it is not release approval.
+
+## Handoff
+
+Send `pass-for-release-agent` reports to Release Agent. Send implementation-owned physics failures to Correction Agent, formulation concerns to Formulation Agent, I/O ambiguity to I/O Definition Agent, and model coverage gaps to Reference Model Agent.
@@ -0,0 +1,4 @@
+interface:
+  display_name: "FESA Physics Sanity"
+  short_description: "Evaluate physical plausibility"
+  default_prompt: "Use $fesa-physics-sanity to evaluate FESA solver physical plausibility."
@@ -0,0 +1,67 @@
+---
+name: fesa-reference-comparison
+description: Use when running FESA solver reference CSV comparison, checking stored artifacts, schema, units, ID matching, tolerance metrics, and reference verification status.
+---
+
+# FESA Reference Comparison
+
+Use this skill to compare generated solver outputs against stored reference artifacts without modifying either side.
+
+## Inputs
+
+Read these first:
+
+- `AGENTS.md`
+- `docs/SOLVER_AGENT_DESIGN.md`
+- `docs/reference-verifications/README.md`
+- Build/Test report with `pass-for-reference-verification`
+- `docs/reference-models/<feature-id>-reference-models.md`
+- `docs/io-definitions/<feature-id>-io.md`
+- Generated solver result CSVs
+- Stored `references/<feature-id>/<model-id>/` artifacts
+
+## Workflow
+
+1. Follow `ARTIFACT CHECK -> COMPARE -> CLASSIFY -> REPORT`.
+2. ARTIFACT CHECK: verify `metadata.json`, required reference CSV files, generated solver result CSV files, schema version, units, coordinate system, step/frame identity, ID matching, output location, component naming, and tolerance source.
+3. Stop with `needs-reference-artifacts`, `needs-solver-results`, or `needs-upstream-decision` when required comparison inputs are missing.
+4. COMPARE only required quantities: `displacements.csv`, `reactions.csv`, `element_forces.csv`, `stresses.csv`, and optional `strains.csv` or `energy_or_residual.csv`.
+5. Apply upstream tolerance exactly. Do not loosen or reinterpret tolerance.
+6. Report max absolute error, max relative error, RMS error, norm error, worst id, worst component, missing rows, extra rows, and pass/fail.
+7. CLASSIFY failures as missing-reference-artifact, missing-solver-output, schema-mismatch, id-mismatch, unit-or-coordinate-mismatch, tolerance-failure, nonfinite-result, upstream-contract, or environment.
+
+## Output Contract
+
+Produce or revise `docs/reference-verifications/<feature-id>-reference-verification.md` with:
+
+- Metadata
+- Artifact Inventory
+- Comparison Contract
+- Quantity Results
+- Failure Classification
+- Handoff Recommendation
+- No-Change Assertion
+- Open Issues
+
+## Boundaries
+
+- Do not edit source code.
+- Do not edit tests.
+- Do not edit CMake files.
+- Do not change requirements, formulations, I/O contracts, reference artifacts, or tolerance policies.
+- Do not change tolerance policies.
+- Do not run Abaqus, Nastran, or any reference solver.
+- Do not generate reference CSVs.
+- Do not approve physics validation or release readiness.
+
+## Quality Gate
+
+- Every compared row has a deterministic matching rule.
+- Missing rows and extra rows are reported, not ignored.
+- Nonfinite values are reported explicitly.
+- `pass-for-physics-evaluation` means reference tolerance success only.
+- Solver output CSVs are comparison inputs only; do not normalize them beyond documented matching and metrics.
+
+## Handoff
+
+Send passing reports to Physics Evaluation Agent. Send implementation-owned mismatches to Correction Agent. Send missing artifacts to Reference Model Agent and schema conflicts to I/O Definition Agent.
@@ -0,0 +1,4 @@
+interface:
+  display_name: "FESA Reference Comparison"
+  short_description: "Compare solver CSV results"
+  default_prompt: "Use $fesa-reference-comparison to compare FESA solver CSVs against reference CSVs."
@@ -0,0 +1,69 @@
+---
+name: fesa-reference-models
+description: Use when designing FESA reference model portfolios, Abaqus input artifact bundles, metadata provenance, required reference CSV artifacts, coverage matrices, and implementation-planning handoffs.
+---
+
+# FESA Reference Models
+
+Use this skill to define test model portfolios and reference artifact contracts before implementation planning.
+
+## Inputs
+
+Read these first:
+
+- `AGENTS.md`
+- `docs/SOLVER_AGENT_DESIGN.md`
+- `docs/reference-models/README.md`
+- `docs/requirements/<feature-id>.md`
+- `docs/research/<feature-id>-research.md`
+- `docs/formulations/<feature-id>-formulation.md`
+- `docs/numerical-reviews/<feature-id>-review.md`
+- `docs/io-definitions/<feature-id>-io.md`
+
+## Workflow
+
+1. Define reference strategy: code verification, solution verification, and benchmark/reference comparison.
+2. Build a model inventory: smoke, analytical, patch test, benchmark, regression, and negative/invalid-input models.
+3. For each model, record `model_id`, purpose, verified requirements, analysis type, element type, material, boundary conditions, loads, expected quantities, tolerance, source, and status.
+4. Define `references/<feature-id>/<model-id>/` artifact bundle requirements.
+5. Require `model.inp`, `metadata.json`, `displacements.csv`, `reactions.csv`, `element_forces.csv`, `stresses.csv`, and `README.md` unless explicitly not applicable.
+6. Define optional `strains.csv` and `energy_or_residual.csv` only when upstream acceptance criteria require them.
+7. Define metadata provenance, units, coordinate system, output requests, artifact status, and limitations.
+8. Build a Coverage Matrix mapping requirement id, model id, compared quantity, artifact file, tolerance, verification method, and status.
+
+## Output Contract
+
+Produce or revise `docs/reference-models/<feature-id>-reference-models.md` with:
+
+- Metadata
+- Reference Strategy
+- Model Inventory
+- Model Record
+- Abaqus Input Requirements
+- Artifact Bundle Contract
+- Metadata JSON Contract
+- Reference CSV Requirements
+- Coverage Matrix
+- Artifact Acceptance Checklist
+- Open Issues and Downstream Handoff
+
+## Boundaries
+
+- Do not implement code.
+- Do not implement parsers.
+- Do not design C++ APIs or file ownership.
+- Do not run Abaqus, Nastran, or any reference solver.
+- Do not generate reference CSVs.
+- Do not compare solver results.
+- Do not approve release readiness.
+
+## Quality Gate
+
+- Every `must` requirement maps to at least one model and compared quantity.
+- `model.inp` stays within the supported Abaqus keyword subset or records an open issue.
+- `metadata.json` includes provenance, Abaqus version/source, units, coordinate system, tolerance, and CSV schema version.
+- Missing required CSVs keep the model at `needs-reference-artifacts`.
+
+## Handoff
+
+Send model order and tests that should fail first to Implementation Planning Agent. Send schema, matching, output location, and tolerance mapping to Reference Verification Agent. Send physical expectations to Physics Evaluation Agent.
@@ -0,0 +1,4 @@
+interface:
+  display_name: "FESA Reference Models"
+  short_description: "Design reference model bundles"
+  default_prompt: "Use $fesa-reference-models to design FESA reference model artifact bundles."
@@ -0,0 +1,66 @@
+---
+name: fesa-release-readiness
+description: Use when auditing FESA solver release readiness, upstream gate evidence, acceptance traceability, known limitations, release notes, and final feature release verdicts.
+---
+
+# FESA Release Readiness
+
+Use this skill to audit whether a solver feature is ready for internal release closure after all technical gates pass.
+
+## Inputs
+
+Read these first:
+
+- `AGENTS.md`
+- `docs/SOLVER_AGENT_DESIGN.md`
+- `docs/releases/README.md`
+- Physics Evaluation report with `pass-for-release-agent`
+- Reference Verification report with `pass-for-physics-evaluation`
+- Build/Test report with `pass-for-reference-verification`
+- Requirements, formulation, numerical review, I/O definition, reference model, implementation, and correction reports
+
+## Workflow
+
+1. Follow `GATE AUDIT -> TRACEABILITY CHECK -> RELEASE DOCUMENTATION -> RELEASE VERDICT`.
+2. GATE AUDIT: confirm required reports exist, share the same `feature_id`, are not stale or contradictory, and carry required pass statuses.
+3. Require `pass-for-reference-verification`, `pass-for-physics-evaluation`, and `pass-for-release-agent`.
+4. TRACEABILITY CHECK: confirm each `must` requirement maps to acceptance criteria, test evidence, reference model evidence, and release scope.
+5. Record deferred requirements, unsupported Abaqus keywords, incomplete artifacts, unresolved defects, accepted risks, and known limitations.
+6. RELEASE DOCUMENTATION: prepare a release checklist, Known Limitations, and Release Notes Draft.
+7. RELEASE VERDICT: issue `ready-for-release` only when all required evidence is present and passing.
+
+## Output Contract
+
+Produce or revise `docs/releases/<feature-id>-release.md` with:
+
+- Metadata
+- Release Scope
+- Gate Evidence Inventory
+- Acceptance Traceability
+- Validation Evidence
+- Known Limitations
+- Release Notes Draft
+- Release Verdict
+- Handoff Recommendation
+- No-Change Assertion
+- Open Issues
+
+## Boundaries
+
+- Do not implement code.
+- Do not edit source code, tests, CMake files, requirements, formulations, I/O contracts, reference artifacts, or tolerance policies.
+- Do not run Abaqus, Nastran, or any reference solver.
+- Do not generate reference CSVs.
+- Do not override failed or missing gates.
+- Do not publish, deploy, package, tag, commit, or externally release anything unless the user explicitly asks.
+
+## Quality Gate
+
+- Do not issue `ready-for-release` without `pass-for-release-agent`, `pass-for-physics-evaluation`, and `pass-for-reference-verification`.
+- Every `must` requirement traces to release scope, acceptance criteria, test or reference evidence, and final disposition.
+- Known limitations and deferred issues are included in the Release Notes Draft.
+- Missing evidence, contradictory reports, unresolved defects, incomplete artifacts, or unavailable validation commands block release readiness.
+
+## Handoff
+
+Send `ready-for-release` to Coordinator Agent for final workflow closure. Send missing documentation to Release Agent revision, missing verification to Reference Verification Agent or Physics Evaluation Agent, and implementation defects to Correction Agent.
@@ -0,0 +1,4 @@
+interface:
+  display_name: "FESA Release Readiness"
+  short_description: "Audit solver release readiness"
+  default_prompt: "Use $fesa-release-readiness to audit FESA solver feature release readiness."
@@ -0,0 +1,62 @@
+---
+name: fesa-requirements-baseline
+description: Use when defining FESA solver feature requirements, acceptance criteria, tolerance decisions, verification quantities, and a requirement verification matrix before research, formulation, reference modeling, or implementation planning.
+---
+
+# FESA Requirements Baseline
+
+Use this skill to turn a solver feature request into a verifiable baseline that downstream agents can use without guessing.
+
+## Inputs
+
+Read these first:
+
+- `AGENTS.md`
+- `docs/SOLVER_AGENT_DESIGN.md`
+- `docs/requirements/README.md`
+- User feature request, target capability, constraints, and known exclusions
+- Existing `docs/requirements/<feature-id>.md` when revising a feature
+
+## Workflow
+
+1. Assign a stable `feature_id` in kebab case.
+2. Define purpose, included scope, excluded scope, and analysis definition.
+3. Convert requested behavior into `shall` statements with ids like `FESA-REQ-<FEATURE>-###`.
+4. Define verification quantities: displacement, reaction, element force, stress, strain, energy, or residual.
+5. Record Tolerance Policy values or mark them `needs-user-decision`.
+6. Record Reference Artifact Requirements under `references/<feature-id>/`.
+7. Build a Requirement Verification Matrix that maps requirement, source, verification method, acceptance criteria, tolerance, downstream agents, and status.
+8. Keep unresolved decisions visible as open issues; do not hide gaps behind vague wording.
+
+## Output Contract
+
+Produce or revise `docs/requirements/<feature-id>.md` with:
+
+- Metadata with `feature_id`, status, owner agent, and date
+- Purpose, In Scope, Out Of Scope, and Analysis Definition
+- Input and Output Requirements
+- Verification Quantities
+- Tolerance Policy
+- Reference Artifact Requirements
+- Requirement Verification Matrix
+- Open Questions and Downstream Handoff
+
+## Boundaries
+
+- Do not implement C++ code.
+- Do not write finite element formulations.
+- Do not design C++ APIs or file ownership.
+- Do not run Abaqus, Nastran, or any reference solver.
+- Do not generate reference CSVs.
+- Do not approve release readiness.
+
+## Quality Gate
+
+- Every `must` requirement has a verification method and acceptance criteria.
+- Every numerical requirement has units, coordinate system, and tolerance or an explicit owner for the decision.
+- Every reference-comparison requirement names required artifacts.
+- Words like "accurate", "fast", and "Abaqus-like" are converted into measurable criteria or open questions.
+
+## Handoff
+
+Route theory gaps to Research Agent, math gaps to Formulation Agent, schema gaps to I/O Definition Agent, reference artifact needs to Reference Model Agent, and implementation readiness to Implementation Planning Agent.
@@ -0,0 +1,4 @@
+interface:
+  display_name: "FESA Requirements Baseline"
+  short_description: "Define solver requirements"
+  default_prompt: "Use $fesa-requirements-baseline to define verifiable FESA solver requirements."
@@ -0,0 +1,61 @@
+---
+name: fesa-research-evidence
+description: Use when collecting FESA solver research evidence, FEM theory sources, benchmarks, source reliability, and applicability limits for a feature before formulation or reference model design.
+---
+
+# FESA Research Evidence
+
+Use this skill to collect source-backed evidence for solver features while separating verified facts from inference.
+
+## Inputs
+
+Read these first:
+
+- `AGENTS.md`
+- `docs/SOLVER_AGENT_DESIGN.md`
+- `docs/research/README.md`
+- `docs/requirements/<feature-id>.md`
+- User-supplied books, papers, manuals, or benchmark constraints
+
+## Workflow
+
+1. Extract research questions from the requirements and open issues.
+2. Build a Source Inventory with Source Reliability Tier for manuals, standards, books, papers, and benchmark repositories.
+3. Summarize FEM theory needed for the feature without finalizing implementation math.
+4. Identify Candidate Benchmarks, patch tests, analytical checks, MMS/MES candidates, and public examples.
+5. Record Verification Relevance for displacement, reaction, element force, stress, strain, energy, or residual checks.
+6. Record Applicability Limits: element type, material model, deformation assumptions, loading, boundary conditions, and known exclusions.
+7. Separate verified facts from inference. Mark unsupported claims as inference or open questions.
+
+## Output Contract
+
+Produce or revise `docs/research/<feature-id>-research.md` with:
+
+- Metadata and source requirement path
+- Research Questions
+- Source Inventory and Source Reliability Tier
+- Theory Summary
+- Candidate Benchmarks
+- Verification Relevance
+- Applicability Limits
+- Downstream Handoff
+
+## Boundaries
+
+- Do not implement code.
+- Do not finalize FEM formulations.
+- Do not design C++ APIs or file ownership.
+- Do not run Abaqus, Nastran, or any reference solver.
+- Do not generate reference CSVs.
+- Do not approve release readiness.
+
+## Quality Gate
+
+- Every key claim has a source, reliability tier, or explicit inference label.
+- Benchmark candidates include what quantity they can verify and what they cannot verify.
+- Missing source evidence is carried forward as an open issue.
+- No reference value, tolerance, or compatibility claim is invented.
+
+## Handoff
+
+Send formulation evidence to Formulation Agent, benchmark and source limits to Numerical Review Agent, artifact candidates to Reference Model Agent, and unresolved source gaps to Coordinator Agent.
@@ -0,0 +1,4 @@
+interface:
+  display_name: "FESA Research Evidence"
+  short_description: "Collect FEM research evidence"
+  default_prompt: "Use $fesa-research-evidence to collect source-backed FEM research evidence."