Always use the skill to retrieve the ***plain syntax rules — but only if you haven't done so yet.

If you only need to add a single spec, use the skill instead. Either way, never edit the section by hand — every new entry must go through one of these two skills so the complexity and conflict checks actually run.

This skill is applied one spec at a time, in order, with no shortcuts. The batch never escapes per-spec rigor.

Order matters: each new spec is inserted only after its complexity and conflict checks pass, so subsequent specs in the batch are always checked against an already-validated file.

All the rules from apply per individual spec. They are restated here so this skill is self-contained.

Each functional spec must imply a maximum of 200 changed lines of code. If a spec is too large, use to split it into multiple smaller, independent specs. Do not include LOC estimates in the spec text.

Specs are rendered incrementally, top to bottom. The renderer has no knowledge of future specs — only previously rendered specs are in context.

Write in terms of behavior, concepts, and domain logic — not implementation constructs. Avoid language-specific types, generics syntax, framework annotations, or other constructs tied to a particular language or framework. General technical terms (null values, JSON types, HTTP status codes) are fine. Language-specific guidance belongs in .

The new specs must not contradict each other and must not contradict any existing functional spec. Conflicting specs are the most costly outcome. The conflict check must cover:

That coverage is achieved by running once per spec being inserted, with the new spec plus every existing spec plus every already-inserted spec from this batch passed in as a single set. The batched analyzer lists every conflicting pair in one call — do not invoke a pair-by-pair analyzer. If ambiguity exists, add explicit detail to eliminate any conflicting interpretation. For each conflicting pair the batched analyzer reports, use the skill to diagnose and fix it before proceeding.

Each functional spec must be unambiguous — the renderer should have only one reasonable interpretation. If a single line is not enough to fully disambiguate the behavior, use nested sub-bullets to add detail. Nested lines clarify the parent spec; they do not introduce separate functionality. Even with nested detail, the spec must still imply ≤ 200 LOC.

- :User: should be able to send a :Message: to a :Conversation:.
  - A :Message: must have non-empty content.
  - The :Message: is appended to the end of the :Conversation:.
  - All :Participant: members of the :Conversation: can see the new :Message:.

Specs must be detailed enough that a developer can use the built software without reading the generated code. All external interfaces must be explicit — REST endpoint paths and HTTP methods, CLI command names and arguments, file formats, message schemas, etc. Never leave interface details up to the renderer's discretion.

Functionality must be self-contained in the spec text. modules only import functional specs, so do not rely on implementation reqs to convey behavior — they won't be visible in downstream modules.

If any of the newly added functional specs need verification, use the skill to add acceptance tests after the batch has been inserted. Do this per spec, not as part of the bulk pass.