A project's own guidelines refine or implement the SpecSheriff guidelines
The guidelines are the SpecSheriff guidelines and a part each project holds as its own: the base of the SpecSheriff guidelines, which every project shares, with the appendix of the toolset the project uses; and the project's own guidelines, which hold what only its specification needs, such as the specification's owner or the list of levels its domains stand at. Each rule of a project's own guidelines refines or implements a rule of the SpecSheriff guidelines and never contradicts it. A project holds no copy of the SpecSheriff guidelines: they come whole with the skills that apply them and are updated with them, and are changed only where they are written.
The SpecSheriff guidelines, shared by every project, are what lets a tool, a skill or a reader carry from one project to the next, and a project needs what they cannot foresee. Refining or implementing the SpecSheriff guidelines and never contradicting them, a project's own rules extend them as the technical appendix extends the base, so that a rule of the SpecSheriff guidelines can be relied on in every project without reading that project's own.
Coming whole with the skills, the SpecSheriff guidelines read the same in every project working by one release, and stand confirmed there as they were confirmed where they are written; a copy changed in one project would be a second version nobody who writes them reads.
The links it makes
The links made to it
- cites ← Checked means its owner confirmed its present wording
- cites ← Of a user interface the base states what it shows, not how it looks
- cites ← Each value choosing a data record variant is declared once
- cites ← Every domain stands at a level
- cites ← Outgoing links are written, incoming links are built
- cites ← A checked rule is implemented or exempted
- implements ← What is checked, when, and what a failure costs
- cites ← The specification is written in English
- implements ← The plugin for Claude Code carries everything its work needs
- implements ← The plugin for Codex CLI carries everything its work needs
The decisions taken on it
- Problem
Rules only one project's specification needed stood in the guidelines every project would share.
- Ruling
The owner: the SpecSheriff guidelines hold what every project shares; a project holds what only its specification needs as rules of its own, standing to them as the technical appendix stands to the base.
- Problem
The SpecSheriff guidelines were to name owners of their own, as a domain does, so that the confirmations they carried into a project would hold there under signatures that project's owner never gave.
- Ruling
The owner: the SpecSheriff guidelines are no domain and have no owners in a project; a project takes them whole, at a version its specification's owner names, their confirmations stay where they are written, and the checks compare them to that version.
- Problem
The part of the guidelines every project takes whole was named the core, a general word that does not say of what.
- Ruling
The owner: it is named the SpecSheriff guidelines.
- Problem
Whether a project names the version of the checks it runs, taking the tools of that version from the repository the SpecSheriff guidelines are written in into a cache on the machine, or the plugin, which Claude Code updates on each machine, carries the tools.
- Ruling
The owner: the plugin is a package holding everything its work needs, and every release reaches every machine through the marketplace's update; a machine not yet updated is its user's matter, and a team's CI is its own and left out of the design.
- Problem
Whether a project's own guidelines may hold rules tied to no rule of the SpecSheriff guidelines, provided they contradict none.
- Ruling
The owner: every rule of a project's own guidelines refines or implements a rule of the SpecSheriff guidelines. The link is what lets a reader judge that it contradicts none, which no check can decide, and a rule on keeping the specification that finds no parent there is most likely a rule of the product.
- Problem
The rule let a project's own guidelines hold a kind of node of its own, while the schema every project reads admits only the kinds it defines.
- Ruling
Following the owner's ruling on §s-rah8b37kytb682y: the kinds of node are those the schema defines (§s-eferktypcj7njt5), the same in every project.
The tests bound to it
- skills/tools/test/unit/reindex.test.ts · s-bsya3febm6u64ab leaves the status of the SpecSheriff guidelines a project takes as it stands, and judges it where they are written