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, 1 MCP server shipped together

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.

agentmods
npx agentmods add commands/ferroxlabs/ijfw/ijfw-audit
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, 1 MCP server.

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.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.svg" alt="Measured on agentmods" 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. Scan, not verified.
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 $0.00014 $0.00318
Sonnet 5 $0.00006 $0.00127
Haiku 4.5 $0.00003 $0.00064

Measured 6d ago against content hash c9eda62ddd09, method: parsed. Prices are Anthropic first-party input rates as of 2026-09-06, 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 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.

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. 6d 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 (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.

Related

Other commands, from other repositories

sdd-verify

Validate implementation matches specs, design, and tasks.

Gentleman-Programming/gentle-ai · 9 tokens

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…

Mozurok/fhorja.dev · 205 tokens

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…

Mozurok/fhorja.dev · 216 tokens

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…

Mozurok/fhorja.dev · 202 tokens

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…

Mozurok/fhorja.dev · 190 tokens

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…

Mozurok/fhorja.dev · 227 tokens