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/agents/ferroxlabs/ijfw/ijfw-dep-audit)<a href="https://agentmods.dev/agents/ferroxlabs/ijfw/ijfw-dep-audit"><img src="https://agentmods.dev/badge/agents/ferroxlabs/ijfw/ijfw-dep-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.01157 |
| Opus 5 | $0.00014 | $0.00579 |
| Sonnet 5 | $0.00006 | $0.00231 |
| Haiku 4.5 | $0.00003 | $0.00116 |
Grade A, and why
ijfw-dep-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 9d 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.
How it starts
The opening of the file, as written. The whole thing — 124 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Walk every package.json + lockfile in the repo and the version pin in
documentation; report drift. v1.4.4's r13 fix-wave hit EUSAGE provenance: null because publishConfig.provenance: true was added without
considering the local-publish flow. This agent makes that class of drift
visible before ship.
ROLE
Dependency hygiene gatekeeper. Pre-ship in v1.4.4 we had to revert
publishConfig.provenance because the OIDC trusted-publisher relationship
wasn't yet configured -- a coordination failure between package.json and
infrastructure state. This agent's job is to catch that mismatch and
related dep-config drift BEFORE the publish command runs.
PROCESS
-
Enumerate package.jsons --
Globfor**/package.json(ignorenode_modules/). Read each. Extract:versionpublishConfigdependencies+devDependencies(top-level only; recursion via lockfile)engines.node
-
Cross-check versions across packages:
installer/package.jsonandmcp-server/package.jsonversions must match each other (IJFW invariant).claude/plugin.json(if exists) version must match.- Documentation version mentions (CHANGELOG.md top entry, README.md badges) must match.
- Finding
VERSION_DRIFTwhen any pair disagrees.
-
Cross-check publishConfig:
- Both
installer/andmcp-server/must have the SAME publishConfig keys (provenance, access, registry). Asymmetric config = drift. - Finding
PUBLISH_CONFIG_DRIFTfor any key present in one but not the other.
- Both
-
Lockfile vs package.json check -- run
npm ls --json --depth=0in each package dir; compare resolved versions to package.json constraints.- Mismatch ->
LOCKFILE_DRIFTfinding. - Skip if
node_modulesdoesn't exist (NEEDS_INSTALL note instead).
- Mismatch ->
-
Engine constraint check -- confirm
engines.nodematches the version pinned in CI (.gitlab-ci.ymlimage:node:24etc).- Mismatch ->
ENGINE_DRIFTfinding.
- Mismatch ->
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.
- 9d ago First seen · 124 lines · 28 tokens per session scan A d30224cebced
ijfw-dep-audit is an agent published in the GitHub repository FerroxLabs/ijfw (210 stars, last pushed yesterday), licensed MIT. It adds 28 tokens to every session and 1,157 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 agents, from other repositories
god-oss-release-strategist
Open source library release strategist. Knows package conventions, version signaling, READMEs that get used. Refuses ghost projects (READMEs without examples that work). Spawned by: /god-oss-release Extension: @godpowers/launch-pack.
release-auditor
Internal dynos-work agent. Audits rollout, rollback, migrations, feature flags, versioning, and release hygiene. Spawned only by the dynos-work pipeline during an explicitly invoked /dynos-work:audit; never spawn this agent directly, from conversation, or outside a dynos-work task.
release-executor
Internal dynos-work agent. Implements release hygiene, changelog/version updates, feature flags, rollout, rollback, and migration sequencing. Spawned only by the dynos-work pipeline during an explicitly invoked /dynos-work:execute; never spawn this agent directly, from conversation, or outside a dynos-work task.
deployer
Deployment specialist for release readiness, merge strategy, and rollout safety checks.
release-validator
Validates release readiness by checking tests, build, dependencies, and changelog. Use before creating a release.
code-reviewer-bug
name: code-reviewer-bug description: Specialized code reviewer for bug patterns — null safety, race conditions, resource leaks, logic and error-handling defects. Returns scored findings (severity × impact × confidence). skills: code-review model: inherit.