--- name: fesa-requirements-baseline description: Use when analyzing new FESA solver feature requirements, acceptance criteria, tolerance decisions, verification quantities, and a requirement verification matrix before research, formulation, reference modeling, or implementation planning. --- # FESA New Solver Feature Requirements Analysis Use this skill to turn a new solver feature request into a verifiable new solver feature requirements analysis baseline that downstream agents can use without guessing. ## Inputs Read these first: - `AGENTS.md` - `docs/AGENT_RULES.md` - `docs/requirements/README.md` - User feature request, target capability, constraints, and known exclusions - Existing `docs/requirements/.md` when revising a feature ## Workflow 1. Assign a stable `feature_id` in kebab case. 2. Analyze purpose, included scope, excluded scope, and analysis definition. 3. Convert requested behavior into analyzed `shall` statements with ids like `FESA-REQ--###`. 4. Analyze and record verification quantities: displacement, reaction, element force, stress, strain, energy, or residual. 5. Analyze and record Tolerance Policy values or mark them `needs-user-decision`. 6. Analyze and record Reference Artifact Requirements under `references//`. 7. Build a Requirement Verification Matrix that maps analyzed 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/.md` as a new solver feature requirements analysis document with: - Metadata with `feature_id`, analysis 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 from the requirements analysis ## 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 HDF5 artifacts or reference CSVs. - Do not approve release readiness. ## Quality Gate - Every `must` requirement analyzed in the document has a verification method and acceptance criteria. - Every numerical requirement analyzed in the document has units, coordinate system, and tolerance or an explicit owner for the decision. - Every reference-comparison requirement analyzed in the document 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.