Runtime Verification Discipline

Internal shared skill. Single source of truth for how verification gets executed in PDCA workflows: the AI runs verification itself, in the right environment, and only hands to a human at a genuine hard boundary. Hosts declare it in dependencies and abort if missing — no silent fallback.

This is the rule layer. It decides where verification runs, who runs it, and whether it is sufficient. It does not contain environment-driving recipes (channel selection, CDP calls) — those live in capability skills such as browser-debug-toolkit. Concrete examples and per-host integration snippets are in reference.md.

Why this skill exists

Workflows used to treat verification as "AI runs Bash test commands; everything else is handed to the user as a checklist." That posture wastes the AI's ability to drive real and simulated environments, and it turns "hand to the user" into an unexamined default — sometimes used because the AI did not try, not because it genuinely could not. The result is avoidable manual verification labor and, worse, occasional false confidence when a low-fidelity check is reported as if it were conclusive.

The meta-lesson this skill enforces:

Verification is the AI's job, done in an environment. Prefer the highest-fidelity environment the AI can drive safely and deterministically; hand to a human only at a true hard boundary, and say exactly why.

When this applies

At any workflow's verify/check stage, for any change with observable behavior — bug fix or feature development alike. If nothing about the change can be exercised in any environment, this skill does not apply (a pure docs/comment change may need no runtime verification).

Iron law