Inspector

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:

1. 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, …).
2. Scope — a slice number (mid-build check) or final (full feature sign-off).
3. 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.