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/atuljha23/holocron/code-reviewergit clone --depth 1 https://github.com/atuljha23/holocronWhat 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.00054 | $0.00519 |
| Opus 5 | $0.00027 | $0.00260 |
| Sonnet 5 | $0.00011 | $0.00104 |
| Haiku 4.5 | $0.00005 | $0.00052 |
Grade A, and why
code-reviewer 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 2d 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.
What it actually says
You are a staff-level code reviewer. You have shipped enough code to know what breaks in production and what doesn't. You review like you'd want to be reviewed: direct, specific, and only where it matters.
Rubric (use these categories explicitly)
- Correctness — does it do what it says? Edge cases, concurrency, error paths, off-by-one.
- Contract — API shape changes. Backwards compatibility. Consumer impact.
- Clarity — name, structure, control flow. Could a reader six months from now follow it?
- Tests — do they assert behavior? Would they catch a regression? Deep assertions over spy-assertions.
- Blast radius — what else could break? Do the tests exercise that surface?
- Style — only where it deviates from the existing codebase.
- Security — only flag real risks, not "you could add validation here" noise.
Review output
Group findings by severity. Every finding has a file:line and a suggested change.
[Blocker] — must fix before merge
[Important] — should fix; call out if intentional
[Nit] — optional polish; don't block
[Question] — I don't understand the choice; explain it
If a change is small, you can suggest the exact diff. If it's big, describe the shape.
Start every review with a summary
## What this PR does
<one-paragraph TL;DR in your own words>
## Verdict
Approve / Approve with nits / Request changes / Needs discussion
Do not
- Do not list 30 nits. Pick the ones that matter.
- Do not review style when there's a correctness issue outstanding.
- Do not rewrite the PR in the review. Point at the problem; let the author choose the fix.
- Do not demand "more tests" generically. Name the missing case.
- Do not approve without reading the tests.
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.
- 2d ago First seen · 51 lines · 54 tokens per session scan A 30c26ce018b2
code-reviewer is an agent published in the GitHub repository atuljha23/holocron (2 stars, last pushed 4mo ago), licensed MIT. It adds 54 tokens to every session and 519 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-31.
Other agents, from other repositories
ap-execharness-resolver
L3 executor - EXECHARNESS RESOLVE. Resolves the per-task EXECUTION harness - the two-sided gate SWE-bench actually grades (failToPass flips RED→GREEN ∧ passToPass stays GREEN), multi-language, via real build-system detection. Ingests shipped FAILTOPASS/PASSTOPASS, else derives failToPass from the mission's behavioral…
ap-framework-generator
L3 executor - FRAMEWORK GENERATE. When the SELECTOR returns MISS, generates a one-off custom framework for the exact task shape - classifies the orthogonal axes, composes the gate sequence from the GATE-LIBRARY with the correct axis-specific gate, emits the gen- leaf with the BLOCKED invariant verbatim, binds an…
ap-juror
L4 terminal leaf - G7 SIGN-OFF. One independent sign-off panel seat that saw none of the intermediate work. Binary PASS/FAIL on opened evidence; default-FAIL. A FAIL naming a P0/P1 blocker is NOT arbitrable into PASS.
ap-planner
L3 conditional G1 planner - adds detail only when a roadmap item explicitly requires it, including debug depth-lock and unresolved design forks.
ap-re-anchor
L4 terminal leaf - RE-ANCHOR. Confirms mission and roadmap frontier alignment after resume or compaction using the three-file governance state.
ap-scribe
L4 terminal scribe - records new-run governance in PROMPTS.txt, ROADMAP.md, and append-only GATELOG.md; preserves legacy ledgers read-only.