# Build with AI and agents

Every page in these docs is also plain Markdown, and the whole API is one OpenAPI file. An assistant that reads them writes better Vabu OS code than one that guesses.

## What to give your assistant

| File | Use it for |
|---|---|
| [llms.txt](https://docs.vabu.live/llms.txt) | A short index of every page, grouped by product, with a one-line summary and a Markdown link. Start here. |
| [llms-full.txt](https://docs.vabu.live/llms-full.txt) | Every page in one file, for assistants that take a large paste or attachment. |
| [openapi.json](https://docs.vabu.live/openapi.json) | Exact paths, parameters, request bodies and responses. |
| Any page with `.md` on the end | One page as clean Markdown, for example `https://docs.vabu.live/guides/streams/quickstart.md`. |

Each page also has buttons at the top: **Copy page** puts its Markdown on your clipboard, **View as Markdown** opens it, and **Open in Claude** and **Open in ChatGPT** start a chat that reads the page.

## Claude Code

Tell Claude Code where the docs are, once, in your repo's `CLAUDE.md` (see the snippet below). To try it on one task, ask:

```text
Read https://docs.vabu.live/llms.txt, then the Streams quickstart it links to.
Add a route to this app that creates a live stream and returns a customer token.
Use the OpenAPI file at https://docs.vabu.live/openapi.json for field names.
```

## Cursor and other editors

In Cursor, add the docs under Settings, Indexing and Docs with the URL `https://docs.vabu.live/llms-full.txt`, then mention it in chat with `@Docs`. Other tools that accept a URL or a file can take `llms.txt`, `llms-full.txt` or `openapi.json` the same way. For tools that read an OpenAPI file, point them at `https://docs.vabu.live/openapi.json`.

## A snippet for your repo

Copy this into the `AGENTS.md` (or `CLAUDE.md`, or your tool's rules file) of the repo that calls Vabu OS.

````markdown
## Vabu OS

We call the Vabu OS API. Read the docs before writing code against it.

- Docs index: https://docs.vabu.live/llms.txt
- Every page as Markdown: add `.md` to its URL
- API description: https://docs.vabu.live/openapi.json
- Never guess a field, scope or error code. Look it up in the OpenAPI file.
- Use test keys (`vk_test_`, `rk_test_`, `vpk_test_`) in development and in tests. Never write a `vk_live_` key into code, a test, a fixture or a prompt.
- Keep keys in environment variables. Secret and restricted keys stay on the server. Only `vpk_` keys go to a browser.
- Send an `Idempotency-Key` on every POST that creates something.
- Verify webhook signatures before acting on an event, and ignore duplicate event ids.
- Money is in cents. Phone numbers are E.164, for example `+254712345678`.
````

## Use test keys while an assistant works

An assistant can run code, and it can make mistakes quickly. Keep it on test keys.

1. Create a test key in the dashboard. Test keys work from the first minute and everything they create has `"livemode": false`. See [environments and keys](https://docs.vabu.live/get-started/environments-and-keys.md).
2. Give the assistant a restricted key (`rk_test_`) with only the scopes the task needs. See [keys and scopes](https://docs.vabu.live/concepts/keys-and-scopes.md).
3. Put the key in an environment variable or a local `.env` file that is not committed. Do not paste it into a chat.
4. Check [test mode](https://docs.vabu.live/concepts/test-mode.md) for what works with test keys. A call that is not available in test mode answers `403 test_mode_unavailable`. Do not switch to a live key to get past it.
5. Run the assistant's code against test keys first. Move to live keys yourself, in your own deploy settings, after you have read the diff.
6. If a key reaches a chat, a log or a commit, revoke it in the dashboard and create a new one.