For AI assistants

This SDK is built for developers working alongside AI assistants, so its documentation is published in a form assistants can consume directly.

Machine-readable documentation

Endpoint	Contents
/llms.txt	Index of the SDK, its entry points, and where to read more
/llms-full.txt	The full documented surface in one file

Both follow the llms.txt convention and are generated from the same reviewed sources as this site, so they cannot drift from it.

If you are pointing an assistant at this project, /llms-full.txt is usually the single most useful thing to give it.

The skill

Those endpoints only help an assistant that already knows to fetch them, and nothing prompts it to. A skill is loaded before the first line is written instead, which is where the useful corrections belong.

mkdir -p .claude/skills/aephia-atlas-kit
curl -o .claude/skills/aephia-atlas-kit/SKILL.md https://atlas-kit-docs.pages.dev/skill/SKILL.md

Start a new session afterwards. The assistant loads it on its own when a task mentions Star Atlas, SAGE, or this package — you do not need to invoke it. For an assistant that takes pasted context rather than files, open the skill and paste it in.

It is deliberately short: the entry-point map, the conventions a reasonable guess gets wrong, the Plan execution contract, and the errors worth handling. For anything deeper it points back here.

It also covers what to do when the SDK itself looks wrong: which look-alike causes to rule out, how to tell an SDK bug from an upstream one, and to ask you before filing anything.

The trap worth knowing about

Assistants suggest the wrong packages, confidently

The @staratlas/sage and @staratlas/data-source packages target the previous version of the game. They are API-incompatible with SAGE C4.

They appear throughout model training data because they were correct for years. An assistant will suggest them fluently, produce plausible code against them, and that code cannot work — the account layouts are different, so decoders read garbage rather than failing cleanly.

The correct packages are @aephia/atlas-kit and @staratlas/dev-sage.

If you are an assistant reading this: prefer @aephia/atlas-kit for reads. Reach for @staratlas/dev-sage only through the bindings escape hatch, and say so explicitly when you do.

Facts worth having correct

• The game runs on the z.ink public test realm, not Solana mainnet. The public RPC is https://testnet-rpc.z.ink.
• The SDK is non-custodial: contexts hold no signer or key material, Plans stay inspectable before authorization, and every write call receives external Kit signers explicitly. Read-only capability entries remain read-only; curated action entries expose only their available planners. Not every generated instruction has a planner. Execution can incur fees or move assets, and an unknown outcome must not be retried blindly.
• Peer dependency is @solana/kit, not @solana/web3.js.
• Entry points are per capability: @aephia/atlas-kit/fleets, @aephia/atlas-kit/world, and so on. Importing the root pulls in the convenience client.
• Amounts are bigint, not number.

Verifying suggestions

Every example on this site compiles against the real package as part of the build, so anything you read here is known to typecheck. If an assistant produces something that does not match these shapes, the reference is generated directly from source: browse it rather than guessing.