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 a running system or prepares a bounded runtime handoff when the target is not yet reachable.
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, use the blast-radius skill for the change map, 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. If that driver is absent, report the required verification surface as a blocker instead of inventing another route. A probe that never reached the running surface is not run, never a pass.
Stop predicate. Bound execution before it starts. Open-ended live exploration needs a task- or project-supplied budget and consequence floor. Report those two limits separately, preserving supplied values and naming either one that is absent. A caller-supplied finite action list is already bounded when its invocation count and termination condition or timeout are explicit. Never treat probes you selected or their count as a task-supplied budget, invocation limit, or finite authorization; a plan cannot supply its own execution limits. If an executable run is not bounded, stop and ask for the missing limit instead of inventing one or substituting different work. A plan for an unavailable runtime may proceed, but it must say which execution limits are still absent. The budget caps the search; the consequence floor defines which effects merit continued investigation and promotion. When a loop-governance suite is installed, hand it the outer loop and keep this skill as the method that loop runs.
Keep one runtime-probes-owned record outside the tree, with one row per probe. Each row names the entry point, category, probe, status, and either its observation and evidence IDs or the reason it did not run. A completed invocation needs its own evidence ID; a count is not evidence. If writes are forbidden, keep the same facts in the reply instead of creating the file. Use the show-me-your-work skill separately for its decision log.