verification-before-completion: the skill requires fresh evidence but never asks where the evidence came from

The problem

The skill's core instruction is right and clear: no completion claims without fresh verification evidence, run the command yourself, read the full output including exit codes.

It does not say anything about the provenance of that output. Three failure modes fit inside "I ran a command and read the output" while producing a false claim. All three occurred in a single debugging session.

1. Evidence the agent produced by hand, read as evidence the system acted

A diagnostic probe was added to a hook script so it would append a timestamp every time it ran, in order to distinguish "the hook never fired" from "the hook fired and its decision was invisible".

In the same shell command that cleared the log, the probe was also exercised by piping a crafted payload directly into the script, to confirm the probe worked. That hand-run wrote an entry.

Seeing one entry, the agent reported that the hook had fired through the harness. It had not. The entry was the agent's own test, run by the agent, minutes earlier.

The command satisfied every existing rule: it was run, the output was read, the claim came after. The output was about the instrument, not the system.

2. An instrument's silence read as a negative result

The same probe later stayed empty, and that was reported as proof the hook never ran. The probe wrote to a path built from a temp-directory environment variable that the hook's own process may set differently, or not at all. The silence was uninterpretable, not negative.

This is the same underlying principle as #2261, which correctly notes that an empty grep result is not proof of absence and proposes command grep for that skill. That fix is right and specific. The general form is not captured anywhere: an empty result reports on two possibilities at once — the data is absent, or the question never got asked — and only the second is a defect the zero conceals. It applies to any instrument, not only to a shadowed grep.

3. A user's existing safety control declared broken

Off the back of those two readings, the agent told the user in bold that their own command-safety hook "is not running" and had been inert.

It was false. The guard worked. A later test that matched one of its deny patterns was blocked outright.

The evidence could not have supported the claim. It rested on the uninterpretable silence above, plus a command matching one of the guard's ask patterns running without a visible prompt — which had an obvious unexamined alternative: the environment silently auto-approves ask-decisions, so an ask and a no-op are externally identical. Only a deny is externally distinguishable, and no deny had been tested.

The cost here is asymmetric in a way the other two are not. Telling someone a working security control is broken spends their trust and invites them to rebuild something that was never damaged.

Proposed change

Three rules, all in verification-before-completion.

1. Provenance:

Before citing an artefact as evidence that a system did something, name the process that wrote it and when. If the answer is "this session, by hand, to test the instrument", it is evidence the instrument works and nothing else. Prove the instrument in one place, clear it, then let the system act — never derive both from the same command.

2. Absence:

An empty or zero result is a claim about the instrument until an independent probe shows the population is empty. Treat absence as evidence only where the instrument is known to work in the same environment the system runs in. Write diagnostics to hardcoded absolute paths, not to paths built from environment variables whose value in the target process you have not inspected. (See #2261 for the same principle in receiving-code-review.)

3. Claims about the user's own tooling:

Before reporting that a user's existing control, guard, test or backup does not work, find a case where it must produce a visible, unambiguous effect, and show that it does not. A missing expected effect is insufficient wherever the control's ordinary signal can be absorbed elsewhere in the stack — enumerate what could swallow the signal before concluding none was sent. Until that positive test exists, the honest report is "I cannot demonstrate that it fired", never "it is not running".

Notes

• Agent-agnostic. No rule depends on a harness, tool name, or shell; the worked examples are illustrative only.
• Rules 1 and 2 could reasonably live in systematic-debugging instead, since all three instances occurred mid-diagnosis rather than at a completion claim. I suggest verification-before-completion because each ended in an assertion to the user, which is that skill's moment. Happy to move them.
• Rule 3 is the one I would prioritise if only one lands.
• If useful, I can open this as a PR against dev instead.