Getting it into your agent
This one installs as part of its plugin. Adding the marketplace and installing the plugin brings it with everything else the plugin ships.
/plugin marketplace add cognitive-fab/polygraph/plugin install polygraphWrote 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/cognitive-fab/polygraph/polynv)<a href="https://agentmods.dev/skills/cognitive-fab/polygraph/polynv"><img src="https://agentmods.dev/badge/skills/cognitive-fab/polygraph/polynv.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.1 | $0.00171 | $0.02182 |
| Opus 5 | $0.00086 | $0.01091 |
| Sonnet 5 | $0.00034 | $0.00436 |
| Haiku 4.5 | $0.00017 | $0.00218 |
Grade A, and why
polynv 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 6d 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 — 154 lines — stays where its author put it; the contents beside it link to each section on GitHub.
polynv — elicit the invariants (the plugin leads)
Every Polygraph gate is exactly as good as invariants.mjs, and writing
good invariants from a blank page is a scarce skill. This skill routes
around it: you (the in-session assistant) drive the interview; the
designer's job is reduced to judging concrete stories — confirm / reject /
modify / defer — which is a common skill. Never wait for the designer to
propose invariants unprompted; propose, ask, and record.
Disclosure (same as the whole plugin). This is experimental, unproven technology. A pre-check verdict is a consistency check over the declared finite (action, data) domains, not a proof. Harvested candidates describe BEHAVIOR, not intent — a machine with a bug yields candidates that bless the bug — which is why nothing enters
invariants.mjswithout the designer's explicit disposition, and why you must never answer an intent question on the designer's behalf. A CONVERGED verdict means every question was answered AND the mutation adequacy grade ran — it still does not prove the questions were sufficient: the grade bounds unconstrained behavior, it does not certify intent, and behavior-removing mutations largely evade it.
The CLI is ${CLAUDE_PLUGIN_ROOT}/polynv/bin/polynv.mjs; an artifact dir
holds contract.json + the SAM v2 module + optional effects.manifest.json
(what polygen emits). The system of record is intent-ledger.json in that
dir — append-only, in git, holding every record ever considered including
rejected and abandoned ones. Deterministic, no API key.
Step 1 — Harvest (mechanical)
node ${CLAUDE_PLUGIN_ROOT}/polynv/bin/polynv.mjs harvest --artifacts <dir> \
[--traces <dir-or-file.ndjson>] [--snapshots <corpus>] [--min-obs N]
Generates template candidates from the contract's own vocabulary (one
absorbing question per terminal state, range/sign/set-once/monotone per
typed field, one no-op question per reject-describing special rule, one
at-most-once question per manifest effect kind) and pre-checks each against
the machine — emission candidates through the machine ∘ mapper composition
(polyrun check-effects) whenever the dir carries effects.cjs + manifest.
Resuming after the machine changed? Run drift --artifacts <dir>
first: it re-checks every recorded answer and names the verdicts that
moved; --reopen --author <designer> re-asks judged answers whose ground
truth drifted, while a confirmed rule now violated stays confirmed as a
finding. Always offer to mine: if traces, a polyrun journal export,
or fleet snapshots exist, pass them — the miners add observed-behavior
candidates (in-domain, ranges, orderings, control-key implications,
temporal precedence) with observation counts as evidence; mined candidates
are behavior, so their question is always "rule, or artifact of the
corpus?". Below-threshold observations become notes, not questions. Read
the output notes: a special rule that mentions rejection but was not
mechanically templatable is YOUR question to ask by hand; pruned and
vacuous candidates are listed with reasons.
Re-running harvest is always safe — settled records are never re-proposed.
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.
- 6d ago First seen · 154 lines · 171 tokens per session scan A 5a66f649bb43
polynv is a skill published in the GitHub repository cognitive-fab/polygraph (11 stars, last pushed 10d ago), licensed Apache-2.0. It adds 171 tokens to every session and 2,182 once invoked, about $0.0009 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
output-dev-eval-testing
Create offline evaluation tests for Output SDK workflows using @outputai/evals. Use when implementing test evaluators with verify(), creating dataset YAML files, building eval workflows, or running workflow tests via CLI.
develop-ai-functions-example
Develop examples for AI SDK functions. Use when creating, running, or modifying examples under examples/ai-functions/src to validate provider support, demonstrate features, or create test fixtures.
output-eval-validate-judge
Validate LLM judges against human labels using TPR/TNR metrics and train/dev/test splits. Use after writing a judge prompt to verify it agrees with human judgment.
output-dev-scenario-file
Create test scenario JSON files for Output SDK workflows. Use when creating test inputs, documenting expected behaviors, or setting up workflow testing.
capture-api-response-test-fixture
For provider response parsing tests, we aim at storing test fixtures with the true responses from the providers (unless they are too large in which case some cutting that does not change semantics is advised).
add-function-examples
Guide for adding new AI function examples, for testing specific features against the actual provider APIs.