53 lines
2.7 KiB
Markdown
53 lines
2.7 KiB
Markdown
---
|
|
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/<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.
|