The method The rules The map The guide The example Articles

The rules

Working with the specification _guidelines/spec
- The model _guidelines/spec/1
  - The nodes are the specification _guidelines/spec/1.1
  - The structure of the specification is defined by its schema _guidelines/spec/1.2
  - A node is one rule, and a section holds rules _guidelines/spec/1.3
  - A node is cited by its sid, and its id is its address _guidelines/spec/1.4
  - Checked means its owner confirmed its present wording _guidelines/spec/1.5
  - Only its owner confirms a node _guidelines/spec/1.6
  - An unchecked node is not implemented _guidelines/spec/1.7
  - Removal goes through the archive when the node was ever confirmed _guidelines/spec/1.8
  - A decision lives on the rule it settled _guidelines/spec/1.9
  - A rule and its reason are held apart _guidelines/spec/1.10
  - What the specification governs _guidelines/spec/1.11
  - The specification holds its content; the code implements it _guidelines/spec/1.12
  - The base specification names no technology _guidelines/spec/1.13
  - Of a user interface the base states what it shows, not how it looks _guidelines/spec/1.14
  - The base specification holds no figure of one instance _guidelines/spec/1.15
  - The technical appendix stands beside the base specification _guidelines/spec/1.16
  - The technical debt holds the problems of the default implementation set aside _guidelines/spec/1.17
  - The guidelines hold their base and the appendix of their tools _guidelines/spec/1.18
  - A project's own guidelines refine or implement the SpecSheriff guidelines _guidelines/spec/1.19
  - Data structures are described in the specification _guidelines/spec/1.20
  - A field is required only where its value is guaranteed _guidelines/spec/1.21
  - A data record variant exists only for a value carrying fields of its own _guidelines/spec/1.22
  - Each value choosing a data record variant is declared once _guidelines/spec/1.23
  - What the domains share is agreed in contracts _guidelines/spec/1.24
  - The specification is divided into domains _guidelines/spec/1.25
  - A part of the specification can be read alone _guidelines/spec/1.26
  - An entity is declared once _guidelines/spec/1.27
  - A domain's specification opens with its header _guidelines/spec/1.28
  - Every domain stands at a level _guidelines/spec/1.29
  - The order of the domains _guidelines/spec/1.30
- Links _guidelines/spec/2
  - Outgoing links are written, incoming links are built _guidelines/spec/2.1
  - A link carries its type _guidelines/spec/2.2
  - A link may cross a domain line _guidelines/spec/2.3
- Code _guidelines/spec/3
  - Code changes only as a consequence of the specification _guidelines/spec/3.1
  - Three records, each answering a different question _guidelines/spec/3.2
  - The test comes before the code _guidelines/spec/3.3
  - Every symbol carries a tag, and what carries no rule says so _guidelines/spec/3.4
  - A checked rule is implemented or exempted _guidelines/spec/3.5
- The map _guidelines/spec/4
  - The map is a mindmap of the specification _guidelines/spec/4.1
- The checks and the procedures _guidelines/spec/5
  - What is checked, when, and what a failure costs _guidelines/spec/5.1
  - The reviewer sees only the change and the nodes it names _guidelines/spec/5.2
  - A procedure that writes the specification is idempotent _guidelines/spec/5.3
  - Where an agent writes, the checks run at each of its edits _guidelines/spec/5.4
- How a rule is written _guidelines/spec/6
  - The specification is written in English _guidelines/spec/6.1
  - A rule names its subject and states what must hold _guidelines/spec/6.2
  - A name is quoted where the reader must reach it, a predicate where the rule must keep binding _guidelines/spec/6.3
  - A reason is no narrower than the rule it holds up _guidelines/spec/6.4
  - A reason gives its grounds and nothing more _guidelines/spec/6.5
  - No count in prose _guidelines/spec/6.6
  - A restriction by list is chosen by which mistake would go unnoticed _guidelines/spec/6.7
  - A general word carries its object _guidelines/spec/6.8
  - No phrase or sentence is set in capitals _guidelines/spec/6.9
  - What no rule requires is not done _guidelines/spec/6.10
The tools _guidelines/tools
- Where the files are _guidelines/tools/1
- The commands _guidelines/tools/2
- Setting a repository up and taking SpecSheriff out of it _guidelines/tools/3
- Building the map _guidelines/tools/4
- What the export, the guide and sheriff show write of a node _guidelines/tools/5
- The hooks _guidelines/tools/6
- How each check is made _guidelines/tools/7
- The tag that binds a symbol to its rule _guidelines/tools/8
- How a test declares the rule it verifies _guidelines/tools/9
- Who runs the reviewer _guidelines/tools/10
- How a confirmation is recorded _guidelines/tools/11
- A git hook runs the SpecSheriff tools a plugin keeps on the machine _guidelines/tools/12
- The plugin for Claude Code carries everything its work needs _guidelines/tools/13
- The plugin for Codex CLI carries everything its work needs _guidelines/tools/14
- The agent's hooks for Codex CLI _guidelines/tools/15
- Where the types and runtime checks generated from the data records are written _guidelines/tools/16
- What a data record node generates _guidelines/tools/17
- A data record its variants refine _guidelines/tools/18
- The type each neutral type of a field gives _guidelines/tools/19
SpecSheriff's own guidelines _guidelines/project

No code without a ruleThe documents CC BY 4.0 · the tools Apache 2.0 · the mark under no open licence · the source