| name | verify-root-cause-before-claiming |
| description | Before you state the CAUSE of a failure to a stakeholder (client, teammate, ticket), verify the cause against the data, not just the symptom. A plausible but unchecked causal claim that turns out false damages trust more than saying "the exact cause I'll confirm in a moment". Trigger whenever you are about to write "the reason X happened is Y" / "it failed because" / "that's due to" in any outward-facing message, PR description, incident note, or status update. |
| metadata | {"type":"feedback"} |
verify-root-cause-before-claiming
Why: In one session I drafted a client message explaining a permission-denied
failure as "the grant landed after your run, so it wasn't there yet". The operator
asked "are we sure?" before sending. Checking the grant history showed the grant had
existed 12 minutes BEFORE the run. The real cause was different (UNLOGGED staging
tables get recreated by each schema apply, dropping their grants). My causal claim was
plausible, confident, and wrong. Had it shipped, the stakeholder would have retried on
a false premise and lost trust when it failed again.
The trap: verifying the SYMPTOM (the grant is applied now, the build is green, the
row count is N) and then asserting a CAUSE (it failed because of timing) that you never
checked against the data. The symptom is real; the causal story is a guess wearing the
symptom's credibility.
How to apply
Before any outward-facing "it failed because X" / "the reason is Y":
- Separate what you verified from what you inferred. "The grant is applied" is
verified. "It wasn't applied at run time" is an inference. Only the first earns a
flat claim.
- Pull the timeline / the history that the cause depends on. If the claim is about
timing, get the actual timestamps of both events. If it's about a missing object,
confirm the object was missing AT the moment of failure, not just now.
- Try to falsify your own cause once. Ask "what would make this explanation
wrong?" and check that specific thing. Here it was "did the grant already exist
before the run?" — one query would have caught it.
- If you cannot verify the cause, say so. "The fix is applied; the exact root cause
I'm still confirming" is honest and costs far less trust than a confident wrong
story. Ship the verified part, hedge the unverified part explicitly.
- Welcome the "are we sure?" check. When the operator or a reviewer pauses you
before an outward-facing claim, that is the cheapest possible catch. Treat it as a
gift, re-verify, do not defend the draft.
Companion skills
investigate-before-asking — investigate before escalating; this is its outward-facing twin (investigate before claiming).source-citation-tagging — every fact references where it came from; a cause with no source is a guess.incident-capture — when the verified root cause is itself worth recording.
