Atomic is our open-source set of AI coding assistant skills, and it runs the same way in Claude Code, OpenAI Codex and GitHub Copilot. Its two skills, generate-fake and update-fake, ship from a single codebase, so a team can change assistants without rebuilding its testing workflow. Swapping the tool leaves the practice intact.
This piece covers how the skills work in each assistant, and a mistake we corrected in the first week.
Why AI coding assistant skills lock teams in
Teams now write a lot of process into their assistants. Prompt files, skill definitions and project instructions encode how a team tests and reviews its work. That is good practice, but each assistant expects those files in its own place and format, so a workflow built for one assistant tends to stay with it.
And teams rarely run a single assistant. Engineers have preferences, and enterprise contracts sometimes decide which tool a project uses. A workflow that only runs in one of them either gets rebuilt for each tool or keeps the team on an assistant for longer than it deserves.
The two testing skills in Atomic 0.1.0
The first release focuses on testability, and specifically on fakes. Atomic's README defines a fake as a cut-down version of an application that exposes the same integration surfaces as the real one, such as HTTP APIs, message queues and gRPC, and returns canned or simple deterministic responses. It runs in a single container on a laptop, and the application's own team owns and maintains it.
The idea has deep roots here. In Uncomfortably Simple: A Framework for Builders, we argued that anything that does not test the hypothesis should be faked. Atomic turns that into something an agent can do on request.
generate-fake inspects an application, finds its integration surfaces and builds the fake under /fake/, along with a Dockerfile, a README, a fragility report and a manifest recording what it was built from. update-fake reads that manifest later and checks for drift using three signals: a spec diff, a source-code diff and the git history. It classes each change as additive, breaking or cosmetic, and it never applies a breaking change until a person approves it.
How one codebase serves three assistants
The mechanics are simpler than they sound. Claude Code and Codex use the same SKILL.md format, so one file serves both. Codex looks for skills under .agents/skills/, and Atomic ships that folder as a symlink to its canonical skills/ directory.
Copilot works differently. It reads slash-command prompt files from .github/prompts/, and those need different frontmatter and rewritten links, so Atomic generates them from the canonical skills with a script, scripts/sync-skills.py. Nobody edits the Copilot files by hand.
One behavioural difference remains. Claude Code and Codex can pick up a skill on their own when a request matches its description, while Copilot only runs a prompt when someone calls it by slash command. The steps behind each skill are identical in all three tools, even though the way you trigger them differs.
We started with one assistant
Atomic did not begin as a tool-agnostic project. Its commit history shows the plugin landing on 16 May 2026 as Claude Code skills only. The Codex and Copilot formats followed on 19 May, three days later.
That retrofit was quick because there were only two skills and they were small. A larger library written for one assistant would have taken far longer to move. So the README now treats skills/ as the single canonical source, and everything each assistant reads is either the same file or generated from it.
Why vendor-neutral skills matter to us
We apply the same rule to models in production. No single vendor should be a hard dependency, and the practices that matter should survive a switch. Atomic extends that rule to the assistants our engineers use every day.
Atomic's design principles also put specs first. Where an OpenAPI, AsyncAPI or protobuf contract exists, the skills treat it as ground truth before inferring anything from code. That keeps a fake anchored to what the service is supposed to do, whichever assistant generated it. It is the same spec-first thinking behind ACDC and ATOM, the delivery method and operating model we describe in Introducing ATOM. The README's roadmap points at future skills for legacy code understanding, refactoring, documentation and migration, with nothing yet committed.
How to try Atomic on your own service
Atomic is public on GitHub under the Apache-2.0 licence at github.com/missionplus/atomic. Pick a service that other teams depend on, open it in whichever assistant you use, and ask it to generate a fake. In Copilot, run /generate-fake explicitly.
Then point one downstream test suite at the fake instead of the real dependency and see how much faster it runs. When the service changes, run update-fake and read the drift report before you approve anything. If your testing approach is currently tied to one assistant, that first fake is a cheap way to find out how much of it would travel.
