Working with AI assistants

Orblit is younger than any language model’s training data, and nothing in it is API-stable yet. So an assistant asked about it either knows nothing, or remembers a name that has since changed and uses it with complete confidence. The fix for both is the same: give it the documentation, in a form it reads well, before it writes anything.

The site, as Markdown

Every page here is also plain Markdown, and there are two files written for models in the format llmstxt.org describes:

/llms.txt	An index: what Orblit is, the few things a model gets wrong without being told, and every page with a line about it
/llms-full.txt	Every page in one file, in the order the sidebar shows them
Any page, with .md	/start/installing/ is also /start/installing.md, and so on for every page

They are built from the same source as the pages you are reading, when the site is built, so they cannot say anything the pages do not. A few things change on the way, because they only mean something to this site:

• Code blocks are copied exactly. The one change is that a block this site marks dart fragment or dart ignore, for its own snippet checker, is marked plain dart.
• Links that point elsewhere on this site are made absolute, so they still work when the file is read somewhere else.
• The cards on the home page and the community page become paragraphs and lists.

llms-full.txt includes every example in the gallery, which makes it long. Most of it is code, and it runs to tens of thousands of tokens. That suits a model with a large context. For a smaller one, start it on llms.txt and let it fetch the pages it needs.

Pointing an assistant at it

An assistant that can fetch a URL only needs telling where to look. Asking it to read https://orblitengine.com/llms.txt before it starts is usually enough.

In a project of your own, put the same thing where your assistant reads its standing instructions. That is CLAUDE.md for Claude Code and AGENTS.md for most of the others:

CLAUDE.md

This project uses Orblit, a pre-alpha 3D engine for Flutter. Its APIs change
between commits, so don't rely on memory: read
https://orblitengine.com/llms.txt, and the page for the part you're working
on, before writing Orblit code.

A skill for Claude Code

The engine’s repository is also a Claude Code plugin marketplace with one plugin in it: a skill that loads whenever a task involves Orblit. It carries the model the rest of this site assumes (a scene stated whole every frame, keys, photometric units, sampled time) and the traps that catch people. Above all, it tells the assistant to check every name against the engine source your project actually resolved before writing it, instead of trusting what it remembers. Install it from inside Claude Code:

/plugin marketplace add ChxisB/orblit
/plugin install orblit@orblit

From a terminal, the same is claude plugin marketplace add ChxisB/orblit and then claude plugin install orblit@orblit. After that it loads by itself, and /orblit:orblit calls it directly. It describes the engine as it was at one commit, so where it and the source disagree, the source wins. claude plugin update orblit@orblit brings in a newer copy, and takes effect when Claude Code restarts.

The skill is a folder of Markdown, skills/orblit in the engine’s repository, so you can point an assistant without plugins at it too.

What none of this fixes

The Dart on this site is compiled against the engine in CI, so the examples an assistant reads are real. Nothing checks what it writes from them until you run it. Treat its Orblit code the way you would treat a snippet from a stranger’s gist: flutter analyze first, and the package reference when a name looks unfamiliar.