Use this handbook with an AI assistant
This handbook is written to be read by people and by language models. Every page is available as plain Markdown, and there are two machine-readable indexes.
| Address | What it is |
|---|---|
/llms.txt |
A short index in the llms.txt format: every page, one line each, linking to its Markdown |
/llms-full.txt |
The whole handbook as one Markdown file, in navigation order, for a single large-context paste |
/md/<page>.md |
The Markdown source of one page, for example /md/games/manifest.md |
/sitemap.xml |
Every page address, for crawlers |
All of them are generated by npm run build, so they always match the pages you are reading. Screenshots appear in
llms-full.txt as [Image: description], using the alt text written for each one, so an assistant can tell what a
screenshot shows. Screenshot slots that have not been filled appear as [Screenshot not yet added: …].
Give an assistant the handbook
Pick whichever fits your tool:
- A chat assistant with web access: give it the address of
llms.txtand ask it to read the pages it needs. - A chat assistant without web access: paste
llms-full.txt, or only the pages for your task. - A coding agent in your game's repository: save
llms-full.txtnext to your code (for exampledocs/vapour.md) and reference it from your agent's instructions file.
A prompt that works
You are helping me publish a web game on Vapour. Use ONLY the attached handbook as your source of truth.
Rules:
- Each feature is labelled Released, Preview or Planned. Do not tell me a Preview or Planned feature is available.
- If the handbook does not say something, say you don't know. Do not guess flags, file names or limits.
- When you give a vapour.toml, use only keys from the "vapour.toml reference" page.
- When you give a command, copy it from the handbook.
My engine is <Godot | Unity | Bevy>. My goal is: <what you want to do>.
What an assistant gets wrong without this
These are mistakes an assistant is likely to make, and the page that corrects each:
| Likely mistake | Truth | Page |
|---|---|---|
Invents vapour.toml keys such as [game] or output |
The keys are fixed and listed | vapour.toml reference |
| Says publishing from CI works | vapour-ci@v1 is not released yet |
Status |
| Puts the profiler or overlay in the published build | They exist only under vapour test and never enter your build |
Profile locally |
Uses build/web as a Bevy output folder |
In the Bevy template that folder holds source files | Bevy tutorial |
| Maps touch controls to mouse actions | Controls can only press keys, so each action needs a key | Godot tutorial |
| Says the profiler shows per-asset load cost for a live game | Only a trace that already contains asset records does; nothing creates them yet |
Find expensive assets |
Says vapour template gives you a working game |
The templates are skeletons with no engine project, so vapour build fails until you add one |
Create or import a project |
| Assumes a Unity build was run | Not built by us | Unity tutorial |
How the pages are written for machines
- Status is stated in text, not by colour: every tool is Released, Preview, Planned or Not run.
- Settings are in tables with the type, whether it is required, and the exact rule.
- Error messages are quoted exactly, next to the fix, so a model can match what you paste to the cause.
- Commands and file contents are in code blocks and are real output from the tools, not retyped.
- Every screenshot has descriptive alt text.
- One H1 per page, and a navigation file (
SUMMARY.md) that lists every page once.
If you find a page where a model would be misled, open an issue.