🌟 Features
| Feature | What it does |
|---|
| Repo-aware sessions | One scan builds a standing map of your codebase that Claude reads before your code, so it stops inventing npm scripts. |
| Code graph | A tree-sitter symbol graph across 31 languages and 23 web frameworks answers callers, call sites, and blast radius, no compiler required. |
| SQL in the graph | Procedures, views, foreign keys, and lineage across Postgres, MySQL, T-SQL, and Snowflake, plus dbt models and macros, read from .sql files with no database connection. |
| Autopilot | /autopilot takes an issue to a merged PR: plans, tests first, reviews its own diff, ships. Your only decision is how to merge. |
| Self-sharpening config | /retrospective-learning mines your corrections for friction and edits its own skills and rules, only with your say-so. |
| Inter-session bus | Concurrent Claude Code sessions message each other over named rooms: delegate work to a peer session, watch or halt a room as the operator. atomic bus gateway hosts rooms across machines behind sealed keys. |
| Persistent REPLs | Named Python and Node interpreter sessions hold state across separate Bash calls, so agents stop re-running setup code to get back to where they were. |
| Structured replies | Tables, trees, and ASCII flows replace walls of prose when they explain faster. |
| Incremental adoption | One install; every layer is optional, from clearer replies up to full autopilot. |
🚀 Usage
Everything below is opt-in and composes into one lifecycle. Lost? /atomic-help reads your git state and names one next command; /atomic-help tour walks the whole system.
The workflow
onboard your repo
/setup-wiki .......................... audit conventions, scaffold what's missing
/refresh-wiki ........................ scan + infer: teach Claude the repo's shape
then get to work
/atomic-plan <desc> .................. design doc + checkpoint spec
/gather-evidence <hypothesis> ...... chase the hunch through primary sources
/pressure-test ..................... defend the design in dialogue before it's built
/challenge-swarm @spec.md .......... parallel expert lenses attack the written spec
/subagent-implementation @spec.md .... implement → review loop; wikis refreshed
/implement ........................... Claude writes it here, reviewer per checkpoint
/quick-fix <task> .................... same loop, no spec, for known-cause fixes
/commit [push|pr|merge|squash] ....... ship from one verb
/autopilot <task|issue#> ............. all of it unattended; you pick the merge
clean up what's already there
/deslop [<path>] ..................... audit standing code for slop → report you read
/deslop apply <ids|tier> ............. fix what you accepted, behind a green baseline
Fresh-context subagents drive the loop as a maker/checker split (Anthropic's evaluator-optimizer pattern): the implementer writes a failing test before any code, the reviewer re-runs tests and gates the diff against the spec, and work commits per green checkpoint. → workflow
Each phase's working state lives in one atomic scratchpad bundle per task — later phases join the same bundle rather than scattering new directories. atomic serve's Plans view lists every bundle and its docs across your worktrees, so you can check what's in flight without cd-ing anywhere. → conventions · serve
Wikis
Wikis are how Claude learns a codebase once instead of every session. Two scopes:
- Repo wiki:
docs/wiki/ inside one repository. Build and framework facts, a domain map, cross-cutting notes. Plus one pointer card per domain under .claude/rules/wiki/, injected whenever Claude touches a file in that domain.
- Realm wiki: a Karpathy-style knowledge base you compile with Claude instead of maintaining by hand. A folder holds your repos and the loose material around them; the
wiki/ beside them holds per-repo summaries, shared concerns, and knowledge pages synthesized from capture buckets.
~/work/acme/ the realm: repos + the material around them
├─ CLAUDE.md realm rules, loaded from any session inside
├─ billing-api/ repo · has its own wiki → linked
├─ gateway/ repo · has its own wiki → linked
├─ vendor-sdk/ repo · no wiki → summarized
├─ research/ capture bucket: findings you write
├─ raw/ capture bucket: PDFs, exports, pasted notes
└─ wiki/ the map atomic compiles
├─ index.md member registry + bucket listing
├─ repos/ summaries of members without their own wiki
├─ concerns/ what cuts across repos
└─ knowledge/ digests synthesized from the buckets
The scopes compose. A realm summarizes the repos under it without writing into them, and a member repo that keeps its own wiki is linked rather than re-summarized. Claude loads whichever scope the session sits in: a realm session sees the cross-repo picture, a repo session sees that repo's map. atomic code index layers a symbol graph onto either scope; at a realm root it indexes every member, and queries fan out across them.
Two commands drive it. /setup-wiki audits a repo's conventions (ignore rules, docs layout, CLAUDE.md wiring) and proposes only what's missing. /refresh-wiki builds or refreshes the wiki at either scope: a deterministic scan captures the facts, an inference pass writes the summaries, and ship verbs mark the wiki dirty as the source tree changes, so a session-start nudge tells you when a refresh is due. → realm wiki · knowledge base · repo wiki
💭 Contributing & feedback
Atomic Claude dogfoods itself: the root artifacts are both the live config and the bundle source. Bugs and ideas are welcome via Issues. To work on the config, see docs/guides/contributing.md.
📖 Further reading
License
MIT
