AbaqusSubroutineDev/.codex/skills/abaqus-subroutine-requirements/SKILL.md

name, description

name	description
abaqus-subroutine-requirements	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/<feature-id>.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-<FEATURE>-###.
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/<feature-id>/.
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/<feature-id>.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.