AbaqusSubroutineDev/.codex/skills/abaqus-fortran-tdd/SKILL.md

name, description

name	description
abaqus-fortran-tdd	Use when planning, implementing, validating, or correcting Abaqus User Subroutine Fortran work with Intel oneAPI, no-Abaqus tests, Abaqus opt-in validation, and RED/GREEN/VERIFY evidence.

Abaqus Fortran TDD

Use this skill to keep Abaqus User Subroutine Fortran work test-first, no-Abaqus compatible by default, and bounded by approved upstream contracts.

Inputs

Read first:

• AGENTS.md
• docs/ABAQUS_SUBROUTINE_AGENT_DESIGN.md
• docs/implementation-plans/README.md
• docs/build-test-reports/README.md
• docs/corrections/README.md
• Related requirements, formulation, numerical review, interface, and test model documents

Workflow

1. For planning, convert upstream documents into ordered Fortran tasks and test ids.
2. For implementation, follow RED -> GREEN -> VERIFY.
3. RED: write the planned no-Abaqus Fortran/Python driver test first and run it to verify expected failure.
4. GREEN: implement the minimum Fortran kernel, Abaqus wrapper, or manifest change needed for the task.
5. VERIFY: run the targeted command, then python scripts/validate_fortran.py, python scripts/validate_reference_artifacts.py, and python scripts/validate_workspace.py.
6. Use Intel oneAPI Fortran discovery. Prefer ifx; use ifort when ifx is unavailable.
7. For failure triage, classify as fortran-compile | link | no-abaqus-test | abaqus-validation | reference-artifact | harness | environment | upstream-contract.

Output Contract

Produce one of these, depending on role: docs/implementation-plans/<feature-id>-implementation-plan.md, an implementation report with RED/GREEN/VERIFY evidence, docs/build-test-reports/<feature-id>-build-test.md, or docs/corrections/<feature-id>-correction.md.

Boundaries

• Do not change requirements, formulations, interface contracts, test model contracts, reference artifacts, or tolerance policies unless explicitly asked.
• Do not run Abaqus unless HARNESS_ABAQUS_VALIDATION=run and explicit commands are provided.
• Do not generate reference CSVs.
• Do not approve release readiness.
• Do not expand scope beyond the approved implementation plan.

Quality Gate

• Every Fortran production change has a related no-Abaqus Fortran/Python driver test or existing failing test.
• Every test records RED failure and GREEN pass evidence.
• Fortran source remains compatible with Intel oneAPI ifx or ifort.
• Validation evidence records command, exit code, stdout/stderr tail, and failure classification.

Handoff

Send passing no-Abaqus and workspace evidence to Build/Test Executor Agent. Send implementation-owned failures to Correction Agent. Send reference artifact readiness to Reference Verification Agent.