ijfw-audit

ijfw-audit is a command for Claude Code from FerroxLabs/ijfw. It costs 28 tokens per session (636 once invoked), scanned A, original, MIT.

A command that checks whether the current or named phase of the IJFW workflow meets its audit checklist. An audit is a review against predefined requirements before moving on.

In plain words
What is it for?
Use it to audit discovery, research, planning, individual tasks, or a whole phase without advancing the workflow.
Why use it?
It catches missing requirements, unresolved execution issues, weak research, incorrect task coverage, or incomplete implementation at the relevant stage.

Command for Claude Code

Written for Claude Code: shipped in a Claude Code plugin.

Part of the ijfw plugin — 34 skills, 22 commands, 37 agents, 6 hooks shipped together

Good fit Use it to audit discovery, research, planning, individual tasks, or a whole phase without advancing the workflow.

Compare 6 commands from other repositories ↓
Install with agentmods
npx agentmods add commands/ferroxlabs/ijfw/ijfw-audit
Install

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.

Clone the repo
git clone --depth 1 https://github.com/FerroxLabs/ijfw

Made for: Claude Code.

Or install ijfw, the plugin that ships this one along with the rest of its 34 skills, 22 commands, 37 agents, 6 hooks.

Wrote 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.

agentmods badge for ijfw-audit

README.md
[![agentmods](https://agentmods.dev/badge/commands/ferroxlabs/ijfw/ijfw-audit/github.svg)](https://agentmods.dev/commands/ferroxlabs/ijfw/ijfw-audit)
Your own site
<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.

agentmods 80×15 button for ijfw-audit

Your own site · 80×15
<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>
Per session 28 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 636 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. A grade says what 26 rules found in the file — not that it is safe.
Origin original No closer match found in the catalogue.
Token cost

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.

ModelPer sessionOnce 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

Measured 1mo ago against content hash c9eda62ddd09, method: parsed. Prices are Anthropic first-party input rates as of 2026-10-07, from the pricing page.

Security

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.

claude/commands/ijfw-audit.md · 61 lines

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.

Changes

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.

  1. 1mo ago First seen · 61 lines · 28 tokens per session scan A c9eda62ddd09

Subscribe to this mod's changes

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.

Related

Other commands, from other repositories

meta-theory-verify

Run the appropriate MetaKim verification path.

KimYx0207/Meta_Kim · 8 tokens

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…

Mozurok/fhorja.dev · 0 tokens

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…

Mozurok/fhorja.dev · 103 tokens

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…

Mozurok/fhorja.dev · 108 tokens

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…

Mozurok/fhorja.dev · 0 tokens

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…

Mozurok/fhorja.dev · 0 tokens