PluginBench
Skill
Pass
Audit score 90

check

juliusbrussee/cavekit

Read-only drift detector that diffs SPEC.md against code and reports violations without making changes.

What is check?

check is a diagnostic skill that compares your SPEC.md specification against the current codebase to detect drift. It reads invariants (§V), interfaces (§I), and task status (§T), classifies violations by severity, and suggests remedies—but never modifies code or spec. Run it after builds and before shipping to catch specification mismatches early.

  • Parses SPEC.md and translates invariants into verifiable code claims
  • Checks interface shapes in code against spec definitions
  • Audits task completion status vs actual implementation
  • Classifies findings as HOLD, VIOLATE, DRIFT, MISSING, EXTRA, STALE, or UNVERIFIABLE
  • Groups violations by severity with file:line evidence
  • Suggests remedies (spec edits, build tasks, code fixes) without invoking them

How to install check

npx skills add https://github.com/juliusbrussee/cavekit --skill check
Prerequisites
  • SPEC.md file in the project root with §V (invariants), §I (interfaces), and §T (tasks) sections
Claude Code
Cursor
Windsurf
Cline

How to use check

  1. 1.Run `check` to audit all sections (§V, §I, §T)
  2. 2.Run `check §V` to check invariants only
  3. 3.Run `check §I` to check interfaces only
  4. 4.Run `check §T` to audit task status
  5. 5.Review the grouped report and severity summary
  6. 6.Use suggested remedies (spec skill, build skill, or manual fixes) to resolve violations

Use cases

Good for
  • Verify code still matches spec after a build or refactor
  • Audit interface definitions before shipping to catch breaking changes
  • Check invariant compliance to catch silent specification drift
  • Review task completion status to find stale or incomplete work
  • Detect undocumented code (EXTRA) that should be added to spec
Who it's for
  • Specification-driven development teams
  • Code reviewers checking spec compliance
  • Release managers verifying invariants before ship
  • Developers maintaining long-lived projects with formal specs

check FAQ

Does check modify SPEC.md or code?

No. check is read-only. It reports violations and suggests remedies but never invokes fixes or edits files.

When should I run check?

After each `/build` and before shipping. Early detection of drift is cheaper than catching it in production.

What does STALE mean?

A task marked complete (x) in §T but with no evidence in the code—the spec claim is outdated.

What's the difference between DRIFT and MISSING?

DRIFT: implementation exists but shape differs from spec. MISSING: implementation is absent entirely.

Can check run sub-agents to fix violations?

No. check only reports. You decide whether to invoke spec skill, build skill, or fix code manually.

Full instructions (SKILL.md)

Source of truth, from juliusbrussee/cavekit.


name: check description: | Read-only drift detector. Diffs SPEC.md against current code and reports violations grouped by severity. Writes nothing — suggests remedies via the spec or build skills but never invokes them. Triggers when the user asks to check drift, audit the spec, verify invariants, or ask whether code still matches the spec. Phrasings: "check drift", "audit the spec", "does the code still match §V", "check invariants", "spec vs code".

check — drift report

Pure diagnostic. Reports violations. Writes nothing. User decides remedy.

Spec drifting silently from code is the #1 SDD failure mode. check is the detector. Run it after each /build and before each ship — drift caught here is a diff; drift caught in prod is a §B.

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.