modify documents
This commit is contained in:
NINI
@@ -0,0 +1,31 @@
|
||||
---
|
||||
name: fesa-abaqus-subset
|
||||
description: Design or review Abaqus input parsing against the documented FESA Phase 1 keyword subset.
|
||||
---
|
||||
|
||||
# FESA Abaqus Subset
|
||||
|
||||
Use this skill when parser scope, input compatibility, Nset/Elset handling, or unsupported keyword behavior is involved.
|
||||
|
||||
## Read First
|
||||
|
||||
- `/AGENTS.md`
|
||||
- `/PROGRESS.md`
|
||||
- `/PLAN.md`
|
||||
- `/docs/ABAQUS_INPUT_SUBSET.md`
|
||||
- `/docs/NUMERICAL_CONVENTIONS.md`
|
||||
- `/docs/ARCHITECTURE.md`
|
||||
- `/docs/VERIFICATION_PLAN.md`
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Map each requested keyword to the documented Phase 1 subset.
|
||||
2. Check `*Nset` and `*Elset` semantics, ordering, generated sets, and use by boundary/load/result requests.
|
||||
3. Keep Abaqus keyword parsing separated from internal object creation through Factory + Registry.
|
||||
4. Require explicit diagnostics for unsupported keywords instead of silent partial parsing.
|
||||
5. Record parser-scope changes in ADRs or subset docs when they affect project policy.
|
||||
|
||||
## Do Not
|
||||
|
||||
- Do not silently expand support beyond the documented subset.
|
||||
- Do not store parser-only details in solver core objects unless the architecture document requires it.
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
name: fesa-adr-update
|
||||
description: Draft or revise FESA ADRs when architecture, numerical conventions, dependencies, result schema, or phase scope decisions change.
|
||||
---
|
||||
|
||||
# FESA ADR Update
|
||||
|
||||
Use this skill when a design decision should become durable project policy.
|
||||
|
||||
## Read First
|
||||
|
||||
- `/AGENTS.md`
|
||||
- `/PROGRESS.md`
|
||||
- `/PLAN.md`
|
||||
- `/docs/ARCHITECTURE.md`
|
||||
- `/docs/ADR.md`
|
||||
- The topic-specific design document.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Identify whether the change is a new decision, a clarification, or a superseding decision.
|
||||
2. Capture context, decision, consequences, alternatives considered, and validation impact.
|
||||
3. Update related docs only when needed to avoid drift.
|
||||
4. Add follow-up tasks to `PLAN.md`.
|
||||
5. Record completed ADR work in `PROGRESS.md`.
|
||||
|
||||
## Decision Quality Bar
|
||||
|
||||
- Decisions should preserve runtime polymorphism, documented state ownership, DofManager ownership, adapter boundaries, step/frame/history outputs, and reference-driven verification.
|
||||
- If a decision weakens those policies, document why and what test or reference coverage will protect it.
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
name: fesa-cpp-tdd
|
||||
description: Implement or review FESA C++ changes using tests first, documented architecture boundaries, and project validation.
|
||||
---
|
||||
|
||||
# FESA C++ TDD
|
||||
|
||||
Use this skill when writing or reviewing C++ solver code, build files, tests, or validation scripts.
|
||||
|
||||
## Read First
|
||||
|
||||
- `/AGENTS.md`
|
||||
- `/PROGRESS.md`
|
||||
- `/PLAN.md`
|
||||
- `/docs/README.md`
|
||||
- `/docs/HARNESS_ENGINEERING.md`
|
||||
- `/docs/ARCHITECTURE.md`
|
||||
- `/docs/ADR.md`
|
||||
- `/docs/NUMERICAL_CONVENTIONS.md`
|
||||
- The topic-specific design document for the code being changed.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Confirm that readiness blockers do not prohibit the requested implementation.
|
||||
2. Confirm that a sprint contract exists for solver behavior, parser, result schema, reference comparator, MITC4, or phase execution work.
|
||||
3. Write or update tests before implementation.
|
||||
4. Keep changes scoped to the requested layer and contract allowed files.
|
||||
5. Preserve runtime polymorphism, DofManager ownership, adapter boundaries, and int64/double numerical defaults.
|
||||
6. Run focused tests plus `python scripts/validate_workspace.py`.
|
||||
7. Update `PROGRESS.md` and `PLAN.md` when status or future work changes.
|
||||
|
||||
## Do Not
|
||||
|
||||
- Do not start solver implementation from this skill when the user asked for planning or documentation only.
|
||||
- Do not start implementation without a testable sprint contract for nontrivial solver work.
|
||||
- Do not bypass tests for parser, DOF mapping, reactions, singular diagnostics, sparse assembly, result writing, or MITC4 behavior.
|
||||
@@ -0,0 +1,34 @@
|
||||
---
|
||||
name: fesa-doc-sync
|
||||
description: Keep FESA documentation, PLAN.md, and PROGRESS.md synchronized after design, planning, or Codex extension changes.
|
||||
---
|
||||
|
||||
# FESA Doc Sync
|
||||
|
||||
Use this skill whenever documentation, `.codex` extension files, phase files, or planning state changes.
|
||||
|
||||
## Read First
|
||||
|
||||
- `/AGENTS.md`
|
||||
- `/PROGRESS.md`
|
||||
- `/PLAN.md`
|
||||
- `/docs/README.md`
|
||||
- Any changed docs, phase files, or `.codex` files.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Put completed work, changed files, verification, and residual risks in `PROGRESS.md`.
|
||||
2. Put future tasks, open decisions, and changed ownership in `PLAN.md`.
|
||||
3. Keep historical notes out of `PLAN.md`.
|
||||
4. Keep future task lists out of `PROGRESS.md`.
|
||||
5. Check whether documentation indexes or agent instructions need updates.
|
||||
|
||||
## Verification
|
||||
|
||||
- Parse changed TOML, JSON, or YAML-like frontmatter when practical.
|
||||
- Run `python scripts/validate_workspace.py` after edits.
|
||||
|
||||
## Output
|
||||
|
||||
- Summarize only the meaningful sync changes.
|
||||
- Call out any stale or contradictory state that remains.
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
name: fesa-mitc4-formulation
|
||||
description: Work on or review MITC4 formulation details, benchmarks, or implementation notes using the documented baseline rather than memory.
|
||||
---
|
||||
|
||||
# FESA MITC4 Formulation
|
||||
|
||||
Use this skill for MITC4 element math, implementation review, benchmark interpretation, or formulation documentation.
|
||||
|
||||
## Read First
|
||||
|
||||
- `/AGENTS.md`
|
||||
- `/PROGRESS.md`
|
||||
- `/PLAN.md`
|
||||
- `/docs/MITC4_FORMULATION.md`
|
||||
- `/docs/NUMERICAL_CONVENTIONS.md`
|
||||
- `/docs/VERIFICATION_PLAN.md`
|
||||
- `/docs/RESULTS_SCHEMA.md`
|
||||
- `/docs/ARCHITECTURE.md`
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Identify whether the work concerns basis construction, kinematics, transverse shear tying, drilling stiffness, integration, stress/resultant recovery, or benchmarks.
|
||||
2. Check whether the relevant formula or convention is explicitly defined in `/docs/MITC4_FORMULATION.md`.
|
||||
3. If it is not defined, treat it as a blocker or documentation task.
|
||||
4. Keep Phase 1 focused on baseline formulation and reference benchmark passing.
|
||||
|
||||
## Do Not
|
||||
|
||||
- Do not infer missing tying-point equations from memory.
|
||||
- Do not introduce S4R or reduced-integration behavior into Phase 1.
|
||||
- Do not optimize before the baseline passes documented reference benchmarks.
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
name: fesa-phase-planning
|
||||
description: Create or review FESA Harness phase plans and self-contained step files after readiness blockers are understood.
|
||||
---
|
||||
|
||||
# FESA Phase Planning
|
||||
|
||||
Use this skill when drafting or reviewing `phases/` work plans for FESA.
|
||||
|
||||
## Read First
|
||||
|
||||
- `/AGENTS.md`
|
||||
- `/PROGRESS.md`
|
||||
- `/PLAN.md`
|
||||
- `/docs/README.md`
|
||||
- `/docs/HARNESS_ENGINEERING.md`
|
||||
- `/docs/PRD.md`
|
||||
- `/docs/ARCHITECTURE.md`
|
||||
- `/docs/ADR.md`
|
||||
- `/docs/NUMERICAL_CONVENTIONS.md`
|
||||
- `/docs/ABAQUS_INPUT_SUBSET.md`
|
||||
- `/docs/VERIFICATION_PLAN.md`
|
||||
- `/docs/RESULTS_SCHEMA.md`
|
||||
- `/docs/MITC4_FORMULATION.md`
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Run the readiness check first.
|
||||
2. Use the repo `harness-workflow` skill when generating phase files.
|
||||
3. Keep each step scoped to one layer or module where possible.
|
||||
4. Make each `stepN.md` executable in a fresh Codex session.
|
||||
5. Include a sprint contract section following `/docs/HARNESS_ENGINEERING.md`.
|
||||
6. Include acceptance commands and explicit prohibitions.
|
||||
7. Do not hide unresolved reference, build, or MITC4 decisions inside implementation tasks.
|
||||
|
||||
## Phase Shape
|
||||
|
||||
- Start with project skeleton, build/test harness, and core types only after readiness blockers are accepted.
|
||||
- Preserve the documented sequence: Domain, parser, diagnostics, DofManager, math adapters, results, reference comparator, MITC4, assembly, linear static path.
|
||||
- For implementation phases, plan the Planner -> Generator -> Evaluator loop explicitly enough that an independent evaluator can pass/fail each step.
|
||||
@@ -0,0 +1,41 @@
|
||||
---
|
||||
name: fesa-readiness
|
||||
description: Check FESA Phase 1 readiness before implementation planning or coding, especially reference artifacts, MITC4 open decisions, result outputs, and build-system blockers.
|
||||
---
|
||||
|
||||
# FESA Readiness
|
||||
|
||||
Use this skill before drafting implementation phases, starting solver code, or deciding whether Phase 1 can proceed.
|
||||
|
||||
## Read First
|
||||
|
||||
- `/AGENTS.md`
|
||||
- `/PROGRESS.md`
|
||||
- `/PLAN.md`
|
||||
- `/docs/README.md`
|
||||
- `/docs/VERIFICATION_PLAN.md`
|
||||
- `/docs/RESULTS_SCHEMA.md`
|
||||
- `/docs/MITC4_FORMULATION.md`
|
||||
- `/docs/NUMERICAL_CONVENTIONS.md`
|
||||
- `/docs/ABAQUS_INPUT_SUBSET.md`
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Compare `/PLAN.md` Phase 1 readiness tasks with the Implementation Readiness Checklist in `/docs/README.md`.
|
||||
2. Classify each item as ready, blocked, explicitly deferred, or unknown.
|
||||
3. Confirm that reference artifacts under `references/` do not require local Abaqus execution.
|
||||
4. Confirm that at least one `*_displacements.csv` can drive automated `U` comparison, and flag missing `RF` artifacts if reaction verification depends on Abaqus output.
|
||||
5. Confirm that MITC4 baseline formulation decisions are not being filled from memory.
|
||||
6. Identify the smallest next decision or artifact needed.
|
||||
|
||||
## Output
|
||||
|
||||
- Lead with the readiness verdict: ready, blocked, or partial.
|
||||
- Include blockers and the exact files that should be updated.
|
||||
- If work is completed during the turn, update `PROGRESS.md`.
|
||||
- If future tasks change, update `PLAN.md`.
|
||||
|
||||
## Do Not
|
||||
|
||||
- Do not start implementation while unresolved readiness blockers remain unless the user explicitly accepts them as deferred.
|
||||
- Do not treat undocumented formulas or reference values as authoritative.
|
||||
@@ -0,0 +1,41 @@
|
||||
---
|
||||
name: fesa-reference-onboarding
|
||||
description: Onboard or review Abaqus reference artifacts for FESA verification without running Abaqus locally.
|
||||
---
|
||||
|
||||
# FESA Reference Onboarding
|
||||
|
||||
Use this skill when the user adds, asks about, or wants to validate stored reference models and results.
|
||||
|
||||
## Read First
|
||||
|
||||
- `/AGENTS.md`
|
||||
- `/PROGRESS.md`
|
||||
- `/PLAN.md`
|
||||
- `/docs/VERIFICATION_PLAN.md`
|
||||
- `/docs/RESULTS_SCHEMA.md`
|
||||
- `/docs/ABAQUS_INPUT_SUBSET.md`
|
||||
- `/docs/NUMERICAL_CONVENTIONS.md`
|
||||
|
||||
## Artifact Checklist
|
||||
|
||||
- Abaqus `.inp` input file.
|
||||
- Solved reference values, initially Abaqus-exported `*_displacements.csv`.
|
||||
- Tolerance metadata by result field where needed.
|
||||
- Unit notes, because FESA does not enforce a unit system.
|
||||
- Abaqus version/provenance when available.
|
||||
- Step/frame/result field mapping that matches `/docs/RESULTS_SCHEMA.md`.
|
||||
- Unsupported keywords documented against `/docs/ABAQUS_INPUT_SUBSET.md`.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Inspect `references/` when present.
|
||||
2. Verify that each artifact can be compared without hidden coordinate, sign, unit, or precision assumptions.
|
||||
3. For `*_displacements.csv`, verify required columns: `Node Label`, `U-U1`, `U-U2`, `U-U3`, `UR-UR1`, `UR-UR2`, `UR-UR3`.
|
||||
4. Check that `U` and `RF` expectations are clear; flag missing reaction artifacts and optional `S`, `E`, and `SF` ambiguity.
|
||||
5. Record completed artifact onboarding in `PROGRESS.md` and remaining artifact tasks in `PLAN.md`.
|
||||
|
||||
## Do Not
|
||||
|
||||
- Do not run Abaqus.
|
||||
- Do not alter numerical tolerances just to make comparisons pass.
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
name: fesa-results-schema
|
||||
description: Design or review FESA HDF5 result outputs, step/frame/field/history layout, and reference comparison mapping.
|
||||
---
|
||||
|
||||
# FESA Results Schema
|
||||
|
||||
Use this skill when result storage, HDF5 groups, field/history outputs, or reference comparison paths are involved.
|
||||
|
||||
## Read First
|
||||
|
||||
- `/AGENTS.md`
|
||||
- `/PROGRESS.md`
|
||||
- `/PLAN.md`
|
||||
- `/docs/RESULTS_SCHEMA.md`
|
||||
- `/docs/VERIFICATION_PLAN.md`
|
||||
- `/docs/NUMERICAL_CONVENTIONS.md`
|
||||
- `/docs/MITC4_FORMULATION.md`
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Preserve the step/frame/field/history model.
|
||||
2. Check entity type, component order, coordinate system, precision, units metadata, and sign convention for each field.
|
||||
3. Distinguish full-vector results from reduced-vector solver internals.
|
||||
4. Ensure `U` and `RF` are clear for Phase 1; flag unresolved `S`, `E`, and `SF` decisions.
|
||||
5. When reference comparison is involved, map `references/*_displacements.csv` to HDF5 field output `U` using the documented Abaqus column names.
|
||||
6. Keep HDF5 API usage behind result writer/adapters.
|
||||
|
||||
## Output
|
||||
|
||||
- Provide docs-ready schema deltas or review findings.
|
||||
- Include reference comparison implications and tests needed.
|
||||
@@ -0,0 +1,41 @@
|
||||
---
|
||||
name: fesa-review
|
||||
description: Review FESA changes against repository guardrails, technical dossier docs, TDD expectations, and validation requirements.
|
||||
---
|
||||
|
||||
# FESA Review
|
||||
|
||||
Use this skill for repository-grounded review of docs, `.codex` extensions, phase plans, or implementation patches.
|
||||
|
||||
## Read First
|
||||
|
||||
- `/AGENTS.md`
|
||||
- `/PROGRESS.md`
|
||||
- `/PLAN.md`
|
||||
- `/docs/README.md`
|
||||
- `/docs/HARNESS_ENGINEERING.md`
|
||||
- `/docs/ARCHITECTURE.md`
|
||||
- `/docs/ADR.md`
|
||||
- `/docs/NUMERICAL_CONVENTIONS.md`
|
||||
- `/docs/ABAQUS_INPUT_SUBSET.md`
|
||||
- `/docs/VERIFICATION_PLAN.md`
|
||||
- `/docs/RESULTS_SCHEMA.md`
|
||||
- `/docs/MITC4_FORMULATION.md`
|
||||
- The changed files under review.
|
||||
|
||||
## Checklist
|
||||
|
||||
- Architecture and ADR compliance.
|
||||
- Numerical convention compliance.
|
||||
- Abaqus subset discipline.
|
||||
- Result schema compatibility.
|
||||
- MITC4 formulation traceability.
|
||||
- TDD or reference verification coverage.
|
||||
- Sprint contract compliance when implementation work is under review.
|
||||
- PLAN.md and PROGRESS.md synchronization.
|
||||
|
||||
## Output
|
||||
|
||||
- Lead with findings ordered by severity.
|
||||
- Include concrete file references and the risk behind each finding.
|
||||
- If no material issues exist, say so and list remaining evidence gaps.
|
||||
Reference in New Issue
Block a user