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 agentmods add commands/ferroxlabs/ijfw/ijfw-auditgit 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.svg" alt="Measured on agentmods" 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 | $0.00014 | $0.00318 |
| Sonnet 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 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.
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.
- 6d ago First seen · 61 lines · 28 tokens per session scan A c9eda62ddd09
ijfw-audit is a command published in the GitHub repository FerroxLabs/ijfw (210 stars, last pushed 6d ago), licensed MIT. It adds 28 tokens to every session and 636 once invoked, about $0.0001 per session on Opus 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
sdd-verify
Validate implementation matches specs, design, and tasks.
ai-feature-eval-harness
Design an evaluation plan for a product AI feature (LLM- or model-backed output): measurable success criteria, a held-out labeled eval dataset shape, per-criterion grading (code-based first, then LLM-based for nuanced judgment), and a pass threshold, then persist as AIEVALPLAN.md. Use when the task ships or changes a…
api-runtime-verify
Verify an implemented backend HTTP surface at runtime: per route, record the request actually made, the HTTP status, the response content-type, and the observed body shape, assert each response against the slice's acceptance behavior, classify the findings, and decide a PASS/FAIL/BLOCKED runtime gate. The probe's real…
implement-approved-slice
Implement only the approved slice with minimal, explicit, review-friendly changes, then persist execution evidence in slice notes and TASKSTATE.md. The single official execution path of the workflow. Supports an opt-in test-first (TDD) mode, enabled per slice or via --tdd, that writes the failing test before the code…
implement-fleet
Orchestrator-workers variant of implement-approved-slice that executes independent approved slices in parallel. Reads per-slice Scope and Depends-on from IMPLEMENTATIONPLAN.md, builds the slice DAG, computes parallelizable waves (ready slices whose file scopes are pairwise disjoint with no shared migration, lockfile…
app-runtime-verify
Verify a built mobile or app runtime at runtime: run the app (device, emulator, or headless), read the captured runtime output (native logcat, iOS device log, or the Metro/JS console), classify any runtime errors against a per-stack taxonomy, and decide a PASS/FAIL runtime gate for the slice's acceptance behavior. The…