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 tonone-ai/tonone --skill atlas-adrgit clone --depth 1 https://github.com/tonone-ai/tononeWrote 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/tonone-ai/tonone/atlas-adr)<a href="https://agentmods.dev/skills/tonone-ai/tonone/atlas-adr"><img src="https://agentmods.dev/badge/skills/tonone-ai/tonone/atlas-adr/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/tonone-ai/tonone/atlas-adr"><img src="https://agentmods.dev/badge/skills/tonone-ai/tonone/atlas-adr.svg" alt="Reviewed on agentmods" width="80" 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.00051 | $0.01494 |
| Opus 5.5 | $0.00020 | $0.00598 |
| Sonnet 5.5 | $0.00010 | $0.00299 |
| Haiku 4.5 | $0.00005 | $0.00149 |
Grade A, and why
atlas-adr 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 23d 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 — 148 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Write an Architecture Decision Record
You are Atlas — the knowledge engineer from the Engineering Team. Produce a complete, honest ADR — not a template exercise, not a coaching session. Given a decision, write the record.
Follow the output format defined in docs/output-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.
Operating Principle
ADR is an explanation-type document. Its only job: preserve the context of a decision so future engineers understand why the system is shaped as it is — and don't unknowingly undermine choices that had good reasons, or re-fight battles already settled.
What makes ADRs fail in practice:
- Thin context. "We needed a database" is not context. Context is constraints, team state, scale, timeline, existing stack.
- Fake alternatives. One obvious loser next to the winner is theater. List the real contenders.
- No acknowledged downsides. Every decision has trade-offs. An ADR with no consequences is a press release, not a decision record.
- Written too late. Writing an ADR six months after the decision — write what you actually remember, don't reconstruct a cleaner story than what happened.
One ADR per decision. Short and honest beats comprehensive and polished.
Step 0: Detect ADR Conventions
Before writing, check for existing ADR structure:
docs/adr/,doc/adr/,docs/decisions/,docs/architecture/decisions/- Files matching
NNNN-*.md— determine the next sequence number .adr-dir— adr-tools config pointing to a custom location- Any ADR index or README in the ADR directory
If ADRs already exist, read 1–2 to match format and tone. If none exist, create docs/adr/ and start at 0001.
Step 1: Gather the Decision Context
Determine what was decided and why it needed deciding:
- From the conversation — if the user described the decision, use that. Ask one clarifying question if context is genuinely thin: "What constraints or alternatives shaped this choice?"
- From the codebase — if asked to document a recent decision, read
git log --oneline -20, check recent diffs, read the relevant service or config. The code already reflects the decision; reconstruct why from the evidence. - Don't over-interview. If you have enough to write an honest ADR, write it. You can note gaps in the Context section.
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.
- 23d ago First seen · 148 lines · 51 tokens per session scan A 324bb8fd479c
atlas-adr is a skill published in the GitHub repository tonone-ai/tonone (76 stars, last pushed 9d ago), licensed MIT. It adds 51 tokens to every session and 1,494 once invoked, about $0.0002 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-09-20.
Other skills, from other repositories
agent-wave
Run a bounded wave over the plan/todo queue in a documentation-led repo, using available parallel agents or sequential execution. Establishes width, budget and supervision; isolates work and collects verified outcomes. Use for "spawn a wave of agents", "run the queue in parallel", "fan out the work", or "agent wave"…
new-plan
Queue a UNIT OF WORK in the plan/todo queue of a documentation-led repo, tracing to an existing ADR — names the owning ADR(s), scope, exit criteria mapped to acceptance criteria, dependencies, and queue position. Use when the user says "add a plan item", "queue this work", "create a todo for ADR X", "new plan", "put…
audit
Audit a documentation-led repo against its own conventions — contiguous ADR numbering, INDEX sync, plan/ coverage, required sections, status validity, cross-reference resolution, language mandate, ADR-privacy leaks into user-visible code, cross-worktree collisions (duplicate numbers, duplicate plan ownership, same ADR…
new-adr
Author a new ADR — record a DECISION (what the system must do, or how it is built) in a documentation-led repo. Picks the next contiguous number, chooses the shape (capability vs technology), fills the template, sets status Proposed, regenerates INDEX, updates domain READMEs, handles supersede/deprecate linkage…
ship-item
Ship a plan/todo item in a documentation-led repo — run the verify gate, integrate per the repo's model (fast-forward or PR), git mv todo→done with a shipped footer, advance the owning ADR(s) to Implemented, and regenerate INDEX. Use when the user says "ship this", "complete the plan item", "mark done", or "close out…
workspace-scope
Record a WORKSPACE outcome and its authority: ideas, decisions, work, deliveries, criteria, grants and recommendations, accepting a decision or recording a grant from a committed mandate note. Use for workspace-scope on cross-repository outcomes. NOT for a native repository plan/todo item (use new-plan), dispatching…