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.
git 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/commands/ferroxlabs/ijfw/ijfw-audit)<a href="https://agentmods.dev/commands/ferroxlabs/ijfw/ijfw-audit"><img src="https://agentmods.dev/badge/commands/ferroxlabs/ijfw/ijfw-audit/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/commands/ferroxlabs/ijfw/ijfw-audit"><img src="https://agentmods.dev/badge/commands/ferroxlabs/ijfw/ijfw-audit.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.00028 | $0.00636 |
| Opus 5.5 | $0.00011 | $0.00254 |
| Sonnet 5.5 | $0.00006 | $0.00127 |
| Haiku 4.5 | $0.00003 | $0.00064 |
Grade A, and why
ijfw-audit 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 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.
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.
What it actually says
Run the audit gate for the current (or named) phase of the active IJFW workflow. Every IJFW workflow phase has a built-in audit checklist -- this command fires it explicitly without advancing to the next phase.
Ledger gate (Damir Law 4 scope -- run before any gate): Read .ijfw/state/execute-issues.json at the start of every audit run:
read_issues() {
local f=".ijfw/state/execute-issues.json"
[ -f "$f" ] || { printf '{"issues":[]}'; return; }
cat "$f"
}
If any entry has status: unresolved, halt with the list before running any phase gate:
ISSUE: unresolved-execute-issues
count: <N>
ids: [iss_001]
action: resolve with /ijfw-execute resolve <id> <note> first
Missing file = zero issues (day-1 fresh-install protection). Do not crash.
Phase audit gates available:
- DISCOVER AUDIT -- scope boundaries, success criteria, no hidden assumptions
- RESEARCH AUDIT -- findings validated, red flags surfaced, brief updated if needed
- PLAN AUDIT -- every requirement has a task, no scope drops, dependencies ordered
- TASK MICRO-AUDIT -- per-task: success criteria met, nothing outside scope changed
- PHASE AUDIT -- all phase tasks complete, brief still accurate, memory updated
- SHIP GATE -- original brief re-read, what was built matches what was asked
Run the gate, fix any failures, then continue. IJFW tracks gate outcomes in
audit-log.md for the active project.
Natural triggers: "audit this phase", "run the gate", "check before we move on", "audit checkpoint", "gate check."
If you name a phase explicitly (e.g. /ijfw-audit plan), that gate runs regardless
of the current workflow position. Omit the argument and the current phase gate runs.
GATE: Each audit gate is a hard stop -- fix failures before the next phase
begins. Gate outcomes are recorded in audit-log.md for the active project.
Confidence declaration (required per finding): Every audit finding is tagged VERIFIED / LIKELY / GUESSING / ISSUE:
- VERIFIED -- command run, raw output shown, reproducible.
- LIKELY -- code read, docs consulted, reasoning given, not externally verified.
- GUESSING -- insufficient information, best guess only.
- ISSUE -- blocker or bug; document and halt.
Gate outcomes with any GUESSING or ISSUE finding do not auto-advance. This is the scoped adoption of Damir Zorcic's "Declare Confidence" law at audit boundaries.
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 · 61 lines · 28 tokens per session scan A c9eda62ddd09
ijfw-audit is a command published in the GitHub repository FerroxLabs/ijfw (214 stars, last pushed 2d ago), licensed MIT. It adds 28 tokens to every session and 636 once invoked, about $0.0001 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-08-30.
Other commands, from other repositories
meta-theory-verify
Run the appropriate MetaKim verification path.
ai-feature-eval-harness
Design an eval plan for a product AI feature: success criteria, a held-out labeled dataset, per-criterion grading (code-based, then LLM-based), and a pass threshold. Use when a task ships or changes a feature with non-deterministic model output (classification, extraction, summarization, ranking, agent action) needing…
implement-approved-slice
Implement only the approved slice with minimal changes, then persist execution evidence in slice notes and TASKSTATE.md. The official execution path. Opt-in test-first mode via --tdd. Use when the plan and slice are approved, ambiguity is resolved and files in scope are known. Do not use during discovery or planning…
implement-fleet
Orchestrator-workers variant of implement-approved-slice that runs independent approved slices in parallel, one worktree-isolated worker per slice per wave, merged after each wave. Use when the active task has an approved multi-slice plan whose Execution waves show at least one wave of size 2 or more. Do not use when…
api-runtime-verify
Verify a built backend HTTP surface at runtime: per route, record the response, assert it against the slice's acceptance behavior, and decide PASS/FAIL/BLOCKED. Do not use to review a contract before implementation (use api-contract-review or graphql-contract-review), write code (use implement-approved-slice), triage…
app-runtime-verify
Verify a mobile or app runtime: run the app (device, emulator, or headless), read captured output (logcat, iOS device log, or Metro/JS console), classify errors per stack, and decide a PASS/FAIL gate. Adapters: React Native/Expo, Unity mobile. Do not use to plan a screen (use implementation-plan), to write or fix code…