Prove a Check Can Fail

Assess whether a green test, build, CI job, smoke check, or rehearsal supports the claim being made from it. This skill verifies the check, not the entire product. Do not edit production code or external systems to manufacture a result.

Route precisely

• Use when the user asks whether a passing check is trustworthy, when a check may have skipped its subject, or when a regression test is being offered as proof of a fix.
• Use code-review for a diff-wide defect review; it may use one bounded negative control without invoking this full workflow.
• Use monitor-ci to follow a running GitHub Actions job to completion. Use this skill afterward only if the user asks whether the green outcome actually proves a behavior.
• Do not use for a zero-result search or to write tests from scratch.

Identify the claim and signal

1. State the precise defect or condition the check claims to detect and the observable that would turn it red. If no such condition can be stated, classify the check as unproven.
2. Record the command, revision, configuration, test selection, input fixture, and environment actually used. Read back setup mutations through a path independent of the write that made them; exit status alone does not prove an edit or override applied.
3. Confirm that the target was exercised. Count named test cases or result events when filters or gates can select nothing. Treat skipped, cached, and no-op outcomes separately from an executed pass.
4. Inspect continue-on-error, warning-only reporting, shell error suppression, retry wrappers, and log parsing. Identify the assertion or artifact that still detects failure when exit status is masked.

Run a proportionate negative control

When the claim matters and the control can be isolated safely, introduce the smallest defect that the check is supposed to catch in a scratch copy or disposable test input. Predict the relevant assertion and require that assertion to fail; a compile error or unrelated failure does not count. Restore the fixed input and confirm the same targeted check passes. Preserve the working checkout, user changes, and other sessions' files.

• For a guard, weaken its decision on a fixture that reaches the guarded path. Simply deleting the guard may fail for the wrong reason.
• For a race, force the losing order; reverting a fix and hoping for a rare interleaving is not a reliable control.
• For a remote or irreversible effect, do not perturb production. Use a local simulation, existing run evidence, or report that a negative control was not performed.
• Do not run broad mutation campaigns, full suites, or costly repeated loops without task authorization. A narrow negative control is enough when it addresses the claim.

Report the evidence boundary

Return the claimed behavior, exact run identity, precondition evidence, proof that the target executed, suppressors found, negative-control result, and remaining limits. Use PROVEN_DETECTION only when the intended defect made the check fail and the fixed subject passed. Use BOUNDED_EVIDENCE when execution is confirmed but no safe negative control ran. Use UNVERIFIED when setup, execution, or failure signaling is unknown. None of these statuses proves all related behavior correct.