The Skills
atlas skills install writes six skills plus a vendor-neutral AGENTS.md. Each skill is a short document covering one part of load testing: what to do, in what order, and which mistakes to avoid.
They are plain Markdown. Read them, edit them for your project, commit them — they are yours once installed.
How they load
Claude Code reads each skill's description and loads the one that fits your request, so you never name a skill yourself. Ask "why did the test fail?" and it loads the results skill; ask "record a checkout" and it loads the recording one. Several can load in one conversation as the work moves on.
Assistants without skill support read the same guidance, condensed, from AGENTS.md.
What each one covers
atlas-load-test
The end-to-end flow, and the one that usually loads first for "load test our checkout". Picking or creating a plan, uploading data, sizing, the mandatory smoke run, then the real run and the report. Mostly it sequences the others.
atlas-record
Recording a scenario from a real browser. Choosing who clicks — you or the assistant — driving the browser through the accessibility tree, naming transactions before performing them, signing in without handing over a password, and the traps: native dialogs that freeze a session, one click recording two requests, everything before the first action landing in one transaction.
atlas-test-plan
Plans and data files, and the longest of the six. Downloading before editing, the three kinds of change in order of preference, and how these plans are laid out — think-time settings, host settings, the numbered transactions that make a report readable, and sizing through run-time properties.
It also carries the two things that save the most time in practice: the stages for turning a fresh recording into a real test (flow → test data → dynamic values → checks → upload), and a local debugging recipe that switches think time off in a throwaway copy, runs one user, and restores the original — seconds instead of minutes per attempt.
atlas-correlate
Values the server issues per session — CSRF tokens, session ids, cart ids — and why a replayed one produces a fast, clean, meaningless test. Reviewing what the recorder detected with its evidence, pinning what it missed, and telling those apart from values that belong in a data file instead.
atlas-run
Starting and sizing a run: how users map onto machines, ramp-up, fixed machines versus a cluster, pass/fail thresholds, exit codes and CI usage, and what to do while a run is queued behind someone else's.
atlas-analyze
Reading a result: the aggregation report, the shape of a run over time, the errors behind a failure — and recognising the failure modes where a broken test looks like a healthy one. If you only read one, read this one.
Editing them
Installed skills are ordinary files in your repository. Adding your own conventions is normal and encouraged:
- which project maps to which service
- the thresholds your team gates on
- environments that must never be load tested
- who to ask before a run above a certain size
atlas skills install will not overwrite a file you have edited unless you pass --force, so your changes survive an upgrade. When you do upgrade, diff first.
Listing what you have
atlas skills list # what this CLI version carries
atlas skills install --force # refresh after upgrading the CLI