prove-control-binds
Skill2 starsChanged 12 days agoMITView on GitHub
Use when declaring any control 'armed', 'protecting', 'green', or 'done', or when auditing one: gates (pre-commit/pre-push hooks, CI merge gates, secret scanners), timers, reapers/GC, monitors/alerts, capture hooks. Symptoms: 'the hook is installed', 'CI is green', 'the monitor shows OK', 'the reaper ran without errors', 'the gate passed' asserted without ever watching the control FIRE against a violation. Green has two indistinguishable causes: nothing to catch, or catching nothing.
In this repository29 other files it gives its agents.
- AGENTS.mdAGENTS.md
- apply-review-findingsSkill
- author-workflow-fanoutSkill
- chain-launcherSkill
- delegateSkill
- design-consultationSkill
- design-fail-closed-gateSkill
- document-releaseSkill
- gistSkill
- goal-promptSkill
- grokbotSkill
- incident-as-codeSkill
- investigateSkill
- learn-captureSkill
- office-hoursSkill
- orion-deep-researchSkill
- oss-loopSkill
- pre-compactSkill
- pre-prSkill
- prove-deploy-is-liveSkill
- readonlySkill
- reassert-guards-on-rewriteSkill
- reprobe-stale-premiseSkill
- scope-guardSkill
- shipSkill
- tdd-loopSkill
- tools-routerSkill
- triage-fanout-verdictsSkill
- xSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 20
Before reporting any gate/timer/automation "armed", "protecting", "capturing", or "done".
- Distinctive: line 22
When auditing existing controls, closing a hardening arc, or decommissioning a producer a monitor watches.
- Distinctive: line 24
NOT for authoring a new gate (that is design-fail-closed-gate) and NOT for deploy liveness (that is prove-deploy-is-live).
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Prove The Control Binds
Overview
A control is proven by watching it FIRE against a deliberate violation, never by watching it stay green. Silent no-op controls pass every casual check: the hook runs (and scans nothing), CI passes (and runs a subset), the monitor is OK (and its producer aged out), the reaper exits 0 (and selected nothing). A recorder hook that dies silently while green can lose a day of captures before anyone notices; this skill is the canary-first audit that catches that class.
When to use
- Before reporting any gate/timer/automation "armed", "protecting", "capturing", or "done".
- When auditing existing controls, closing a hardening arc, or decommissioning a producer a monitor watches.
- NOT for authoring a new gate (that is design-fail-closed-gate) and NOT for deploy liveness (that is prove-deploy-is-live); this PROVES an existing control fires.
Procedure
- Name the negative path: the exact input or state the control must block, flag, reap, or alert on. If you cannot name it, the audit cannot pass.
- Inject a canary: a synthetic violation in a sandbox or reversible form (fabricated secret assembled from fragments, synthetic drift, a fake orphan, a silenced producer, a skipped capture).
- Watch the control FIRE from its own output: blocking exit code, alert event, reap log line, BLOCKED message. Your inference that it "would have" fired does not count.
- Probe the binding seam: is the control actually in the execution path? (See the no-op shapes table.)
- Reapers/trimmers/GC: selection-model check. Run once against the KNOWN live leak and require acted-on count > 0. "Armed + green + reaped 0" over a real leak is an alibi, not remediation.
- Record the canary proof (command + output) in the arc or runbook before declaring armed.
Known silent-no-op shapes
| Shape | Mechanism |
| Shadowed hook | core.hooksPath (global) makes .git/hooks/* dead code |
| Empty pathspec | git diff -- '**' / wrong-dir pathspec silently matches nothing |
| Subset CI | required check runs a file list; new/moved tests never gate |
| Vacuous skip | importorskip / conditional skip makes the gate pass without running |
| Invisible failure | hook writes stderr + exit 0; harness shows nothing; capture silently dead |
| Aged-out monitor | Alertmanager/monitor OK while the producer stopped reporting |
| Reaper alibi | selection/liveness model spares everything; exits green having reaped 0 |
| Relative gate | gate compares candidate vs baseline only; absolute failures launder through |
Rationalizations
| Excuse | Reality |
| "It ran without errors" | So does a control that scans nothing |
| "The hook is installed and executable" | Installed is not invoked; probe the resolution path |
| "CI is green" | Green subset CI is a hermeticity hole, not protection |
| "The monitor shows OK" | OK-state persists after the producer dies |
| "I read the code; the logic is right" | The seam, not the logic, is where controls die |
| "A canary is overkill for this small gate" | The canary takes one minute; the silent no-op can cost a day of captures |
Red flags
- The word "armed" or "protected" in your report with no canary command beside it.
- An audit that only exercised the happy path.
- A reaper/trimmer declared working with acted-on count = 0.
- Declaring a monitor healthy without probing its producer.
Related
Siblings in this collection: design-fail-closed-gate (authors the gate); prove-deploy-is-live (deploy liveness). If the control was recently refactored or ported, first confirm the guard survived the rewrite before spending a canary to prove it binds.
Boundary
This is the auditing discipline, not a tool. Wire the canary in your own harness: the injection form (sandbox, reversible, or fabricated-from-fragments), the block signal you watch for (exit code, alert event, reap log line), and where you record the proof (arc note, runbook, PR) are your repo's mechanics. The discipline is invariant: name the negative path, inject it, and watch the control fire from its own output before you call it armed.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.