update agent, skill and scripts
This commit is contained in:
KOKO\Mimi
@@ -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.
|
||||
|
||||
@@ -1,26 +1,5 @@
|
||||
# Evidence and Handoff Contract
|
||||
# Evidence Notes
|
||||
|
||||
Use [Feature document management](../../../../docs/FEATURE_DOCUMENTATION.md) for concise main reports,
|
||||
linked details, and Coordinator's document inventory. Include main and required detail paths in evidence.
|
||||
Use this reference only when a task needs a durable evidence record. Record the feature/document path, decisive facts and assumptions, relevant commands with exit codes, comparison quantities and tolerance source when applicable, and residual risks. Keep source facts, calculations, inferences, and decisions distinct. A required failed or unrun check is not a pass.
|
||||
|
||||
Every stage returns one envelope:
|
||||
|
||||
| Field | Required content |
|
||||
| --- | --- |
|
||||
| `feature_id` | Stable feature identifier |
|
||||
| `stage` | `requirements`, `research`, `formulation`, `numerical-review`, `io-definition`, `implementation-planning`, `implementation`, `correction`, `physics-evaluation`, or `release-readiness` |
|
||||
| `outcome` | `pass`, `return-upstream`, `retry`, `blocked-environment`, or `needs-user-decision` |
|
||||
| `next_owner` | Agent id, or YAML `null` |
|
||||
| `evidence_paths` | Repository-relative artifacts used or produced |
|
||||
| `evidence_digest` | Concise findings tied to requirement IDs |
|
||||
| `failure_classification` | `configure`, `compile`, `link`, `test`, `reference-comparison`, `harness`, `environment`, `upstream-contract`, `physics`, `evidence`, or YAML `null` |
|
||||
| `retry_key` | `<feature-id>\|<failing-gate>\|<classification>\|<contract-revision>`, or YAML `null` |
|
||||
| `attempt` | Coordinator-managed nonnegative attempt count for the retry key |
|
||||
| `escalation_class` | Critical-decision class, or YAML `null` |
|
||||
| `blocker` | Actionable blocker, or YAML `null` |
|
||||
|
||||
Evidence records include, when applicable: source locator and access date; assumptions; command, exit code, duration, and relevant output; test identity and RED/GREEN result; artifact hash; comparison quantity, tolerance source, and decision; residual risk.
|
||||
|
||||
Use repository-relative paths and stable identifiers. Distinguish observed facts, calculations, inferences, and decisions. Never report a pass when a required command failed, evidence is stale, or a blocking acceptance item is unresolved.
|
||||
|
||||
Retry is bounded by the coordinator policy. A repeated normalized failure returns to its owning stage; it does not justify changing requirements, formulations, schemas, reference artifacts, or tolerances.
|
||||
Return a concise result containing changed paths, evidence, and blockers; no common handoff envelope, workflow state, retry key, or coordinator inventory is required. Do not use repeated failure to justify changing requirements, formulations, schemas, reference artifacts, or tolerances.
|
||||
|
||||
@@ -18,7 +18,7 @@ Proceed without user review for reversible choices within approved contracts: in
|
||||
|
||||
## User decisions
|
||||
|
||||
Return `needs-user-decision` only for a choice that changes at least one of:
|
||||
Ask the user only for a choice that changes at least one of:
|
||||
|
||||
- supported physics, formulation meaning, or analysis scope;
|
||||
- public compatibility or an authoritative I/O schema;
|
||||
@@ -28,6 +28,6 @@ Return `needs-user-decision` only for a choice that changes at least one of:
|
||||
|
||||
Everything else follows the authority order. Lack of a preference is not a blocker when a deterministic in-contract choice exists.
|
||||
|
||||
## Contract flow
|
||||
## Responsibilities
|
||||
|
||||
Requirements own acceptance intent; research owns evidence; formulation owns mathematics; numerical review owns independent numerical findings and logical verification coverage; I/O owns external/internal mappings; implementation owns code and tests; physics review owns physical plausibility; release review owns closure evidence. A downstream stage returns a defect to the owning upstream stage instead of silently rewriting its contract.
|
||||
Requirements own acceptance intent; research owns evidence; formulation owns mathematics; numerical review owns independent numerical findings and verification coverage; I/O owns mappings; implementation owns code and tests; and physics review owns plausibility findings. Use only the expertise needed by the task. Do not silently rewrite another owner's contract to make downstream work pass.
|
||||
|
||||
Reference in New Issue
Block a user