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 skills add damusix/atomic-claude --skill atomic-reviewgit clone --depth 1 https://github.com/damusix/atomic-claudeWrote 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/skills/damusix/atomic-claude/atomic-review)<a href="https://agentmods.dev/skills/damusix/atomic-claude/atomic-review"><img src="https://agentmods.dev/badge/skills/damusix/atomic-claude/atomic-review.svg" alt="Measured on agentmods" 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.00063 | $0.01450 |
| Opus 5 | $0.00032 | $0.00725 |
| Sonnet 5 | $0.00013 | $0.00290 |
| Haiku 4.5 | $0.00006 | $0.00145 |
Grade A, and why
atomic-review 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 7d 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 — 111 lines — stays where its author put it; the contents beside it link to each section on GitHub.
- "review this PR", "code review", "review the diff", "check this PR"
- "review this change", "review my changes"
- Reviewing pull requests or diffs
Write code review comments terse and actionable. One line per finding. Location, problem, fix. No throat-clearing.
Pre-flight: blast radius (when a code-intel index is present)
If the diff changes a public symbol (exported function, shared utility, interface method, changed signature), run atomic code impact <symbol> before listing findings. Callers that assume the old behavior become 🟡 risk findings. One targeted query per changed public symbol — no full-graph dump. Skip silently when no index is present.
<output_format>
Format
path:line: <emoji> <severity>: <problem>. <fix>.
Single-file reviews may use L<line>: ... instead of path:L<line>: ....
Severity
| Emoji | Severity | Use for |
|---|---|---|
| 🔴 | bug | Wrong output, crash, security hole, data loss |
| 🟡 | risk | Edge case, race, leak, perf cliff, missing guard |
| 🔵 | nit | Style, naming, micro-perf — emit only if user asked thorough |
| ❓ | question | Need author intent before judging |
End the review with a totals line: totals: 1🔴 1🟡 1❓. Zero findings → No issues. File order, ascending line numbers within file.
Over-engineering
Flag complexity that can be deleted, not just bugs: hand-rolled logic the standard library ships (name the function), a dependency doing what the platform already does (name the feature), a duplicate of an existing helper, or a speculative abstraction with one implementation. 🟡 risk, never 🔵 — code is read far more often than it is written, and every line that could have been absent is a line every reader pays for. Always name the concrete replacement, never "consider simplifying".
src/util.ts:12-38: 🟡 risk: hand-rolled email validator. Real validation is the confirmation mail; 26 lines go.src/date.ts:4: 🟡 risk: moment.js for one format call. Intl.DateTimeFormat, 0 deps.src/repo.ts:88: 🟡 risk: AbstractRepository with one impl. Inline until a second exists.
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.
- 7d ago First seen · 111 lines · 63 tokens per session scan A a7840ad3710e
atomic-review is a skill published in the GitHub repository damusix/atomic-claude (84 stars, last pushed today), licensed MIT. It adds 63 tokens to every session and 1,450 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-30.
Other skills, from other repositories
memstack-development-code-reviewer
Use this skill when the user says 'review code', 'code review', 'check my code', 'audit this', 'review PR', 'review changes', 'what's wrong with this', or is requesting a structured review of code quality, security, performance, or maintainability. Do NOT use for refactoring plans or test generation.
shard
Use when the user says 'shard this', 'split file', or when working with files over 1000 lines.
ralphctl-code-review-and-quality
Multi-phase code-quality skill — primary frame for the evaluator role in Execute, the architecture axis in Plan, and correctness/readability in Refine. Multi-axis code review with severity vocabulary. Use when you are the evaluator assessing a generator's output, and when reviewing any change before signalling…
executing-plans
Use when you have an implementation plan ready to execute. Triggers: 'run the plan', 'start building', 'execute the tasks', 'implement the steps', 'next task in the plan', 'work through the plan'. Also invoked by develop after planning phase completes. NOT for: creating plans (use writing-plans).
reviewing-impl-plans
Use when reviewing implementation plans before execution. Triggers: 'is this plan solid', 'review the plan', 'check before I start building', 'anything missing from this plan', 'will this plan work', 'audit the implementation plan'. NOT for: reviewing design documents (use reviewing-design-docs) or creating plans (use…
adversarial-review
Use when dispatching a subagent to re-check work against external feedback (PR review comments, audit findings, multi-comment review cycles, 'did I really address X' verifications). Triggers: 'verify all the review comments are addressed', 'check that I really fixed all the audit findings', 'did I miss anything from…