knowledge-mcp: Skill for Claude Code

PROBE-A-GATE — proving a gate can actually catch its defect

A probe that can only say yes

A criterion reporting success is UNVERIFIED until you have shown it capable of reporting failure. Seeing green proves nothing on its own — the green may be the only answer it can give. Before trusting any gate, construct the state it is supposed to reject and confirm it goes red. The shapes differ every time: a linter handed an empty file list reports "0 issues"; a test selector matching nothing exits 0; a grep for token= is satisfied by a token with no value; an empty capture coerces to 0 in a numeric test. Each produces a confident green; the check is the same for all and costs one extra run.

Both directions, then the third input

Ask of every gate: (1) does it fail if the implementer did NOTHING? (2) does it pass against CORRECT work — including the plan's own prescribed text? A gate that greps a literal your own step mandates, pins a count your prescribed text changes, or breaks a fixture your surface touches is a scheduled false failure — the more damaging direction, because its pressure is toward corrupting correct work. Then stop reasoning and RUN it, both directions.

RED PLUS GREEN IS STILL NOT SUFFICIENT: a defective gate is often correct on exactly those two inputs and wrong on a THIRD — the plausible-but-incorrect implementation an honest engineer might write. Reach for it whenever the subject is WHICH of several sibling containers holds a value: a grep proving a token is somewhere in a region proves region membership, not the intended sub-container. Construct the wrong-but-reasonable variant and run the stored command against it. When tightening by narrowing to a sub-region, check the hazard the fix creates: a region delimited by neighbouring declarations inherits an ordering dependency nothing enforces — write the required order into the step.