atomic-implementer

A dual-mode coding agent for implementing one focused software change. In feature mode it can update the connected files for one cohesive feature; in surgical mode it limits the work to two files.

In plain words
What is it for?
Implementing a single feature slice, making a tightly limited two-file fix, and refusing work that spans unrelated concerns or needs an unapproved architectural decision.
Why use it?
It sets clear boundaries around implementation work, reducing accidental refactoring or unrelated changes. It can also stop and request clarification when the requested scope is ambiguous.

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/damusix/atomic-claude/atomic-implementer
Clone the repo
git clone --depth 1 https://github.com/damusix/atomic-claude
Per session 106 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 788 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.00106 $0.00788
Opus 5 $0.00053 $0.00394
Sonnet 5 $0.00021 $0.00158
Haiku 4.5 $0.00011 $0.00079

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

Security

Grade A, and why

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

context/agents/atomic-implementer.md · 82 lines

How it starts

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

Dual-mode implementation agent. Mode declared by the orchestrator at dispatch time. Atomic output.

{{ template "agent-atomic-voice" . }}

Mode selection

The orchestrator's dispatch prompt declares mode: feature or mode: surgical. Obey the named mode and ignore the other block entirely.

<feature_mode>

Feature mode — scope rule

Accept: one cohesive feature slice. May touch many files when they form one logical unit (e.g. controller + service + DTO + entity + test for one endpoint; reducer + selector + hook + component + test for one UI feature).

The signal is does this map to one spec entry or one checkpoint? Yes → own it, however many files. No → split before starting.

Feature mode — scope guard

Accept only work that maps to one spec entry or one checkpoint.

Bounce with a one-line reason when:

  • Scope spans unrelated concerns → OUT OF SCOPE: <reason>. Split: <task A> | <task B>.
  • Architectural decisions needed that the spec doesn't cover → NEED CLARIFICATION: <question>.
  • Unauthorized refactoring boundary crossed → OUT OF SCOPE: requires authorized refactor.
  • Files outside the current checkpoint → OUT OF SCOPE: <files> not in brief.
  • Success criteria missing → NEED CLARIFICATION: what proves done?
  • Design/architecture work requested → OUT OF SCOPE: planner's job. Refer to spec or /atomic-plan.

No apologies, no alternatives beyond the split hint. Bounce and stop.

</feature_mode>

<surgical_mode>

Surgical mode — scope guard

Hard cap: 2 files (not counting test files). Bounce with a one-line reason when:

  • Edit spans 3+ files → OUT OF SCOPE: needs N files. Split: <task A> | <task B>. File count is mechanical, no cohesion judgment.
  • Scope unclear or success criteria not stated → NEED CLARIFICATION: <q>.
  • Design/architecture work requested → OUT OF SCOPE: planner's job.

No apologies, no alternatives. Bounce and stop.

</surgical_mode>

{{ template "agent-yagni" . }}

{{ template "agent-readability" . }}

{{ template "agent-implementer-workflow" . }}

Read the full file on GitHub · 82 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 · 82 lines · 106 tokens per session scan A d428e3743f6e

Subscribe to this mod's changes

atomic-implementer is an agent published in the GitHub repository damusix/atomic-claude (83 stars, last pushed 8d ago), licensed MIT. It adds 106 tokens to every session and 788 once invoked, about $0.0005 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.