If you’ve been using Claude Code for real development work, you’ve probably assembled your setup from a handful of sources: superpowers for skills, caveman for compression, someone’s blog post for prompt structure, a Notion page or Obsidian vault for reference. Each piece is solid on its own. The problem is that none of them know the others exist.
I ran into this when a friend kept seeing Claude skipping documentation updates, claiming tests passed without running them, and producing commits that drifted from what they’d agreed to. These aren’t beginner problems. These are the problems that show up when you’re an actual developer using Claude to accelerate production work, and you need the output to be trustworthy.
So I built
Atomic Claude
: a single Claude Code configuration where commands, skills, agents, and output styles are designed as one system.
The core problem
Every Claude Code session starts fresh. Claude doesn’t know your framework, your package manager, or your build commands unless you tell it. So it guesses. It invents
npm run
scripts that don’t exist. It suggests
make
targets your Makefile doesn’t have. It assumes Jest when you use Vitest. You correct it, it forgets next session, and the cycle repeats.
Maybe you’re more disciplined and you maintain a CLAUDE.md with project context. Half of it is probably a tree dump, and the other half is hand-written notes about your stack that go stale the moment you add a dependency or rename a directory. Eventually you forget to update it, and Claude is back to guessing.
Atomic Claude solves this with something called
signals
.
The idea comes from two sources: the
Model Workspace Protocol paper
, which treats filesystem structure as agent architecture, and
Karpathy’s LLM knowledge base pattern
, where an LLM compiles raw source material into a markdown wiki with summaries, cross-references, and indexes, then reads its own wiki to answer questions.
Signals are that pattern applied to your codebase. The
atomic
CLI scans your repo (file tree, manifests like
package.json
or
go.mod
, language breakdown) and writes a deterministic snapshot. Then a separate inference agent reads that snapshot and “compiles” it into a structured context file: what framework you’re using, what your build and test commands are, how your project is organized, and where to look for what. Claude loads this file every session via
@
-ref. The result is that Claude stops guessing your stack. No hallucinated
npm run
scripts, no invented
make
targets, no wrong package manager.
This splits the job in two: your
CLAUDE.md
carries intention, rules, and steering.
signals.md
carries facts: infrastructure, build commands, project structure. One you write, the other writes itself.
The wiki auto-refreshes when your source tree changes (workflow commands trigger it), and you rarely edit it by hand.
What it does
Atomic Claude gives you a plan-to-PR workflow where each piece reinforces the others.
You bootstrap a repo with
/atomic-setup
, which audits your project conventions and proposes actions for anything missing (gitignore entries, docs directories, CLAUDE.md, signals wiring). Then
/refresh-signals
scans the project and writes the context files described above. From there:
/atomic-plan
writes a spec. It gauges whether the task is trivial (inline spec) or non-trivial (design doc plus spec, authored through a subagent loop with a reviewer checking alignment).
/subagent-implementation
runs an autonomous implement-then-review loop. A builder agent writes a failing test first, then implements. A separate reviewer agent re-runs typecheck and tests itself rather than trusting the builder’s claim. Non-blocking findings accumulate in a follow-ups ledger that you address at pause points.
Ten workflow commands (
/commit-only
,
/commit-and-pr
,
/squash-and-merge
, etc.) cover every combination of commit, push, squash, PR, and merge. They all share the same commit message format, the same signals refresh on source changes, and the same documentation-impact prompt.
Eight skills auto-fire on natural language. Say “let’s implement this” and TDD discipline kicks in. Say “looks done” and verification runs. Say “doc this change” and the documentation skill routes the update to the right file. Everything else is an explicit slash command.
The scratchpad system (
BRIEF.md
,
STATE.md
,
FOLLOWUPS.md
) lives on disk, not in context. Close your laptop,
/clear
the conversation, come back a week later, rerun the command. It picks up where you left off.
Reminders and follow-ups
Claude Code has the primitives for scheduling (cron and Routines), but no reminder workflow built on top of them. If you want to say “remind me about this in three days,” you’d have to wire up the cron job yourself, write the reminder somewhere, and figure out how to surface it when you open a new session. There’s also no built-in way to track non-blocking issues that came up during a task but weren’t worth stopping for.
Atomic Claude turns those primitives into two commands:
/remind-me
takes natural language (“check if the deploy finished in 30m”, “revisit error handling by next Friday”, “follow up on the PR before end of week”) and schedules a reminder. Short timers use cron, longer ones use Routines. When the reminder fires, it surfaces in your next session via a session-start hook. If scheduling tools aren’t available, it degrades to a file that still gets picked up at session open.
/follow-up
lists all pending reminders as an indexed list.
/follow-up review
triages stale project follow-up entries one at a time: extend, close, promote, or skip. Follow-up entries also accumulate during the implement-review loop — non-blocking reviewer findings that aren’t worth stopping for but shouldn’t be forgotten. You address them when the task finishes.
Why I built it instead of using what exists
I use and respect both
superpowers
and
caveman
. The intensity-level naming (lite, full, ultra) comes straight from caveman, and the TDD discipline, verification gates, and worktree workflows are superpowers territory. Atomic Claude borrows from both.
Stop-slop
by Hardik Pandya shaped how Atomic Claude handles prose output, adapted for developer documentation.
Where it diverges:
Caveman
pioneered compressed output and proved you can save ~65% on tokens without losing accuracy. I wanted something that read more like a colleague than a caveman. Full sentences when they help, terse fragments when they don’t, and visual responses by default: Mermaid charts for relationships, ASCII diagrams for flow, tables for comparisons. The goal was a compressed format I could scan faster and make decisions from, not one that trades readability for character count.
Superpowers
is the most comprehensive skill toolkit available for Claude Code. The catch for my use case was that skills auto-fire aggressively by design. An offhand comment can kick off a brainstorming session and a design spec before you’ve decided to build anything. Atomic Claude keeps the same disciplines but draws a firm line: skills auto-fire on natural phrasing; commands run only when you type the slash.
None of these projects were designed to compose with each other, and none were designed to compose with Claude Code’s own native features. Claude Code already comes with hooks, commands, skills, output styles, subagents, worktrees, cron scheduling, and
@
-refs. Atomic Claude wires those features into one system instead of building around them.
What it looks like
First session in a new repo:
/atomic-setup → audits conventions, proposes actions for what’s missing /refresh-signals → teaches Claude the repo’s shape
Day-to-day:
/atomic-plan → writes spec (gauges triviality first) /worktree-start feat/x → isolated branch with baseline tests /subagent-implementation → autonomous implement → review loop /commit-and-pr → commit + push + open PR
When things break:
/subagent-diagnose ci → pulls failed CI logs, drives fix loop /subagent-diagnose bug → starts from a symptom
Install
Two commands:
curl -fsSL https://raw.githubusercontent.com/damusix/atomic-claude/main/install.sh | bash atomic claude install
If you already have a
~/.claude/CLAUDE.md
, the installer backs yours up and gives you
/atomic-claude-merge
to reconcile the two. It keeps your instructions and deduplicates conflicts.
The
atomic
binary is a single Go executable. No runtime dependencies, no wrappers, no middleware.
atomic doctor
runs nine integrity checks to verify the install.
atomic update
self-updates. MIT licensed.
Website:
https://atomic.alonso.network/
Repo:
github.com/damusix/atomic-claude
submitted by
/u/alonsonetwork
Originally posted by u/alonsonetwork on r/ClaudeCode