--- name: abaqus-subroutine-requirements description: Use when defining Abaqus User Subroutine requirements, acceptance criteria, verification quantities, tolerance policy, and a requirement verification matrix before research, formulation, TDD test models, or Fortran implementation. --- # Abaqus Subroutine Requirements Use this skill to turn a requested Abaqus User Subroutine behavior into a measurable contract for downstream research, formulation, interface, test model, implementation, and validation work. ## Inputs Read first: - `AGENTS.md` - `docs/ABAQUS_SUBROUTINE_AGENT_DESIGN.md` - `docs/requirements/README.md` - User request, target Abaqus entry point, material/element behavior, constraints, and exclusions - Existing `docs/requirements/.md` when revising a feature ## Workflow 1. Assign a stable `feature_id` in kebab case. 2. Define purpose, scope, analysis procedure, element/material family, units, and target entry points such as `UMAT | VUMAT | UEL | UEXPAN | DISP | USDFLD`. 3. Convert requested behavior into singular `shall` statements with ids like `ABAQUS-USUB-REQ--###`. 4. Define Verification Quantities: stress, strain, state variables, DDSDDE/tangent terms, displacement, reaction, energy, residual, or user output variables. 5. Record Tolerance Policy values or mark them `needs-user-decision`. 6. Record Reference Artifact Requirements under `references//`. 7. Build a Requirement Verification Matrix mapping requirement, source, verification method, acceptance criteria, tolerance, downstream agents, and status. ## Output Contract Produce or revise `docs/requirements/.md` with Metadata, Purpose, In Scope, Out Of Scope, 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 Fortran code. - Do not write finite element formulations. - Do not design Abaqus ABI argument handling. - Do not run Abaqus. - 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 decision owner. - Every reference-comparison requirement names required artifacts. - Words like "accurate", "robust", and "Abaqus-like" are converted into measurable criteria or open questions. ## Handoff Route theory gaps to Research Agent, math gaps to Formulation Agent, ABI and parameter gaps to I/O Definition Agent, TDD model needs to Reference Model Agent, and implementation readiness to Implementation Planning Agent.