Check
Run a read-only audit that compares your Cavekit SPEC.md to the codebase and reports invariant, interface, and task drift by severity.
Overview
check is an agent skill most often used in Ship (also Build, Operate) that read-only audits Cavekit SPEC.md against your codebase and reports invariant, interface, and task violations.
Install
npx skills add https://github.com/juliusbrussee/cavekit --skill checkWhat is this skill?
- Read-only drift detector: diffs SPEC.md against code and writes nothing
- CHECK §V invariants with HOLD / VIOLATE / UNVERIFIABLE plus file:line evidence
- CHECK §I interfaces for MATCH / DRIFT / MISSING / EXTRA surface areas
- CHECK §T tasks and flags stale completed rows lacking evidence
- Invocation scopes: §V default, §I, §T, or --all for all three sections
- Three spec sections: §V invariants, §I interfaces, §T tasks
- Default check targets §V; --all runs all three sections
Adoption & trust: 1.6k installs on skills.sh; 999 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your SPEC.md says one thing but the codebase has drifted and you are not sure which invariants or interfaces broke.
Who is it for?
Indie builders using Cavekit specs who want a spec-vs-code gate before shipping or after a burst of agent edits.
Skip if: Repos without SPEC.md, or when you want the agent to auto-apply fixes instead of a diagnostic-only report.
When should I use this skill?
User asks to check drift, audit the spec, verify invariants, or whether code still matches §V/§I/§T (e.g. “check drift”, “spec vs code”).
What do I get? / Deliverables
You receive a grouped drift report with evidence and severity classes so you can fix the spec or code deliberately without the agent mutating anything.
- Drift report with HOLD/VIOLATE/UNVERIFIABLE or MATCH/DRIFT/MISSING/EXTRA classifications
- File:line evidence citations
- STALE task flags for unchecked completions
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Spec-versus-code review is most critical before you ship or merge, when drift would violate promises to users or teammates. Canonical shelf is ship/review because the skill classifies HOLD/VIOLATE/DRIFT/MISSING/STALE evidence without writing fixes—pure review output.
Where it fits
After an agent marks T-rows complete in SPEC.md, run check §T to catch STALE tasks with no code evidence.
Before tagging a release, run --all to see VIOLATE invariants and DRIFT interfaces against §V and §I.
After a production hotfix, re-run §V to confirm operational invariants still HOLD.
When scope changed mid-build, audit §I to list MISSING or EXTRA API surfaces relative to the written contract.
How it compares
Spec contract checker with structured §V/§I/§T modes—not a linter substitute and not an auto-remediation workflow.
Common Questions / FAQ
Who is check for?
Solo builders on Cavekit who maintain SPEC.md and need evidence-backed drift detection before merging, releasing, or continuing agent-driven builds.
When should I use check?
In Ship/review before release, in Build/pm after marking tasks done, in Operate/iterate after hotfixes—whenever you ask to check drift, audit the spec, verify invariants, or compare spec vs code.
Is check safe to install?
It is designed read-only, but you should still review the Security Audits panel on this Prism page and confirm the agent only reads files and does not invoke write skills without your approval.
SKILL.md
READMESKILL.md - Check
# check — drift report Pure diagnostic. Reports violations. Writes nothing. User decides remedy. ## LOAD 1. Read `SPEC.md`. If missing → "no spec, nothing to check." Stop. 2. Parse invocation args: - `§V` → check invariants only (default) - `§I` → check interfaces - `§T` → audit task status vs code - `--all` → all three ## CHECK §V — invariants For each V<n>: 1. Translate invariant into verifiable claim about code. 2. Grep / read relevant files. 3. Classify: **HOLD** / **VIOLATE** / **UNVERIFIABLE**. 4. Record address + file:line evidence. ## CHECK §I — interfaces For each I item: 1. Locate implementation. 2. Classify: - **MATCH** — shape in code = shape in spec. - **DRIFT** — impl exists, shape differs. - **MISSING** — impl absent. - **EXTRA** — code exposes surface not in §I. ## CHECK §T — tasks For each T<n>: 1. If `x`: verify claimed work present. 2. If `~`: note as in-progress. 3. If `.`: note as pending. 4. Flag `x` rows with no evidence as **STALE**. ## REPORT Caveman. Grouped by severity. ``` ## §V drift V2 VIOLATE: auth/mw.go:47 uses `<` not `≤`. see §B.1. V5 UNVERIFIABLE: no test covers ∀ req path. ## §I drift I.api DRIFT: POST /x returns `{result}` not `{id}`. route.go:112. I.cmd MISSING: `foo bar` absent from cli/*.go. ## §T drift T3 STALE: status `x`, no middleware file exists. ## summary 2 violate. 1 missing. 1 stale. 1 unverifiable. next: spec skill with `bug:` or fix code at cited lines. ``` ## REMEDY HINTS (not actions) End report with one-line hint per class: - VIOLATE / DRIFT → invoke spec skill `bug: <V.n>` or fix code. - MISSING → invoke build skill on `§T.n` if task exists; else spec skill `amend §T`. - STALE → spec skill `amend §T` to uncheck. - EXTRA → spec skill `amend §I` to document, or delete code. Never invoke fixes. Report only. ## NON-GOALS - Zero writes. No SPEC.md edits. No code edits. - No sub-agents. Main thread reads. - No scores, no grades. Binary per item: holds or drifts.