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 FerroxLabs/ijfw --skill ijfw-verifygit clone --depth 1 https://github.com/FerroxLabs/ijfwWrote 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/ferroxlabs/ijfw/ijfw-verify)<a href="https://agentmods.dev/skills/ferroxlabs/ijfw/ijfw-verify"><img src="https://agentmods.dev/badge/skills/ferroxlabs/ijfw/ijfw-verify/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/ferroxlabs/ijfw/ijfw-verify"><img src="https://agentmods.dev/badge/skills/ferroxlabs/ijfw/ijfw-verify.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 2 findings, up to medium
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- medium Excessive Agency · line 126 Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.Fix: Add human-in-the-loop confirmation for destructive, irreversible, or high-impact operations. Never auto-execute commands that modify files, send data, or alter system state.
- medium Excessive Agency · line 129 Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.Fix: Add human-in-the-loop confirmation for destructive, irreversible, or high-impact operations. Never auto-execute commands that modify files, send data, or alter system state.
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.00083 | $0.02303 |
| Opus 5.5 | $0.00033 | $0.00921 |
| Sonnet 5.5 | $0.00017 | $0.00461 |
| Haiku 4.5 | $0.00008 | $0.00230 |
Grade A, and why
ijfw-verify scanned grade A with 1 finding 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 1mo 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
| "deployment complete" | Deployed URL + health-check (`curl -fsS <url>`) output | How it starts
The opening of the file, as written. The whole thing — 149 lines — stays where its author put it; the contents beside it link to each section on GitHub.
IJFW Verify -- The Iron Law
The Iron Law
NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.
If you haven't run the verification command in this message, you cannot claim it passes. "Earlier" doesn't count. "Should pass" doesn't count. "The code looks right" doesn't count.
Violating the letter of this rule is violating the spirit of this rule.
Why this exists
IJFW v1.4.x shipped at least four times with "done" claims that later turned out to be false: a v1.4.0 milestone declared "shipped" without verifying the GitHub mirror push had landed; v1.4.3 declared Windows CI "promoted to required" before the workflow file change had been merged; v1.4.4 had three of six parallel subagents return DONE without their checkpoints being written; and the Trident cross-audit at r13 reported PASS while one auditor (codex) was UNREACHABLE. Every one of those was an Iron-Law violation -- a claim without same-message evidence -- and every one cost a recovery wave.
This skill is the gate that catches it.
The 5-Step Gate Function
Before emitting any completion claim (verbal or structured):
- IDENTIFY -- What command, in this repo, proves the claim true?
- RUN -- Execute the FULL command via Bash tool, in the same message as the claim. Not summarised. Not paraphrased. The actual command, fresh.
- READ -- Read the full output. Check the exit code. Count failures. Do not skim.
- VERIFY -- Does the output literally confirm the claim?
- If NO: state the actual status with the evidence. Do not claim completion.
- If YES: state the claim with the output excerpted inline.
- ONLY THEN -- emit the claim.
Skip any step = lying, not verifying.
Common Failures -- claim vs required evidence
| Claim | Required evidence (same message) |
|---|---|
| "all tests pass" | Output of npm test (or the project's test command), exit 0, failure count = 0 |
| "build succeeded" | Output of the build command, exit 0 |
| "fixed the bug" | Reproduction output before + after the fix |
| "deployment complete" | Deployed URL + health-check (curl -fsS <url>) output |
| "implementation done" | Output proving the new behaviour (run the new code) |
| "no regressions" | Baseline test output + post-change test output |
| "all subagents DONE" | cat .ijfw/wave-*/subagent-*.checkpoint.json showing each checkpoint written |
| "wave complete" | node scripts/wave-status.js showing all subs DONE and commits resolved |
| "Trident r PASS" | All three auditor reports written and readable; no UNREACHABLE |
| "shipped to npm" | npm view <pkg> version returning the new version |
| "pushed to GitLab/GitHub" | git ls-remote <remote> <tag> returning the tag SHA |
| "ledger clean" | cat .ijfw/state/execute-issues.json showing zero unresolved entries |
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.
- 1mo ago First seen · 149 lines · 83 tokens per session scan A 6a2860dc2d1b
ijfw-verify is a skill published in the GitHub repository FerroxLabs/ijfw (214 stars, last pushed 2d ago), licensed MIT. It adds 83 tokens to every session and 2,303 once invoked, about $0.0003 per session on Opus 5.5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-05.
Other skills, from other repositories
verification-before-completion
A checklist for verifying work before claiming that it is finished, fixed, built, tested, or ready to submit. It requires fresh command output and evidence for each claim.
writing-skills
A guide for creating and testing reusable instructions for AI agents, called skills. It applies test-driven development, or TDD—the practice of writing tests before implementation—to instruction documents.
test-driven-development
Test-driven development, or TDD, is a way to build software by writing a test that fails, adding the smallest code that makes it pass, and then cleaning up the code. These instructions require that process for features, bug fixes, refactors, and behavior changes.
gentle-ai-bench
Trigger: bench, journey, journeys, driven mode, gentle-ai-bench, journey corpus, j-numbers, bench axis. Author and verify gentle-ai bench journeys; go test ./bench never proves driven execution.
go-testing
Trigger: Go tests, go test coverage, Bubbletea teatest, golden files. Apply focused Go testing patterns.
coverage
Compute code coverage for active track or module. Targets 95%+ coverage with report and justification for uncovered lines. Complements TDD workflow.