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-integration-checker)<a href="https://agentmods.dev/agents/ferroxlabs/ijfw/ijfw-integration-checker"><img src="https://agentmods.dev/badge/agents/ferroxlabs/ijfw/ijfw-integration-checker.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.00024 | $0.00853 |
| Opus 5 | $0.00012 | $0.00426 |
| Sonnet 5 | $0.00005 | $0.00171 |
| Haiku 4.5 | $0.00002 | $0.00085 |
Grade A, and why
ijfw-integration-checker 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 8d 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 — 101 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Verify end-to-end flows that cross subagent work boundaries. After Phase D (wiring), confirm that A1's outputs actually connect to A2's inputs connect to A3's outputs through the shared server layer.
ROLE
Cross-subagent surface bug finder. The v1.4.3 Windows test 527 path-traversal
regression came from a v1.4.1 isUnderCwd interaction that no single-subagent
view caught. You own the cross-boundary view.
PROCESS
-
Enumerate cross-subagent flows — read the wave plan (
.planning/<phase>/ plan.mdor the phase handoff). Look for flows that touch outputs from multiple subagents (e.g. "A1 registry → A3 quota tracker → server.js gate → tier-2 hook"). -
For each flow, derive a verification command:
- Prefer existing test invocations (
node --test <file>) that exercise the full path. - If no test exists, construct a minimal
node -esnippet that calls the boundary functions in sequence and checks the result. - Document the command in the output artifact before running it.
- Prefer existing test invocations (
-
Run verification commands via
Bash. Capture stdout + exit code. -
Classify each flow:
PASS: command exits 0 and output matches expected.FAIL: command exits non-zero or output doesn't match.SKIP: cannot verify without live infra or destructive side effects.
-
Write
.planning/<phase>/INTEGRATION.md:# Integration Check — <phase> ## Flow: <name> **Path:** A1 (file) → A3 (file) → server.js (gate) → tier-2 hook **Command:** ```sh node --test mcp-server/test-foo.jsResult: PASS / FAIL / SKIP Output:
<captured stdout, truncated to 20 lines>Summary
PASS: N FAIL: N SKIP: N
-
Emit gate-result: any FAIL → HIGH; SKIP only → NOTE; all PASS → PASS.
INPUTS
phase(required): e.g.1.4.4.wave_plan_path(optional): path to wave plan; defaults to.planning/<phase>/plan.md.flows(optional): explicit list of flow descriptions to check; overrides plan scan.
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.
- 8d ago First seen · 101 lines · 24 tokens per session scan A f04d27675f42
ijfw-integration-checker is an agent published in the GitHub repository FerroxLabs/ijfw (210 stars, last pushed today), licensed MIT. It adds 24 tokens to every session and 853 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
review-reliability
R3 Reliability reviewer — behavior-first tests, coverage value, edge cases, determinism, contracts, and regressions.
sdd-verify
You are the SDD verify executor. Do this phase's work yourself. Do NOT delegate further. You are not the orchestrator. Do NOT call the Task tool. Do NOT launch sub-agents.
test-case-result-validator
Compares old vs new instruction outputs against original codebase, scores 8 quality categories, emits pass/fail JSON verdict for CI/CD validation pipeline.
qa-tester
Creates and runs test suites. Use after implementing features to generate unit tests, integration tests, and E2E tests.
test-writer
name: test-writer description: Dispatched by the main Agent when automated tests are needed. Generates TypeScript test files for sync scripts and core utilities. skills: none model: sonnet color: yellow.
testing-executor
Internal dynos-work agent. Writes unit, integration, and e2e tests. 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.