SpecSheriff

SpecSheriff — no code without a rule

SpecSheriff

No code ships without a rule that warrants it.

SpecSheriff is a method of spec-anchored development, the tools that hold a project to it, and a worked example of it. The specification is a set of small rule nodes, each with a permanent identifier, a reason held apart from the requirement, and a status that says whether the specification's owner has read the wording. Every symbol in the code names the rule it implements, every test declares the rule it verifies, and every commit is checked against the rules it claims to serve — by deterministic checks, and by an independent reviewer that sees only the change and the text of those rules.

How does it work? The life of a rule: confirmed by its owner, a test and the code carrying its sid, the commit through the checks and the reviewer; a changed wording returns it to unconfirmed.
How does it work?
What stops bad code? The gate of every commit: the deterministic checks, then the reviewer's one judgement.
What stops bad code?
Will it survive a change of stack? One base specification, a technical appendix for each stack.
Will it survive a change of stack?
How does it differ from Spec Kit? Spec-first, spec-anchored and spec-as-source, the tools placed on them.
How does it differ from Spec Kit?

Installing it

claude plugin marketplace add non4me/SpecSheriff#release
claude plugin install specsheriff@specsheriff-marketplace

The branch release holds only releases, so a machine never reads the work in progress on main. In a session, /plugin does the same. From a private fork or mirror, git must already be able to read the repository with a credential it stores, which the background updates use too; a GITHUB_TOKEN alone does nothing for them.

Install the plugin