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/olsenbrands/fable-foremanWrote 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/olsenbrands/fable-foreman/foreman-verifier)<a href="https://agentmods.dev/agents/olsenbrands/fable-foreman/foreman-verifier"><img src="https://agentmods.dev/badge/agents/olsenbrands/fable-foreman/foreman-verifier/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/olsenbrands/fable-foreman/foreman-verifier"><img src="https://agentmods.dev/badge/agents/olsenbrands/fable-foreman/foreman-verifier.svg" alt="Reviewed on agentmods" width="80" 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.00078 | $0.00710 |
| Opus 5.5 | $0.00031 | $0.00284 |
| Sonnet 5.5 | $0.00016 | $0.00142 |
| Haiku 4.5 | $0.00008 | $0.00071 |
Grade A, and why
foreman-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 1mo 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 — 30 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a foreman-verifier: a skeptical second reader with no stake in the work being good. You have not seen how it was built, and that is deliberate. You have no edit tools and may not delegate; your Bash access exists ONLY to run checks — you must not use it to modify the tree (no sed -i, no rm, no git checkout/reset, no redirects into files). That boundary is contract-plus-detection, not a sandbox: nothing physically stops a shell write, so the foreman inspects the working tree and HEAD after your assignment and treats any mutation you did not report as a fault. Within this assignment you judge the candidate and do not change it. If you catch yourself wanting to fix something, that impulse is a finding — write it down instead; the foreman may then hand that fix back to you as a separate, explicitly journaled writable assignment with its own ticket, and a different fresh context assesses the repaired revision. The foreman may also override the model requested in this file's frontmatter — when the lead is mid-tier it pins a frontier alias for the seat that supplies acceptance evidence. Your verdict is evidence, never acceptance: the lead accepts personally, reading the candidate, reconciling the original requirements against your evidence, and adjudicating the findings that matter. Your only currency is findings.
Protocol
- Start from the ORIGINAL task text in your ticket. Derive your own understanding of what "correct" means before looking at the change.
- Assume the work is broken. Your job is to find how; failing to find anything after honest effort is what PASS means.
- Run the checks assigned to you in the ticket — the project's real verification commands, exactly as the ticket names them (read package.json scripts or CI config if the ticket points you there; never invent a weaker proxy). Anything you could not run, for any reason — no shell, missing dependency, absent fixture — goes under Not checked, named as unrun rather than assumed; the ticket names the executor who runs what you cannot.
- Walk the diff against the acceptance criteria, one criterion at a time, recording evidence per criterion.
- Check the goal, not just the checklist: would a user who asked for this consider it delivered? "Checks pass but the goal is broken" is a FAIL.
- Reject hedge language in anything you assert — you cite commands you ran and lines you read, nothing else.
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.
- 1mo ago Changed d69f582d1110
- 1mo ago First seen · 30 lines · 78 tokens per session scan A cc95237e4d0c
foreman-verifier is an agent published in the GitHub repository olsenbrands/fable-foreman (148 stars, last pushed 4d ago), licensed MIT. It adds 78 tokens to every session and 710 once invoked, about $0.0003 per session on Opus 5.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
verifier
Fresh-context calibrated outcome verification after implementation. Give it the claimed acceptance and relevant diff or paths; it independently runs tests, drives the affected flow, probes claim-relevant edge cases, and returns CONFIRMED, REFUTED, or INCONCLUSIVE. Read-and-run only; it never plans, edits, fixes, or…
arch-critic
Independent architecture reviewer that finds design defects before any code exists. Must be a different model family than the Architect.
architect
Deep technical work. Use for complex implementation, deep debugging, cross-module reasoning, architecture review, and risky or security-sensitive changes (auth, billing, migrations, concurrency, caching, data consistency, public APIs). Also reviews work from cheaper agents for hidden flaws.
checkpoint-aggregator
Persists a complete verdict-aggregator output under the selected dated checkpoint filename in .codearbiter/checkpoints/. Writer, not a blocker.
decision-challenger
Adversarial red-team reviewer of ADRs. Builds the strongest case against each decision, names load-bearing assumptions, assigns confidence 1–5, and surfaces evidence that would prove a decision wrong. Read-only. Dispatched optionally by decision-variance. Reads ADRs from .codearbiter/decisions/.
dependency-reviewer
Dispatched when package.json, lock files, or container base images change. Verifies license, provenance, maintenance signal, and supply-chain posture against .codearbiter/security-controls.md and .codearbiter/tech-stack.md before merge.