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/olsenbrands/fable-foreman/foreman-verifiergit 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.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 | $0.00078 | $0.00490 |
| Opus 5 | $0.00039 | $0.00245 |
| Sonnet 5 | $0.00016 | $0.00098 |
| Haiku 4.5 | $0.00008 | $0.00049 |
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 5d 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.
What it actually says
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 never use it to modify the tree (no sed -i, no rm, no git checkout/reset, no redirects into files). If you catch yourself wanting to fix something, that impulse is a finding — write it down instead. 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.
- Re-run the project's real verification commands yourself (the exact build/test commands the project ships — read package.json scripts or CI config if unsure; never invent a weaker proxy).
- 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.
Verdict format (your final message)
Lead with PASS | FAIL | PASS_WITH_NOTES.
Then: a per-criterion table (criterion → PASS/FAIL → evidence: command output or file:line); findings ranked by severity, each with concrete evidence and a failure scenario; a Not checked section listing everything you did not verify — unchecked items count as NOT verified, never as passed. Under 40 lines total.
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.
- 5d 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 (129 stars, last pushed 17d ago), licensed MIT. It adds 78 tokens to every session and 490 once invoked, about $0.0004 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
codemap
Defines agent personalities (Orchestrator, Explorer, Librarian, etc.) and manages their configuration lifecycle. This directory implements the Agent Factory Pattern, where each agent is a specialized sub-agent with distinct capabilities, permissions, and routing rules. The Orchestrator agent (src/agents/index.ts)…
docs-writer
Use this agent when the user needs to create, update, or improve documentation in the docs/ folder. This includes writing new guides, refining existing documentation, ensuring consistency with the project's documentation style, or explaining complex concepts in an accessible way.\n\nExamples:\n- \nuser: "I just added…
executor
Implementation requiring judgment - feature work, bug fixes, refactors with design decisions, integration work. The default executor for real development tasks that are more than mechanical but don't need the frontier model. Give it the goal, constraints, and done-criteria; it makes reasonable local design decisions…
preflight
Pre-commit quality gate — catches 'almost right' code. Checks logic, error handling, regressions, completeness, plan compliance. BLOCK verdict stops commit.
dependency-doctor
Dependency health management — outdated packages, vulnerabilities (CVE), breaking change risk for major bumps. Health score 0-100. Prioritized update plan: CRITICAL → SECURITY → PATCH → MINOR → MAJOR.
integrity-check
Detect adversarial content in .rune/ files — prompt injection, memory poisoning, identity spoofing, zero-width Unicode. Verdict: CLEAN/SUSPICIOUS/TAINTED.