spec-check
Skill2 starsChanged 33 days agoMITView on GitHub
Check a task against the project's specs before implementing it, and again before declaring it done. Produces the requirement table that the code-kit path guard requires before a lane writes code on a branch. Use at the start of any non-trivial task, or when checking code against the spec.
5 other projects use a version of this.
Adopted by
Most recently taken up by
- matthull/my-skillstheir own version, first seen Oct 20, 2026
- OHOKAYYEAH/claude-skillstheir own version, first seen Oct 13, 2026
- MelbourneDeveloper/dart_nodetheir own version, first seen Oct 9, 2026
- yisean/claude-spec-skillstheir own version, first seen Jun 15, 2026
- p-larsson/spec-orbittheir own version, first seen Jun 5, 2026
Other versions5 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 5
- MelbourneDeveloper/dart_node★ 113same name
- p-larsson/spec-orbit★ 2same name
- OHOKAYYEAH/claude-skills★ 1same name
- matthull/my-skills★ 0same name
- yisean/claude-spec-skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
The file
Files
Spec check
The project's specs are in the folder named by docs.specs in .claude/code-kit.json. The engineering principles are in docs.principles, and the plan in docs.plan. Open the config with the Read tool. A shell script that reads it works too, but one that could write to it waits for a person's approval.
Steps
- Find the section. The task should name its requirement IDs (
BOOK-4, headings in the specs) or a spec section. If it doesn't, search the specs folder for the domain nouns. Read the whole section, not just the matching lines, plus every section it references. - Read the principles. Re-read the parts of
docs.principlesthat apply: layers, ports and providers, events, testing and the rules for agents. Note this lane's layer rules fromlayersin the config. - Make a checklist. One line per requirement: behaviour, fields, error cases, permissions, states, tests.
- Compare with the code. For each line, search for where it's implemented, then read what implements it: the functions and types the requirement touches, not every file around them.
- Report as a table:
| Requirement | Status (done / partial / missing / conflicts) | Where | Note |
- In a project built as streams (the config has
streams), runnode "${CLAUDE_PLUGIN_ROOT}/bin/code-kit.mjs" promote --story <ST-n>: it lists each requirement of the story that another stream's spec already has. Don't build it again: note it in the table, and ask the lead whether it comes from core (a change request to the platform) or from that stream. - List questions for the lead wherever the spec is missing, ambiguous, or contradicts the code or another spec. Don't resolve them by guessing.
Output
The table, the questions, and a one-line recommendation: ready to implement, or blocked on questions.
Save it to .claude/state/spec-check/<branch>.md, with / in the branch name replaced by _ (for example lane_data-e2-s1.md). The table must keep its | Requirement | header. A lane can't write code on a branch until this report exists, and the lead reads it when reviewing the pull request. If the recommendation is "blocked on questions", stop and ask the lead instead of writing code.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.