KOKO\Mimi
67 lines
3.1 KiB
Markdown
67 lines
3.1 KiB
Markdown
---
|
|
name: fesa-requirements-baseline
|
|
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 Requirements Baseline
|
|
|
|
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/SOLVER_AGENT_DESIGN.md`
|
|
- User feature request, target capability, constraints, and known exclusions
|
|
- Existing `docs/<feature-id>/requirements.md` when revising a feature
|
|
|
|
## Workflow
|
|
|
|
1. Assign a stable `feature_id` in kebab case.
|
|
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 a minimal Reference Case: exact existing input/required CSV paths, blocking and
|
|
warning-only quantities, HDF5 projection, source-ID/component matching, and tolerance.
|
|
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/<feature-id>/requirements.md` with:
|
|
|
|
- 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 Case Requirements
|
|
- Requirement Verification Matrix
|
|
- Open Questions and Downstream Handoff
|
|
|
|
## Boundaries
|
|
|
|
- Do not implement C++ code.
|
|
- 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 or modify Abaqus reference CSV files.
|
|
- Do not approve release readiness.
|
|
|
|
## Quality Gate
|
|
|
|
- Every `must` requirement has a verification method and acceptance criteria.
|
|
- Every numerical solver-output requirement has units, coordinates, and tolerance when applicable.
|
|
- Every reference-comparison requirement names exact required files, compared components,
|
|
source identity, blocking/warning behavior, and tolerance.
|
|
- Do not require canonical names, README, metadata, provenance, or CSVs for quantities outside
|
|
the feature acceptance boundary.
|
|
- Words like "accurate", "fast", and "Abaqus-like" are converted into measurable criteria or open questions.
|
|
- Return reference artifact, comparison quantity, source-identity/component, and tolerance gaps for Numerical Review rather than inventing acceptance rules.
|
|
|
|
## Handoff
|
|
|
|
Return `docs/<feature-id>/requirements.md`, status, evidence summary, and blockers to Coordinator Agent. Route theory questions to Research Agent and reference acceptance, artifact, identity/component, and tolerance questions to Numerical Review Agent through Coordinator Agent.
|