modify agent and skill

.codex/agents/requirement-agent.toml

@@ -1,5 +1,5 @@
 name = "requirement-agent"
-description = "Drafts verifiable requirements for FESA FEM solver features before formulation, implementation, and reference validation."
+description = "Analyzes new FESA FEM solver feature requirements and produces verifiable requirements analysis before formulation, implementation, and reference validation."
 sandbox_mode = "read-only"
 model_reasoning_effort = "extra high"
 
@@ -7,12 +7,12 @@ developer_instructions = """
 You are the Requirement Agent for the FESA structural analysis solver project.
 
 Mission:
-- Convert solver feature requests into a verifiable requirements baseline.
+- Analyze new solver feature requests into a verifiable new solver feature requirements analysis baseline.
-- Produce a Feature Requirement Specification and a Requirement Verification Matrix.
+- Produce a New Solver Feature Requirements Analysis document and a Requirement Verification Matrix.
 - Keep the output aligned with docs/AGENT_RULES.md.
 
 Skill references:
-- Use $fesa-requirements-baseline when drafting or revising requirements, acceptance criteria, tolerance decisions, verification quantities, reference artifact requirements, or Requirement Verification Matrix entries.
+- Use $fesa-requirements-baseline when analyzing, drafting, or revising new solver feature requirements, acceptance criteria, tolerance decisions, verification quantities, reference artifact requirements, or Requirement Verification Matrix entries.
 
 Hard boundaries:
 - Do not implement code.
@@ -28,7 +28,7 @@ Source priorities:
 3. Stored project references under references/, when present.
 4. Publicly cited requirements, verification, FEM benchmark, or V&V sources only when the user asks for research-backed requirements.
 
-Requirement drafting rules:
+New solver feature requirements analysis rules:
 - Write requirements as "The FESA solver shall ..." statements.
 - State what the solver must do, not how it must be implemented.
 - Keep each requirement singular, measurable, feasible, verifiable, and traceable.
@@ -36,7 +36,7 @@ Requirement drafting rules:
 - Mark unverifiable requirements as needs-user-decision.
 - Replace vague claims such as "accurate", "fast", or "Abaqus-like" with measurable acceptance criteria or an explicit open question.
 
-Required Feature Requirement Specification sections:
+Required New Solver Feature Requirements Analysis sections:
 1. Metadata: feature_id, title, status, owner_agent, date.
 2. Purpose and expected behavior.
 3. In scope.
@@ -51,7 +51,7 @@ Required Feature Requirement Specification sections:
 12. Open questions.
 13. Downstream handoff.
 
-Requirement record format:
+Requirements analysis record format:
 id: FESA-REQ-<FEATURE>-###
 statement: "The FESA solver shall ..."
 category: functional | physics | numerical | input | output | verification | constraint
@@ -66,7 +66,7 @@ trace_to:
   downstream_agents: ["Research Agent", "Formulation Agent", "Reference Model Agent"]
 status: draft | needs-user-decision | approved
 
-Verification planning rules:
+Requirements analysis verification planning rules:
 - Every must requirement must have a verification method and acceptance criterion.
 - Numerical requirements must include units, coordinate system, and tolerance.
 - Reference-comparison requirements must identify the required reference artifact files.
@@ -74,13 +74,13 @@ Verification planning rules:
 - If reference artifacts are missing, hand off requirements to Reference Model Agent.
 
 Downstream handoff rules:
-- Research Agent: theory sources, benchmark questions, and standards to investigate.
+- Research Agent: theory sources, benchmark questions, and standards identified by the requirements analysis.
-- Formulation Agent: analysis type, target elements, material assumptions, DOFs, outputs, and numerical constraints.
+- Formulation Agent: analysis type, target elements, material assumptions, DOFs, outputs, and numerical constraints from the requirements analysis.
-- I/O Definition Agent: input and output schema requirements.
+- I/O Definition Agent: input and output schema requirements from the requirements analysis.
-- Reference Model Agent: references/<feature>/ artifact requirements.
+- Reference Model Agent: references/<feature>/ artifact requirements from the requirements analysis.
-- Implementation Planning Agent: tests to write first and acceptance criteria.
+- Implementation Planning Agent: tests to write first and acceptance criteria from the requirements analysis.
 
 Output language:
-- Write feature requirement documents in Korean Markdown unless the user requests another language.
+- Write new solver feature requirements analysis documents in Korean Markdown unless the user requests another language.
 - Keep requirement IDs, categories, and machine-readable fields in English.
 """

.codex/skills/fesa-requirements-baseline/SKILL.md

@@ -1,11 +1,11 @@
 ---
 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.
+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.
 ---
 
-# FESA Requirements Baseline
+# FESA New Solver Feature Requirements Analysis
 
-Use this skill to turn a solver feature request into a verifiable baseline that downstream agents can use without guessing.
+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.
 
 ## Inputs
 
@@ -20,26 +20,26 @@ Read these first:
 ## Workflow
 
 1. Assign a stable `feature_id` in kebab case.
-2. Define purpose, included scope, excluded scope, and analysis definition.
+2. Analyze purpose, included scope, excluded scope, and analysis definition.
-3. Convert requested behavior into `shall` statements with ids like `FESA-REQ-<FEATURE>-###`.
+3. Convert requested behavior into analyzed `shall` statements with ids like `FESA-REQ-<FEATURE>-###`.
-4. Define verification quantities: displacement, reaction, element force, stress, strain, energy, or residual.
+4. Analyze and record verification quantities: displacement, reaction, element force, stress, strain, energy, or residual.
-5. Record Tolerance Policy values or mark them `needs-user-decision`.
+5. Analyze and record Tolerance Policy values or mark them `needs-user-decision`.
-6. Record Reference Artifact Requirements under `references/<feature-id>/`.
+6. Analyze and 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.
+7. Build a Requirement Verification Matrix that maps analyzed 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` with:
+Produce or revise `docs/requirements/<feature-id>.md` as a new solver feature requirements analysis document with:
 
-- Metadata with `feature_id`, status, owner agent, and date
+- Metadata with `feature_id`, analysis 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
+- Open Questions and Downstream Handoff from the requirements analysis
 
 ## Boundaries
 
@@ -52,9 +52,9 @@ Produce or revise `docs/requirements/<feature-id>.md` with:
 
 ## Quality Gate
 
-- Every `must` requirement has a verification method and acceptance criteria.
+- Every `must` requirement analyzed in the document has a verification method and acceptance criteria.
-- Every numerical requirement has units, coordinate system, and tolerance or an explicit owner for the decision.
+- Every numerical requirement analyzed in the document has units, coordinate system, and tolerance or an explicit owner for the decision.
-- Every reference-comparison requirement names required artifacts.
+- Every reference-comparison requirement analyzed in the document names required artifacts.
 - Words like "accurate", "fast", and "Abaqus-like" are converted into measurable criteria or open questions.
 
 ## Handoff

.codex/skills/fesa-requirements-baseline/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
-  display_name: "FESA Requirements Baseline"
+  display_name: "FESA Requirements Analysis"
-  short_description: "Define solver requirements"
+  short_description: "Analyze new solver requirements"
-  default_prompt: "Use $fesa-requirements-baseline to define verifiable FESA solver requirements."
+  default_prompt: "Use $fesa-requirements-baseline to analyze new FESA solver feature requirements."

AGENTS.md

@@ -15,7 +15,7 @@ FESA는 Abaqus, Nastran 같은 유한요소법 기반 구조해석 솔버를 C++
 ## 기본 개발 워크플로우
 솔버 기능 개발은 아래 순서를 기본으로 한다.
 
-1. 솔버 기능에 대한 요구조건 정의
+1. 새로운 솔버 기능 요구조건 분석
 2. 책, 논문 등 연구자료 조사
 3. 코드 구현을 위한 유한요소 정식화
 4. 솔버 입출력 데이터 정의

docs/AGENT_RULES.md

@@ -16,7 +16,7 @@ Before changing code or documents, every Agent must read:
 ## Global Solver Workflow
 All solver features follow this stage-gated workflow:
 
-1. Define solver feature requirements.
+1. Analyze new solver feature requirements.
 2. Research books, papers, manuals, benchmarks, and reference implementations.
 3. Write FEM formulation for implementation.
 4. Define solver input and output data.

docs/PLAN.md

@@ -10,7 +10,7 @@ Build the FESA structural solver foundation around the initial feature `mitc4-li
 
 ## Current High-Level Plan
 1. Maintain project-level documentation and handoff files.
-2. Define requirements for `mitc4-linear-static-shell`.
+2. Analyze new solver feature requirements for `mitc4-linear-static-shell`.
 3. Gather research evidence for MITC4, OpenSees `ShellMITC4`, Abaqus S4/S4R, patch tests, and Scordelis-Lo.
 4. Write FEM formulation for the MITC4 linear static shell feature.
 5. Define Abaqus `.inp` input subset and HDF5 output/reference schemas.

docs/PROGRESS.md

@@ -18,9 +18,11 @@
 - Moved solver plan/design documents to `docs/project-plan/` and updated agent, skill, test, and document references.
 - Extracted common per-run rules from the solver agent design into `docs/AGENT_RULES.md`.
 - Updated `.codex/agents/*.toml`, `.codex/skills/*/SKILL.md`, and related tests to reference `docs/AGENT_RULES.md` instead of the solver agent design document.
+- Renamed the first solver development workflow stage to "새로운 솔버 기능 요구조건 분석" across `AGENTS.md`, `docs/`, `.codex/agents/requirement-agent.toml`, and `.codex/skills/fesa-requirements-baseline`.
+- Refined `requirement-agent` and `fesa-requirements-baseline` internals to describe a new solver feature requirements analysis document instead of a requirements drafting/specification task.
 
 ## In Progress
-- Ready for the next stage: requirements baseline for `mitc4-linear-static-shell`.
+- Ready for the next stage: new solver feature requirements analysis for `mitc4-linear-static-shell`.
 
 ## Next Tasks
 1. Create `docs/requirements/mitc4-linear-static-shell.md`.
@@ -31,6 +33,12 @@
 6. Create `docs/implementation-plans/mitc4-linear-static-shell-implementation-plan.md`.
 
 ## Last Validation
+- 2026-06-08: After refining `requirement-agent` and `fesa-requirements-baseline` internals, `python C:\Users\baram\.codex\skills\.system\skill-creator\scripts\quick_validate.py .codex\skills\fesa-requirements-baseline` passed.
+- 2026-06-08: After refining `requirement-agent` and `fesa-requirements-baseline` internals, `python -m unittest discover -s scripts -p "test_*.py"` passed. 85 tests ran successfully.
+- 2026-06-08: After refining `requirement-agent` and `fesa-requirements-baseline` internals, `python scripts/validate_workspace.py` passed through the expected no-op path because no root `CMakeLists.txt` exists yet.
+- 2026-06-08: `python C:\Users\baram\.codex\skills\.system\skill-creator\scripts\quick_validate.py .codex\skills\fesa-requirements-baseline` passed.
+- 2026-06-08: `python -m unittest discover -s scripts -p "test_*.py"` passed. 85 tests ran successfully.
+- 2026-06-08: `python scripts/validate_workspace.py` passed through the expected no-op path because no root `CMakeLists.txt` exists yet.
 - 2026-06-05: After extracting `docs/AGENT_RULES.md`, `python -m unittest discover -s scripts -p "test_*.py"` passed. 85 tests ran successfully.
 - 2026-06-05: `python scripts/validate_workspace.py` passed through the expected no-op path because no root `CMakeLists.txt` exists yet.
 - 2026-06-05: After document relocation and reference updates, `python -m unittest discover -s scripts -p "test_*.py"` passed. 85 tests ran successfully.

docs/coordination/README.md

@@ -153,7 +153,7 @@ INTAKE -> STATE AUDIT -> GATE DECISION -> HANDOFF PACKAGE -> STATUS REPORT
 ## 상태 값
 
 - `intake`: 기능 요청은 들어왔지만 첫 handoff가 완료되지 않았다.
-- `needs-requirements`: Requirement Agent가 요구조건을 정의하거나 수정해야 한다.
+- `needs-requirements`: Requirement Agent가 새로운 솔버 기능 요구조건 분석 산출물을 작성하거나 수정해야 한다.
 - `needs-research`: Research Agent가 source-backed research evidence를 제공하거나 수정해야 한다.
 - `needs-formulation`: Formulation Agent가 FEM 정식화를 작성하거나 수정해야 한다.
 - `needs-numerical-review`: Numerical Review Agent가 정식화를 검토하거나 재검토해야 한다.

docs/project-plan/SOLVER_AGENT_DESIGN.md

@@ -6,7 +6,7 @@
 이번 구성안은 ALL-FEM 논문의 구조를 확장하거나 재사용하는 계획이 아니다. 논문은 Agent 설계를 위한 참고 자료로만 사용하며, 본 프로젝트는 C++/MSVC 기반 독립 솔버 개발 워크플로우를 따른다.
 
 ## 설계 원칙
-- 기능 요구조건, 이론 정식화, 코드 구현, 검증, 배포 역할을 분리한다.
+- 새로운 솔버 기능 요구조건 분석, 이론 정식화, 코드 구현, 검증, 배포 역할을 분리한다.
 - 실행 가능성만으로 성공을 판단하지 않고, 레퍼런스 결과와 물리량을 비교해 기능 완료를 판정한다.
 - 테스트는 구현 전에 준비한다. 개발 대상 솔버 테스트와 레퍼런스 솔버 결과 비교 테스트를 함께 사용한다.
 - Abaqus나 Nastran을 Agent가 직접 실행하지 않는다. `references/`에 저장된 입력 파일과 레퍼런스 CSV 결과를 검증 기준으로 사용한다.
@@ -21,7 +21,7 @@
 책임:
 - 기능 개발 요청을 단계별 작업으로 분해한다.
 - 각 Agent의 산출물을 연결하고 누락된 결정을 추적한다.
-- 요구조건, 정식화, 테스트, 구현, 검증, 배포 단계의 진행 상태를 관리한다.
+- 요구조건 분석, 정식화, 테스트, 구현, 검증, 배포 단계의 진행 상태를 관리한다.
 - 실패 시 어떤 Agent로 되돌릴지 결정한다.
 
 주요 산출물:
@@ -30,10 +30,10 @@
 - 실패 원인과 재작업 지시
 
 ### Requirement Agent
-솔버 기능 요구조건을 정의하는 Agent이다.
+새로운 솔버 기능 요구조건을 분석하는 Agent이다.
 
 책임:
-- 해석 기능의 범위, 입력, 출력, 제약조건을 정의한다.
+- 해석 기능의 범위, 입력, 출력, 제약조건을 분석하고 명시한다.
 - 대상 요소, 재료 모델, 경계조건, 하중 조건, 해석 타입을 명확히 한다.
 - 검증해야 할 물리량과 tolerance 기준을 정한다.
 
@@ -240,7 +240,7 @@ python scripts/validate_workspace.py
 
 | 개발 과정 | 담당 Agent | 필수 산출물 |
 | --- | --- | --- |
-| 1. 솔버 기능 요구조건 정의 | Requirement Agent | 요구조건, acceptance criteria |
+| 1. 새로운 솔버 기능 요구조건 분석 | Requirement Agent | 요구조건 분석, acceptance criteria |
 | 2. 연구자료 조사 | Research Agent | 자료 요약, benchmark 후보 |
 | 3. 유한요소 정식화 | Formulation Agent, Numerical Review Agent | 정식화 문서, 리뷰 결과 |
 | 4. 입출력 데이터 정의 | I/O Definition Agent | 입력/출력 schema |
@@ -278,7 +278,7 @@ flowchart TD
 
 ## 검증 Gate
 
-### Gate 1: 요구조건 승인
+### Gate 1: 요구조건 분석 승인
 통과 조건:
 - 대상 기능과 제외 범위가 명확하다.
 - 입력, 출력, tolerance, 검증 물리량이 정의되어 있다.

docs/project-plan/SOLVER_IMPLEMENT_INITIAL_PLAN.md

@@ -5,7 +5,7 @@ FESA will implement an initial finite element structural solver feature named `m
 
 The implementation must follow the full solver development workflow:
 
-1. Define solver feature requirements.
+1. Analyze new solver feature requirements.
 2. Research books, papers, manuals, and related solver implementations.
 3. Write the finite element formulation required for code implementation.
 4. Define solver input and output data contracts.
@@ -56,10 +56,10 @@ Primary conceptual modules:
 - `ResultWriter`: HDF5 output.
 - `ReferenceComparator`: HDF5 reference comparison.
 
-## Step 1: Requirements Baseline
+## Step 1: New Solver Feature Requirements Analysis
 Create `docs/requirements/mitc4-linear-static-shell.md`.
 
-The requirement document must define:
+The requirements analysis document must define:
 - analysis type: linear static
 - element type: MITC4 shell
 - DOF order: `U1, U2, U3, UR1, UR2, UR3`

docs/project-plan/SOLVER_SKILL_DESIGN.md

@@ -21,7 +21,7 @@ Agent는 역할과 책임 단위이고, skill은 여러 Agent가 반복적으로
 
 | Skill | 적용 개발 과정 | 주요 사용자 Agent | 대표 산출물 |
 | --- | --- | --- | --- |
-| `fesa-requirements-baseline` | 1. 솔버 기능 요구조건 정의 | Requirement Agent, Coordinator Agent | `docs/requirements/<feature-id>.md` |
+| `fesa-requirements-baseline` | 1. 새로운 솔버 기능 요구조건 분석 | Requirement Agent, Coordinator Agent | `docs/requirements/<feature-id>.md` |
 | `fesa-research-evidence` | 2. 책, 논문 등 연구자료 조사 | Research Agent, Formulation Agent | `docs/research/<feature-id>-research.md` |
 | `fesa-formulation-spec` | 3. 코드 구현을 위한 유한요소 정식화 | Formulation Agent, Implementation Planning Agent | `docs/formulations/<feature-id>-formulation.md` |
 | `fesa-numerical-review` | 3. 정식화 독립 수치 검토 | Numerical Review Agent, Coordinator Agent | `docs/numerical-reviews/<feature-id>-review.md` |
@@ -36,7 +36,7 @@ Agent는 역할과 책임 단위이고, skill은 여러 Agent가 반복적으로
 
 예시 기능: `linear-truss-1d`
 
-1. Requirement Agent는 `fesa-requirements-baseline`을 사용해 기능 범위, 제외 범위, 입력, 출력, 검증 물리량, tolerance, `Requirement Verification Matrix`를 작성한다.
+1. Requirement Agent는 `fesa-requirements-baseline`을 사용해 새로운 솔버 기능의 범위, 제외 범위, 입력, 출력, 검증 물리량, tolerance, `Requirement Verification Matrix`를 분석하고 작성한다.
 2. Research Agent는 `fesa-research-evidence`를 사용해 truss/bar element 이론, benchmark 후보, source reliability, applicability limits를 정리한다.
 3. Formulation Agent는 `fesa-formulation-spec`을 사용해 strong form, weak form, shape functions, B matrix, element stiffness, output recovery를 정리한다.
 4. Numerical Review Agent는 `fesa-numerical-review`를 사용해 rigid body modes, patch test, stiffness symmetry, Jacobian, locking 위험을 검토하고 `pass-for-implementation-planning` 여부를 판단한다.
@@ -51,7 +51,7 @@ Agent는 역할과 책임 단위이고, skill은 여러 Agent가 반복적으로
 
 ### `fesa-requirements-baseline`
 
-- 기능 요청을 검증 가능한 요구조건 baseline으로 만든다.
+- 새로운 솔버 기능 요청을 검증 가능한 요구조건 분석 baseline으로 만든다.
 - `shall` 문장과 `FESA-REQ-<FEATURE>-###` id를 사용한다.
 - 모든 `must` 요구조건은 verification method와 acceptance criteria를 가져야 한다.
 - FEM 정식화, C++ 구현, reference CSV 생성, release readiness 판단은 하지 않는다.

docs/requirements/README.md

@@ -1,12 +1,12 @@
 # 요구조건 문서 작성 가이드
 
-이 디렉터리는 Requirement Agent가 작성하거나 제안한 기능별 요구조건 문서를 보관하는 위치다.
+이 디렉터리는 Requirement Agent가 작성하거나 제안한 새로운 솔버 기능 요구조건 분석 문서를 보관하는 위치다.
 
-기본 파일명은 `docs/requirements/<feature-id>.md` 형식을 사용한다. 각 문서는 구현 전에 작성되며, Formulation Agent, I/O Definition Agent, Reference Model Agent, Implementation Planning Agent가 이어받을 수 있는 검증 가능한 baseline이어야 한다.
+기본 파일명은 `docs/requirements/<feature-id>.md` 형식을 사용한다. 각 문서는 구현 전에 작성되며, Formulation Agent, I/O Definition Agent, Reference Model Agent, Implementation Planning Agent가 이어받을 수 있는 검증 가능한 요구조건 분석 baseline이어야 한다.
 
 ## Requirement Agent 역할
 
-Requirement Agent는 솔버 기능 요청을 검증 가능한 요구조건으로 바꾼다.
+Requirement Agent는 새로운 솔버 기능 요청을 검증 가능한 요구조건 분석 산출물로 바꾼다.
 
 수행한다:
 - 기능 범위, 제외 범위, 입력, 출력, 제약조건을 정의한다.