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-verifygit 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-verify)<a href="https://agentmods.dev/skills/damusix/atomic-claude/atomic-verify"><img src="https://agentmods.dev/badge/skills/damusix/atomic-claude/atomic-verify/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/damusix/atomic-claude/atomic-verify"><img src="https://agentmods.dev/badge/skills/damusix/atomic-claude/atomic-verify.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.00099 | $0.00925 |
| Opus 5.5 | $0.00040 | $0.00370 |
| Sonnet 5.5 | $0.00020 | $0.00185 |
| Haiku 4.5 | $0.00010 | $0.00093 |
Grade A, and why
atomic-verify 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 1mo 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 — 81 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Verify before claim. No claim without fresh evidence in this turn.
- "done", "fixed", "passing", "complete", "ready to merge", "looks good"
- "should work", "should pass", "this works"
- "tests pass", "build green", "lint clean", "typecheck green"
- "bug fixed", "regression resolved"
- Any phrase implying success not preceded by verification output IN THIS TURN.
The gate
- IDENTIFY — what command proves this claim?
- RUN — execute it fresh in this turn.
- READ — full output, check exit code.
- VERIFY — output matches the claim?
- ONLY THEN — state the claim, WITH evidence.
Skip any step = lying, not verifying.
Claim → required check
| Claim | Required verification |
|---|---|
| tests pass | run test command, see 0 failures |
| build green | run build, exit 0 |
| lint clean | run lint, 0 errors |
| typecheck green | run typecheck (tsc/mypy/etc), 0 errors |
| bug fixed | run repro that failed before, see it pass now |
| agent task complete | check VCS diff for actual changes |
| code I wrote myself is ready | dispatch atomic-reviewer (code mode, diff: working, model override to the session's model), 0 unaddressed 🔴 findings, state the review: line in the claim |
| regression test works | red → fix → green sequence verified |
| spec/artifact changed | run atomic validate spec + atomic validate config + atomic validate artifacts, 0 FAIL (skip if atomic binary absent) |
diff: working tells atomic-reviewer to also read untracked files — a new file is the most common shape of an ad-hoc change and never appears in git diff HEAD. Resolution is the reviewer's job; see atomic-reviewer.md's code-mode step 2.
Verification discipline
Every completion claim needs a fresh command run in this turn. Watch for these moments:
- Before saying "done" or "fixed" — run the proof command first
- Before committing or pushing — verify all signals are green
- After a subagent reports success — check the artifacts yourself
- Partial checks (one test out of N) are not verification — run the full suite
- When the change touched
docs/spec/**,docs/design/**, or bundled artifacts (agents/,commands/,skills/,output-styles/,rules/,CLAUDE.md), runatomic validate spec(when a spec changed),atomic validate config, andatomic validate artifacts. A FAIL is a gate failure with the same standing as a failing test. Graceful degradation: if theatomicbinary is not on PATH or no matching files exist, skip silently — never fail the gate on absence. (This skill ships to user repos that may not have the binary installed.)
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.
- 1mo ago Changed · +2 lines · +20 tokens per session 646a06ee0ed7
- 1mo ago Changed · +2 lines fa917e3b6c0c
- 1mo ago First seen · 77 lines · 79 tokens per session scan A 5668ada68772
atomic-verify is a skill published in the GitHub repository damusix/atomic-claude (114 stars, last pushed yesterday), licensed MIT. It adds 99 tokens to every session and 925 once invoked, about $0.0004 per session on Opus 5.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
loongsuite-pilot-insight
A reporting workflow for turning LoongSuite Pilot and AI coding-agent logs into structured reports about events, teams, data quality, development efficiency, and AI use. It defines the meaning of the log fields and the measurements used in dashboards.
loongsuite-pilot-ops
Skill "loongsuite-pilot-ops" from alibaba/loongsuite-pilot, covering loongsuite-pilot-ops, quick start, todo: add quick start commands and usage.
sipcode-regress
Check the user's own local Claude Code and Codex logs for regressions after an update (prompt-cache misses, 5-minute cache TTL, uncached context, hourly cache rebuilds, Codex usage limit draining faster per token) and pin each one to the version that introduced it, using the Sipcode CLI. Use when the user asks whether…
sipcode-spend
Report how much the user spent on Codex (tokens and cost at API prices) today, this month, the projected month end, or over a period, from their local Codex logs, using the Sipcode CLI. Use when the user asks how much they spent on Codex, how many tokens Codex used today or this month, or what this month will cost.
sipcode-why
Explain why a Codex session used so many tokens (largest requests, files read more than once, context carried while idle) from the user's local Codex logs, using the Sipcode CLI. Use when the user asks why their last Codex session was so expensive, where the tokens went, or what made a session cost so much.
impact
A/B compare the user's actual token spend before and after they installed Sipcode's optimizers — on their own session data. The honesty-first savings verifier. Use when the user asks "is sipcode actually saving me tokens?", "show me the impact", "prove sipcode is working", or any variant of "is this thing worth…