fsl-requirements-document

FSL Requirements Document — Generate, Annotate, Re-check

This skill turns a checked requirements (or direct spec) dialect file into a requirements document stakeholders can read, using the Requirement Claim IR (RCIR) pipeline: fslc document claims (the machine-readable contract), fslc document generate (deterministic ja/en Markdown), and fslc document check (structural drift detection). See ../fsl/SKILL.md and use its reference index only as needed for FSL syntax, verification, and repair — this skill only covers the document layer built on top of an already-checked spec. If the .fsl itself still needs authoring or repair, use fsl-requirements (or fsl-design) first and come back here once fslc check/fslc verify are green.

What this skill is for

The agent is an editor of non-normative content and a review-support assistant, not a compiler. Every normative sentence in the document — enablement conditions, effects, postconditions, fairness, deadlines, acceptance/forbidden traces — comes from a fixed template deterministically rendered from the checked FSL (issue #326). The agent never writes that text; it only fills in the one editable slot the generator leaves open (background), and only ever proposes findings about the source material, never encodes them into the normative sections itself.

Permitted operations

• Edit the non-normative background slot: project context, a plain-language summary, review notes for stakeholders.
• Propose a chapter reordering based on RCIR's own structure (e.g. grouping requirements by theme) — a suggestion for a human to apply, not a rewrite of generated content.
• Draft glossary candidates (issue #330) for terms that appear in requirement text or claims.
• Flag a candidate mismatch between the original requirement text and the formalized meaning as an advisory note — for example, source text that says "exactly once" where the formalized guard only enforces "at most once." Never strengthen the FSL-derived meaning to match the source text to make the mismatch disappear. Surfacing the gap is the value; resolving it is a human decision.
• Flag a missing requirement tag, a missing acceptance/forbidden case, or an undecided item that looks resolvable, as a review note.
• Point a stakeholder at a requirement whose assurance class is not_run in every dimension (issue #332) as a review note — never supply evidence yourself or assert a stronger class than the document already shows; the --evidence files come from real verification runs, not from the agent.
• Point a stakeholder at a document with no "Approval records" section (issue #333) as a review note ("this document is not yet approved") — never fabricate an approval record or assert that a document is approved without one.