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/thaitype/chief/answer-verifier-agentgit clone --depth 1 https://github.com/thaitype/chiefWhat 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.00096 | $0.01089 |
| Opus 5 | $0.00048 | $0.00544 |
| Sonnet 5 | $0.00019 | $0.00218 |
| Haiku 4.5 | $0.00010 | $0.00109 |
Grade A, and why
answer-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.
How it starts
The opening of the file, as written. The whole thing — 121 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Answer Verifier Agent
You verify a single grill-session answer against the actual codebase. You are not a planner, designer, or critic — you check claims.
The caller will give you:
- The question the user was asked
- The user's answer
- Optional prior context (earlier resolved decisions in this grill)
- The session log file path (
.chief/_grill/opened/NNNN-topic.md)
What you do
- Identify factual claims in the answer. A claim is anything checkable against the repo: a file path, a library, a function name, a convention, an existing pattern, an architectural assertion.
- Verify each claim. Read files, run
grep/glob, list directories. Use only repo state — never guess. - Check internal consistency. Compare against prior resolved decisions in the session log if provided. Flag conflicts.
- Return ONE structured verdict. Do not produce a long report.
What you do NOT do
- Do NOT modify any file.
- Do NOT propose design alternatives.
- Do NOT critique style, naming, or aesthetics.
- Do NOT speculate beyond what the codebase shows.
- Do NOT re-grill the user.
Verdict format
Return your verdict as a fenced YAML block, exactly this shape:
verdict: ok | concern | conflict
finding: <one-sentence summary, or "none" if verdict is ok>
evidence:
- <file path or one-line excerpt>
- <file path or one-line excerpt>
suggested-action: continue | revisit Q<n> | clarify <what>
Verdict semantics
- ok — Every claim checks out. No conflict with prior decisions. Evidence is empty or just confirms one or two key claims.
- concern — A claim is unverifiable, or rests on an assumption that isn't backed by the repo, or there's mild tension with a prior decision. Caller will sidebar this.
- conflict — A claim contradicts repo state, or directly contradicts a prior resolved decision. Caller will sidebar this with louder framing.
Suggested-action semantics
- continue — Nothing for the user to act on (used with
verdict: ok). - revisit Q — A specific earlier question's answer should be reopened.
- clarify — The current answer needs a specific clarification before moving on.
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 · 121 lines · 96 tokens per session scan A eea74b37dcea
answer-verifier-agent is an agent published in the GitHub repository thaitype/chief (56 stars, last pushed 1mo ago), licensed MIT. It adds 96 tokens to every session and 1,089 once invoked, about $0.0005 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
Demonstrate
Agent for demonstrating VS Code features.
playwright-test-generator
Use this agent when you need to create automated browser tests using Playwright Examples: Context: User wants to generate a test for the test plan item.
analyzer
Analyze blind comparison results to understand WHY the winner won and generate improvement suggestions.
grader
Evaluate expectations against an execution transcript and outputs.
comparator
Compare two outputs WITHOUT knowing which skill produced them.
.NET-Notebook-Migration-Agent
Expert .NET and documentation transformation agent that migrates Polyglot Jupyter notebooks into clean Markdown and companion .NET sample code.