baram2584/FESADev
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

revert

Browse Source
This commit is contained in:
김경종
2026-06-10 10:03:11 +09:00
parent 87529c811a
commit 0912ee6f3b
174 changed files with 414 additions and 8544 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.codex/skills/fesa-requirements-baseline/SKILL.md
+17 -17
View File
@@ -1,18 +1,18 @@
---
name: fesa-requirements-baseline
description: Use when analyzing new FESA solver feature requirements, acceptance criteria, tolerance decisions, verification quantities, and a requirement verification matrix before research, formulation, reference modeling, or implementation planning.
description: Use when defining FESA solver feature requirements, acceptance criteria, tolerance decisions, verification quantities, and a requirement verification matrix before research, formulation, reference modeling, or implementation planning.
---
# FESA New Solver Feature Requirements Analysis
# FESA Requirements Baseline
Use this skill to turn a new solver feature request into a verifiable new solver feature requirements analysis baseline that downstream agents can use without guessing.
Use this skill to turn a solver feature request into a verifiable baseline that downstream agents can use without guessing.
## Inputs
Read these first:
- `AGENTS.md`
- `docs/AGENT_RULES.md`
- `docs/SOLVER_AGENT_DESIGN.md`
- `docs/requirements/README.md`
- User feature request, target capability, constraints, and known exclusions
- Existing `docs/requirements/<feature-id>.md` when revising a feature
@@ -20,26 +20,26 @@ Read these first:
## Workflow
1. Assign a stable `feature_id` in kebab case.
2. Analyze purpose, included scope, excluded scope, and analysis definition.
3. Convert requested behavior into analyzed `shall` statements with ids like `FESA-REQ-<FEATURE>-###`.
4. Analyze and record verification quantities: displacement, reaction, element force, stress, strain, energy, or residual.
5. Analyze and record Tolerance Policy values or mark them `needs-user-decision`.
6. Analyze and record Reference Artifact Requirements under `references/<feature-id>/`.
7. Build a Requirement Verification Matrix that maps analyzed requirement, source, verification method, acceptance criteria, tolerance, downstream agents, and status.
2. Define purpose, included scope, excluded scope, and analysis definition.
3. Convert requested behavior into `shall` statements with ids like `FESA-REQ-<FEATURE>-###`.
4. Define verification quantities: displacement, reaction, element force, stress, strain, energy, or residual.
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 that maps requirement, source, verification method, acceptance criteria, tolerance, downstream agents, and status.
8. Keep unresolved decisions visible as open issues; do not hide gaps behind vague wording.
## Output Contract
Produce or revise `docs/requirements/<feature-id>.md` as a new solver feature requirements analysis document with:
Produce or revise `docs/requirements/<feature-id>.md` with:
- Metadata with `feature_id`, analysis status, owner agent, and date
- Metadata with `feature_id`, status, owner agent, and date
- Purpose, In Scope, Out Of Scope, and Analysis Definition
- Input and Output Requirements
- Verification Quantities
- Tolerance Policy
- Reference Artifact Requirements
- Requirement Verification Matrix
- Open Questions and Downstream Handoff from the requirements analysis
- Open Questions and Downstream Handoff
## Boundaries
@@ -47,14 +47,14 @@ Produce or revise `docs/requirements/<feature-id>.md` as a new solver feature re
- Do not write finite element formulations.
- Do not design C++ APIs or file ownership.
- Do not run Abaqus, Nastran, or any reference solver.
- Do not generate reference HDF5 artifacts or reference CSVs.
- Do not generate reference CSVs.
- Do not approve release readiness.
## Quality Gate
- Every `must` requirement analyzed in the document has a verification method and acceptance criteria.
- Every numerical requirement analyzed in the document has units, coordinate system, and tolerance or an explicit owner for the decision.
- Every reference-comparison requirement analyzed in the document names required artifacts.
- Every `must` requirement has a verification method and acceptance criteria.
- Every numerical requirement has units, coordinate system, and tolerance or an explicit owner for the decision.
- Every reference-comparison requirement names required artifacts.
- Words like "accurate", "fast", and "Abaqus-like" are converted into measurable criteria or open questions.
## Handoff