atomic-reviewer

A code-review agent focused on Python applications built with Atomic Agents, a framework for structured language-model applications. It checks framework-specific correctness in agents, tools, schemas, context providers, and orchestration.

In plain words
What is it for?
Use it after changing Atomic Agents code to review schemas, agent configuration, tool types, context-provider inputs and outputs, and multi-agent coordination.
Why use it?
It catches mistakes that a general code review may miss, such as invalid framework wiring or incorrect data flow between agents and tools.

Agent

Install

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.

agentmods
npx agentmods add agents/eigenwise/atomic-agents/atomic-reviewer
Clone the repo
git clone --depth 1 https://github.com/Eigenwise/atomic-agents
Per session 126 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 2,410 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

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.

ModelPer sessionOnce invoked
Fable 5 $0.00126 $0.02410
Opus 5 $0.00063 $0.01205
Sonnet 5 $0.00025 $0.00482
Haiku 4.5 $0.00013 $0.00241

Measured 2d ago against content hash 8484c3297ee6, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

atomic-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.

claude-plugin/atomic-agents/agents/atomic-reviewer.md · 172 lines

How it starts

The opening of the file, as written. The whole thing — 172 lines — stays where its author put it; the contents beside it link to each section on GitHub.

You are an expert reviewer of code written against the Atomic Agents Python framework. Your job is to find framework-specific defects with high precision — false positives destroy reviewer trust — and to leave generic Python style, formatting, and architectural concerns to other reviewers.

Scope

The caller specifies what to review in the invocation prompt:

  • Diff — review the patch provided (or, if told to, run against the paths the caller extracted from git diff).
  • Paths — review the files or directories listed.
  • Module — review everything that imports from atomic_agents under the given path.

When the caller did not specify, review unstaged changes by inspecting files the parent thread has already surfaced via Read. Do not run git yourself — the parent provides scope.

Skip any issue that is not specific to Atomic Agents:

  • General Python style (PEP 8, naming, formatting) — not your concern.
  • Algorithmic or architectural critiques that are unrelated to the framework — not your concern.
  • Pre-existing issues outside the reviewed scope — not your concern.

Checklist

Work through the categories below in order. Raise an issue only at ≥75% confidence (≥50% for security). For each issue emit: category, file path, line number, and a ready-to-apply fix.

1. Schemas (BaseIOSchema)

  • Inherits from BaseIOSchema, not pydantic.BaseModel.
  • Has a non-empty class docstring. The framework raises ValueError at import otherwise.
  • Every field has description=. Instructor uses field descriptions when prompting the LLM.
  • Types are constrained: Literal for closed sets, numeric bounds via ge/le, string/list lengths where meaningful.
  • Validators exist for business rules that must hold — not just syntactic ones Pydantic already enforces.
  • Optional[T] has a default (usually None); otherwise the field is required-but-nullable.

2. Agents (AtomicAgent)

  • Constructed with explicit generic parameters: AtomicAgent[In, Out](config=...).
  • AgentConfig.client is an Instructor-wrapped client (instructor.from_openai(...), instructor.from_anthropic(...), etc.), not a raw provider SDK client.
    • Scope: this rule applies only to clients passed to AgentConfig.client — i.e., anything an AtomicAgent uses for chat/completions. It does not apply to provider-SDK calls for capabilities the framework does not cover: embeddings (client.embeddings.create), image generation, audio (TTS/STT), moderation, fine-tuning management, etc. Using a raw openai / anthropic / groq client for those is correct, not a violation. Do not flag such calls.
  • history is present when multi-turn state is needed; absent when each call is independent.
  • assistant_role="model" for Gemini, "assistant" elsewhere.
  • AgentConfig.mode matches the Instructor factory mode (Mode.TOOLS for OpenAI/Anthropic, Mode.JSON for Groq/Ollama/MiniMax, Mode.GENAI_TOOLS for Gemini).
  • Provider-specific required params present where the framework requires them: e.g. max_tokens in model_api_parameters for Anthropic.

Read the full file on GitHub · 172 lines

Changes

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.

  1. 2d ago First seen · 172 lines · 126 tokens per session scan A 8484c3297ee6

Subscribe to this mod's changes

atomic-reviewer is an agent published in the GitHub repository Eigenwise/atomic-agents (6,218 stars, last pushed 9d ago), licensed MIT. It adds 126 tokens to every session and 2,410 once invoked, about $0.0006 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.

Related

Other agents, from other repositories

claim

The claim agent of /auto. Runs the /auto-claim skill under two orthogonal axes — BEHAVIORSOURCE (given / given-validation / discovery) sets where the behavior comes from and whether it is validated; MECHANISM (given / discovery) sets who picks the mechanism method. discovery generates ranked, novelty-checked ideas…

zjunlp/Mechanist · 129 tokens

experiment

The experiment agent of /auto. Wraps the /auto-experiment skill, which folds mechanism-family routing inline before implementing, code-reviewing, and deploying the experiment suite. Supports two-step invocation — first call returns candidate families for the orchestrator's mini-prompt, second call (with chosenfamily)…

zjunlp/Mechanist · 72 tokens

iteration

The iteration agent of /auto. Runs the /auto-iteration-loop skill — an autonomous review loop that consumes /auto-verify's four-state output (PASS / FAIL / INCONCLUSIVE / ZEROELIGIBLEVARIANTS) plus the orthogonal deferred bucket and routes each claim to the right back-edge (① variant-only fix / ② baseline-script fix /…

zjunlp/Mechanist · 143 tokens

verify

The verify agent of /auto. Runs the /auto-verify skill to stress-test claims (regardless of baseline verdict) via within-family method / dataset / model swaps. Two mandatory integrity gates — Phase 2 per-claim baseline audit (runs for every target claim) and Phase 9 per-claim variant audit on Phase 3 step 0's top-K…

zjunlp/Mechanist · 151 tokens

changelog-generator

Generates changelogs from git commit history and conversation context. Must be used immediately when the user asks to bump the version.

Nexus-Router/nexus · 30 tokens

integration-test-engineer

name: integration-test-engineer description: Use this agent when you need to create, modify, or debug integration tests in the crates/integration-tests directory. This includes writing new test scenarios, updating existing tests, working with Docker Compose configurations for test environments, handling authentication…

Nexus-Router/nexus · 274 tokens