runtime-probes
Runtime probes
The twin of the spec-probes skill on the other side of the code. That one probes a requirement before anything runs. This one probes the running system after. Reach for it when nothing has been reported and the job is to find out what is wrong.
Two failure modes shape the design. An unbounded probe run burns budget and returns noise. A promoted finding no caller can reach wastes a maintainer's day. Pass 1 bounds the search. Pass 2 bounds what escapes it.
Before either pass
Name the scope, the surface, and the stop predicate, in that order.
Scope. A PR diff, one feature, or a whole product. For a diff, take the change map from the blast-radius skill and probe what it names rather than re-deriving it.
Surface. Probes run against the real thing through the project's verify-<app> driver, which the create-verification-skill skill builds when the project has none. A probe that never reached the running surface is not run, never a pass.
Stop predicate. A budget and a floor, both written down before the first probe. "Two hours or four hundred probes, whichever comes first, and never fewer than ten probes per entry point" is the shape. The budget ends a run that is finding nothing. The floor stops a run ending early because it got lucky on probe three. When a loop-governance suite is installed, hand it the outer loop and keep this skill as the method that loop runs; otherwise this predicate bounds the run.
Open a findings.tsv through the show-me-your-work skill, one row per probe: id, entry point, category, probe, observed, reproduces, state, reason. A probe that produced no finding is pass, not run, or unclassified. Otherwise the row carries that finding's state from Pass 2. reason carries the dismissal reason, the guard name on a gap, or the open question on an escalation. Keep it out of the tree so it survives reverts.