メニュー
Author a new or substantially changed .fsl spec and take it through native check, bounded verification, induction where relevant, mutation, and vacuity evidence before completion.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Shared FSL language and verifier reference for writing, checking, verifying, repairing, explaining, mutating, refining, replaying, generating scenarios/test scaffolds, and interpreting fslc JSON results. Use directly for FSL syntax, kernel specs, verifier errors, repair loops, and command usage. For role-specific authoring, prefer fsl-business for business flows, fsl-requirements for PM requirements/acceptance/NFR specs, and fsl-design for engineering design/refinement work.
Generate, edit, and re-verify a human-readable requirements document (Markdown) from a checked FSL requirements/spec dialect file, using fslc document generate/claims/check. The agent is a non-normative editor and review-support assistant, never a compiler — it may only fill in the document's editable slot (background, summary, review notes) and propose advisory findings; it must never rewrite a generated claim block or invent normative language FSL does not state. Use when the deliverable is a requirements document artifact for stakeholders, not FSL authoring (use fsl-requirements for that) or a verification audit ledger (use fsl for fslc ledger).
Operate FSL's GitLab Flow-inspired lifecycle from short-lived branches through main and production to an exact vX.Y.Z release tag. Use when adopting the branch flow, integrating post-merge quality improvements, promoting a release, cutting a release, or handling a production hotfix.
Write and verify FSL requirements-layer specs for PMs/PdMs from natural-language product requirements, acceptance criteria, forbidden flows, requirement IDs, traceability, and NFRs such as permissions, audit, capacity, reliability, and SLA/deadline behavior. Use when the deliverable is a requirements specification, not business process discovery, software architecture, internal design, or implementation conformance.
Reconcile tasks/active.md with Git, changed files, and observed verification before compaction, clearing, or handoff.
Create or refresh the verified, resumable task packet in tasks/active.md before substantial FSL repository work.
| name | new-spec |
| description | Author a new or substantially changed .fsl spec and take it through native check, bounded verification, induction where relevant, mutation, and vacuity evidence before completion. |
Read skills/fsl/reference.md before writing syntax. Use the working-tree native prefix:
cargo run --manifest-path rust/Cargo.toml -p fslc-rust --bin fslc --
check <spec> for syntax and semantic diagnostics.verify <spec> --depth 8 or a justified bound for bounded evidence.verify <spec> --engine induction when the intended claim is unbounded.mutate <spec> to measure whether properties constrain behavior.verify <spec> --vacuity error where applicable.Do not hollow out a spec to dodge a counterexample. Confirm source requirements and exceptions before inventing behavior. Keep confirmed assumptions with the spec using established metadata. If FSL is the wrong tool for the behavior, say so rather than forcing a vacuous model.
Changing a corpus file may affect contract or compatibility artifacts. Use their owning generator only after confirming the semantic change is intentional; never hand-edit a snapshot.