FESADev/.codex/skills/fesa-requirements-baseline/SKILL.md

name, description

name	description
fesa-requirements-baseline	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
• User feature request, target capability, constraints, and known exclusions
• Existing docs/<feature-id>/requirements.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 a minimal Reference Case: exact existing input/required CSV paths, blocking and warning-only quantities, HDF5 projection, source-ID/component matching, and tolerance.
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/<feature-id>/requirements.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 Case 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 or modify Abaqus reference CSV files.
• Do not approve release readiness.

Quality Gate

• Every must requirement has a verification method and acceptance criteria.
• Every numerical solver-output requirement has units, coordinates, and tolerance when applicable.
• Every reference-comparison requirement names exact required files, compared components, source identity, blocking/warning behavior, and tolerance.
• Do not require canonical names, README, metadata, provenance, or CSVs for quantities outside the feature acceptance boundary.
• Words like "accurate", "fast", and "Abaqus-like" are converted into measurable criteria or open questions.
• Return reference artifact, comparison quantity, source-identity/component, and tolerance gaps for Numerical Review rather than inventing acceptance rules.

Handoff

Return docs/<feature-id>/requirements.md, status, evidence summary, and blockers to Coordinator Agent. Route theory questions to Research Agent and reference acceptance, artifact, identity/component, and tolerance questions to Numerical Review Agent through Coordinator Agent.