initial commit
This commit is contained in:
김경종
@@ -0,0 +1,52 @@
|
||||
---
|
||||
name: abaqus-fortran-tdd
|
||||
description: 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.
|
||||
@@ -0,0 +1,4 @@
|
||||
interface:
|
||||
display_name: "Abaqus Fortran TDD"
|
||||
short_description: "Run Fortran test-first work."
|
||||
default_prompt: "Use $abaqus-fortran-tdd for Abaqus User Subroutine Fortran TDD implementation work."
|
||||
@@ -0,0 +1,53 @@
|
||||
---
|
||||
name: abaqus-subroutine-formulation
|
||||
description: Use when drafting Abaqus User Subroutine finite element formulation specifications, stress updates, consistent tangents, state variable evolution, weak forms, element equations, numerical integration, and output recovery contracts.
|
||||
---
|
||||
|
||||
# Abaqus Subroutine Formulation
|
||||
|
||||
Use this skill to convert approved requirements and research evidence into a finite element formulation suitable for Abaqus User Subroutine implementation. Finite element formulation is the owned artifact for this skill.
|
||||
|
||||
## Inputs
|
||||
|
||||
Read first:
|
||||
|
||||
- `AGENTS.md`
|
||||
- `docs/ABAQUS_SUBROUTINE_AGENT_DESIGN.md`
|
||||
- `docs/formulations/README.md`
|
||||
- `docs/requirements/<feature-id>.md`
|
||||
- `docs/research/<feature-id>-research.md`
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Confirm analysis assumptions, element/material family, strain measure, stress measure, coordinate system, and units.
|
||||
2. Define Strong Form and Boundary Conditions when relevant.
|
||||
3. Define Weak or Variational Form and residual statement when relevant.
|
||||
4. Define discretization, kinematics, strain-displacement relations, and numerical integration.
|
||||
5. Define stress update, consistent tangent, state variables, and output recovery.
|
||||
6. Define Constitutive Contract without creating Fortran source layout.
|
||||
7. Record numerical risks and tests that should catch them.
|
||||
8. Write Algorithm Pseudocode at math level only.
|
||||
|
||||
## Output Contract
|
||||
|
||||
Produce or revise `docs/formulations/<feature-id>-formulation.md` with Strong Form and Boundary Conditions, Weak or Variational Form, Discretization, Kinematics, Constitutive Contract, Element Equations, Mapping and Numerical Integration, Output Recovery, Abaqus Subroutine Mapping, Numerical Risks, Algorithm Pseudocode, and Downstream Handoff.
|
||||
|
||||
## Boundaries
|
||||
|
||||
- Do not implement code.
|
||||
- Do not design Fortran source layout.
|
||||
- Do not choose file ownership.
|
||||
- Do not run Abaqus.
|
||||
- Do not generate reference CSVs.
|
||||
- Do not approve release readiness.
|
||||
|
||||
## Quality Gate
|
||||
|
||||
- Stress update, consistent tangent, and state variables are defined when the selected entry point requires them.
|
||||
- Element equations identify residual, tangent, stiffness, mass, or damping terms when applicable.
|
||||
- Output recovery identifies location, components, units, and coordinate system.
|
||||
- Numerical risks include rigid body modes, patch test, hourglass, locking, Jacobian, conditioning, tangent consistency, and convergence risks when relevant.
|
||||
|
||||
## Handoff
|
||||
|
||||
Send review-ready formulation to Numerical Review Agent, interface needs to I/O Definition Agent, model needs to Reference Model Agent, and implementation algorithm notes to Implementation Planning Agent.
|
||||
@@ -0,0 +1,4 @@
|
||||
interface:
|
||||
display_name: "Abaqus Subroutine Formulation"
|
||||
short_description: "Draft formulation specs."
|
||||
default_prompt: "Use $abaqus-subroutine-formulation to draft Abaqus User Subroutine finite element formulation specs."
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
name: abaqus-subroutine-interface
|
||||
description: Use when defining Abaqus User Subroutine input/output parameter contracts, Abaqus ABI argument semantics, supported .inp test scope, validation rules, and extracted CSV schemas for reference comparison.
|
||||
---
|
||||
|
||||
# Abaqus Subroutine Interface
|
||||
|
||||
Use this skill to define exactly what Abaqus passes into a User Subroutine and what the subroutine must return or update.
|
||||
|
||||
## Inputs
|
||||
|
||||
Read first:
|
||||
|
||||
- `AGENTS.md`
|
||||
- `docs/ABAQUS_SUBROUTINE_AGENT_DESIGN.md`
|
||||
- `docs/io-definitions/README.md`
|
||||
- Requirements, research, formulation, and numerical review documents
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Define the Abaqus ABI Contract for each entry point.
|
||||
2. Record required parameter semantics for UMAT, VUMAT, UEL, or other selected entry points.
|
||||
3. Define input parameters, output parameters, in-place updates, units, coordinate system, and storage conventions.
|
||||
4. For UMAT, define STRESS, STRAN, DSTRAN, TIME, DTIME, TEMP, PREDEF, PROPS, NPROPS, COORDS, DROT, DDSDDE, STATEV, PNEWDT, NOEL, NPT, KSTEP, and KINC usage as applicable.
|
||||
5. Define supported `.inp` model scope for tests and output requests needed for extracted CSV comparison.
|
||||
6. Define Validation Rules and failure messages.
|
||||
|
||||
## Output Contract
|
||||
|
||||
Produce or revise `docs/io-definitions/<feature-id>-io.md` with Abaqus Input Scope, Abaqus ABI Contract, Syntax Policy, Model Data Mapping, History Data Mapping, Subroutine Parameter Contract, Output and CSV Schemas, Validation Rules, and Downstream Handoff.
|
||||
|
||||
## Boundaries
|
||||
|
||||
- Do not implement parsers.
|
||||
- Do not implement wrappers.
|
||||
- Do not design Fortran source layout.
|
||||
- Do not claim full Abaqus compatibility.
|
||||
- Do not run Abaqus.
|
||||
- Do not generate reference CSVs.
|
||||
- Do not approve release readiness.
|
||||
|
||||
## Quality Gate
|
||||
|
||||
- Unsupported Abaqus input is explicit: unsupported, ignored-with-warning, or requires user decision.
|
||||
- CSV schema includes units, coordinate system, output location, components, step/frame identity, and ID matching.
|
||||
- ABI parameter direction and update responsibility are explicit for every used argument.
|
||||
|
||||
## Handoff
|
||||
|
||||
Send input examples and schema needs to Reference Model Agent, implementation constraints to Implementation Planning Agent, and comparison matching rules to Reference Verification Agent.
|
||||
@@ -0,0 +1,4 @@
|
||||
interface:
|
||||
display_name: "Abaqus Subroutine Interface"
|
||||
short_description: "Define ABI and output contracts."
|
||||
default_prompt: "Use $abaqus-subroutine-interface to define Abaqus User Subroutine input/output parameter contracts."
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
name: abaqus-subroutine-numerical-review
|
||||
description: Use when independently reviewing Abaqus User Subroutine formulation correctness, algorithmic consistency, tangent consistency, state updates, stability risks, patch tests, locking, Jacobian handling, and implementation readiness.
|
||||
---
|
||||
|
||||
# Abaqus Subroutine Numerical Review
|
||||
|
||||
Use this skill to review whether a formulation is numerically sound enough for Abaqus User Subroutine interface definition and Fortran implementation planning. Numerical review is the owned artifact for this skill.
|
||||
|
||||
## Inputs
|
||||
|
||||
Read first:
|
||||
|
||||
- `AGENTS.md`
|
||||
- `docs/ABAQUS_SUBROUTINE_AGENT_DESIGN.md`
|
||||
- `docs/numerical-reviews/README.md`
|
||||
- `docs/formulations/<feature-id>-formulation.md`
|
||||
- Related requirements and research documents
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Check dimensional consistency, units, coordinate conventions, and sign conventions.
|
||||
2. Check residual, stress update, and consistent tangent consistency.
|
||||
3. Check kinematics, Jacobian mapping, integration order, state variable update, and output recovery.
|
||||
4. Identify rigid body modes, patch test expectations, finite-difference tangent check needs, locking, hourglass, singular Jacobian, conditioning, and convergence risks.
|
||||
5. Require revisions when the formulation is ambiguous or inconsistent.
|
||||
6. Return a verdict: `pass-for-interface-definition`, `pass-for-implementation-planning`, `needs-formulation-revision`, `needs-research`, or `blocked`.
|
||||
|
||||
## Output Contract
|
||||
|
||||
Produce or revise `docs/numerical-reviews/<feature-id>-review.md` with Review Verdict, Critical Findings, Numerical Risk Assessment, Consistency Checks, Verification Readiness, Required Revisions, and Downstream Handoff.
|
||||
|
||||
## Boundaries
|
||||
|
||||
- Do not implement code.
|
||||
- Do not edit formulations directly.
|
||||
- Do not design Fortran source layout.
|
||||
- Do not run Abaqus.
|
||||
- Do not generate reference CSVs.
|
||||
- Do not approve release readiness.
|
||||
|
||||
## Quality Gate
|
||||
|
||||
- Findings cite the exact formulation section or missing assumption.
|
||||
- Tangent/stiffness expectations are explicit enough for tests.
|
||||
- Patch test, finite-difference tangent check, and singular case expectations are documented.
|
||||
- Blocking issues are routed to the owning upstream agent.
|
||||
|
||||
## Handoff
|
||||
|
||||
Send approved formulations to I/O Definition Agent and Implementation Planning Agent. Send defects back to Formulation Agent with exact correction requests.
|
||||
@@ -0,0 +1,4 @@
|
||||
interface:
|
||||
display_name: "Abaqus Numerical Review"
|
||||
short_description: "Review numerical readiness."
|
||||
default_prompt: "Use $abaqus-subroutine-numerical-review to review Abaqus User Subroutine numerical readiness."
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
name: abaqus-subroutine-physics-sanity
|
||||
description: Use when evaluating Abaqus User Subroutine physical plausibility after validation, including equilibrium, reactions, displacement direction, stress/strain sanity, state variable behavior, energy/residual checks, and model coverage.
|
||||
---
|
||||
|
||||
# Abaqus Subroutine Physics Sanity
|
||||
|
||||
Use this skill to decide whether validation-passing Abaqus User Subroutine outputs are physically credible enough for readiness review. Physics sanity is the owned artifact for this skill.
|
||||
|
||||
## Inputs
|
||||
|
||||
Read first:
|
||||
|
||||
- `AGENTS.md`
|
||||
- `docs/ABAQUS_SUBROUTINE_AGENT_DESIGN.md`
|
||||
- `docs/physics-evaluations/README.md`
|
||||
- Reference verification reports
|
||||
- Stored reference and generated CSVs
|
||||
- Requirements, formulation, interface, and test model documents
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Check global equilibrium, reaction consistency, displacement direction, symmetry, and boundary condition effects.
|
||||
2. Check stress/strain signs, magnitudes, locations, coordinate systems, and state variable evolution.
|
||||
3. Check energy/residual quantities when available.
|
||||
4. Check model coverage for the claimed behavior.
|
||||
5. Classify failures as `physics-implausible | model-inadequate | artifact-gap | upstream-contract | needs-correction`.
|
||||
|
||||
## Output Contract
|
||||
|
||||
Produce or revise `docs/physics-evaluations/<feature-id>-physics-evaluation.md` with Input Evidence, Physics Checks, Failure Classification, Evaluation Verdict, Handoff Recommendation, and No-Change Assertion.
|
||||
|
||||
## Boundaries
|
||||
|
||||
- Do not edit source code.
|
||||
- Do not edit tests.
|
||||
- Do not run Abaqus.
|
||||
- Do not generate reference CSVs.
|
||||
- Do not change tolerances.
|
||||
- Do not approve release readiness.
|
||||
|
||||
## Quality Gate
|
||||
|
||||
- Physical checks are tied to requirements and model purpose.
|
||||
- Passing tolerance comparison is not treated as sufficient by itself.
|
||||
- Implausible results name the exact quantity, model, and likely owner.
|
||||
|
||||
## Handoff
|
||||
|
||||
Send implementation-owned physical failures to Correction Agent, inadequate model coverage to Reference Model Agent, and passing physics evidence to Release Agent.
|
||||
@@ -0,0 +1,4 @@
|
||||
interface:
|
||||
display_name: "Abaqus Physics Sanity"
|
||||
short_description: "Check physical plausibility."
|
||||
default_prompt: "Use $abaqus-subroutine-physics-sanity to evaluate Abaqus User Subroutine physical plausibility."
|
||||
@@ -0,0 +1,49 @@
|
||||
---
|
||||
name: abaqus-subroutine-readiness
|
||||
description: Use when auditing Abaqus User Subroutine readiness from upstream gate evidence, acceptance traceability, no-Abaqus tests, Abaqus validation artifacts, known limitations, and release-note drafts.
|
||||
---
|
||||
|
||||
# Abaqus Subroutine Readiness
|
||||
|
||||
Use this skill to audit whether an Abaqus User Subroutine feature is ready for internal closure after all technical gates pass. Readiness audit is the owned artifact for this skill.
|
||||
|
||||
## Inputs
|
||||
|
||||
Read first:
|
||||
|
||||
- `AGENTS.md`
|
||||
- `docs/ABAQUS_SUBROUTINE_AGENT_DESIGN.md`
|
||||
- `docs/releases/README.md`
|
||||
- Requirements, research, formulation, numerical review, interface, test model, implementation, validation, and physics reports
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Run gate audit over requirements, research, formulation, interface, TDD test models, Fortran implementation evidence, subroutine validation, and physics sanity.
|
||||
2. Build Acceptance Traceability from requirements to tests, artifacts, validation evidence, and limitations.
|
||||
3. Record Validation Evidence, including no-Abaqus tests, `python scripts/validate_workspace.py`, and any opt-in Abaqus validation evidence.
|
||||
4. Record Known Limitations, deferred requirements, unsupported entry points, missing artifacts, unresolved defects, accepted risks, and open items.
|
||||
5. Return a verdict: `ready-for-release`, `needs-documentation`, `needs-correction`, `needs-reference-artifacts`, `needs-upstream-decision`, or `blocked`.
|
||||
|
||||
## Output Contract
|
||||
|
||||
Produce or revise `docs/releases/<feature-id>-release.md` with Gate Evidence Inventory, Acceptance Traceability, Validation Evidence, Known Limitations, Release Notes Draft, Release Verdict, and No-Change Assertion.
|
||||
|
||||
## Boundaries
|
||||
|
||||
- Do not implement code.
|
||||
- Do not edit source code or tests.
|
||||
- Do not change requirements, formulations, interface contracts, reference artifacts, or tolerance policies.
|
||||
- Do not run Abaqus.
|
||||
- Do not override failed or missing upstream gates.
|
||||
- Do not publish, deploy, package, tag, commit, or externally release anything unless the user explicitly asks.
|
||||
|
||||
## Quality Gate
|
||||
|
||||
- Every `must` requirement is traced to passing evidence or a blocker.
|
||||
- Missing validation evidence is a blocker, not a limitation.
|
||||
- Known limitations are explicit and tied to requirements, models, or artifacts.
|
||||
- Release Verdict is internal readiness, not permission to publish.
|
||||
|
||||
## Handoff
|
||||
|
||||
Send missing gate evidence to Coordinator Agent, implementation defects to Correction Agent, artifact gaps to Reference Model Agent, and accepted ready evidence to the user.
|
||||
@@ -0,0 +1,4 @@
|
||||
interface:
|
||||
display_name: "Abaqus Subroutine Readiness"
|
||||
short_description: "Audit internal readiness."
|
||||
default_prompt: "Use $abaqus-subroutine-readiness to audit Abaqus User Subroutine readiness."
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
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.
|
||||
@@ -0,0 +1,4 @@
|
||||
interface:
|
||||
display_name: "Abaqus Subroutine Requirements"
|
||||
short_description: "Define subroutine requirements."
|
||||
default_prompt: "Use $abaqus-subroutine-requirements to define verifiable Abaqus User Subroutine requirements."
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
name: abaqus-subroutine-research
|
||||
description: Use when collecting Abaqus User Subroutine research evidence from official Abaqus manuals, books, papers, benchmark sources, and source reliability notes before formulation, interface definition, or test model design.
|
||||
---
|
||||
|
||||
# Abaqus Subroutine Research
|
||||
|
||||
Use this skill to collect source-backed Research evidence for Abaqus User Subroutine work while separating verified facts from inference.
|
||||
|
||||
## Inputs
|
||||
|
||||
Read first:
|
||||
|
||||
- `AGENTS.md`
|
||||
- `docs/ABAQUS_SUBROUTINE_AGENT_DESIGN.md`
|
||||
- `docs/research/README.md`
|
||||
- `docs/requirements/<feature-id>.md`
|
||||
- User-provided references, official Abaqus documentation links, books, papers, and benchmark sources
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Define exact research questions from requirements and open issues.
|
||||
2. Search source priorities in order: official Abaqus documentation, Abaqus User Subroutines Reference Guide, Abaqus Analysis User's Guide, books, papers, and benchmark sources.
|
||||
3. Record source reliability tier, citation, scope, assumptions, and applicability limits.
|
||||
4. Extract only facts needed by downstream formulation, Abaqus ABI interface definition, TDD test models, and Fortran implementation.
|
||||
5. Separate verified facts from inference.
|
||||
6. Identify candidate benchmark models, closed-form checks, patch tests, tangent checks, and negative tests.
|
||||
7. Record unresolved conflicts or missing evidence as open issues.
|
||||
|
||||
## Output Contract
|
||||
|
||||
Produce or revise `docs/research/<feature-id>-research.md` with Source Inventory, Source Reliability Tier, Extracted Facts, Candidate Benchmarks, Verification Relevance, Applicability Limits, Open Issues, and Downstream Handoff.
|
||||
|
||||
## Boundaries
|
||||
|
||||
- Do not implement code.
|
||||
- Do not finalize FEM formulations.
|
||||
- Do not design Fortran source layout or Abaqus wrapper code.
|
||||
- Do not run Abaqus.
|
||||
- Do not generate reference CSVs.
|
||||
- Do not approve release readiness.
|
||||
|
||||
## Quality Gate
|
||||
|
||||
- Source tiers are explicit.
|
||||
- Each extracted fact links to a cited source.
|
||||
- Inference is labeled as inference.
|
||||
- Benchmark applicability limits are clear enough for Formulation and Reference Model Agents.
|
||||
|
||||
## Handoff
|
||||
|
||||
Send math evidence to Formulation Agent, Abaqus parameter evidence to I/O Definition Agent, benchmark candidates to Reference Model Agent, and validation risk notes to Numerical Review Agent.
|
||||
@@ -0,0 +1,4 @@
|
||||
interface:
|
||||
display_name: "Abaqus Subroutine Research"
|
||||
short_description: "Collect source-backed evidence."
|
||||
default_prompt: "Use $abaqus-subroutine-research to collect source-backed Abaqus User Subroutine research evidence."
|
||||
@@ -0,0 +1,49 @@
|
||||
---
|
||||
name: abaqus-subroutine-test-models
|
||||
description: Use when designing Abaqus User Subroutine TDD test models, no-Abaqus driver cases, Fortran manifest entries, Abaqus .inp reference bundles, artifact metadata, source hashes, log tails, and CSV extraction contracts.
|
||||
---
|
||||
|
||||
# Abaqus Subroutine Test Models
|
||||
|
||||
Use this skill to define the TDD test model portfolio before Fortran implementation and Abaqus validation.
|
||||
|
||||
## Inputs
|
||||
|
||||
Read first:
|
||||
|
||||
- `AGENTS.md`
|
||||
- `docs/ABAQUS_SUBROUTINE_AGENT_DESIGN.md`
|
||||
- `docs/reference-models/README.md`
|
||||
- Requirements, research, formulation, numerical review, and interface documents
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Define TDD test model categories: no-Abaqus unit driver, analytical material point, finite-difference tangent check, `.inp` smoke model, benchmark/reference model, regression case, and negative case.
|
||||
2. For no-Abaqus tests, define `tests/fortran/manifest.json` entries, source files, driver inputs, expected outputs, and tolerances.
|
||||
3. For Abaqus validation, define `references/<feature-id>/<model-id>/` artifact bundle requirements.
|
||||
4. Require `model.inp`, `metadata.json`, source hash entries, Abaqus version, compiler version, msg/dat/log tail files, and extracted CSV files for `ready-for-comparison` artifacts.
|
||||
5. Define Coverage Matrix rows mapping requirement id, model id, compared quantity, tolerance, artifact file, and status.
|
||||
|
||||
## Output Contract
|
||||
|
||||
Produce or revise `docs/reference-models/<feature-id>-reference-models.md` with TDD test model strategy, no-Abaqus manifest plan, Abaqus Input Requirements, Artifact Bundle Contract, Metadata JSON Contract, Reference CSV Requirements, Coverage Matrix, Artifact Acceptance Checklist, and Downstream Handoff.
|
||||
|
||||
## Boundaries
|
||||
|
||||
- Do not implement code.
|
||||
- Do not run Abaqus.
|
||||
- Do not generate reference CSVs.
|
||||
- Do not invent Abaqus, compiler, or source hash provenance.
|
||||
- Do not compare implementation results.
|
||||
- Do not approve release readiness.
|
||||
|
||||
## Quality Gate
|
||||
|
||||
- Every `must` requirement maps to at least one no-Abaqus test or Abaqus validation model.
|
||||
- No-Abaqus tests identify exactly what should fail before implementation.
|
||||
- Each ready artifact contract includes source hash, Abaqus version, compiler version, msg/dat/log tail, and CSV file expectations.
|
||||
- Missing required reference artifacts keep the model at `needs-reference-artifacts`.
|
||||
|
||||
## Handoff
|
||||
|
||||
Send no-Abaqus test order to Implementation Planning Agent, ABI/schema issues to I/O Definition Agent, artifact readiness needs to Reference Verification Agent, and physics expectations to Physics Evaluation Agent.
|
||||
@@ -0,0 +1,4 @@
|
||||
interface:
|
||||
display_name: "Abaqus Subroutine Test Models"
|
||||
short_description: "Design TDD and reference models."
|
||||
default_prompt: "Use $abaqus-subroutine-test-models to design Abaqus User Subroutine TDD test models and reference artifact contracts."
|
||||
@@ -0,0 +1,53 @@
|
||||
---
|
||||
name: abaqus-subroutine-validation
|
||||
description: Use when validating Abaqus User Subroutine outputs against stored reference artifacts, checking metadata, source hashes, Abaqus and compiler versions, msg/dat/log tails, CSV schemas, tolerances, and opt-in Abaqus validation evidence.
|
||||
---
|
||||
|
||||
# Abaqus Subroutine Validation
|
||||
|
||||
Use this skill to validate implemented subroutines against no-Abaqus results and stored Abaqus reference artifacts without changing either side. Subroutine validation is the owned artifact for this skill.
|
||||
|
||||
## Inputs
|
||||
|
||||
Read first:
|
||||
|
||||
- `AGENTS.md`
|
||||
- `docs/ABAQUS_SUBROUTINE_AGENT_DESIGN.md`
|
||||
- `docs/reference-verifications/README.md`
|
||||
- `docs/reference-models/<feature-id>-reference-models.md`
|
||||
- `references/<feature-id>/<model-id>/metadata.json`
|
||||
- Generated no-Abaqus and extracted CSV outputs
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Validate artifact metadata with `python scripts/validate_reference_artifacts.py`.
|
||||
2. For `ready-for-comparison`, check model `.inp`, metadata.json, source hash, Abaqus version, compiler version, msg/dat/log tail files, and declared CSV files.
|
||||
3. Run no-Abaqus comparison commands when available.
|
||||
4. Run Abaqus only when explicitly configured through `HARNESS_ABAQUS_VALIDATION=run` and `HARNESS_ABAQUS_VALIDATION_COMMANDS`.
|
||||
5. Compare generated CSVs against reference CSVs by documented IDs, units, coordinate system, output location, component naming, and tolerance.
|
||||
6. Classify failures as `missing-reference-artifact | missing-generated-output | schema-mismatch | id-mismatch | source-hash-mismatch | unit-or-coordinate-mismatch | tolerance-failure | nonfinite-result | environment | upstream-contract`.
|
||||
|
||||
## Output Contract
|
||||
|
||||
Produce or revise `docs/reference-verifications/<feature-id>-reference-verification.md` with Artifact Inventory, Comparison Contract, Quantity Results, Failure Classification, Validation Evidence, Handoff Recommendation, and No-Change Assertion.
|
||||
|
||||
## Boundaries
|
||||
|
||||
- Do not edit source code.
|
||||
- Do not edit tests.
|
||||
- Do not change reference artifacts.
|
||||
- Do not change tolerance policies.
|
||||
- Do not generate reference CSVs.
|
||||
- Do not run Abaqus unless the opt-in environment contract is explicit.
|
||||
- Do not approve release readiness.
|
||||
|
||||
## Quality Gate
|
||||
|
||||
- `ready-for-comparison` artifacts pass metadata validation.
|
||||
- Source hash, Abaqus version, compiler version, msg/dat/log provenance, and CSV schemas are reported.
|
||||
- Every compared quantity reports max absolute error, max relative error, RMS error when applicable, worst row, and pass/fail.
|
||||
- Nonfinite values are reported explicitly.
|
||||
|
||||
## Handoff
|
||||
|
||||
Send implementation-owned mismatches to Correction Agent, artifact gaps to Reference Model Agent, ABI/schema gaps to I/O Definition Agent, and physically suspicious passing results to Physics Evaluation Agent.
|
||||
@@ -0,0 +1,4 @@
|
||||
interface:
|
||||
display_name: "Abaqus Subroutine Validation"
|
||||
short_description: "Validate artifacts and CSVs."
|
||||
default_prompt: "Use $abaqus-subroutine-validation to validate Abaqus User Subroutine artifacts and CSV comparison results."
|
||||
@@ -0,0 +1,141 @@
|
||||
---
|
||||
name: fem-theory-query
|
||||
description: Use when answering finite element method, structural analysis solver, element formulation, residual/tangent, constitutive integration, contact, dynamics, eigenproblem, or verification questions from a configured FEM wiki vault.
|
||||
---
|
||||
|
||||
# FEM Theory Query
|
||||
|
||||
Use this skill as a portable domain router for finite element method and structural solver theory questions. Ground answers in a configured FEM wiki vault, then compose sibling skills instead of reimplementing their workflows.
|
||||
|
||||
## FEM Vault Resolution
|
||||
|
||||
Resolve the FEM wiki vault in this order:
|
||||
|
||||
1. Skill-local config file: `vault-path.txt` in this skill folder. Read the first non-empty, non-comment line as the vault root path.
|
||||
2. Current project instructions: `AGENTS.md`, `CLAUDE.md`, or an equivalent section named `FEM Solver Theory Wiki`.
|
||||
3. Environment variable: `FEM_THEORY_WIKI_VAULT`.
|
||||
|
||||
If no valid vault is found, ask the user for the vault path. A valid vault must contain `wiki/hot.md` or `wiki/index.md`.
|
||||
|
||||
Keep `vault-path.txt` PC-specific. When the vault moves, update that file instead of editing this skill body.
|
||||
|
||||
## Companion Skill Protocols
|
||||
|
||||
This skill is an orchestrator. Do not reimplement sibling skills. Use the sibling skill instructions as authoritative when available.
|
||||
|
||||
### Companion skill path resolution
|
||||
|
||||
After reading `vault-path.txt`, call that value `FEM_VAULT_ROOT`. Resolve companion skill files from that absolute vault root:
|
||||
|
||||
- `FEM_VAULT_ROOT\skills\think\SKILL.md`: use for non-trivial FEM formulation, solver architecture, ambiguity, tradeoffs, verification design, or gap assessment.
|
||||
- `FEM_VAULT_ROOT\skills\wiki-query\SKILL.md`: use for normal wiki-grounded answers from the configured FEM vault.
|
||||
- `FEM_VAULT_ROOT\skills\autoresearch\SKILL.md`: use only when the user explicitly asks to research, find sources, update the wiki, or fill missing wiki coverage.
|
||||
|
||||
If the runtime provides a skill activation mechanism, activate the companion skill by name. If not, read the absolute companion `SKILL.md` path constructed from `vault-path.txt` and follow its workflow. If an absolute companion path does not exist, tell the user which path is missing and ask them to fix `vault-path.txt`.
|
||||
|
||||
### Relative paths inside companion skills
|
||||
|
||||
When a companion skill refers to another file by a relative path, resolve that path from the absolute directory of the companion skill file under `FEM_VAULT_ROOT`, not from the caller project or current working directory. Normalize `..` segments after joining paths. Keep the resolved path inside `FEM_VAULT_ROOT` unless the companion skill explicitly requires an external path.
|
||||
|
||||
Examples from `FEM_VAULT_ROOT\skills\autoresearch\SKILL.md`:
|
||||
|
||||
- `../wiki-cli/SKILL.md` resolves to `FEM_VAULT_ROOT\skills\wiki-cli\SKILL.md`.
|
||||
- `../../wiki/references/transport-fallback.md` resolves to `FEM_VAULT_ROOT\wiki\references\transport-fallback.md`.
|
||||
- `references/program.md` resolves to `FEM_VAULT_ROOT\skills\autoresearch\references\program.md`.
|
||||
|
||||
If a resolved companion-relative path is missing, report the missing absolute path and ask the user to fix `vault-path.txt` or install the full `skills/` bundle.
|
||||
|
||||
### How to use `think`
|
||||
|
||||
Use `think` as a compact internal preflight before answering FEM solver questions.
|
||||
|
||||
Do:
|
||||
- Identify the user's real question: theory derivation, implementation design, verification, comparison, or missing source.
|
||||
- Check whether you are relying on memory instead of wiki evidence.
|
||||
- Decide whether the answer can be handled by wiki query or needs autoresearch.
|
||||
- For complex questions, surface the reasoning structure briefly in the answer.
|
||||
|
||||
Do not:
|
||||
- Print all 10 stages for routine factual questions.
|
||||
- Use `think` as a substitute for reading wiki sources.
|
||||
- Skip the `ACCEPT` step when the wiki has insufficient coverage.
|
||||
|
||||
### How to use `wiki-query`
|
||||
|
||||
Use `wiki-query` for the default answer path.
|
||||
|
||||
Follow this order:
|
||||
|
||||
1. Resolve the FEM vault path.
|
||||
2. Read `wiki/hot.md`.
|
||||
3. If needed, use `wiki-retrieve` when provisioned: `python scripts/retrieve.py "<question>" --top 5`.
|
||||
4. If retrieval is not provisioned or fails, read `wiki/index.md`.
|
||||
5. Read 3-7 relevant wiki pages.
|
||||
6. Synthesize with Obsidian wikilink citations.
|
||||
|
||||
Do:
|
||||
- Cite every core claim with `[[Page Name]]`.
|
||||
- Prefer vault evidence over model memory.
|
||||
- Say clearly when the wiki lacks enough evidence.
|
||||
|
||||
Do not:
|
||||
- Answer a vault-specific question from training data alone.
|
||||
- Open many pages when 3-7 are enough.
|
||||
- Write to the wiki unless the user explicitly asks.
|
||||
|
||||
### How to use `autoresearch`
|
||||
|
||||
Use `autoresearch` only for explicit research or wiki-expansion requests.
|
||||
|
||||
Trigger examples:
|
||||
- "Find sources and strengthen this wiki coverage."
|
||||
- "If the wiki does not cover this, research it."
|
||||
- "Research and file this topic."
|
||||
- "Create source and concept pages for this topic."
|
||||
|
||||
Before starting:
|
||||
- Tell the user it will use web search/fetch and write new wiki pages.
|
||||
- Mention that fetched content is subject to the `autoresearch` web egress hygiene rules.
|
||||
- Ask for approval unless the user already gave explicit approval in the same request.
|
||||
|
||||
Do:
|
||||
- Read `FEM_VAULT_ROOT\skills\autoresearch\SKILL.md` and `FEM_VAULT_ROOT\skills\autoresearch\references\program.md`.
|
||||
- File results into the configured FEM vault, not the caller project.
|
||||
- Use wiki locks and transport rules from the sibling skill.
|
||||
|
||||
Do not:
|
||||
- Run autoresearch for ordinary Q&A.
|
||||
- Fetch web sources silently.
|
||||
- Write into `.raw/` or `wiki/` without explicit user intent.
|
||||
|
||||
## Answer Contract
|
||||
|
||||
Answer in the user's language. For Korean questions, translate the section headings naturally.
|
||||
|
||||
Use this structure unless the user asks for another format:
|
||||
|
||||
- Summary conclusion
|
||||
- Formulation
|
||||
- Solver implementation view
|
||||
- Verification and benchmarks
|
||||
- Evidence
|
||||
- Wiki gap
|
||||
|
||||
Every core technical claim should trace to wiki evidence. Use Obsidian wikilinks such as `[[Finite Element Method]]`, `[[Solid Element Stiffness Integration]]`, or the relevant source page. If the wiki does not cover a point, label it as a gap instead of presenting model memory as vault knowledge.
|
||||
|
||||
## FEM Query Expansion
|
||||
|
||||
When a user asks a short FEM question, expand the retrieval intent before searching:
|
||||
|
||||
- Element formulation: shape functions, DOFs, Jacobian, `B` matrix, integration, load vector, result recovery.
|
||||
- Nonlinear solve: residual, tangent, Newton update, convergence norms, load/time increments, cutback policy.
|
||||
- Constitutive update: stress update, material tangent, state variables, return mapping, history evolution.
|
||||
- Dynamics/eigen: mass, damping, time integration, modal extraction, normalization, residual checks.
|
||||
- Contact/constraints: gap, normal/tangential law, penalty or multiplier enforcement, search, tangent contribution.
|
||||
- Verification: patch tests, convergence, benchmark problems, matrix checks, residual norms, source-solver comparison.
|
||||
|
||||
Keep expansion internal unless showing it helps the user understand the answer.
|
||||
|
||||
## Deployment Notes
|
||||
|
||||
Distribute this skill with the whole `skills/` bundle so sibling paths remain valid. After installing or symlinking the bundle into another agent, update `vault-path.txt` for that PC or set `FEM_THEORY_WIKI_VAULT`.
|
||||
@@ -0,0 +1,4 @@
|
||||
interface:
|
||||
display_name: "FEM Theory Query"
|
||||
short_description: "Query FEM solver theory from wiki."
|
||||
default_prompt: "Use $fem-theory-query to answer a finite-element structural solver formulation question from the wiki."
|
||||
@@ -0,0 +1,3 @@
|
||||
# FEM wiki vault root path.
|
||||
# Edit this per PC. Use an absolute path to the vault that contains wiki/ and .raw/.
|
||||
D:\Obsidian\MultiPhysicsVault
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
name: harness-review
|
||||
description: "Use when reviewing this Abaqus User Subroutine Harness repository: local changes, generated phase files, implementation diffs, missing tests, Fortran validation readiness, reference artifact contracts, or compliance with AGENTS.md, docs/ARCHITECTURE.md, docs/ADR.md, and Harness acceptance criteria."
|
||||
---
|
||||
|
||||
# Harness Review
|
||||
|
||||
## Overview
|
||||
|
||||
Use this skill to review Harness work against repository rules, Abaqus User Subroutine workflow, Fortran TDD, no-Abaqus validation, reference artifact contracts, and explicit Abaqus opt-in validation requirements. Prioritize bugs, regressions, missing tests, and rule violations.
|
||||
|
||||
## Review Process
|
||||
|
||||
1. Read `/AGENTS.md`, `/docs/ABAQUS_SUBROUTINE_AGENT_DESIGN.md`, `/docs/ARCHITECTURE.md`, and `/docs/ADR.md`.
|
||||
2. Inspect changed files with `git status --short` and `git diff`.
|
||||
3. Check architecture, Fortran test coverage, reference artifact contracts, critical rules, and validation readiness.
|
||||
4. Run relevant commands when feasible:
|
||||
- `python -m unittest discover -s scripts -p "test_*.py"`
|
||||
- `python scripts/validate_fortran.py`
|
||||
- `python scripts/validate_reference_artifacts.py`
|
||||
- `python scripts/validate_workspace.py`
|
||||
5. Lead with actionable findings. Keep summaries secondary.
|
||||
|
||||
## Checklist
|
||||
|
||||
| Item | Question |
|
||||
| --- | --- |
|
||||
| Workflow | Does the change fit the seven-step Abaqus User Subroutine process? |
|
||||
| Architecture | Does the change follow `docs/ARCHITECTURE.md` ownership boundaries? |
|
||||
| Tests | Are new or changed Fortran behaviors covered by no-Abaqus Fortran/Python tests or harness tests? |
|
||||
| TDD Guard | Would Fortran production edits be blocked without related tests? |
|
||||
| References | Do reference artifacts include `.inp`, source hash, Abaqus version, compiler version, msg/dat/log tail, and extracted CSV contracts when required? |
|
||||
| Abaqus Opt-in | Is `HARNESS_ABAQUS_VALIDATION=run` used only when explicitly configured? |
|
||||
| Build | Do the Python, Fortran, reference artifact, and workspace validation commands pass or report expected skips? |
|
||||
|
||||
## Output Format
|
||||
|
||||
If there are findings, list them first in severity order with file and line references when possible. Then include this table:
|
||||
|
||||
| Item | Result | Notes |
|
||||
| --- | --- | --- |
|
||||
| Workflow | PASS/FAIL | {detail} |
|
||||
| Architecture | PASS/FAIL | {detail} |
|
||||
| Tests | PASS/FAIL | {detail} |
|
||||
| TDD Guard | PASS/FAIL | {detail} |
|
||||
| Reference Artifacts | PASS/FAIL | {detail} |
|
||||
| Abaqus Opt-in | PASS/FAIL | {detail} |
|
||||
| Validation | PASS/FAIL | {detail} |
|
||||
|
||||
When there are no findings, say that clearly, then mention commands not run or remaining risk.
|
||||
@@ -0,0 +1,4 @@
|
||||
interface:
|
||||
display_name: "Subroutine Harness Review"
|
||||
short_description: "Review Fortran subroutine harness work."
|
||||
default_prompt: "Use $harness-review to review Abaqus User Subroutine Harness changes."
|
||||
@@ -0,0 +1,118 @@
|
||||
---
|
||||
name: harness-workflow
|
||||
description: "Use when planning or running this Abaqus User Subroutine Harness: reading AGENTS.md and docs/*.md, discussing implementation scope, creating or updating phases/index.json, phases/{task}/index.json, phases/{task}/stepN.md, or invoking scripts/execute.py for staged Codex execution."
|
||||
---
|
||||
|
||||
# Harness Workflow
|
||||
|
||||
## Overview
|
||||
|
||||
Use this skill to turn a user-approved Abaqus User Subroutine task into small, self-contained Harness steps. Keep every step grounded in repository docs, Fortran TDD, no-Abaqus validation, reference artifact validation, and explicit Abaqus opt-in rules.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Read `AGENTS.md`, `docs/ABAQUS_SUBROUTINE_AGENT_DESIGN.md`, `docs/PRD.md`, `docs/ARCHITECTURE.md`, and `docs/ADR.md`.
|
||||
2. Map the task to the seven-step Abaqus User Subroutine process: requirements, research, formulation, interface, TDD test models, Fortran implementation, validation.
|
||||
3. Discuss unresolved product or technical decisions with the user before writing phase files.
|
||||
4. Create or update `phases/index.json`, `phases/{task-name}/index.json`, and one `phases/{task-name}/stepN.md` per step.
|
||||
5. Run the phase with `python scripts/execute.py {task-name}` when asked. Use `--push` only when the user asks.
|
||||
|
||||
## Step Design Rules
|
||||
|
||||
- Scope each step to one artifact family: requirements, research, formulation, ABI/interface, no-Abaqus tests, Fortran source, validation, or documentation.
|
||||
- Make every step self-contained. Include required context and file paths.
|
||||
- Specify interfaces and signatures only when the step owns the interface contract.
|
||||
- Use executable acceptance criteria, not abstract statements.
|
||||
- For Fortran behavior changes, require tests first and name the no-Abaqus Fortran/Python driver test or `tests/fortran/manifest.json` entry.
|
||||
- Preserve the rule that Abaqus is not run by default; use `HARNESS_ABAQUS_VALIDATION=run` only when explicitly requested and configured.
|
||||
|
||||
## Phase Files
|
||||
|
||||
Create or update `phases/index.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"phases": [
|
||||
{
|
||||
"dir": "abaqus-subroutine-feature",
|
||||
"status": "pending"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Create `phases/{task-name}/index.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"project": "FESA Harness",
|
||||
"phase": "<task-name>",
|
||||
"steps": [
|
||||
{ "step": 0, "name": "requirements", "status": "pending" },
|
||||
{ "step": 1, "name": "test-models", "status": "pending" },
|
||||
{ "step": 2, "name": "fortran-implementation", "status": "pending" }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Rules:
|
||||
|
||||
- `project` comes from `AGENTS.md`.
|
||||
- `phase` matches the task directory name.
|
||||
- `steps[].step` starts at `0`.
|
||||
- Initial status is always `pending`.
|
||||
- Do not add timestamps when creating files. `scripts/execute.py` records timestamps.
|
||||
|
||||
## Step Template
|
||||
|
||||
```markdown
|
||||
# Step {N}: {name}
|
||||
|
||||
## Read First
|
||||
|
||||
- `/AGENTS.md`
|
||||
- `/docs/ABAQUS_SUBROUTINE_AGENT_DESIGN.md`
|
||||
- `/docs/ARCHITECTURE.md`
|
||||
- `/docs/ADR.md`
|
||||
- {previously created or modified files}
|
||||
|
||||
## Task
|
||||
|
||||
{Concrete instructions with file paths, interfaces, signatures, and rules.}
|
||||
|
||||
## Tests To Write First
|
||||
|
||||
- {Exact no-Abaqus Fortran/Python test file, manifest entry, or Python harness test to add before implementation.}
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
```bash
|
||||
python -m unittest discover -s scripts -p "test_*.py"
|
||||
python scripts/validate_fortran.py
|
||||
python scripts/validate_reference_artifacts.py
|
||||
python scripts/validate_workspace.py
|
||||
```
|
||||
|
||||
## Validation Notes
|
||||
|
||||
- Use `HARNESS_ABAQUS_VALIDATION=run` only when the step explicitly owns Abaqus validation and the command contract is provided.
|
||||
- Update `phases/{task-name}/index.json` with `completed`, `error`, or `blocked` and a concrete summary/reason.
|
||||
|
||||
## Forbidden
|
||||
|
||||
- Do not add JavaScript/TypeScript/npm fallback.
|
||||
- Do not run Abaqus by default.
|
||||
- Do not generate reference CSVs unless the user explicitly authorized a reference-artifact phase.
|
||||
- Do not break existing tests.
|
||||
```
|
||||
|
||||
## Execution And Recovery
|
||||
|
||||
Run:
|
||||
|
||||
```bash
|
||||
python scripts/execute.py {task-name}
|
||||
python scripts/execute.py {task-name} --push
|
||||
```
|
||||
|
||||
If a step is `error`, fix the cause, set it back to `pending`, remove `error_message`, and rerun. If a step is `blocked`, resolve `blocked_reason`, set it back to `pending`, remove `blocked_reason`, and rerun.
|
||||
@@ -0,0 +1,4 @@
|
||||
interface:
|
||||
display_name: "Subroutine Harness Workflow"
|
||||
short_description: "Plan staged Fortran subroutine work."
|
||||
default_prompt: "Use $harness-workflow to plan or run staged Abaqus User Subroutine Harness work."
|
||||
Reference in New Issue
Block a user