Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add orenluxy/fable-method --skill prove-the-gatesgit clone --depth 1 https://github.com/orenluxy/fable-methodWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/orenluxy/fable-method/prove-the-gates)<a href="https://agentmods.dev/skills/orenluxy/fable-method/prove-the-gates"><img src="https://agentmods.dev/badge/skills/orenluxy/fable-method/prove-the-gates/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/orenluxy/fable-method/prove-the-gates"><img src="https://agentmods.dev/badge/skills/orenluxy/fable-method/prove-the-gates.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00127 | $0.01576 |
| Opus 5.5 | $0.00051 | $0.00630 |
| Sonnet 5.5 | $0.00025 | $0.00315 |
| Haiku 4.5 | $0.00013 | $0.00158 |
Grade A, and why
prove-the-gates scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 6d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 59 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Prove the Gates
Purpose: every other review verifies claims about the code. None verifies the thing doing the verifying. A check that guards a place that no longer exists is noise; a check whose rule moved without it is a hole; a check that passes because it never reaches its own assertion is worse than no check, because it is trusted. An unproven check is a promise, not a gate.
Procedure
-
Inventory every check. Test files, gate scripts, lint configs, CI steps, pre-commit hooks. For each, write down in one line: what it guards. Fix your unit first and say what it is — a file, a named check id, or an assertion give wildly different fractions, and a fraction whose unit is unstated says nothing.
-
Does that place still exist? Match each check against the current tree. A check demanding a file that moved, a selector that was renamed, a build step that went to CI — that is noise to report, not a gate.
-
Does anything actually run it? Trace every check to the command that invokes it: the test script, the push command, the CI config, the hook. A check nobody runs is not a gate, however good it is — and this is the cheapest hole to find and the easiest to miss, because the file exists and reads well. Documentation claiming a check is enforced is a claim; the invocation is the fact.
-
Prove it reddens. For each check: copy the repo to a scratch directory — include
.git, and whatever the build genuinely needs (node_modules, env files) or the run is not the real one — break exactly what that check protects there, and run the original unedited script against the copy. Mark each one proven / not proven / cannot be proven, because —. Never break anything in the working tree; confirmgit statusis unchanged when you finish, and report that. -
Break it the way the application builds it. This is where a proof goes wrong while looking right. Injecting an artificial element, a hand-written fixture or a synthetic record can satisfy a check that every real one bypasses — the check then proves itself on a case that never occurs in production. Measured: a gate filtered out every button carrying a framework-internal property, which the framework attaches to everything it renders; a hand-injected button had none, was caught, and the gate was recorded as proven while it had not caught a real one in weeks. If your broken sample took a different path into existence than the real thing, you proved nothing.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 6d ago Changed · +9 lines · +36 tokens per session 7d3ef6f02b6c
- 25d ago First seen · 50 lines · 91 tokens per session scan A 47686463a485
prove-the-gates is a skill published in the GitHub repository orenluxy/fable-method (1 stars, last pushed 7d ago), licensed MIT. It adds 127 tokens to every session and 1,576 once invoked, about $0.0005 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-19.
Other skills, from other repositories
verify
The profile-parameterized static-validation + test executor (/foundry:verify, SDLC steps 7 & 8). Resolves the ACTIVE stack profile from .foundry/stack-profile.lock (via the merged stack-profile loader's resolvelock) and dispatches the profile-declared staticvalidation (format/lint/typecheck/build) + testrecipe…
ci-speedup
Cuts the wait from push to green by measuring a pipeline's critical path from run timestamps, then splitting, sharding, trimming setup and sharing test module state, with a before/after ledger. Use when asked to "speed up CI", "CI is slow", "why does a PR take 15 minutes", "CI is the bottleneck", or when agents merge…
vibe-safe-deploy
Performs deployment with pre-flight checks, atomic replacement, post-deploy verification, provenance (proving the environment serves the exact commit you pushed), and automatic rollback. Use before any deployment to staging, preview, or production.
audit-harness
Use when auditing HARNESS.md, pre-commit hooks, pre-push hooks, architecture gates, or CI workflows for tunacode-cli. This skill treats any mismatch, skipped gate, or failing check as a critical failure and requires manual one-by-one execution rather than make targets, batch wrappers, or summary-only audits.
e2e
Orchestrates e2e testing: BDD scenarios, Playwright autotests. Triggers: e2e tests, BDD scenarios, write autotest.
ci-gates
The CI gates of vibing.nvim (test:lua exit code, E2E timeout budget, check:doc, check) and the ways each one has silently stopped failing. Use when editing package.json scripts, .github/workflows/ci.yml, scripts/check-help.lua, doc/.txt, or any tests/.test.mjs that guards a gate; when writing a new guard, meta-test…