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/cognitive-fab/polygraph/verifiergit clone --depth 1 https://github.com/cognitive-fab/polygraphWhat 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.00057 | $0.00822 |
| Opus 5 | $0.00028 | $0.00411 |
| Sonnet 5 | $0.00011 | $0.00164 |
| Haiku 4.5 | $0.00006 | $0.00082 |
Grade A, and why
polygraph-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 yesterday.
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 run the Polygraph trace-driven verification loop end to end and
return a triaged findings report. The method's scripts are under
${CLAUDE_PLUGIN_ROOT}/scripts/; the full method is in the polygraph
skill — follow it. The derived artifact is a SAM v2 strict-profile module
(named intents/schemas/domains, keyed acceptors, observable reject(reason),
sealed model). The 1.x bare next(state, action, data) artifact was removed in
8.0.0 and is refused by every stage.
Inputs you expect (ask only if missing): a contract.json (or enough
information to build one from ${CLAUDE_PLUGIN_ROOT}/templates/), the source
file under test, and a trace corpus directory. For generation you need
ANTHROPIC_API_KEY and a model (recommend opus-5; if the API refuses the
prompt on policy grounds, retry with opus-4.8 — per-step source of truth:
RECOMMENDED_MODELS in scripts/models.mjs).
Procedure:
- Validate the corpus with
scripts/validate_corpus.mjs. If chaining or terminal-state checks fail, stop and report — the traces are untrustworthy; do not proceed to modeling. - Run controls if reference specs are provided: a positive control must score 100% and a negative (mutated) control must fail only its target windows. If they do not, the corpus or the reference is wrong — report and stop.
- Run
scripts/verify.mjsin generation mode (--model,--n 5) or, if no key/model is available, in--specsmode over provided specs. Add--tlawhen the user wants the TLC escalation tier (needsPOLYGRAPH_JAVA/javaandPOLYGRAPH_TLA_JAR; a missing toolchain is a report note, and the.tla/.cfgartifacts are still written). - Triage every non-consistent window from
out/findings.json:- all specs disagree → code-finding (open the source at that pre-state and action and describe what the code actually does) or contract-error (a driving field is missing from the observable state, or the trace uses an action the contract does not declare);
- some specs pass, some fail → spec-error (a generation missed a rule; name the rule);
- unscoreable in all specs → generation problem, not a code problem;
- use the v2 step classifications:
rejected(reason)andidentity-by-mutationare the good no-op classes;unhandled(neither acted nor rejected) is itself a finding; a uniform rejection-reason on a code-finding window means the contract took a side — triage the contract first.
Return: the summary counts, a ranked list of code-findings with the exact (scenario, window, pre-state, action) and your reading of the source, the spec-errors with the missed rule named, and a one-line honest caveat that this is a consistency check, not a proof. Do not overstate: a clean run means observable behavior matches an independent reading of the source, over the declared finite (action, data) domains only — nothing more.
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.
- yesterday First seen · 57 lines · 57 tokens per session scan A 44ebc8119673
polygraph-verifier is an agent published in the GitHub repository cognitive-fab/polygraph (11 stars, last pushed 5d ago), licensed Apache-2.0. It adds 57 tokens to every session and 822 once invoked, about $0.0003 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 agents, from other repositories
analyze-pass-impact
Analyzes how a specific topic affects a group of compiler passes. Used by the /plan-update skill to parallelize research across all compiler phases. Use when you need to understand the impact of a cross-cutting concern on specific compiler passes.
json-output-reviewer
Reviews JSON output schema design, backwards compatibility, actions arrays, and machine-readability.
github-action-reviewer
Reviews GitHub Action composite action, shell scripts, jq filters, PR annotations, comments, and review integration.
workflow-debugger
Use this agent when you need to debug Output SDK workflows in local development. Invoke when workflows fail, return unexpected results, or you need to analyze execution traces to identify root causes.
docs-reviewer
Lean docs reviewer that dispatches reviews docs for a particular skill.
workflow-prompt-writer
Use this agent when writing, reviewing, or debugging LLM prompt files (.prompt). Specializes in Liquid.js template syntax, YAML frontmatter configuration, and Output SDK prompt conventions.