specification

specification

Turns a need into a structured, contractable specification (cahier des charges). Elicits the missing context, drafts the document with uniquely identified and prioritized requirements, then runs an adversarial pass so every requirement is unambiguous, atomic and verifiable.

Available actions

#	Action	Role	Input
01	elicit	Gather objectives, stakeholders, scope, constraints, budget/timeline	the need / brief
02	draft	Write the specification from the structure	elicited context
03	challenge	Adversarial pass — testability, atomicity, scope, contradictions	a draft spec

Default flow

Linear: 01 → 02 → 03. elicit may pause for the user's answers; challenge can run standalone on an existing spec.

Trigger-to-action mapping:

• "write the specification / cahier des charges for ", "formalize this need into a spec", "requirements document" → full flow from elicit
• "what do we need to know for the spec" → elicit
• "challenge / review this specification", "are these requirements testable" → challenge

Transversal rules

• Read ${CLAUDE_PLUGIN_ROOT}/references/doc-principles.md and references/spec-structure.md first.
• Rédaction en français par défaut — le cahier des charges est rédigé en français (sauf demande explicite d'une autre langue) ; les termes techniques consacrés gardent leur forme d'origine.
• Output style: follow ${CLAUDE_PLUGIN_ROOT}/skills/specification/references/output-style.md for voice and formatting by default. To inject a different one, pass --style <path> in $ARGUMENTS; load that file and follow it instead.
• Output format: Markdown by default. --format icml exports the finished cahier des charges to ICML (Adobe InCopy/InDesign) via pandoc — see ${CLAUDE_PLUGIN_ROOT}/references/export-icml.md. Markdown stays the source.
• Every requirement is atomic, uniquely identified, prioritized, and verifiable. IDs like FR-1, NFR-1; priority via MoSCoW (Must/Should/Could/Won't).
• Scope is explicit on both sides: an "out of scope" list is mandatory.
• Acceptance criteria are measurable — a criterion you cannot test is not done.
• Never invent budget, deadlines, volumes, or constraints; ask, or list them as assumptions/open questions.
• Distinguish requirement (what) from solution (how); keep imposed technical choices in Constraints, not smuggled into functional requirements.
• elicit asks blocking questions in a single numbered list, then waits.

References

• references/spec-template.md — the fillable French cahier-des-charges skeleton (base structure)
• references/spec-structure.md — the sections of the specification and the rules for requirements
• ${CLAUDE_PLUGIN_ROOT}/skills/specification/references/output-style.md — default voice/formatting (override with --style <path>)
• ${CLAUDE_PLUGIN_ROOT}/references/doc-principles.md — shared documentation ethos

Evals

• evals/scenarios.json