gating
SolidBuild and audit deterministic verification gates — a check that blocks a pipeline and can be shown to go red. Use when writing a calibration gate, CI check, validation script or pre-publication check for a numeric or empirical result; when a plausible-but-wrong value would survive review; when asking whether an existing test, linter rule or check could actually fail; and when a suite passes first try, passes suspiciously often, or was written by whatever produced the thing it checks. Triggers on "can this check fail", "known-bad", "negative control", "calibration gate", "sanity check my results", "is this test actually testing anything".
Install
Quality Score: 84/100
Skill Content
Details
- Author
- oaustegard
- Repository
- oaustegard/claude-skills
- Created
- 10 months ago
- Last Updated
- today
- Language
- Python
- License
- MIT
Similar Skills
Semantically similar based on skill content — not just same category
rule-gate-integrity
Ways a gate or test proves nothing while looking decisive: grading a copy of itself, passing on emptiness, a canary firing for the wrong reason, a summary read as a verdict, a probe pointed at the wrong invocation. Load before writing a gate, a mutation harness, or any check guarding generated output.
ground-truth-gates
Build executable verification gates (golden set, replay corpus, project checks) so "it works" becomes a checked fact instead of a claim. Load when changing any LLM-judgment step (classify/extract/route/prompt), refactoring logic that processes real logged data, designing tests for a fix, setting up a commit/ship gate for a project, designing a runtime guard (a hook, validator, or auth check) and its fail direction, or when you are about to trust a passing test that has never been shown able to fail. Also the reference for what "proof gate" means in delegation-and-review packets. Do NOT load for one-off scripts or exploratory spikes — plain operational-rigor covers those.
verifiable-quality-gates
When you write, review, or rely on an automated check — a CI guard, custom lint rule, schema/config validator, or architecture fitness function: make it provably detect what it claims. Every check gets a committed test that FAILS when the check is neutralized (proven mechanically by a mutation gate), fails closed, and proves each invariant at the layer that owns it. Triggers on: adding/changing a CI check or guard, a check that 'passes' but might not be catching anything, a green build you don't fully trust, making quality gates self-proving.