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

update agent, skill and scripts

Browse Source
This commit is contained in:
KOKO\Mimi
2026-09-07 01:15:26 +09:00
parent 42a4847da5
commit d7e9629640
38 changed files with 476 additions and 2946 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.codex/skills/fem-requirements-baseline/SKILL.md
+5 -29
View File
@@ -1,38 +1,14 @@
---
name: fem-requirements-baseline
description: Use when baselining a finite-element structural solver feature before research, formulation, interface definition, or implementation planning.
description: Define a durable, verifiable structural FEM feature scope and acceptance contract when one is needed.
---
# FEM Requirements Baseline
Turn a structural-analysis solver request into a stable, verifiable contract without choosing downstream mathematics or implementation.
Turn the assigned request into observable scope, exclusions, assumptions, compatibility boundary, and acceptance intent. Use an existing PRD when it is sufficient; create a separate requirements document or matrix only when the feature needs that separation.
## Inputs
Write atomic requirements with a measurable acceptance method. State quantities, locations, units, coordinates, and physical behavior where relevant. Preserve user- or standard-defined acceptance; leave formulation choices, implementation, schema design, and numerical tolerance selection to their owners.
- Project instructions and architecture decisions
- User request, constraints, exclusions, and existing feature artifacts
- Applicable standards or compatibility commitments already selected by the project
Read [workflow-and-decisions.md](references/workflow-and-decisions.md) only for a material ambiguity or authority question. Return the document path, decisions, verification intent, and unresolved critical choice. Do not invent physics, compatibility, or acceptance promises.
## Workflow
1. Use the stable kebab-case `feature_id` and feature folder supplied by Coordinator; define purpose, scope, exclusions, analysis family, assumptions, units, coordinates, and compatibility boundary.
2. Write atomic `FEM-REQ-<FEATURE>-###` shall-statements. Give each an observable acceptance criterion and verification method.
3. Define logical verification quantities and required physical behavior. Preserve acceptance fixed by the user or an applicable standard; otherwise delegate quantity details, metric, scale, blocking class, and numerical tolerance to Numerical Review under `docs/TOLERANCE.md`.
4. Build the requirement-verification matrix and classify open issues using the project workflow.
Read [workflow and decision authority](references/workflow-and-decisions.md) when resolving ambiguity or deciding whether user input is critical. Use [evidence and handoff](references/evidence-and-handoff.md) for the returned envelope.
## Output
Follow [Feature document management](../../../docs/FEATURE_DOCUMENTATION.md): read the Coordinator's
feature context, keep main reports concise, and link necessary owned details in the same feature folder.
Create or revise `docs/<feature-id>/requirements.md` with metadata, scope, analysis definition, requirements, acceptance criteria, verification intent, compatibility boundary, matrix, open decisions, and handoff.
## Evidence
Every requirement traces to its source and an acceptance method. Numerical outputs state quantity, location, units, coordinates, and tolerance source when applicable.
## Boundary
Do not derive the formulation, select a numerical algorithm, design APIs or storage schemas, implement code, calibrate tolerances, or claim compatibility beyond the approved boundary. Route missing theory, reference evidence, or physical acceptance choices to their owning stage.
Use [evidence notes](references/evidence-and-handoff.md) when a separate durable evidence record is needed.