verification-standard

Verification standard

This skill packages CLAUDE.md's Verification standard section for delivery via a plugin. If this project's coordinator uses the file-copy install, the project-root CLAUDE.md already carries this exact content under its own "Verification standard" heading — this skill is a second, parallel delivery path for the same rules, not a replacement. See coordinator-kit:execute-loop for where these checks plug into the per-task loop (the push gate and the task-completion gate); this skill is only about what makes a given check trustworthy.

• "Non-trivial" heuristic (governs whether a task needs an independent verifier): treat a task as non-trivial unless it's a pure config/copy/comment tweak with no logic or behavior change. When unsure, treat it as non-trivial — an extra verify pass is cheaper than a bad merge.
• Build agents must deliver high test coverage, not a happy-path smoke test.
• Anything with a browser-visible surface gets live click-through verification in a real browser: start the server, navigate, click, read the rendered page. Not curl, not reading the component source and asserting it's probably fine.
• Before any user-facing demo/playtest link goes out, a verifier must actually play the flow end-to-end (a full round, or a full journey to its completion signal) at the real URL. Connectivity and render checks pass even when the underlying content is wrong (wrong fixture, stale data, broken logic) — only actually exercising the flow catches that. If a flow can't be played end-to-end, say so explicitly instead of implying it was verified.
• Permission-gated browser APIs — push notifications via Notification.requestPermission, camera/mic, geolocation — auto-deny in automated browsers instead of showing a real dialog. A verifier must disclose that leg as unverifiable-by-automation and ask for a manual user check, not silently claim it passed because the auto-denied code path didn't error.
• Deploy/infra verification includes confirming file modes survived (e.g. executable bits on scripts — a git checkout -f can silently drop them), not just file content.
• Local zero-new-failures authorizes the push; a confirmed-green CI run closes the task (see coordinator-kit:execute-loop's push gate and task-completion gate) — local-green does not mean CI-green, since CI runners can hit failures a targeted local suite never exercises. A failed Actions run means the task is NOT done; loop back into the retry cycle the same as any other verification failure. If the project has no CI pipeline yet, the local zero-new-failures report is the task-completion gate on its own.
• Never blanket-suppress stderr on a diagnostic feeding a real conclusion. A diagnostic or investigative command (a prod-DB check, a log query) whose result will inform a real conclusion must show its errors — 2>/dev/null or equivalent swallows a real failure (e.g. a query against a nonexistent column) and produces a confident wrong answer instead of a visible one.
• If the project has a monitoring/alerting/detector surface, backtest against real history — not synthetic fixtures. Replay real data with the clock moved: output that changes only because time changed is broken regardless of thresholds. Never emit "resolved" merely because something aged out of a lookback window — name what improved. Confirm the backtest's own gating logic isn't narrower than it needs; grading itself blind is worse than none.
• Browser viewport resizing can silently no-op — and a named preset can land somewhere worse than "unchanged". A resize call can report success while changing nothing, and a named preset (desktop, mobile) has reported success while the page then measured 0x0 — so a responsive/mobile check can pass having never rendered at that viewport, or at any viewport. Set an explicit width and height instead of a preset, read window.innerWidth/ window.innerHeight back from the page afterward, and attribute every finding to the viewport actually measured, not the one requested. A check that can't confirm its own viewport reports its findings as viewport-unattributed rather than labelling them desktop or mobile.
• Verifying an email leg means reading the mail from the mail server, not from a mirror. Any file-based inbox mirror — a poller writing messages into a local file, a cached export, a notification feed — can be alive and still minutes behind, so "it isn't there" is not evidence that nothing was sent. Read the delivered message directly over read-only IMAP (SELECT the mailbox read-only, fetch with BODY.PEEK so the check can't mutate flags), and use the mirror only as a cross-check. Same rule for any verification that reads a queue or inbox through a cache instead of its source of truth: an absent item in a lagging cache is a false negative, not a finding.
• A green test run can be silently skipping tests, not just passing them. Config-gated tests (a gitignored config absent from a bare clone or fresh worktree, driving an assume/skip guard) skip rather than fail, and the run still reports success — distinct from the push gate's self-skip prohibition, which is deliberate (see coordinator-kit:execute-loop). Assert the skip count, not just pass/fail, so a suite that quietly stopped testing anything is visible.
• A column rename or drop can break database-resident views invisibly. Views live outside the repo, so nothing in a code diff or test run reveals the breakage — check any rename/drop against the database's own view definitions.