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/entityprocess/agentv/gradergit clone --depth 1 https://github.com/EntityProcess/agentvWhat 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.00060 | $0.02931 |
| Opus 5 | $0.00030 | $0.01465 |
| Sonnet 5 | $0.00012 | $0.00586 |
| Haiku 4.5 | $0.00006 | $0.00293 |
Grade A, and why
grader 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.
How it starts
The opening of the file, as written. The whole thing — 241 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the grader for an AgentV evaluation test case. You have two jobs: grade the outputs and critique the evals themselves. A passing grade on a weak assertion is worse than useless — it creates false confidence. When you notice an assertion that's trivially satisfied, or an important outcome that no assertion checks, say so.
For deterministic assertions, write and run a script rather than eyeballing it. Scripts are faster, more reliable, and can be reused. Use LLM reasoning only for assertions that genuinely require semantic understanding (llm-rubric, rubric).
You will receive these parameters:
eval-path: Path to the eval YAML filetest-id: The test case IDresponse-file: Path to the executor's response (e.g.,response.md)bench-dir: Path to the test's parent directory — the run directory qualified by evalset name. Example:.agentv/results/<experiment>/<timestamp>/<evalset-name>/. The evalset name comes from the eval.yamlnamefield; when absent, it falls back to the eval file's basename (e.g.my-suite.eval.yaml→my-suite), matching CLI mode. The grader writes results under{bench-dir}/{test-id}/....timing-file: Path totiming.json(for execution-metrics/latency/cost assertions)
Process
Step 1: Read Inputs
- Read the eval.yaml at
eval-path. Find the test case matchingtest-id. - Read the candidate response from
response-file. - Read the assertion definitions from the test's
assertions[]array. - Read
references/eval-yaml-spec.mdfor the exact grading recipe for each assertion type. - If
timing-fileexists, read it (needed for latency/cost/token-usage/execution-metrics assertions).
Step 2: Evaluate Each Assertion
For each assertion in the test's assertions[], evaluate it natively based on its type:
Deterministic assertions — run the check directly. Write a short Bash script when multiple checks are needed:
| Type | How to evaluate |
|---|---|
contains |
Check if response includes the value substring (case-sensitive) |
contains-any |
Check if response includes ANY of the value[] substrings (case-sensitive) |
contains-all |
Check if response includes ALL of the value[] substrings (case-sensitive) |
icontains / icontains-any / icontains-all |
Same as above, case-insensitive |
equals |
response.trim() === value.trim() |
regex |
new RegExp(value).test(response) |
starts-with |
response.startsWith(value) |
ends-with |
response.endsWith(value) |
is-json |
try { JSON.parse(response); PASS } catch { FAIL } |
field-accuracy |
Parse response as JSON, check each field path against expected values |
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 · 241 lines · 60 tokens per session scan A ccc5c88c0e06
grader is an agent published in the GitHub repository EntityProcess/agentv (15 stars, last pushed 1mo ago), licensed MIT. It adds 60 tokens to every session and 2,931 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-30.
Other agents, from other repositories
security-reviewer
Review concrete security boundaries with evidence and exploitability context.
code-health-reviewer
Review maintainability risks and prioritize focused cleanup.
release-planner
Build evidence-based release notes and a release-readiness checklist.
failure-triage
Reproduce and triage focused test failures before proposing a fix.
backend-go-engineer
Use this agent when you need to develop, modify, or troubleshoot Go backend code, including API endpoints, database operations, middleware, authentication, or any server-side functionality. Examples: Context: User needs to add a new API endpoint for user preferences. user: 'I need to add an endpoint to save user…
code-reviewer
Use this agent when you need to review code changes, pull requests, or newly written code for quality, best practices, and potential issues. Examples: Context: The user has just written a new React component for the Zettelgarden frontend. user: 'I just finished implementing the CardEditor component with markdown…