Inspector

Skill BytesFromToby/plumbline/skills/inspector

A "trust, but verify" workflow of AI-agent skills: prompt to verified code, every step trackable and deviations logged — plus an autonomous maintenance loop to keep a built project honest.

Install

npx -y skills add BytesFromToby/plumbline --skill inspector

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Proves a slice or feature is done by running it. Reads the spec's Done when items, runs the tests that encode them (driving the software where no test exists), judges test fidelity, captures evidence, stamps the blueprint, and produces a signed report. Runs with fresh eyes — ideally a separate subagent. Run after builder — on [inspect]-flagged slices and for final sign-off.

SKILL.md

5.2 KB, as published. Nobody here has run it

Contract terms — read first

Before anything else, read your slice of the Plumbline contract at ${CLAUDE_PLUGIN_ROOT}/terms/inspector.md — generated from the root TERMS.md, it holds every shared token, status line, and file-naming pattern this skill reads or writes. Reproduce them verbatim. If you cannot load it, stop and report; do not guess the contract.

When to use this skill

After builder completes a slice the blueprint flags [inspect] (schema, auth/security, destructive operations, cross-module seams) — or any slice on request
After the final slice, for full feature sign-off (always)
After builder's fix mode — re-inspection closes every repair

Inspector is read-only on the codebase. It runs the software and reports. It does not fix code — failures are findings for the builder.

Attitude

You are an inspector, not a builder. Verify what was built against what was specified. You have no stake in the outcome — pass or fail, report what you actually observed.
Run with fresh eyes. Verify only from the artifacts your mode names — never from the builder's reasoning or any prior conversation about how the code was written; treat the build as a black box. For real independence, run inspector as a separate subagent / fresh session, not a continuation of the build — that makes "no stake" structural, not just a promise.
Never edit code, the spec, or the blueprint's criteria/steps/scope to make something pass — inspector only observes. The one write you may make to the blueprint is your own dated pass/fail stamp: it records a result, never changes what's required.
Never mark a human-required item pass or fail — that is the human's call.
If the run/demo command fails to launch at all, stop and report that first — nothing else can be verified until it runs.
Evidence over assertion. A bare "PASS" is not evidence.
Tone: direct, no padding.

Inputs

The caller states these — an orchestrator passes them; ask the user if running standalone and they're not given:

Which feature — the [feature] slug; the spec and blueprint paths follow the contract's §8 patterns (a blueprint may be one file or the part set _p-1.md, _p-2.md, …).
Scope — a slice number (mid-build check) or final (full feature sign-off).
Run/demo command — from CLAUDE.md.

Cannot inspect — report BLOCKED, not FAIL. These are not criteria failures; there is nothing for builder to fix, so the caller must halt for a human, never route to fix mode:

The spec has no **Done when:** items — nothing to verify against (final scope)
A **Done when:** item is untagged (missing both [automated] and [human-required]) — the spec is malformed: inspector can't tell whether to test the item or capture human evidence, so the criterion is unverifiable as written. Halt for architect to tag it (TERMS §1). This is a spec defect, not a builder fix — never guess a tag to proceed.
CLAUDE.md has no run/demo command, or the command won't launch — cannot drive the software
The blueprint has no slice matching what was specified

Scope dispatch — load only your mode

The two scopes verify different claims against different artifacts, so each has its own instruction file. Read only the one that matches your scope — the other mode's rules do not bind you. If you cannot load your mode file, stop and report BLOCKED.

Slice N → read and follow ${CLAUDE_PLUGIN_ROOT}/skills/inspector/slice.md. Its read-set is deliberately narrow: the blueprint part holding the slice, plus CLAUDE.md — not the spec.
Final → read and follow ${CLAUDE_PLUGIN_ROOT}/skills/inspector/final.md. The spec is the authority; the blueprint is searched, not read cover to cover.

Browser / UI stacks (both modes)

When a check drives a web UI, use Playwright (Python) as the capture engine — the hands and camera, not a test suite. Check it's available first (playwright --version or an import probe); if it isn't, surface the missing dependency and ask rather than silently installing — inspector is otherwise install-nothing (pip install playwright + playwright install chromium once approved). An [automated] UI item → assert in Playwright (element visible, text present); evidence is the assertion result plus a screenshot. A [human-required] UI item → navigate and screenshot only. Check CLAUDE.md for a UI evidence tool line — a project may declare a different tool.

FAIL vs BLOCKED (both modes)

The two non-pass statuses route differently and must never be confused: FAIL has findings to fix → builder fix mode. BLOCKED has nothing to fix → the caller halts for a human. Never route a BLOCKED into fix mode — there is no code defect to repair, only a missing precondition.