Check
Run a read-only SPEC.md versus codebase drift audit and get severity-grouped violations before you rewrite specs or schedule build work.
Overview
Check is an agent skill most often used in Ship (also Build, Validate) that diffs SPEC.md against code and reports invariant, interface, and task violations without writing files.
Install
npx skills add https://github.com/juliusbrussee/blueprint --skill checkWhat is this skill?
- Read-only: writes nothing; user chooses whether to fix via spec or build skills
- Scoped checks: §V invariants (default), §I interfaces, §T tasks, or --all
- Invariant outcomes: HOLD, VIOLATE, UNVERIFIABLE with file:line evidence
- Interface outcomes: MATCH, DRIFT, MISSING, EXTRA compared to §I
- Task audit flags stale x rows and tracks ~ in-progress vs . pending
- Three check scopes: §V invariants, §I interfaces, §T tasks (or --all)
Adoption & trust: 5 installs on skills.sh; 1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a SPEC.md but cannot tell whether invariants, APIs, and checked-off tasks still match what is actually in the repository.
Who is it for?
Spec-driven solo builders using Blueprint SPEC.md who want periodic audits before merge or after agent-heavy sessions.
Skip if: Repos without SPEC.md, greenfield ideas with no written contract yet, or users who want the agent to auto-fix drift.
When should I use this skill?
User asks to check drift, audit the spec, verify invariants, or whether code still matches the spec (e.g. check drift, spec vs code).
What do I get? / Deliverables
You receive a severity-grouped drift report with evidence lines so you can update the spec or queue build fixes yourself—check never auto-invokes other skills.
- Drift report with HOLD/VIOLATE/UNVERIFIABLE and MATCH/DRIFT/MISSING/EXTRA classifications
- Stale task flags on §T
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Formal spec-vs-code review is the canonical shelf in Ship review, right before you merge or replan. The skill classifies HOLD/VIOLATE/UNVERIFIABLE invariants and interface drift—classic pre-ship review diagnostics with no writes.
Where it fits
After scoping §I interfaces, run check to see if prototype code already diverged from the written API surface.
Mid-sprint, audit §T task rows so stale x marks do not hide unfinished agent work.
Pre-merge, run --all to catch VIOLATE invariants and EXTRA exports not documented in SPEC.md.
Post-incident, re-check §V to confirm hotfix code did not break documented system invariants.
How it compares
Read-only spec auditor—not a linter replacement and not an autonomous fixer like a build or codegen skill.
Common Questions / FAQ
Who is check for?
Builders using juliusbrussee Blueprint with a committed SPEC.md who need evidence-backed drift detection before changing code or specs.
When should I use check?
During Ship review before release, during Build after large changes, or when you ask to check drift, audit the spec, verify §V invariants, or compare spec vs code.
Is check safe to install?
It is designed read-only, but review the Security Audits panel on this page; the agent will grep and read files across your repo during the audit.
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.