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 skills add hams-ollo/zen-agent-skills --skill verifier-agentgit clone --depth 1 https://github.com/hams-ollo/zen-agent-skillsWrote 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/skills/hams-ollo/zen-agent-skills/verifier-agent)<a href="https://agentmods.dev/skills/hams-ollo/zen-agent-skills/verifier-agent"><img src="https://agentmods.dev/badge/skills/hams-ollo/zen-agent-skills/verifier-agent/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/skills/hams-ollo/zen-agent-skills/verifier-agent"><img src="https://agentmods.dev/badge/skills/hams-ollo/zen-agent-skills/verifier-agent.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.00166 | $0.02930 |
| Opus 5 | $0.00083 | $0.01465 |
| Sonnet 5 | $0.00033 | $0.00586 |
| Haiku 4.5 | $0.00017 | $0.00293 |
Grade A, and why
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 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.
How it starts
The opening of the file, as written. The whole thing — 229 lines — stays where its author put it; the contents beside it link to each section on GitHub.
verifier-agent
Turn "it works" into a record. This is the independent verification stage of the contract-driven
spine: it runs immediately before reconcile-worktrees, and its
verdict is what the decision to land should rest on.
Three signals already exist separately and none of them answers the landing question alone. A
command result proves the suite runs but not that the behavior matches the contract.
spec-conformance audits code against a spec but is explicitly
independent of test pass/fail, so a clean matrix says nothing about whether anything was executed. A
task's acceptance criteria state what done means but nothing records that they were checked.
verifier-agent combines all three into one deterministic verdict with the evidence attached.
It composes spec-conformance by reference for the contract half and
does not restate or re-derive its matrix. It formalizes the verification pass that
fix-batch requires but leaves to the agent running it, so depth and
evidence stop varying between runs.
Independence is the point. Where the harness allows the separation, the agent that verifies should not be the agent that wrote the implementation. Self-verification is the failure mode this skill exists to remove.
When to use
- An implementation is finished and about to be reconciled, merged, or handed back as done.
- A worktree agent reports success and that claim needs independent evidence before it is trusted.
- A task's acceptance criteria need to be checked against what the code and commands actually do.
When not to use
- You only need the spec-vs-code audit by inspection, with no commands run and no verdict: use
spec-conformancedirectly. - You need tests to exist before anything can be verified: use
test-authorfirst. - You want an opinion on code quality, design, or style: use
house-review. - You are deciding whether a spec plus its plan are ready to implement: that is
spec-plan-readiness, which gates the front of the spine, not the back.
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 Changed · +5 lines e5623d65cf34
- 9d ago First seen · 224 lines · 166 tokens per session scan A a1cdc72c30e4
verifier-agent is a skill published in the GitHub repository hams-ollo/zen-agent-skills (2 stars, last pushed 7d ago), licensed MIT. It adds 166 tokens to every session and 2,930 once invoked, about $0.0008 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-31.
Other skills, from other repositories
implementation-standards
Reference material with coding standards (defensive coding, error handling, testing patterns). Loaded on demand by the Developer sub-agent (.github/agents/developer.md); not directly invokable.
clarification-strategies
Reference material with ambiguity-audit patterns and critique strategies for requirements. Loaded on demand by clarify-spec; not directly invokable.
gauntlet-proof-audit
Use to audit the gauntlet records, "are the ROUNDS.md records honest", "verify the proof corpus", "check each run record against its evidence", "audit the gauntlet corpus", "is the gauntlet proof trustworthy", or a scheduled gauntlet-proof-audit cadence run. Enumerates every committed gauntlet run record…
ai-feature-eval-harness
Design an evaluation plan for a product AI feature (LLM- or model-backed output): measurable success criteria, a held-out labeled eval dataset shape, per-criterion grading (code-based first, then LLM-based for nuanced judgment), and a pass threshold, then persist as AIEVALPLAN.md. Use when the task ships or changes a…
rig-task
Implement one unit of work end-to-end — from a tracker issue OR an ad-hoc description: spec review, TDD (RED→GREEN→REFACTOR), pre-PR self-review, open a PR, then drive the review-bot loop to clean. Runs start→finish in one shot by default; start/finish are optional phases for pause/resume. Sibling to /rig-epic (one…
api-runtime-verify
Verify an implemented backend HTTP surface at runtime: per route, record the request actually made, the HTTP status, the response content-type, and the observed body shape, assert each response against the slice's acceptance behavior, classify the findings, and decide a PASS/FAIL/BLOCKED runtime gate. The probe's real…