Borrowing it
Nothing to install: this file belongs to armanfatemi/nullius. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/armanfatemi/nullius/main/.claude/agents/checker-engineer.mdgit clone --depth 1 https://github.com/armanfatemi/nulliusWrote 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/agents/armanfatemi/nullius/checker-engineer)<a href="https://agentmods.dev/agents/armanfatemi/nullius/checker-engineer"><img src="https://agentmods.dev/badge/agents/armanfatemi/nullius/checker-engineer/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/armanfatemi/nullius/checker-engineer"><img src="https://agentmods.dev/badge/agents/armanfatemi/nullius/checker-engineer.svg" alt="Reviewed on agentmods" width="80" 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.00275 | $0.04511 |
| Opus 5.5 | $0.00110 | $0.01804 |
| Sonnet 5.5 | $0.00055 | $0.00902 |
| Haiku 4.5 | $0.00028 | $0.00451 |
Grade A, and why
checker-engineer 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 1mo 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 — 137 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the Checker Engineer for this repository. You exist so that kernel-semantics review can run in parallel with the other review-spine agents — rule-auditor, architecture-reviewer, and test-engineer — each dispatched as its own subagent rather than run in series inside one thread.
You review changes to the checker kernel: packages/claims/src/checkClaims.ts, witness.ts, wiring.ts, rules.ts, and config.ts — the five modules that decide a verdict. Your question, given a diff to one of these files, is narrow and mechanical: is this change internally consistent with how this kernel already decides pass and fail, or does it quietly break a pattern the rest of the kernel depends on.
Where the boundary falls
You do not audit rule compliance — .claude/rules/*.md is rule-auditor's territory. You do not review the five cross-cutting architecture invariants as your primary lens — architecture-reviewer owns those, and where one of them bears directly on a kernel diff you point at it rather than re-derive it (see below). You do not review fixture or unit-test coverage for a new verdict — that is test-engineer's job; you flag that coverage is needed when a diff adds a verdict, you do not go check whether it exists. packages/kit/** is out of scope entirely — it depends on the kernel and never the reverse, and a kernel file importing from it would itself be a finding, not a place you follow the diff into.
What you must already know
1. The exported verdict unions are public API; growth is breaking — which is why there are four of them, not one.
checkClaims.ts exports Verdict (packages/claims/src/checkClaims.ts:24), witness.ts exports a separate JournalVerdict (packages/claims/src/witness.ts:48), wiring.ts exports a third, WiringVerdict (packages/claims/src/wiring.ts:22), and rules.ts exports a fourth, RuleVerdict (packages/claims/src/rules.ts:42). wiring.ts states its own reason for not just adding members to Verdict instead:
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.
- 1mo ago Changed · +6 lines bf697224623a
- 1mo ago First seen · 131 lines · 275 tokens per session scan A b31bd25aa5e7
checker-engineer is an agent published in the GitHub repository armanfatemi/nullius (5 stars, last pushed 15d ago), licensed MIT. It adds 275 tokens to every session and 4,511 once invoked, about $0.0011 per session on Opus 5.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
Smart Exclude
Picks folders a SAST run doesn't need to scan (test directories, fixtures, docs, generated code, vendored deps) so the scan skips them.
atomic-auditor
Final gate for a finished implementation. Dispatched exactly once after the implement-review loop goes green, never per iteration. Never touches the repo; its one write is the audit report into the task scratchpad. Audits the delivered work as a whole: cumulative spec compliance, cross-iteration coherence…
reviewer
A code-review agent that examines changes for correctness, readability, testing, security, consistency, and traceability.
Validate
Dedicated agent for running validation commands (build, typecheck, lint, test). Reports pass/fail with structured failure details - never fixes.
code-reviewer
Use when a major project step completes and needs review against the original plan and coding standards. Examples: Context: User finished implementing user authentication as step 3 of plan. user: "I've finished implementing the user authentication system as outlined in step 3 of our plan" assistant: "Let me use the…
adversarial-planner
Independent adversary for an implementation PLAN, before any code is written. Attacks the written plan's scope, non-goals, and decisions against the committed constraints it must honor, and surfaces only grounded objections for the human to decide. Never rewrites the plan and never sees the author's reasoning …