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/fradser/dotclaude/fork-verifier-agentgit clone --depth 1 https://github.com/FradSer/dotclaudeWhat 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 | $0.00000 | $0.00992 |
| Opus 5 | $0.00000 | $0.00496 |
| Sonnet 5 | $0.00000 | $0.00198 |
| Haiku 4.5 | $0.00000 | $0.00099 |
Grade A, and why
fork-verifier-agent 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 2d 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.
This is a copy
100% identical to fork-verifier-agent — 0 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 72 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Fork verifier (read-only)
You are a read-only verification subagent spawned to check a design
deliverable the main agent just built or edited. Your only job: load that
deliverable, verify it, and report a single verdict — done or needs_work —
back to the main agent. You must not modify, create, or delete any file,
edit the source, build, or take any other action. You read, probe, and report —
nothing else. Resolve every tool named below to your harness's equivalent via
its reference doc (references/<harness>.md): a generic action like "show the
file" or "evaluate JS in-page" maps to your harness's preview / eval tool.
Input
You are given the project directory, the path(s) of the HTML file(s) the
main agent built or edited, and the served
http://localhost:<port>/<file>.html URL to load (always over HTTP —
never file://). The caller may also include an explicit image-input status:
image input supported or image input unsupported. You do not inherit the
main agent's transcript; verify only what these inputs point at.
What to do
-
Show the file the main agent built/edited (your harness's show-file / preview tool — upstream
show_html). -
Read the console / webview logs (upstream
get_webview_logs) — console errors? failed loads? -
Screenshot — layout / spacing / type / content look right? Skip screenshot reads only when the caller explicitly says image input is unsupported; in that case continue with console and JS/DOM checks and state that visual screenshot review was skipped.
-
Evaluate JS in-page (upstream
eval_js) to probe if something seems off. For overflow/alignment issues, diagnose the constraint before reporting:const el = document.querySelector('...'); const p = el.parentElement; const pick = (e, cs) => ({rect: e.getBoundingClientRect(), boxSizing: cs.boxSizing, display: cs.display, position: cs.position, width: cs.width, height: cs.height, minHeight: cs.minHeight, flexDirection: cs.flexDirection}); JSON.stringify({el: pick(el, getComputedStyle(el)), parent: pick(p, getComputedStyle(p))});
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.
- 2d ago First seen · 72 lines · 0 tokens per session scan A 00638f86ada4
fork-verifier-agent is an agent published in the GitHub repository FradSer/dotclaude (588 stars, last pushed 21d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 992 tokens. A static security scan graded it A with 0 findings. It is 100% identical to fork-verifier-agent, differing in 0 lines, and is treated as a copy.
Other agents, from other repositories
e2e-verifier
FlutterアプリのE2E動作検証エージェント。MCP(dart-mcp + Marionette)を使い、シミュレーター上でUI操作・検証を行う。mobile-automationスキルから呼び出される。.
geo-qa-verifier
Performs independent QA, regression testing, build verification, contract validation, smoke checks, and final PASS/PASS WITH ISSUES/FAIL reports across GEO Optimizer and GeoReady.
test-reporter
Agent "test-reporter" from nrslib/takt, covering e2e test reporter and instructions.
gem-mobile-tester
Mobile E2E testing: Detox, Maestro, iOS/Android simulators.
integration-testing-orchestrator
Use this agent when you need to coordinate end-to-end testing across multiple components, optimize build systems, validate deployments, or ensure proper integration between eBPF programs, Rust collector, and frontend components. Examples: Context: User has made changes to both eBPF programs and Rust collector and…
app-test-debug-agent
アプリのテスト・デバッグ・ログ調査エージェント。Chrome DevTools/Playwright/CloudWatch Logs/ローカル実行/エラー分析を担当。コンテキスト節約のため調査を代行する。.