For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /docs/web/agents.md (or send Accept: text/markdown).
Build with a coding agent
Hand tasks to a coding agent: the files it reads, the pasteable prompt library, unattended setup, and the review that keeps you in control.
Beginner walkthrough
Prerequisites: Read the two beginner guides below, finish Web local setup, and open this repository at its root in your editor. A coding agent is an AI tool — Cursor, Claude Code, Devin or a similar assistant — that reads your project, edits files and runs commands. Everything on this page applies to whichever one you use.
Quick terms: a prompt is the instruction text you paste into the agent. A diff is the list of file changes it proposes. The repository root is the top folder containing package.json — the agent should always start there.
1. Open the prompts/ folder in the repository root and copy the prompt closest to your task. new-landing-page.md is a good first try.
2. Paste it into your agent and fill the <placeholders>: the route you want, what the page or screen should do, who may use it, and what success looks like. Then add one line: Read llms.txt, then AGENTS.md, then .ai/PROJECT_CONTEXT.md before touching code.
3. Let the agent list the files it will change and the checks it will run before it edits. When it finishes, review the diff — you are approving real changes to your product.
4. Publishing, deploying and paid provider calls are never part of a task prompt. Keep them as separate steps you approve explicitly.
The files your agent reads
The repository ships a small stack of files written for agents, not only for humans. You never paste this context by hand — point the agent at llms.txt and it reads the rest itself.
Read order matters: llms.txt is the map, AGENTS.md sets the boundaries, and .ai/PROJECT_CONTEXT.md carries what earlier sessions learned. An agent that skips the boundaries produces code you cannot ship.
| File | What it gives the agent |
|---|---|
| llms.txt | The repository entry map — every doc worth reading plus the security protocols, in read order |
| AGENTS.md | The non-negotiable boundaries: local work only until you approve more, workspaceId scoping, server-only secrets |
| .ai/PROJECT_CONTEXT.md | Cross-session memory — what changed recently and why; read before code changes |
| .ai/ mirror docs | A matching .ai/<path>.md note beside important files, recording per-file decisions and open threads |
| docs/agent-setup.md | The unattended runbook — install, migrate and deploy phases with a verification checkpoint after each |
| prompts/ | Pasteable task prompts for the jobs owners ask for most |
| docs/agent-security.md | The acceptance checklist — authentication, workspace and RLS checks, redacted logs, deployment evidence |
| .env.example | The complete environment inventory — the agent never invents a variable name absent from this file |
The prompt library
prompts/README.md is the index. Each file is a complete brief: paste it, fill the <placeholders>, and the kit's rules — design tokens over hardcoded colors, kit blocks over invented patterns — travel with it.
For the zero-to-running path, paste prompts/agent-setup.md instead — it drives the unattended setup described next.
agent-setup.md— stand the kit up and deploy it with an agentpick-a-style.md— apply a design style across the whole productnew-landing-page.md— scaffold a marketing page from kit blocksnew-app-screen.md— add a screen inside the workspace app shellrestyle-product.md— re-theme an existing page onto kit tokensui-audit.md— run the visual and accessibility audit on a route
Letting the agent install and deploy
The kit can largely set itself up. Pasting prompts/agent-setup.md makes the agent execute docs/agent-setup.md — the shipped runbook — phase by phase: preflight checks, environment files, install, database start, migrations, app start, and optionally a VPS deploy. After each phase it runs that phase's verification checkpoint and reports real output, not a claim.
Two helpers keep that safe. scripts/setup-env.mjs bootstraps the env files from .env.example: it creates only missing files, generates only missing or placeholder secrets, and its --check mode validates without writing. docker-compose.dev.yml is a fully containerized dev environment — Postgres plus a Node 22 dev container — so the agent does not need Node.js installed on your computer.
Which repository you received matters here. The Web repository and the All Platforms monorepo ship the runbook, the compose files, scripts/setup-env.mjs and prompts/. The standalone Mobile and Desktop repositories ship a scoped llms.txt, AGENTS.md, the .ai/ mirror docs and curated docs including docs/agent-security.md — but not the setup runbook or compose files, because the backend those apps talk to lives in the Web repository.
How the agent remembers between sessions
Agents have no memory between sessions — the .ai/ folder is the memory. .ai/PROJECT_CONTEXT.md records what changed recently and why. Beside it, a mirror doc such as .ai/apps/web/src/reports.md explains the decisions behind apps/web/src/reports.ts that the code alone does not show.
The contract is simple: read a file's mirror before editing it, and update the mirror when the change lands. Open Threads entries record unfinished work so the next session resumes instead of starting over. A stale mirror is worse than none — when you review the agent's diff, check that the mirrors of changed files moved with it.
The running app's own agent surface
Your deployed product answers agents too — these endpoints exist on the running app, not only in the repository.
GET /llms.txt— the app serves its own llmstxt.org index: the guides, public pages and public endpoints, with absolute URLs.POST /api/mcp— a stateless MCP endpoint exposing the app's tools. It acceptssk_API keys as bearer tokens only — browser cookie sessions never apply. Create keys under Settings → Developers.GET /api/v1/openapi— the OpenAPI specification of the public REST API, for client generators and agent tools.GET /api/health— the liveness and dependency probe that load balancers and uptime checks call; it reports provider configuration kinds, never secrets./status— a human-readable page reporting each subsystem's health.
Review the agent's work honestly
A finished task is evidence, not a summary. Before you keep the agent's work, check it the way docs/agent-security.md checks a deployment:
When something is wrong, send the diff back — the agent fixes its own work fastest when you name the failing check. For anything it should never have attempted alone, say so explicitly once; the boundary holds for the rest of the session.
- It ran the tests it claims — ask for the command and its output, not a conclusion.
- Secrets stayed server-only — nothing new carries a
NEXT_PUBLIC_orEXPO_PUBLIC_prefix, and no key was printed into a report or commit. - Every user-owned read and write stayed scoped by
workspaceId— no query trusts an id sent by the browser. - The
.ai/mirror of each changed file moved with the code. - Publishing, deploying and paid provider calls stayed separate steps you approved — the agent never merged, pushed or deployed on its own.
- If a step failed twice, it stopped and reported the failing command instead of improvising around it.
If you want to continue setup, read Create your external accounts.