Semiotic-Specification-Specification

Semiotic-specific conformance requirements for specifications. This document extends specification-specification (the general normative scaffold) with requirements specific to specifications within a semiotic universe.

This is a convention specification (per semiotic-specification §0).

Relationship to specification-specification

Per the naming convention (decision 0005):

All requirements from specification-specification (A.1-A.10) apply. This document adds semiotic-specific requirements on top.

0. Scope

This specification applies to every document that declares type: specification in its semiotic-markdown frontmatter. It extends specification-specification with requirements for integration into the semiotic universe.

1. Semiotic frontmatter requirements

Beyond A.1 (versioning), semiotic specifications MUST include:

• spec-id in frontmatter (kebab-case, matching directory name).
• stability in frontmatter (matching A.1 values).
• requires listing relative paths to specifications this one depends on.
• part-of declaring the parent specification or directory.
• type: specification in frontmatter.

2. Semiotic-markdown compliance

Semiotic specifications MUST conform to semiotic-markdown:

• YAML frontmatter with required fields per semiotic-markdown §2.
• Body in Markdown following semiotic-markdown conventions.
• Cross-references using relative paths, not wikilinks.

3. Endeavor integration

Semiotic specifications that define an endeavor aspect MUST:

• Be registered in the semiotic-endeavor’s specified aspects table.
• Be registered in the conceptual dependency map.
• Follow the lifecycle procedures in semiotic-endeavor-specification §7.

4. Naming convention compliance

Semiotic specification names MUST follow decision 0005:

• The spec-id MUST match the directory name.
• If the specification provides conformance requirements for a convention semiotic-X, the spec-id MUST be semiotic-X-specification.
• The directory MUST be placed at technology/specifications/{spec-id}/.

5. Skills and scripts

Semiotic specifications MAY include:

• skills/ directory for operational skills.
• scripts/ directory for deterministic scripts.

These MUST be registered in the skill registry at .claude/skills/registry.md.

Glossary

• Semiotic specification: a specification that conforms to both specification-specification (general scaffold) and this document (semiotic-specific requirements).
• Endeavor aspect: a specification that defines part of an endeavor’s interface.

Rationale (non-normative)

Separating the general normative scaffold (specification-specification) from semiotic-specific requirements (this document) serves two purposes:

1. The general scaffold can be reused outside semiotic contexts.
2. Agents writing semiotic specs can reference this short document instead of re-reading the full scaffold each time — the scaffold is encoded in the make-specification skill’s template.

Relationship to other specs

• Extends: specification-specification (all A.1-A.10 requirements apply).
• Requires: semiotic-specification (convention this provides conformance for), semiotic-markdown (file format).
• Promoted from: triage/engine/contracts/spec-spec/README.md (the scaffold content now lives in specification-specification).
• Parallel structure: semiotic-specification-specification is to semiotic-specification what semiotic-endeavor-specification is to semiotic-endeavor.