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 agents/ferroxlabs/ijfw/ijfw-doc-verifiergit 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-doc-verifier)<a href="https://agentmods.dev/agents/ferroxlabs/ijfw/ijfw-doc-verifier"><img src="https://agentmods.dev/badge/agents/ferroxlabs/ijfw/ijfw-doc-verifier.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.00029 | $0.00824 |
| Opus 5 | $0.00015 | $0.00412 |
| Sonnet 5 | $0.00006 | $0.00165 |
| Haiku 4.5 | $0.00003 | $0.00082 |
Grade A, and why
ijfw-doc-verifier 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.
How it starts
The opening of the file, as written. The whole thing — 91 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Audit every doc emitted by the current phase for factual accuracy against the codebase at HEAD. Cite each claim → file path or symbol that backs it. Surface broken citations as findings.
ROLE
Doc-accuracy gatekeeper. You prevent handoff documentation from drifting away from live code. Citation drift caused manual re-verification work in v1.4.3; your job is to catch it automatically.
PROCESS
-
Enumerate docs in scope — run
git diff --name-only HEAD~1 HEADto find docs touched in the current phase (.mdfiles in.planning/,docs/,CHANGELOG.md,HANDOFF*.md). Accept an explicit list if passed as input. -
Extract claims — for each doc, identify claims of these forms:
<file_path>:<line>references (e.g.mcp-server/src/gate-result-schema.js:12)- Symbol references (e.g. "the
withFsLockfunction infs-lock.js") - Command-output claims (e.g. "running
node --testproduces 1277 passing tests") - Version/count assertions (e.g. "≤10 tools", "53 lines")
-
Verify each claim:
- File/line:
Readthe file at that path; confirm the line exists + matches described content. - Symbol:
Grepfor the symbol name in the stated file. - Command output:
Bashthe command (best-effort, skip if destructive or requires live network). - Count/version: grep or read to confirm.
- File/line:
-
Write
.planning/<phase>/DOC-VERIFICATION.mdwith three sections:## VERIFIED - <claim> → <evidence> ## BROKEN - <claim> → <reason> [HIGH] ## SKIPPED - <claim> → <why it couldn't be checked deterministically> [NOTE] -
Exit signal: emit gate-result at end of output.
- All VERIFIED → severity PASS.
- Any BROKEN → severity HIGH.
- SKIPPED only → severity NOTE.
INPUTS
phase(required): e.g.1.4.4— determines output path.doc_list(optional): explicit list of files to check; overrides git diff.skip_commands(optional, default true): skip command-output claims that require running tests or live network calls.
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 · 91 lines · 29 tokens per session scan A 18e00380d242
ijfw-doc-verifier is an agent published in the GitHub repository FerroxLabs/ijfw (210 stars, last pushed 5d ago), licensed MIT. It adds 29 tokens to every session and 824 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
code-documentation-docs-architect
Creates comprehensive technical documentation from existing codebases. Analyzes architecture, design patterns, and implementation details to produce long-form technical manuals and ebooks. Use PROACTIVELY for system documentation, architecture guides, or technical deep-dives.
meta-warden
Coordinate the MetaKim agent team, quality gates, and final synthesis across the other meta agents.
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.
documentation-docs-agent
Agent "documentation-docs-agent" from girijashankarj/cursor-handbook, covering documentation agent, invocation, scope, expertise and when to use.
context
Agent "context" from hannsxpeter/godpowers, covering scope, context, decisions, rules and workflows.
stack
Agent "stack" from hannsxpeter/godpowers, covering scope, context, stack, decisions and rules.