# Build with AI

> This documentation is written to be read by AI coding agents. Here is how to point one at it and get a working mini app.

Source: https://miniapp.sollar.com/ai/

---

A company should be able to point an AI coding agent at this site and get a working mini app of its
own ERP, without a specialist who already knows the platform. That is a design goal of the
documentation, not an afterthought — and it is why every page here states its constraints in prose
rather than assuming background knowledge.

## Point an agent at the docs

Give the agent this line:

```
Read https://miniapp.sollar.com/llms.txt and build a Sollar mini app that <what you want>.
```

| Artifact | What it is |
|---|---|
| [`/llms.txt`](/llms.txt) | An index of the whole site, plus the rules an agent needs before writing a line |
| [`/llms-full.txt`](/llms-full.txt) | Every page concatenated, for an agent with room for it |
| `<any page>.md` | The Markdown source of that page — e.g. [`/reference/manifest.md`](/reference/manifest.md) |
| [`/schemas/manifest.schema.json`](/schemas/manifest.schema.json) | JSON Schema 2020-12 for the manifest |
| [`/schemas/sollar.d.ts`](/schemas/sollar.d.ts) | The canonical bridge type definitions |

The `.md` twins are generated **from the source Markdown**, not scraped back out of rendered HTML.
An agent fetching `/reference/manifest.md` gets what the author wrote, with the tables intact.

## Scaffold a project

```sh
sollar create-mini-app acme-erp --template react
cd acme-erp
```

The scaffold writes two files that matter to agents:

```
AGENTS.md      ← the instructions
CLAUDE.md      ← one line: @AGENTS.md
```

**Why two.** `AGENTS.md` is the filename Codex, Cursor, Jules, Factory and Aider look for. Claude
Code reads `CLAUDE.md` and does **not** read `AGENTS.md`. Rather than maintaining the same
instructions twice and letting them drift, `CLAUDE.md` imports the other:

```markdown title="CLAUDE.md"
@AGENTS.md
```

One file is the source; the other is a pointer. Never duplicate the content by hand — a duplicated
instruction file is worse than none, because half of it will be a year out of date and nothing will
say which half.

See [AGENTS.md](/ai/agents-md/) for what to put in it.

## What an agent gets wrong without being told

Every one of these has a page that explains it; an agent that has not read that page will get it
wrong in a way that looks plausible. Put them in your `AGENTS.md`.

**It will invent bridge methods.** `sollar.getLocation()`, `sollar.camera.take()`,
`sollar.requestPayment()` — all reasonable-looking, none real. The bridge covers only Sollar's own
domain; device capabilities are standard Web APIs. → [Bridge API](/reference/bridge-api/)

**It will trust the client.** `sollar.identity.get()` returns an `app_user_id`, and an agent will
happily authorise against it. It is UI convenience. Authorisation happens on the server, against the
token. → [Authentication](/guides/authentication/)

**It will post to a room from the server.** The obvious design for "notify the channel when the order
is approved" is a server-side call, and it does not work in an encrypted room — which, in the
Enterprise and Sovereign tiers, is every room by default.
→ [Messaging and rooms](/guides/messaging-and-rooms/)

**It will fetch a host that is not in the manifest.** The network allowlist is enforced natively and
the failure is `ERR_HOST_NOT_ALLOWED`. Adding a host means a new version.
→ [Manifest](/reference/manifest/)

**It will write a permission check in JavaScript.** Permission decisions are made in native code
against the signed manifest. A JavaScript check is not a check.
→ [Permissions](/guides/permissions/)

**It will guess the version.** Do not let it. Run `sollar --version` and read
[the baseline](/reference/baseline/).

## Verify, do not trust

An agent will produce a mini app that looks right. Two commands decide whether it is:

```sh
sollar validate --strict     # the same checks the submission gate runs
sollar test --conformance    # the ES2022 floor, the CSS baseline, every bridge method
```

`--strict` applies the store review checks — purpose strings, justifiable hosts, SBOM, no remote
scripts, no `eval`. Running it in CI turns a review rejection three days from now into a red build
in ninety seconds.

## Writing actions an agent uses correctly

The other half of "build with AI": your mini app's `actions[]` are tools that *other* agents will
call. Writing a description is engineering, and the rules are in
[Agent actions](/guides/agent-actions/):

- Make implicit context explicit — "only the current user's queue, never another's".
- Fully qualify parameter names — `purchase_order_id`, not `id`.
- State units and formats — `amount_minor`, `currency_code` in ISO 4217.
- Say what is irreversible. It is what makes an agent stop and ask.
- Return errors that teach: *"Order 4471 was already approved on 2026-08-30 by another approver"*
  beats `ERR_CONFLICT`, which teaches nothing and invites a retry.
- Prefer a few coarse actions to many fine ones.

## An honest note about this site

The platform described here is **specified, not built**. An agent reading these pages is reading a
design contract. Everything is internally consistent and evidence-backed, and none of it has been
run in production or audited by an independent team.

If you are generating code against it, generate against the schemas — they are machine-checkable —
and expect the surface to move before launch.