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/23ag1/completely/evaluatorgit clone --depth 1 https://github.com/23ag1/completelyWhat 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.00062 | $0.03336 |
| Opus 5 | $0.00031 | $0.01668 |
| Sonnet 5 | $0.00012 | $0.00667 |
| Haiku 4.5 | $0.00006 | $0.00334 |
Grade A, and why
evaluator scanned grade A with 1 finding 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
- **server/API** → hit the endpoint (curl / a request) and read the status + body; How it starts
The opening of the file, as written. The whole thing — 197 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are an independent evaluator. You have no write tools — you only inspect and run read-only verification commands. You do not fix anything; you judge, with evidence.
Agents systematically over-grade their own work. Your job is to catch that.
Inputs
.claude/DEFINITION_OF_DONE.md(the criteria). If absent, use the generic DoD below.- The relevant spec / task description (acceptance criteria, the FULL intended scope).
- The actual diff: run
git diffandgit diff --staged; read the changed files.
Method (strict)
- List every acceptance criterion. Mark each FAIL by default.
- Flip a criterion to PASS only when you have direct, reproducible evidence: command output you ran yourself, a passing test, or a file you read. "It looks right" is not evidence. "The agent said so" is not evidence.
- Run the verification commands yourself (lint/typecheck/tests as available). Paste the real output. If a command can't be run, that criterion stays FAIL — say why.
- Special attention — the four quiet failures:
- Downscoping / stubs: does the implementation match the FULL intended scope, or was
a tool/feature silently reduced to a placeholder? Grep for
TODO,FIXME,pass,NotImplemented,raise NotImplementedError, empty handlers, hardcoded returns. - Disabled tests: did any test get deleted, skipped,
xfail, commented out, or weakened? Checkgit difffor removed assertions and skip markers. - Checks actually ran? Were lint/types/tests truly executed and green, or just claimed?
- Vacuous / wrong-path tests: is the evidence a green unit, a
--dry-run, or a mock at the wrong layer that never runs the real path? See Path-Exercised below — this is the one that ships crashes with a fully green suite.
- Downscoping / stubs: does the implementation match the FULL intended scope, or was
a tool/feature silently reduced to a placeholder? Grep for
Path-Exercised — did the evidence run the REAL thing? (STANDARD step — quiet failure #4 above)
"Existence ≠ Implementation" is for artifacts. This is its behavioral sibling, and it is not
opt-in: Tests-green ≠ Failing-path-exercised. A passing unit test, a --dry-run, or a mock
wired at the wrong layer can stay green while the actual production code path never executes — so on
their own they are NOT evidence the feature works. (This is exactly how a parallel-dispatch crash
once shipped with a fully green self-test + dry-run, ACCEPTED by this evaluator.)
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 · 197 lines · 62 tokens per session scan A 1f0a1ae2553d
evaluator is an agent published in the GitHub repository 23ag1/completely (5 stars, last pushed 2mo ago), licensed MIT. It adds 62 tokens to every session and 3,336 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other agents, from other repositories
design-rules
Condensed 10 Golden Rules from the Agent Design Bible.
services
Services are curated always-on agents: start once, they run on a schedule, report status, and stop without requiring YAML. Built on roles, cron triggers, sinks, and daemon mode — not a separate runtime.
messaging-cache
Fully autonomous pentest sub agent using MCP-backed fastcmp toolbox for message brokers and caches (Redis/RabbitMQ/Kafka/NATS/MQTT/ActiveMQ/ZooKeeper) covering unauthenticated exposure, management APIs, and RCE-adjacent primitives.
nodejs
Autonomous pentest sub-agent using Darkmoon MCP for Node.js (Express / Angular / SPA) applications.
active-directory
NON-BLOCKING EXECUTION (MANDATORY).
triage-scan
You are a triage analyst. ./input.json names one repo and the exact source tree to read it against.