feat(break-risk): negative-control a check you cite, not only one you write

The existing rule demands a negative control for a check the author writes. It
says nothing about a check the author cites as the reason a change is safe, and
that gap is what a 42-day CI regression rode through.

Measured in infinito-nexus-core on 2026-09-18. A sweep renamed twelve workflow
files, and its commit message claimed a lint guarded exactly that rename. The
lint's docstring promised "every workflow file named anywhere in the repository
exists". Its pattern required a directory prefix, so a bare filename was
invisible: it reported zero offenders while twenty real ones sat in the tree,
one of them a `gh workflow run` at a file that no longer existed. GitHub
resolves such a name to the deleted workflow's tombstone and answers HTTP 422,
so the scheduled release job failed on 41 consecutive runs and nobody read the
regex.

Reading the pattern instead of the prose, and watching the check fail on the
case being trusted to it, costs a minute and would have caught it on day one.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

skills/break-risk/SKILL.md

@@ -83,6 +83,10 @@ over an exposure and not creating the exposure, prefer the second and say why.
 - Negative control before claiming a check works: make the thing it should
   catch, watch it fail, restore. A check never observed failing is not known to
   work.
+- The same applies to a check you did not write. Citing an existing lint, test
+  or gate as the reason a change is safe means reading its pattern, not its
+  docstring, and watching it fail on the case you are trusting it to catch. A
+  green gate whose rule never matched your case is silence, not a pass.
 - After a context compaction, rebuild attributions from the source; conclusions
   survive compaction, the evidence under them does not.