Atomic ClaudeHigher accuracy. Less busywork.

Claude explores your repo first ​

New chats start blind. Claude doesn't know your framework, your build command, or how your code is organized, so it guesses. The guesses surface as invented npm scripts and wrong assumptions about your architecture.

One scan fixes that. /refresh-signals is a Karpathy-inspired repo explorer: it walks your repo and builds a standing model of it.

• The facts. Directory tree, manifests, languages, lockfiles. Reproducible and idempotent.
• The meaning. Framework, build, test, and lint commands, architectural style, and a domain map of which directories form which feature, across every layer.

Claude reads that model before it reads your code, so it knows what it's looking at before your first question. Ship commands refresh it as the repo changes, so the map stays current and you don't hand-maintain a CLAUDE.md that drifts.

Hand off the whole feature ​

Most workflow tools stop at scaffolding a plan. /autopilot takes a task description or a GitHub issue number and runs the entire lifecycle on its own.

/autopilot 142 squash-and-merge

   → Reads issue #142. Writes a spec: controller, service, DTO,
     queue, signature validation.
   → Worktree-isolated. Builder implements each checkpoint;
     atomic-tdd fires — failing test first, then code.
   → Reviewer re-runs tests and gates against the spec. Every
     finding, blocking or not, gets fixed in-iteration.
   → Stuck twice on the same error? It dispatches a read-only
     strategist for root-cause analysis, then keeps going.
   → Squashes, merges, closes the issue.

One decision is yours: how to merge. Everything else runs unattended. To stay in the loop, run the same steps as individual commands (/atomic-plan, /subagent-implementation, then a ship verb), each with its own approval gate.

The config learns from you ​

Most setups are static. You write rules once and they rot. /atomic-improve runs a retrospective instead: it reads your recent session history and the current conversation, finds where Claude caused friction, fought you, or repeated a mistake, and cross-checks it against your installed skills, rules, and memory.

/atomic-improve

   → Scans the last 5 sessions plus this conversation.
   → Finding: you corrected the commit format three times across
     two sessions. Proposes a one-line edit to atomic-commit.
   → Finding: a skill fired on the wrong trigger twice. Proposes
     tightening its description.
   → You accept two, skip one. It writes a learnings log so the
     next run knows what you keep and what you drop.

Nothing changes without your yes. But over weeks the config stops being someone else's defaults and becomes yours.

And the replies are tighter ​

Same question, same model. Default Claude Code on the left, Atomic Claude on the right.

Sure! I'd be happy to help you understand
that. The issue you're experiencing is
likely caused by the middleware not properly
validating the token expiry timestamp. What's
happening is that the comparison uses a strict
less-than operator when it should be using
less-than-or-equal-to, which means tokens that
expire at exactly the current second are
incorrectly rejected.

I'd suggest updating the comparison on line 42
of src/auth/middleware.ts...

Bug in auth middleware. Token expiry check at
src/auth/middleware.ts:42 uses `<` not `<=` —
tokens expiring at current second get rejected.

Fix: change `token.exp < now` to
`token.exp <= now`.

Same accuracy. Fewer tokens. Faster to scan.

Pick your depth ​

You don't have to adopt all of it. Start where it helps.

1. Compressed replies only. Install, activate the output style via /config. Done. Everything else is optional.
2. A repo explorer. Run /atomic-setup + /refresh-signals in your repo. Claude stops hallucinating build commands.
3. Full plan → implement → review loop, or autopilot. Read the workflow reference.

Not sure where to begin? Run /atomic-help in any repo. It reads your git state and recommends one next command.