What problem does it solve? Domain specifications drift out of sync with code, scenarios get duplicate identifiers across branches, and rules are written without verifiable bindings. This Skill enforces a consistent structure for domain specs in docs/specs so that every rule is traceable to code and every scenario maps to a test. ## Core Features & Use Cases - Mandatory spec structure: Enforces the verbatim section headings (Зачем, Терминология, Правила, Контракт, Данные, and more) plus header lines for dependencies, laws, and procedures. - Rule-to-code binding: Maintains implementation.md tables that map each rule's exact text to a file:symbol anchor, with unbound rules moved to open questions. - Scenario discipline: Defines the SC-<PREFIX>-<NUMBER> scenario form, single-outcome Then clauses, coverage marks, and cross-branch number allocation to prevent identifier collisions. - Use Case: When editing a .proto file, update the touched domains' specs in the same branch, write scenarios first, then implement code and name tests by scenario identifiers before running npm run check:specs. ## Quick Start Ask the assistant to create a new domain spec in docs/specs following the spec-driven-domain pattern with its mandatory sections and initial scenarios.
