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/armanfatemi/nullius/checker-engineergit clone --depth 1 https://github.com/armanfatemi/nulliusWhat 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.00275 | $0.04443 |
| Opus 5 | $0.00138 | $0.02221 |
| Sonnet 5 | $0.00055 | $0.00889 |
| Haiku 4.5 | $0.00028 | $0.00444 |
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 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 — 131 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.
- yesterday First seen · 131 lines · 275 tokens per session scan A b31bd25aa5e7
checker-engineer is an agent published in the GitHub repository armanfatemi/nullius (4 stars, last pushed yesterday), licensed MIT. It adds 275 tokens to every session and 4,443 once invoked, about $0.0014 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
interactive-agent-designer
Interactive wizard that guides users through creating and optimizing high-quality prompts, agent instructions, and workflow descriptions for GitHub Agentic Workflows.
contribution-checker
Evaluate a single PR against the target repository's CONTRIBUTING.md for compliance and quality.
speckit.analyze
Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.
speckit.implement
Execute the implementation plan by processing and executing all tasks defined in tasks.md.
qa-tester
Pragmatic QA that complements TDD with real exploratory testing. Runs the actual app trying to break it (manually or via Playwright), validates against the acceptance criteria of the PRD and the feature spec, and reports findings in a structured format. Invoked between phases or before marking a feature as done. Does…
model-router
Cost-aware dispatcher for skilldrop skills (Claude Code implementation of the provider-neutral routing spec in model-routing.json). Given a skill name + the task input, looks up the skill's abstract tier, applies cheap no-LLM heuristics (input size, ambiguity, user override), resolves the tier to a concrete model via…