SpecSheriff
The method
The rules
The map
The guide
The example
Articles
The map of the specification
The rules
Working with the specification
The model
The nodes are the specification
The structure of the specification is defined by its schema
A node is one rule, and a section holds rules
A node is cited by its sid, and its id is its address
Checked means its owner confirmed its present wording
Only its owner confirms a node
An unchecked node is not implemented
Removal goes through the archive when the node was ever confirmed
A decision lives on the rule it settled
A rule and its reason are held apart
What the specification governs
The specification holds its content; the code implements it
The base specification names no technology
Of a user interface the base states what it shows, not how it looks
The base specification holds no figure of one instance
The technical appendix stands beside the base specification
The technical debt holds the problems of the default implementation set aside
The guidelines hold their base and the appendix of their tools
A project's own guidelines refine or implement the SpecSheriff guidelines
Data structures are described in the specification
A field is required only where its value is guaranteed
A data record variant exists only for a value carrying fields of its own
Each value choosing a data record variant is declared once
What the domains share is agreed in contracts
The specification is divided into domains
A part of the specification can be read alone
An entity is declared once
A domain's specification opens with its header
Every domain stands at a level
The order of the domains
Links
Outgoing links are written, incoming links are built
A link carries its type
A link may cross a domain line
Code
Code changes only as a consequence of the specification
Three records, each answering a different question
The test comes before the code
Every symbol carries a tag, and what carries no rule says so
A checked rule is implemented or exempted
The map
The map is a mindmap of the specification
The checks and the procedures
What is checked, when, and what a failure costs
The reviewer sees only the change and the nodes it names
A procedure that writes the specification is idempotent
Where an agent writes, the checks run at each of its edits
How a rule is written
The specification is written in English
A rule names its subject and states what must hold
A name is quoted where the reader must reach it, a predicate where the rule must keep binding
A reason is no narrower than the rule it holds up
A reason gives its grounds and nothing more
No count in prose
A restriction by list is chosen by which mistake would go unnoticed
A general word carries its object
No phrase or sentence is set in capitals
What no rule requires is not done
The tools
Where the files are
The commands
Setting a repository up and taking SpecSheriff out of it
Building the map
What the export, the guide and
sheriff show
write of a node
The hooks
How each check is made
The tag that binds a symbol to its rule
How a test declares the rule it verifies
Who runs the reviewer
How a confirmation is recorded
A git hook runs the SpecSheriff tools a plugin keeps on the machine
The plugin for Claude Code carries everything its work needs
The plugin for Codex CLI carries everything its work needs
The agent's hooks for Codex CLI
Where the types and runtime checks generated from the data records are written
What a data record node generates
A data record its variants refine
The type each neutral type of a field gives
SpecSheriff's own guidelines