add skills
This commit is contained in:
김경종
@@ -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."
|
||||
+131
-182
@@ -1,232 +1,181 @@
|
||||
# FESA Solver Development Skill 구성안
|
||||
# FESA Solver Skill Rebuild Plan
|
||||
|
||||
## 목적
|
||||
|
||||
이 문서는 FESA 유한요소 기반 구조해석 솔버 개발에 사용할 Codex skills 구성을 정의한다.
|
||||
이 문서는 FESA 유한요소 기반 구조해석 솔버 개발에 사용할 project-local Codex skill 구성을 정의한다.
|
||||
|
||||
Agent는 역할과 책임 단위이고, skill은 여러 Agent가 반복적으로 사용하는 기술과 절차 단위다. 따라서 skill은 Agent와 1:1로 대응시키지 않고, solver 개발 과정에서 반복되는 공통 workflow를 압축해 구성한다.
|
||||
Agent는 역할과 책임 단위이고, skill은 여러 Agent가 반복적으로 사용하는 절차와 검증 도구 단위다. 따라서 skill은 Agent와 1:1로 대응하지 않는다. 대신 요구조건, 연구, 정식화, I/O 계약, reference model, C++ TDD 구현, reference 비교, 물리 검토, release readiness처럼 솔버 개발 과정에서 반복되는 작업 흐름을 기준으로 구성한다.
|
||||
|
||||
## 설계 원칙
|
||||
|
||||
- Skill은 특정 Agent 전용 지시가 아니라 여러 Agent가 공유하는 반복 절차로 둔다.
|
||||
- Skill은 `SKILL.md` 기반의 project-local workflow로 시작한다.
|
||||
- Skill은 구현 세부사항보다 입력, 절차, 산출물, 금지사항, 검증 기준을 제공한다.
|
||||
- Abaqus/Nastran 실행과 reference CSV 생성은 skill 범위에 포함하지 않는다.
|
||||
- C++ 구현 관련 skill은 C++17, MSVC, CMake, CTest, TDD 기준을 따른다.
|
||||
- 모든 검증은 `python scripts/validate_workspace.py`를 기본 workspace validation 명령으로 둔다.
|
||||
- Skill은 `.codex/skills/<skill-name>/SKILL.md`에 둔다.
|
||||
- 각 skill은 필수 frontmatter `name`, `description`과 UI metadata `agents/openai.yaml`을 가진다.
|
||||
- Skill 본문은 agent TOML의 역할 설명을 반복하지 않고, 입력, 절차, 산출물, 금지사항, 품질 gate, handoff를 정의한다.
|
||||
- Skill은 `AGENTS.md`와 `docs/SOLVER_AGENT_DESIGN.md`를 공통 상위 기준으로 읽는다.
|
||||
- Abaqus, Nastran 또는 reference solver 실행은 skill 범위에 포함하지 않는다.
|
||||
- Reference CSV 생성 또는 수정은 skill 범위에 포함하지 않는다.
|
||||
- C++ 구현 관련 skill은 C++17 이상, MSVC, CMake, CTest, TDD 원칙을 따른다.
|
||||
- 기본 workspace validation 명령은 `python scripts/validate_workspace.py`이다.
|
||||
|
||||
## Skill 구성
|
||||
|
||||
### 1. `fesa-feature-definition`
|
||||
| Skill | 적용 개발 과정 | 주요 사용자 Agent | 대표 산출물 |
|
||||
| --- | --- | --- | --- |
|
||||
| `fesa-requirements-baseline` | 1. 솔버 기능 요구조건 정의 | Requirement Agent, Coordinator Agent | `docs/requirements/<feature-id>.md` |
|
||||
| `fesa-research-evidence` | 2. 책, 논문 등 연구자료 조사 | Research Agent, Formulation Agent | `docs/research/<feature-id>-research.md` |
|
||||
| `fesa-formulation-spec` | 3. 코드 구현을 위한 유한요소 정식화 | Formulation Agent, Implementation Planning Agent | `docs/formulations/<feature-id>-formulation.md` |
|
||||
| `fesa-numerical-review` | 3. 정식화 독립 수치 검토 | Numerical Review Agent, Coordinator Agent | `docs/numerical-reviews/<feature-id>-review.md` |
|
||||
| `fesa-io-contract` | 4. 솔버 입출력 데이터 정의 | I/O Definition Agent, Reference Verification Agent | `docs/io-definitions/<feature-id>-io.md` |
|
||||
| `fesa-reference-models` | 5. TDD/reference 테스트모델 작성 | Reference Model Agent, Implementation Planning Agent | `docs/reference-models/<feature-id>-reference-models.md` |
|
||||
| `fesa-cpp-msvc-tdd` | 6. 코드 구현 및 build/test correction | Implementation Planning Agent, Implementation Agent, Build/Test Executor Agent, Correction Agent | implementation plan/report, build/test report, correction report |
|
||||
| `fesa-reference-comparison` | 7. reference solver 결과와 구현 solver 결과 비교 | Reference Verification Agent | `docs/reference-verifications/<feature-id>-reference-verification.md` |
|
||||
| `fesa-physics-sanity` | 8. tolerance 통과 후 물리 타당성 검토 | Physics Evaluation Agent | `docs/physics-evaluations/<feature-id>-physics-evaluation.md` |
|
||||
| `fesa-release-readiness` | 9. 솔버 기능 배포 준비 | Release Agent, Coordinator Agent | `docs/releases/<feature-id>-release.md` |
|
||||
|
||||
요구조건 정의와 연구 질문 정리를 위한 skill이다.
|
||||
## 개발 과정별 사용 예
|
||||
|
||||
사용 Agent:
|
||||
- Requirement Agent
|
||||
- Research Agent
|
||||
- Coordinator Agent
|
||||
- Release Agent
|
||||
예시 기능: `linear-truss-1d`
|
||||
|
||||
적용 개발 과정:
|
||||
- 1. 솔버 기능에 대한 요구조건 정의
|
||||
- 2. 책, 논문 등 연구자료 조사
|
||||
1. Requirement Agent는 `fesa-requirements-baseline`을 사용해 기능 범위, 제외 범위, 입력, 출력, 검증 물리량, tolerance, `Requirement Verification Matrix`를 작성한다.
|
||||
2. Research Agent는 `fesa-research-evidence`를 사용해 truss/bar element 이론, benchmark 후보, source reliability, applicability limits를 정리한다.
|
||||
3. Formulation Agent는 `fesa-formulation-spec`을 사용해 strong form, weak form, shape functions, B matrix, element stiffness, output recovery를 정리한다.
|
||||
4. Numerical Review Agent는 `fesa-numerical-review`를 사용해 rigid body modes, patch test, stiffness symmetry, Jacobian, locking 위험을 검토하고 `pass-for-implementation-planning` 여부를 판단한다.
|
||||
5. I/O Definition Agent는 `fesa-io-contract`를 사용해 지원할 Abaqus `.inp` keyword subset과 `displacements.csv`, `reactions.csv`, `element_forces.csv`, `stresses.csv` schema를 정의한다.
|
||||
6. Reference Model Agent는 `fesa-reference-models`를 사용해 `references/linear-truss-1d/<model-id>/` artifact bundle 계약과 coverage matrix를 작성한다.
|
||||
7. Implementation Planning Agent와 Implementation Agent는 `fesa-cpp-msvc-tdd`를 사용해 테스트 작성, 실패 확인, 최소 구현, CMake/CTest 등록, validation을 수행한다.
|
||||
8. Reference Verification Agent는 `fesa-reference-comparison`을 사용해 구현 solver CSV와 저장된 reference CSV를 tolerance 기준으로 비교한다.
|
||||
9. Physics Evaluation Agent는 `fesa-physics-sanity`를 사용해 global equilibrium, reaction consistency, displacement direction, symmetry, model coverage를 검토한다.
|
||||
10. Release Agent는 `fesa-release-readiness`를 사용해 gate evidence, acceptance traceability, known limitations, release notes draft를 작성한다.
|
||||
|
||||
주요 기능:
|
||||
- 기능 요청을 검증 가능한 requirement baseline으로 정리한다.
|
||||
- `shall` 요구조건, acceptance criteria, verification matrix를 작성한다.
|
||||
- 필요한 연구 질문과 source gap을 정리한다.
|
||||
- 미확정 tolerance, 지원 범위, reference artifact 요구사항을 open issue로 남긴다.
|
||||
## Skill별 핵심 계약
|
||||
|
||||
대표 산출물:
|
||||
- `docs/requirements/<feature-id>.md`
|
||||
- `docs/research/<feature-id>-research.md`
|
||||
- requirement verification matrix
|
||||
- downstream handoff questions
|
||||
### `fesa-requirements-baseline`
|
||||
|
||||
금지사항:
|
||||
- FEM 정식화를 확정하지 않는다.
|
||||
- C++ 구현, Abaqus/Nastran 실행, reference CSV 생성을 하지 않는다.
|
||||
- 검증 불가능한 요구조건을 완료 상태로 두지 않는다.
|
||||
- 기능 요청을 검증 가능한 요구조건 baseline으로 만든다.
|
||||
- `shall` 문장과 `FESA-REQ-<FEATURE>-###` id를 사용한다.
|
||||
- 모든 `must` 요구조건은 verification method와 acceptance criteria를 가져야 한다.
|
||||
- FEM 정식화, C++ 구현, reference CSV 생성, release readiness 판단은 하지 않는다.
|
||||
|
||||
### 2. `fesa-fem-specification`
|
||||
### `fesa-research-evidence`
|
||||
|
||||
FEM 정식화, 수치 검토, 입출력 계약을 구현 가능한 specification으로 정리하기 위한 skill이다.
|
||||
- 연구 질문, source inventory, source reliability tier, benchmark 후보를 정리한다.
|
||||
- 검증된 사실과 추론을 분리한다.
|
||||
- source gap은 open issue로 남긴다.
|
||||
- FEM 정식화 확정이나 reference value 생성을 하지 않는다.
|
||||
|
||||
사용 Agent:
|
||||
- Formulation Agent
|
||||
- Numerical Review Agent
|
||||
- I/O Definition Agent
|
||||
- Implementation Planning Agent
|
||||
### `fesa-formulation-spec`
|
||||
|
||||
적용 개발 과정:
|
||||
- 3. 코드 구현을 위한 유한요소 정식화
|
||||
- 4. 솔버 입출력 데이터 정의
|
||||
- strong form, weak form, discretization, kinematics, constitutive contract, element equations를 구분해 작성한다.
|
||||
- Jacobian, derivative transform, numerical integration, output recovery, numerical risks를 명시한다.
|
||||
- C++ API, parser, file ownership은 설계하지 않는다.
|
||||
- Numerical Review Agent 검토 전 최종 승인 상태로 두지 않는다.
|
||||
|
||||
주요 기능:
|
||||
- strong form, weak form, shape function, B matrix, element equations를 정리한다.
|
||||
- numerical integration, Jacobian, output recovery, numerical risk를 점검한다.
|
||||
- Abaqus `.inp` keyword subset과 internal model mapping을 정의한다.
|
||||
- result CSV schema와 units, coordinate system, component naming을 정리한다.
|
||||
### `fesa-numerical-review`
|
||||
|
||||
대표 산출물:
|
||||
- `docs/formulations/<feature-id>-formulation.md`
|
||||
- `docs/numerical-reviews/<feature-id>-review.md`
|
||||
- `docs/io-definitions/<feature-id>-io.md`
|
||||
- 정식화를 수치 알고리즘 계약으로 독립 검토한다.
|
||||
- dimensions, signs, DOF ordering, coordinate transforms, Jacobian, integration rule, stiffness symmetry, rigid body modes, patch test, hourglass, locking을 확인한다.
|
||||
- `pass-for-implementation-planning`은 구현 계획 가능 상태만 의미한다.
|
||||
- 정식화 문서를 직접 수정하지 않는다.
|
||||
|
||||
금지사항:
|
||||
- C++ API나 파일 구조를 확정하지 않는다.
|
||||
- parser 구현을 하지 않는다.
|
||||
- reference artifact나 tolerance policy를 임의로 만들지 않는다.
|
||||
### `fesa-io-contract`
|
||||
|
||||
### 3. `fesa-reference-validation`
|
||||
- FESA solver input이 지원할 Abaqus `.inp` subset을 정의한다.
|
||||
- model data와 history data를 구분한다.
|
||||
- 내부 semantic model 계약과 output/CSV schema를 정의한다.
|
||||
- parser 구현이나 full Abaqus compatibility claim은 하지 않는다.
|
||||
|
||||
reference model 설계, stored Abaqus CSV 비교, physics sanity 평가를 위한 skill이다.
|
||||
### `fesa-reference-models`
|
||||
|
||||
사용 Agent:
|
||||
- Reference Model Agent
|
||||
- Reference Verification Agent
|
||||
- Physics Evaluation Agent
|
||||
- Coordinator Agent
|
||||
|
||||
적용 개발 과정:
|
||||
- 5. TDD 방법 사용을 위한 개발 솔버와 reference solver 테스트모델 작성
|
||||
- 7. reference solver 결과와 구현 solver 결과 비교
|
||||
- 8. 결과 차이가 tolerance 범위 내에 들어오면 구현 완료
|
||||
|
||||
주요 기능:
|
||||
- `references/<feature-id>/<model-id>/` artifact bundle 요구사항을 정의한다.
|
||||
- smoke, analytical, patch test, benchmark, regression, negative/invalid-input 모델을 구분한다.
|
||||
- `references/<feature-id>/<model-id>/` artifact bundle 계약을 정의한다.
|
||||
- `model.inp`, `metadata.json`, `displacements.csv`, `reactions.csv`, `element_forces.csv`, `stresses.csv`를 기준 artifact로 둔다.
|
||||
- solver result CSV와 stored reference CSV를 schema, unit, coordinate, id matching, tolerance 기준으로 비교한다.
|
||||
- reference verification 통과 후 equilibrium, reaction consistency, displacement direction, stress/strain sanity, model coverage를 검토한다.
|
||||
- Reference CSV가 없으면 완료 상태가 아니라 `needs-reference-artifacts`로 둔다.
|
||||
|
||||
대표 산출물:
|
||||
- `docs/reference-models/<feature-id>-reference-models.md`
|
||||
- `docs/reference-verifications/<feature-id>-reference-verification.md`
|
||||
- `docs/physics-evaluations/<feature-id>-physics-evaluation.md`
|
||||
### `fesa-cpp-msvc-tdd`
|
||||
|
||||
금지사항:
|
||||
- Abaqus/Nastran 또는 reference solver를 실행하지 않는다.
|
||||
- reference CSV를 생성하거나 수정하지 않는다.
|
||||
- tolerance를 통과시키기 위해 solver output을 보정하지 않는다.
|
||||
- physics pass를 release readiness로 해석하지 않는다.
|
||||
- C++ 구현을 `RED -> GREEN -> VERIFY` 순서로 수행한다.
|
||||
- C++ production 변경에는 관련 C++ test file이 있어야 한다.
|
||||
- 기본 검증 명령:
|
||||
|
||||
### 4. `fesa-cpp-msvc-tdd`
|
||||
|
||||
C++17/MSVC/CMake/CTest 기반 TDD 구현과 build/test 실패 분석을 위한 skill이다.
|
||||
|
||||
사용 Agent:
|
||||
- Implementation Planning Agent
|
||||
- Implementation Agent
|
||||
- Build/Test Executor Agent
|
||||
- Correction Agent
|
||||
|
||||
적용 개발 과정:
|
||||
- 6. 코드 구현
|
||||
|
||||
주요 기능:
|
||||
- upstream specification을 TDD task와 CMake/CTest plan으로 변환한다.
|
||||
- `RED -> GREEN -> VERIFY` 순서로 C++ 구현을 진행한다.
|
||||
- C++ production 변경에는 관련 C++ test를 요구한다.
|
||||
- Build/Test 실패를 configure, compile, link, test, reference-comparison, harness, environment, upstream-contract로 분류한다.
|
||||
- implementation-owned failure만 최소 수정한다.
|
||||
|
||||
대표 산출물:
|
||||
- `docs/implementation-plans/<feature-id>-implementation-plan.md`
|
||||
- implementation report
|
||||
- `docs/build-test-reports/<feature-id>-build-test.md`
|
||||
- `docs/corrections/<feature-id>-correction.md`
|
||||
|
||||
기본 검증 명령:
|
||||
|
||||
```bash
|
||||
```powershell
|
||||
python -m unittest discover -s scripts -p "test_*.py"
|
||||
python scripts/validate_workspace.py
|
||||
ctest -C Debug -R <feature-or-label>
|
||||
```
|
||||
|
||||
기본 CMake/MSVC 경로:
|
||||
- 실패는 `configure | compile | link | test | reference-comparison | harness | environment | upstream-contract`로 분류한다.
|
||||
- 요구조건, 정식화, I/O 계약, reference artifact, tolerance policy를 바꾸지 않는다.
|
||||
|
||||
```bash
|
||||
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
|
||||
```
|
||||
### `fesa-reference-comparison`
|
||||
|
||||
금지사항:
|
||||
- 요구조건, 정식화, I/O 계약, reference artifact, tolerance policy를 변경하지 않는다.
|
||||
- Abaqus/Nastran을 실행하지 않는다.
|
||||
- release readiness를 승인하지 않는다.
|
||||
- `ARTIFACT CHECK -> COMPARE -> CLASSIFY -> REPORT` 순서로 수행한다.
|
||||
- `metadata.json`, schema version, units, coordinate system, step/frame identity, ID matching, output location, tolerance source를 확인한다.
|
||||
- max absolute error, max relative error, RMS error, norm error, missing rows, extra rows를 보고한다.
|
||||
- Reference pass는 physics validation이나 release readiness를 의미하지 않는다.
|
||||
|
||||
### 5. `fesa-release-coordination`
|
||||
### `fesa-physics-sanity`
|
||||
|
||||
전체 workflow gate, handoff, blocker, release readiness 정리를 위한 skill이다.
|
||||
- Reference comparison 통과 후 물리 타당성을 검토한다.
|
||||
- global equilibrium, reaction consistency, displacement direction, symmetry, element force balance, stress/strain sanity, rigid body mode, model coverage를 확인한다.
|
||||
- 문서화된 물리 기대값이 없으면 pass를 선언하지 않는다.
|
||||
- `pass-for-release-agent`는 Release Agent 검토 가능 상태만 의미한다.
|
||||
|
||||
사용 Agent:
|
||||
- Coordinator Agent
|
||||
- Release Agent
|
||||
### `fesa-release-readiness`
|
||||
|
||||
적용 개발 과정:
|
||||
- 9. 솔버 기능 배포
|
||||
|
||||
주요 기능:
|
||||
- feature별 workflow state를 audit한다.
|
||||
- 다음 Agent handoff package를 작성한다.
|
||||
- repeated failure, blocker, user decision을 기록한다.
|
||||
- release checklist, known limitations, release notes draft를 작성한다.
|
||||
- Build/Test, Reference Verification, Physics Evaluation, Release gate evidence를 확인한다.
|
||||
|
||||
대표 산출물:
|
||||
- `docs/coordination/<feature-id>-coordination.md`
|
||||
- `docs/releases/<feature-id>-release.md`
|
||||
|
||||
상태 전이 기준:
|
||||
- `ready-for-implementation`: Implementation Planning report가 준비되었을 때
|
||||
- `needs-reference-verification`: Build/Test report가 `pass-for-reference-verification`일 때
|
||||
- `needs-physics-evaluation`: Reference Verification report가 `pass-for-physics-evaluation`일 때
|
||||
- `needs-release`: Physics Evaluation report가 `pass-for-release-agent`일 때
|
||||
- `completed`: Release Agent report가 `ready-for-release`이고 final workflow closure가 기록되었을 때
|
||||
|
||||
금지사항:
|
||||
- 다른 Agent가 소유한 기술 판정을 대체하지 않는다.
|
||||
- 실패하거나 누락된 gate evidence를 우회하지 않는다.
|
||||
- 사용자 명시 요청 없이 publish, deploy, package, tag, commit을 수행하지 않는다.
|
||||
|
||||
## 개발 과정과 Skill 매핑
|
||||
|
||||
| 개발 과정 | Skill |
|
||||
| --- | --- |
|
||||
| 1. 솔버 기능에 대한 요구조건 정의 | `fesa-feature-definition` |
|
||||
| 2. 책, 논문 등 연구자료 조사 | `fesa-feature-definition` |
|
||||
| 3. 코드 구현을 위한 유한요소 정식화 | `fesa-fem-specification` |
|
||||
| 4. 솔버 입출력 데이터 정의 | `fesa-fem-specification` |
|
||||
| 5. TDD 방법 사용을 위한 테스트모델 작성 | `fesa-reference-validation` |
|
||||
| 6. 코드 구현 | `fesa-cpp-msvc-tdd` |
|
||||
| 7. reference solver 결과와 구현 solver 결과 비교 | `fesa-reference-validation` |
|
||||
| 8. tolerance 범위 내 결과 차이 확인 | `fesa-reference-validation` |
|
||||
| 9. 솔버 기능 배포 | `fesa-release-coordination` |
|
||||
- `GATE AUDIT -> TRACEABILITY CHECK -> RELEASE DOCUMENTATION -> RELEASE VERDICT` 순서로 수행한다.
|
||||
- `pass-for-reference-verification`, `pass-for-physics-evaluation`, `pass-for-release-agent` evidence를 요구한다.
|
||||
- Known Limitations와 Release Notes Draft를 작성한다.
|
||||
- 사용자 명시 요청 없이 publish, deploy, package, tag, commit, external release를 수행하지 않는다.
|
||||
|
||||
## Agent와 Skill 관계
|
||||
|
||||
| Agent | 주로 사용하는 Skill |
|
||||
| --- | --- |
|
||||
| Coordinator Agent | `fesa-release-coordination`, `fesa-feature-definition`, `fesa-reference-validation` |
|
||||
| Requirement Agent | `fesa-feature-definition` |
|
||||
| Research Agent | `fesa-feature-definition` |
|
||||
| Formulation Agent | `fesa-fem-specification` |
|
||||
| Numerical Review Agent | `fesa-fem-specification` |
|
||||
| I/O Definition Agent | `fesa-fem-specification` |
|
||||
| Reference Model Agent | `fesa-reference-validation` |
|
||||
| Implementation Planning Agent | `fesa-fem-specification`, `fesa-cpp-msvc-tdd` |
|
||||
| Coordinator Agent | `fesa-requirements-baseline`, `fesa-reference-models`, `fesa-release-readiness` |
|
||||
| Requirement Agent | `fesa-requirements-baseline` |
|
||||
| Research Agent | `fesa-research-evidence` |
|
||||
| Formulation Agent | `fesa-formulation-spec` |
|
||||
| Numerical Review Agent | `fesa-numerical-review` |
|
||||
| I/O Definition Agent | `fesa-io-contract` |
|
||||
| Reference Model Agent | `fesa-reference-models` |
|
||||
| Implementation Planning Agent | `fesa-formulation-spec`, `fesa-reference-models`, `fesa-cpp-msvc-tdd` |
|
||||
| Implementation Agent | `fesa-cpp-msvc-tdd` |
|
||||
| Build/Test Executor Agent | `fesa-cpp-msvc-tdd` |
|
||||
| Correction Agent | `fesa-cpp-msvc-tdd` |
|
||||
| Reference Verification Agent | `fesa-reference-validation` |
|
||||
| Physics Evaluation Agent | `fesa-reference-validation` |
|
||||
| Release Agent | `fesa-release-coordination`, `fesa-feature-definition` |
|
||||
| Reference Verification Agent | `fesa-reference-comparison`, `fesa-io-contract` |
|
||||
| Physics Evaluation Agent | `fesa-physics-sanity` |
|
||||
| Release Agent | `fesa-release-readiness` |
|
||||
|
||||
## v1 구현 방침
|
||||
## 검증 기준
|
||||
|
||||
- 각 skill은 `.codex/skills/<skill-name>/SKILL.md`에 둔다.
|
||||
- v1에서는 `SKILL.md`만 작성하고, 별도 scripts, references, assets, plugin packaging은 만들지 않는다.
|
||||
- skill 본문은 agent TOML의 역할 설명을 반복하지 않고, 실제 반복 절차와 checklist 중심으로 작성한다.
|
||||
- skill description은 Codex가 자동으로 고를 수 있도록 trigger 상황을 명확히 쓴다.
|
||||
- 추후 반복 사용 중 절차가 안정화되면 검증 스크립트나 reference template을 skill resource로 분리한다.
|
||||
Skill 구성 검증은 `scripts/test_fesa_solver_skills.py`가 담당한다.
|
||||
|
||||
검증 항목:
|
||||
|
||||
- 10개 solver skill의 `SKILL.md` 존재 여부
|
||||
- YAML frontmatter의 `name`, `description`
|
||||
- 공통 섹션: `Inputs`, `Workflow`, `Output Contract`, `Boundaries`, `Quality Gate`, `Handoff`
|
||||
- `AGENTS.md`와 `docs/SOLVER_AGENT_DESIGN.md` 참조
|
||||
- skill-specific 핵심 문구와 산출물 경로
|
||||
- `agents/openai.yaml` UI metadata
|
||||
- 이 문서가 아니라 실제 skill 파일이 기준이 되도록 `docs/SOLVER_SKILL_DESIGN.md`에 대한 skill 본문 참조 금지
|
||||
|
||||
검증 명령:
|
||||
|
||||
```powershell
|
||||
python -m unittest discover -s scripts -p "test_*.py"
|
||||
python scripts/validate_workspace.py
|
||||
```
|
||||
|
||||
Skill 구조 검증:
|
||||
|
||||
```powershell
|
||||
python C:\Users\user\.codex\skills\.system\skill-creator\scripts\quick_validate.py .codex\skills\<skill-name>
|
||||
```
|
||||
|
||||
## v1 범위
|
||||
|
||||
- v1은 `SKILL.md`와 `agents/openai.yaml`만 포함한다.
|
||||
- 별도 `scripts/`, `references/`, `assets/`는 만들지 않는다.
|
||||
- 반복 사용 중 절차가 안정화되면 deterministic comparison script, reference artifact template, report template 같은 resource를 별도 후속 작업으로 분리한다.
|
||||
- 이 문서는 skill 구성을 설명하는 계획 문서이며, 실제 실행 지침의 source of truth는 각 `.codex/skills/<skill-name>/SKILL.md`이다.
|
||||
|
||||
@@ -0,0 +1,75 @@
|
||||
import unittest
|
||||
from pathlib import Path
|
||||
|
||||
try:
|
||||
import tomllib
|
||||
except ModuleNotFoundError: # pragma: no cover
|
||||
import tomli as tomllib
|
||||
|
||||
|
||||
ROOT = Path(__file__).resolve().parents[1]
|
||||
AGENTS_ROOT = ROOT / ".codex" / "agents"
|
||||
|
||||
AGENT_SKILL_REFERENCES = {
|
||||
"coordinator-agent.toml": (
|
||||
"fesa-requirements-baseline",
|
||||
"fesa-reference-models",
|
||||
"fesa-release-readiness",
|
||||
),
|
||||
"requirement-agent.toml": ("fesa-requirements-baseline",),
|
||||
"research-agent.toml": (
|
||||
"fesa-research-evidence",
|
||||
"fem-theory-query",
|
||||
),
|
||||
"formulation-agent.toml": (
|
||||
"fesa-formulation-spec",
|
||||
"fem-theory-query",
|
||||
),
|
||||
"numerical-review-agent.toml": (
|
||||
"fesa-numerical-review",
|
||||
"fem-theory-query",
|
||||
),
|
||||
"io-definition-agent.toml": (
|
||||
"fesa-io-contract",
|
||||
"fem-theory-query",
|
||||
),
|
||||
"reference-model-agent.toml": (
|
||||
"fesa-reference-models",
|
||||
"fem-theory-query",
|
||||
),
|
||||
"implementation-planning-agent.toml": (
|
||||
"fesa-formulation-spec",
|
||||
"fesa-reference-models",
|
||||
"fesa-cpp-msvc-tdd",
|
||||
"fem-theory-query",
|
||||
),
|
||||
"implementation-agent.toml": ("fesa-cpp-msvc-tdd",),
|
||||
"build-test-executor-agent.toml": ("fesa-cpp-msvc-tdd",),
|
||||
"correction-agent.toml": ("fesa-cpp-msvc-tdd",),
|
||||
"reference-verification-agent.toml": (
|
||||
"fesa-reference-comparison",
|
||||
"fesa-io-contract",
|
||||
),
|
||||
"physics-evaluation-agent.toml": (
|
||||
"fesa-physics-sanity",
|
||||
"fem-theory-query",
|
||||
),
|
||||
"release-agent.toml": ("fesa-release-readiness",),
|
||||
}
|
||||
|
||||
|
||||
class AgentSkillReferenceTests(unittest.TestCase):
|
||||
def test_agents_reference_their_solver_skills(self):
|
||||
for agent_file, skill_names in AGENT_SKILL_REFERENCES.items():
|
||||
with self.subTest(agent=agent_file):
|
||||
text = (AGENTS_ROOT / agent_file).read_text(encoding="utf-8")
|
||||
data = tomllib.loads(text)
|
||||
instructions = data["developer_instructions"]
|
||||
|
||||
self.assertIn("Skill references:", instructions)
|
||||
for skill_name in skill_names:
|
||||
self.assertIn(f"${skill_name}", instructions)
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
unittest.main()
|
||||
@@ -1,92 +0,0 @@
|
||||
import unittest
|
||||
from pathlib import Path
|
||||
|
||||
|
||||
ROOT = Path(__file__).resolve().parents[1]
|
||||
SKILL_PATH = ROOT / ".codex" / "skills" / "fesa-feature-definition" / "SKILL.md"
|
||||
|
||||
|
||||
def read_skill():
|
||||
return SKILL_PATH.read_text(encoding="utf-8")
|
||||
|
||||
|
||||
def parse_frontmatter(text):
|
||||
lines = text.splitlines()
|
||||
if not lines or lines[0] != "---":
|
||||
raise AssertionError("SKILL.md must start with YAML frontmatter")
|
||||
|
||||
fields = {}
|
||||
for line in lines[1:]:
|
||||
if line == "---":
|
||||
return fields
|
||||
key, sep, value = line.partition(":")
|
||||
if not sep:
|
||||
raise AssertionError(f"Invalid frontmatter line: {line}")
|
||||
fields[key.strip()] = value.strip()
|
||||
|
||||
raise AssertionError("SKILL.md frontmatter must be closed")
|
||||
|
||||
|
||||
class FesaFeatureDefinitionSkillTests(unittest.TestCase):
|
||||
def test_skill_file_exists_with_required_frontmatter(self):
|
||||
self.assertTrue(SKILL_PATH.exists(), "fesa-feature-definition SKILL.md is missing")
|
||||
|
||||
fields = parse_frontmatter(read_skill())
|
||||
|
||||
self.assertEqual(set(fields), {"name", "description"})
|
||||
self.assertEqual(fields["name"], "fesa-feature-definition")
|
||||
self.assertIn("Use when", fields["description"])
|
||||
self.assertIn("FESA solver feature requests", fields["description"])
|
||||
self.assertIn("requirements", fields["description"])
|
||||
self.assertIn("research questions", fields["description"])
|
||||
self.assertIn("acceptance criteria", fields["description"])
|
||||
self.assertIn("verification matrices", fields["description"])
|
||||
|
||||
def test_skill_body_defines_core_workflow_and_inputs(self):
|
||||
body = read_skill()
|
||||
|
||||
for required_text in (
|
||||
"## Inputs",
|
||||
"## Workflow",
|
||||
"## Output Contract",
|
||||
"## Boundaries",
|
||||
"## Quality Gate",
|
||||
"docs/SOLVER_SKILL_DESIGN.md",
|
||||
"docs/SOLVER_AGENT_DESIGN.md",
|
||||
"AGENTS.md",
|
||||
"docs/requirements/<feature-id>.md",
|
||||
"docs/research/<feature-id>-research.md",
|
||||
):
|
||||
self.assertIn(required_text, body)
|
||||
|
||||
def test_skill_body_defines_requirement_and_verification_contract(self):
|
||||
body = read_skill()
|
||||
|
||||
for required_text in (
|
||||
"Feature Definition Packet",
|
||||
"shall",
|
||||
"Requirement Verification Matrix",
|
||||
"Research Questions",
|
||||
"Reference Artifact Needs",
|
||||
"Tolerance Decisions",
|
||||
"Downstream Handoff",
|
||||
"FESA-REQ-<FEATURE>-###",
|
||||
"needs-user-decision",
|
||||
):
|
||||
self.assertIn(required_text, body)
|
||||
|
||||
def test_skill_body_enforces_scope_boundaries(self):
|
||||
body = read_skill()
|
||||
|
||||
for required_text in (
|
||||
"Do not finalize FEM formulations.",
|
||||
"Do not implement C++ code.",
|
||||
"Do not run Abaqus, Nastran, or any reference solver.",
|
||||
"Do not generate reference CSVs.",
|
||||
"Do not approve release readiness.",
|
||||
):
|
||||
self.assertIn(required_text, body)
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
unittest.main()
|
||||
@@ -1,124 +0,0 @@
|
||||
import unittest
|
||||
from pathlib import Path
|
||||
|
||||
|
||||
ROOT = Path(__file__).resolve().parents[1]
|
||||
SKILL_PATH = ROOT / ".codex" / "skills" / "fesa-fem-specification" / "SKILL.md"
|
||||
|
||||
|
||||
def read_skill():
|
||||
return SKILL_PATH.read_text(encoding="utf-8")
|
||||
|
||||
|
||||
def parse_frontmatter(text):
|
||||
lines = text.splitlines()
|
||||
if not lines or lines[0] != "---":
|
||||
raise AssertionError("SKILL.md must start with YAML frontmatter")
|
||||
|
||||
fields = {}
|
||||
for line in lines[1:]:
|
||||
if line == "---":
|
||||
return fields
|
||||
key, sep, value = line.partition(":")
|
||||
if not sep:
|
||||
raise AssertionError(f"Invalid frontmatter line: {line}")
|
||||
fields[key.strip()] = value.strip()
|
||||
|
||||
raise AssertionError("SKILL.md frontmatter must be closed")
|
||||
|
||||
|
||||
class FesaFemSpecificationSkillTests(unittest.TestCase):
|
||||
def test_skill_file_exists_with_required_frontmatter(self):
|
||||
self.assertTrue(SKILL_PATH.exists(), "fesa-fem-specification SKILL.md is missing")
|
||||
|
||||
fields = parse_frontmatter(read_skill())
|
||||
|
||||
self.assertEqual(set(fields), {"name", "description"})
|
||||
self.assertEqual(fields["name"], "fesa-fem-specification")
|
||||
self.assertIn("Use when", fields["description"])
|
||||
self.assertIn("FESA FEM formulations", fields["description"])
|
||||
self.assertIn("numerical review", fields["description"])
|
||||
self.assertIn("Abaqus .inp", fields["description"])
|
||||
self.assertIn("CSV schemas", fields["description"])
|
||||
self.assertIn("implementation-planning handoffs", fields["description"])
|
||||
|
||||
def test_skill_body_defines_workflow_and_inputs(self):
|
||||
body = read_skill()
|
||||
|
||||
for required_text in (
|
||||
"## Inputs",
|
||||
"## Workflow",
|
||||
"INPUT CHECK",
|
||||
"FORMULATION SPEC",
|
||||
"NUMERICAL REVIEW CHECK",
|
||||
"I/O CONTRACT",
|
||||
"HANDOFF",
|
||||
"## Quality Gate",
|
||||
"docs/SOLVER_SKILL_DESIGN.md",
|
||||
"docs/SOLVER_AGENT_DESIGN.md",
|
||||
"AGENTS.md",
|
||||
"docs/requirements/<feature-id>.md",
|
||||
"docs/research/<feature-id>-research.md",
|
||||
):
|
||||
self.assertIn(required_text, body)
|
||||
|
||||
def test_skill_body_defines_formulation_contract(self):
|
||||
body = read_skill()
|
||||
|
||||
for required_text in (
|
||||
"Strong Form",
|
||||
"Weak or Variational Form",
|
||||
"Discretization",
|
||||
"Kinematics",
|
||||
"Element Equations",
|
||||
"Mapping and Numerical Integration",
|
||||
"Output Recovery",
|
||||
"Numerical Risks",
|
||||
"partition of unity",
|
||||
"Kronecker delta",
|
||||
"Jacobian",
|
||||
"derivative transform",
|
||||
):
|
||||
self.assertIn(required_text, body)
|
||||
|
||||
def test_skill_body_defines_io_contract(self):
|
||||
body = read_skill()
|
||||
|
||||
for required_text in (
|
||||
"Abaqus Input Scope",
|
||||
"Model Data Mapping",
|
||||
"History Data Mapping",
|
||||
"Internal Model Contract",
|
||||
"Output and CSV Schemas",
|
||||
"*NODE",
|
||||
"*ELEMENT",
|
||||
"*MATERIAL",
|
||||
"*ELASTIC",
|
||||
"*BOUNDARY",
|
||||
"*STEP",
|
||||
"*OUTPUT",
|
||||
"*NODE OUTPUT",
|
||||
"*ELEMENT OUTPUT",
|
||||
"displacements.csv",
|
||||
"reactions.csv",
|
||||
"element_forces.csv",
|
||||
"stresses.csv",
|
||||
):
|
||||
self.assertIn(required_text, body)
|
||||
|
||||
def test_skill_body_enforces_scope_boundaries(self):
|
||||
body = read_skill()
|
||||
|
||||
for required_text in (
|
||||
"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.",
|
||||
):
|
||||
self.assertIn(required_text, body)
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
unittest.main()
|
||||
@@ -0,0 +1,283 @@
|
||||
import unittest
|
||||
from pathlib import Path
|
||||
|
||||
|
||||
ROOT = Path(__file__).resolve().parents[1]
|
||||
SKILLS_ROOT = ROOT / ".codex" / "skills"
|
||||
COMMON_SECTIONS = (
|
||||
"## Inputs",
|
||||
"## Workflow",
|
||||
"## Output Contract",
|
||||
"## Boundaries",
|
||||
"## Quality Gate",
|
||||
"## Handoff",
|
||||
)
|
||||
|
||||
|
||||
SKILLS = {
|
||||
"fesa-requirements-baseline": {
|
||||
"description_terms": (
|
||||
"Use when",
|
||||
"FESA solver",
|
||||
"requirements",
|
||||
"acceptance criteria",
|
||||
"verification matrix",
|
||||
),
|
||||
"body_terms": (
|
||||
"docs/requirements/<feature-id>.md",
|
||||
"Requirement Verification Matrix",
|
||||
"shall",
|
||||
"FESA-REQ-<FEATURE>-###",
|
||||
"Verification Quantities",
|
||||
"Tolerance Policy",
|
||||
"Reference Artifact Requirements",
|
||||
"Do not implement C++ code.",
|
||||
),
|
||||
},
|
||||
"fesa-research-evidence": {
|
||||
"description_terms": (
|
||||
"Use when",
|
||||
"FESA solver",
|
||||
"research",
|
||||
"FEM theory",
|
||||
"benchmarks",
|
||||
),
|
||||
"body_terms": (
|
||||
"docs/research/<feature-id>-research.md",
|
||||
"Source Inventory",
|
||||
"Source Reliability Tier",
|
||||
"Candidate Benchmarks",
|
||||
"Verification Relevance",
|
||||
"Applicability Limits",
|
||||
"Separate verified facts from inference.",
|
||||
),
|
||||
},
|
||||
"fesa-formulation-spec": {
|
||||
"description_terms": (
|
||||
"Use when",
|
||||
"FESA FEM",
|
||||
"formulation",
|
||||
"element equations",
|
||||
"output recovery",
|
||||
),
|
||||
"body_terms": (
|
||||
"docs/formulations/<feature-id>-formulation.md",
|
||||
"Strong Form",
|
||||
"Weak or Variational Form",
|
||||
"Discretization",
|
||||
"Kinematics",
|
||||
"Element Equations",
|
||||
"Jacobian",
|
||||
"Output Recovery",
|
||||
"Do not design C++ APIs.",
|
||||
),
|
||||
},
|
||||
"fesa-numerical-review": {
|
||||
"description_terms": (
|
||||
"Use when",
|
||||
"FESA FEM",
|
||||
"numerical review",
|
||||
"stability",
|
||||
"implementation planning",
|
||||
),
|
||||
"body_terms": (
|
||||
"docs/numerical-reviews/<feature-id>-review.md",
|
||||
"pass-for-implementation-planning",
|
||||
"rigid body modes",
|
||||
"patch test",
|
||||
"hourglass",
|
||||
"locking",
|
||||
"Jacobian",
|
||||
"Do not edit formulations directly.",
|
||||
),
|
||||
},
|
||||
"fesa-io-contract": {
|
||||
"description_terms": (
|
||||
"Use when",
|
||||
"FESA solver",
|
||||
"Abaqus .inp",
|
||||
"CSV schemas",
|
||||
"I/O",
|
||||
),
|
||||
"body_terms": (
|
||||
"docs/io-definitions/<feature-id>-io.md",
|
||||
"Abaqus Input Scope",
|
||||
"Internal Model Contract",
|
||||
"Output and CSV Schemas",
|
||||
"*NODE",
|
||||
"*ELEMENT",
|
||||
"*MATERIAL",
|
||||
"*BOUNDARY",
|
||||
"*STEP",
|
||||
"Do not implement parsers.",
|
||||
),
|
||||
},
|
||||
"fesa-reference-models": {
|
||||
"description_terms": (
|
||||
"Use when",
|
||||
"FESA",
|
||||
"reference model",
|
||||
"Abaqus input",
|
||||
"artifact",
|
||||
),
|
||||
"body_terms": (
|
||||
"docs/reference-models/<feature-id>-reference-models.md",
|
||||
"references/<feature-id>/<model-id>/",
|
||||
"model.inp",
|
||||
"metadata.json",
|
||||
"displacements.csv",
|
||||
"reactions.csv",
|
||||
"element_forces.csv",
|
||||
"stresses.csv",
|
||||
"Coverage Matrix",
|
||||
"Do not generate reference CSVs.",
|
||||
),
|
||||
},
|
||||
"fesa-cpp-msvc-tdd": {
|
||||
"description_terms": (
|
||||
"Use when",
|
||||
"FESA solver",
|
||||
"C++",
|
||||
"MSVC",
|
||||
"TDD",
|
||||
),
|
||||
"body_terms": (
|
||||
"docs/implementation-plans/<feature-id>-implementation-plan.md",
|
||||
"RED -> GREEN -> VERIFY",
|
||||
"python -m unittest discover -s scripts -p \"test_*.py\"",
|
||||
"python scripts/validate_workspace.py",
|
||||
"ctest",
|
||||
"configure | compile | link | test | reference-comparison",
|
||||
"Do not change requirements.",
|
||||
),
|
||||
},
|
||||
"fesa-reference-comparison": {
|
||||
"description_terms": (
|
||||
"Use when",
|
||||
"FESA solver",
|
||||
"reference CSV",
|
||||
"tolerance",
|
||||
"comparison",
|
||||
),
|
||||
"body_terms": (
|
||||
"docs/reference-verifications/<feature-id>-reference-verification.md",
|
||||
"ARTIFACT CHECK -> COMPARE -> CLASSIFY -> REPORT",
|
||||
"max absolute error",
|
||||
"max relative error",
|
||||
"RMS error",
|
||||
"missing rows",
|
||||
"extra rows",
|
||||
"pass-for-physics-evaluation",
|
||||
"Do not change tolerance policies.",
|
||||
),
|
||||
},
|
||||
"fesa-physics-sanity": {
|
||||
"description_terms": (
|
||||
"Use when",
|
||||
"FESA solver",
|
||||
"physical plausibility",
|
||||
"equilibrium",
|
||||
"physics",
|
||||
),
|
||||
"body_terms": (
|
||||
"docs/physics-evaluations/<feature-id>-physics-evaluation.md",
|
||||
"global equilibrium",
|
||||
"reaction consistency",
|
||||
"displacement direction",
|
||||
"symmetry",
|
||||
"element force balance",
|
||||
"model coverage",
|
||||
"pass-for-release-agent",
|
||||
"Do not approve release readiness.",
|
||||
),
|
||||
},
|
||||
"fesa-release-readiness": {
|
||||
"description_terms": (
|
||||
"Use when",
|
||||
"FESA solver",
|
||||
"release readiness",
|
||||
"release notes",
|
||||
"known limitations",
|
||||
),
|
||||
"body_terms": (
|
||||
"docs/releases/<feature-id>-release.md",
|
||||
"GATE AUDIT -> TRACEABILITY CHECK -> RELEASE DOCUMENTATION -> RELEASE VERDICT",
|
||||
"ready-for-release",
|
||||
"Known Limitations",
|
||||
"Release Notes Draft",
|
||||
"pass-for-reference-verification",
|
||||
"pass-for-physics-evaluation",
|
||||
"pass-for-release-agent",
|
||||
"Do not publish, deploy, package, tag, commit, or externally release anything unless the user explicitly asks.",
|
||||
),
|
||||
},
|
||||
}
|
||||
|
||||
|
||||
def read_skill(skill_name):
|
||||
return (SKILLS_ROOT / skill_name / "SKILL.md").read_text(encoding="utf-8")
|
||||
|
||||
|
||||
def parse_frontmatter(text):
|
||||
lines = text.splitlines()
|
||||
if not lines or lines[0] != "---":
|
||||
raise AssertionError("SKILL.md must start with YAML frontmatter")
|
||||
|
||||
fields = {}
|
||||
for line in lines[1:]:
|
||||
if line == "---":
|
||||
return fields
|
||||
key, sep, value = line.partition(":")
|
||||
if not sep:
|
||||
raise AssertionError(f"Invalid frontmatter line: {line}")
|
||||
fields[key.strip()] = value.strip()
|
||||
|
||||
raise AssertionError("SKILL.md frontmatter must be closed")
|
||||
|
||||
|
||||
class FesaSolverSkillTests(unittest.TestCase):
|
||||
def test_all_solver_skill_files_exist_with_required_frontmatter(self):
|
||||
for skill_name, spec in SKILLS.items():
|
||||
with self.subTest(skill=skill_name):
|
||||
skill_path = SKILLS_ROOT / skill_name / "SKILL.md"
|
||||
self.assertTrue(skill_path.exists(), f"{skill_name} SKILL.md is missing")
|
||||
|
||||
fields = parse_frontmatter(read_skill(skill_name))
|
||||
|
||||
self.assertEqual(set(fields), {"name", "description"})
|
||||
self.assertEqual(fields["name"], skill_name)
|
||||
for term in spec["description_terms"]:
|
||||
self.assertIn(term, fields["description"])
|
||||
|
||||
def test_all_solver_skills_define_common_contract_sections(self):
|
||||
for skill_name in SKILLS:
|
||||
with self.subTest(skill=skill_name):
|
||||
body = read_skill(skill_name)
|
||||
for section in COMMON_SECTIONS:
|
||||
self.assertIn(section, body)
|
||||
self.assertIn("AGENTS.md", body)
|
||||
self.assertIn("docs/SOLVER_AGENT_DESIGN.md", body)
|
||||
self.assertNotIn("docs/SOLVER_SKILL_DESIGN.md", body)
|
||||
|
||||
def test_solver_skills_define_skill_specific_contracts(self):
|
||||
for skill_name, spec in SKILLS.items():
|
||||
with self.subTest(skill=skill_name):
|
||||
body = read_skill(skill_name)
|
||||
for term in spec["body_terms"]:
|
||||
self.assertIn(term, body)
|
||||
|
||||
def test_solver_skills_have_openai_ui_metadata(self):
|
||||
for skill_name in SKILLS:
|
||||
with self.subTest(skill=skill_name):
|
||||
metadata = SKILLS_ROOT / skill_name / "agents" / "openai.yaml"
|
||||
self.assertTrue(metadata.exists(), f"{skill_name} openai.yaml is missing")
|
||||
text = metadata.read_text(encoding="utf-8")
|
||||
self.assertIn("interface:", text)
|
||||
self.assertIn("display_name:", text)
|
||||
self.assertIn("short_description:", text)
|
||||
self.assertIn("default_prompt:", text)
|
||||
self.assertIn(f"${skill_name}", text)
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
unittest.main()
|
||||
Reference in New Issue
Block a user