modify documents
This commit is contained in:
NINI
@@ -0,0 +1,28 @@
|
||||
---
|
||||
description: Draft or update an ADR for a FESA architecture or numerical decision.
|
||||
---
|
||||
|
||||
# /adr
|
||||
|
||||
## Preflight
|
||||
|
||||
- Read `/AGENTS.md`, `/PROGRESS.md`, `/PLAN.md`, `/docs/ARCHITECTURE.md`, `/docs/ADR.md`, and the topic-specific design docs.
|
||||
- Use `$fesa-adr-update` when available.
|
||||
- Identify whether this is a new decision, a revision, or a superseding ADR.
|
||||
|
||||
## Task
|
||||
|
||||
- Capture context, decision, consequences, alternatives considered, and affected docs.
|
||||
- Update related docs only when needed to keep decisions consistent.
|
||||
- Record follow-up tasks in `PLAN.md` and completed ADR work in `PROGRESS.md`.
|
||||
|
||||
## Verification
|
||||
|
||||
- Check links and decision numbering manually.
|
||||
- Run `python scripts/validate_workspace.py`.
|
||||
|
||||
## Result
|
||||
|
||||
- **Action**: drafted or updated ADR content
|
||||
- **Status**: success | partial | blocked
|
||||
- **Details**: ADR section changed, affected docs, and validation result
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
description: Guide or validate addition of a new stored reference benchmark.
|
||||
---
|
||||
|
||||
# /benchmark-add
|
||||
|
||||
## Preflight
|
||||
|
||||
- Read `/AGENTS.md`, `/PROGRESS.md`, `/PLAN.md`, `/docs/VERIFICATION_PLAN.md`, `/docs/RESULTS_SCHEMA.md`, and `/docs/ABAQUS_INPUT_SUBSET.md`.
|
||||
- Use `$fesa-reference-onboarding` when available.
|
||||
- Do not run Abaqus locally.
|
||||
|
||||
## Task
|
||||
|
||||
- Help organize the benchmark input, solved reference values such as `*_displacements.csv`, tolerance metadata, unit notes, result fields, and provenance.
|
||||
- Check that Abaqus keywords are within the Phase 1 subset or explicitly documented as unsupported.
|
||||
- Ensure comparison values can be tied to step/frame/field/history result paths.
|
||||
|
||||
## Verification
|
||||
|
||||
- Parse any JSON metadata if present.
|
||||
- For `*_displacements.csv`, check the required Abaqus displacement/rotation columns.
|
||||
- Run `python scripts/validate_workspace.py` when files are changed.
|
||||
|
||||
## Result
|
||||
|
||||
- **Action**: added or validated benchmark artifact
|
||||
- **Status**: ready | partial | blocked
|
||||
- **Details**: benchmark name, files, missing metadata, and validation result
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
description: Review FESA documentation for architecture, numerical, and coordination drift.
|
||||
---
|
||||
|
||||
# /doc-guard
|
||||
|
||||
## Preflight
|
||||
|
||||
- Read `/AGENTS.md`, `/PROGRESS.md`, `/PLAN.md`, `/docs/README.md`, and the docs changed in the current work.
|
||||
- Use `$fesa-doc-sync` and `$fesa-review` when available.
|
||||
- If the user explicitly asks for delegated review, use `harness_reviewer` or `progress_plan_auditor`.
|
||||
|
||||
## Task
|
||||
|
||||
- Check consistency across architecture, ADRs, numerical conventions, Abaqus subset, verification plan, result schema, MITC4 formulation, PLAN.md, and PROGRESS.md.
|
||||
- Lead with concrete drift findings and file references.
|
||||
- Keep comments focused on correctness, missing decisions, and validation gaps.
|
||||
|
||||
## Verification
|
||||
|
||||
- If edits are made, run `python scripts/validate_workspace.py`.
|
||||
- Confirm that future work stays in PLAN.md and completed work stays in PROGRESS.md.
|
||||
|
||||
## Result
|
||||
|
||||
- **Action**: reviewed documentation guardrails
|
||||
- **Status**: success | partial | blocked
|
||||
- **Details**: findings, edits if any, and validation result
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
description: Prepare a concise handoff for the next FESA agent session.
|
||||
---
|
||||
|
||||
# /handoff
|
||||
|
||||
## Preflight
|
||||
|
||||
- Read `/AGENTS.md`, `/PROGRESS.md`, `/PLAN.md`, and changed files.
|
||||
- Use `$fesa-doc-sync` when available.
|
||||
- Identify what changed, what was verified, what remains blocked, and what should happen next.
|
||||
|
||||
## Task
|
||||
|
||||
- Add a factual `PROGRESS.md` entry for completed work.
|
||||
- Update `PLAN.md` only for future tasks, changed ownership, open questions, or blockers.
|
||||
- Keep the handoff concise enough that a fresh agent can act without private context.
|
||||
|
||||
## Verification
|
||||
|
||||
- Run `python scripts/validate_workspace.py`.
|
||||
- Confirm that the next-session required reading remains current.
|
||||
|
||||
## Result
|
||||
|
||||
- **Action**: prepared handoff
|
||||
- **Status**: success | partial | blocked
|
||||
- **Details**: progress entry, plan deltas, blockers, and validation result
|
||||
@@ -0,0 +1,31 @@
|
||||
---
|
||||
description: Draft Harness phase and step files for FESA implementation planning.
|
||||
---
|
||||
|
||||
# /phase-draft
|
||||
|
||||
## Preflight
|
||||
|
||||
- Read `/AGENTS.md`, `/PROGRESS.md`, `/PLAN.md`, `/docs/README.md`, `/docs/HARNESS_ENGINEERING.md`, and all Phase 1 design docs.
|
||||
- Use `$fesa-readiness` first.
|
||||
- Use `$fesa-phase-planning` and the repo `harness-workflow` skill when file generation is requested.
|
||||
- Do not spawn subagents unless the user explicitly asks for delegated work.
|
||||
|
||||
## Task
|
||||
|
||||
- Identify readiness blockers before drafting steps.
|
||||
- Keep each phase step self-contained for a fresh Codex session.
|
||||
- Include a sprint contract: objective, required reading, scope, allowed files, explicit non-goals, tests to write first, reference artifacts, acceptance commands, evaluator checklist, and handoff requirements.
|
||||
- Do not hide unresolved formulation or reference decisions inside broad implementation steps.
|
||||
|
||||
## Verification
|
||||
|
||||
- Parse generated JSON phase files.
|
||||
- Re-read generated `stepN.md` files for self-containment.
|
||||
- Run `python scripts/validate_workspace.py`.
|
||||
|
||||
## Result
|
||||
|
||||
- **Action**: drafted phase files
|
||||
- **Status**: success | partial | blocked
|
||||
- **Details**: phase directory, step count, blockers, and validation result
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
description: Reconcile PLAN.md and PROGRESS.md after documentation, planning, or implementation work.
|
||||
---
|
||||
|
||||
# /plan-sync
|
||||
|
||||
## Preflight
|
||||
|
||||
- Read `/AGENTS.md`, `/PROGRESS.md`, `/PLAN.md`, and changed files.
|
||||
- Use `$fesa-doc-sync` when available.
|
||||
- Identify completed work, future tasks, blockers, and stale items.
|
||||
|
||||
## Task
|
||||
|
||||
- Move completed facts into `PROGRESS.md`.
|
||||
- Keep future tasks and open decisions in `PLAN.md`.
|
||||
- Preserve history unless the user explicitly asks for archival cleanup.
|
||||
- Add changed files and verification notes to the progress entry.
|
||||
|
||||
## Verification
|
||||
|
||||
- Parse or inspect any file format touched.
|
||||
- Run `python scripts/validate_workspace.py`.
|
||||
|
||||
## Result
|
||||
|
||||
- **Action**: synchronized plan and progress
|
||||
- **Status**: success | partial | blocked
|
||||
- **Details**: entries changed, remaining blockers, validation result
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
description: Check whether FESA is ready to start Phase 1 implementation planning or coding.
|
||||
---
|
||||
|
||||
# /readiness
|
||||
|
||||
## Preflight
|
||||
|
||||
- Read `/AGENTS.md`, `/PROGRESS.md`, `/PLAN.md`, and `/docs/README.md`.
|
||||
- Read the readiness-related docs listed by `/docs/README.md`.
|
||||
- Use `$fesa-readiness` when available.
|
||||
|
||||
## Task
|
||||
|
||||
- Evaluate each Phase 1 readiness item in `/PLAN.md` and the Implementation Readiness Checklist in `/docs/README.md`.
|
||||
- Classify each item as ready, blocked, deferred with explicit acceptance, or unknown.
|
||||
- Do not start implementation from this command.
|
||||
|
||||
## Verification
|
||||
|
||||
- If files are unchanged, no repository validation is required.
|
||||
- If readiness notes are written to `PLAN.md` or `PROGRESS.md`, run `python scripts/validate_workspace.py`.
|
||||
|
||||
## Result
|
||||
|
||||
- **Action**: checked implementation readiness
|
||||
- **Status**: ready | blocked | partial
|
||||
- **Details**: readiness table, blockers, and recommended next decision
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
description: Inspect stored Abaqus reference artifacts for Phase 1 verification readiness.
|
||||
---
|
||||
|
||||
# /reference-check
|
||||
|
||||
## Preflight
|
||||
|
||||
- Read `/AGENTS.md`, `/PROGRESS.md`, `/PLAN.md`, `/docs/VERIFICATION_PLAN.md`, `/docs/RESULTS_SCHEMA.md`, and `/docs/ABAQUS_INPUT_SUBSET.md`.
|
||||
- Use `$fesa-reference-onboarding` when available.
|
||||
- If the user explicitly asks for delegated review, use the `reference_artifact_curator` agent.
|
||||
|
||||
## Task
|
||||
|
||||
- Inspect the `references/` folder when present.
|
||||
- Check for `.inp` files, `*_displacements.csv` files, tolerance metadata, units notes, Abaqus version/provenance, and mapping to FESA result fields.
|
||||
- For displacement CSV files, verify the required columns `Node Label`, `U-U1`, `U-U2`, `U-U3`, `UR-UR1`, `UR-UR2`, `UR-UR3`.
|
||||
- Flag unsupported Abaqus input features as compatibility notes; do not treat stored reference input as automatic Phase 1 parser support.
|
||||
- Do not run Abaqus locally.
|
||||
|
||||
## Verification
|
||||
|
||||
- If no files are edited, summarize findings only.
|
||||
- If manifests or docs are updated, run `python scripts/validate_workspace.py`.
|
||||
|
||||
## Result
|
||||
|
||||
- **Action**: checked reference artifacts
|
||||
- **Status**: ready | partial | blocked
|
||||
- **Details**: artifacts found, missing metadata, and comparison-readiness notes
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
description: Summarize the current FESA project status and next work from PLAN.md and PROGRESS.md.
|
||||
---
|
||||
|
||||
# /status
|
||||
|
||||
## Preflight
|
||||
|
||||
- Read `/AGENTS.md`, `/PROGRESS.md`, `/PLAN.md`, and `/docs/README.md`.
|
||||
- Check whether the user asked for status only or also wants edits.
|
||||
- Do not modify files unless the user explicitly asks for synchronization or cleanup.
|
||||
|
||||
## Task
|
||||
|
||||
- Summarize current project status, blockers, risks, and the next actionable items.
|
||||
- Mention whether solver implementation has started.
|
||||
- Highlight unresolved Phase 1 readiness items and the current validation state.
|
||||
|
||||
## Verification
|
||||
|
||||
- If no edits were made, state that no validation command was required.
|
||||
- If the user asked you to update files, run `python scripts/validate_workspace.py`.
|
||||
|
||||
## Result
|
||||
|
||||
- **Action**: reported FESA status
|
||||
- **Status**: success | partial | blocked
|
||||
- **Details**: current objective, blockers, next tasks, and validation note
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
description: Validate Codex extension files, plugin command metadata, and project documentation metadata.
|
||||
---
|
||||
|
||||
# /verify-docs
|
||||
|
||||
## Preflight
|
||||
|
||||
- Read `/AGENTS.md`, `/PROGRESS.md`, `/PLAN.md`, and any changed `.codex`, `plugins/`, `.agents/plugins/`, or documentation files.
|
||||
- Use `$fesa-doc-sync` when available.
|
||||
|
||||
## Task
|
||||
|
||||
- Parse `.codex/config.toml` and `.codex/agents/*.toml`.
|
||||
- Parse `.codex/hooks.json`.
|
||||
- Parse `plugins/*/.codex-plugin/plugin.json`.
|
||||
- Parse `.agents/plugins/marketplace.json`.
|
||||
- Check `.codex/skills/*/SKILL.md` frontmatter for `name` and `description`.
|
||||
- Check `plugins/*/commands/*.md` command Markdown files for description frontmatter.
|
||||
|
||||
## Verification
|
||||
|
||||
- Run the format checks above.
|
||||
- Run `python scripts/validate_workspace.py`.
|
||||
|
||||
## Result
|
||||
|
||||
- **Action**: verified docs and Codex extension files
|
||||
- **Status**: success | partial | blocked
|
||||
- **Details**: files checked, failures, and validation result
|
||||
Reference in New Issue
Block a user