# Build with AI agents

Each page is also served as Markdown. The files below give a coding agent the same facts these pages give you.

## What is here for machines[​](#what-is-here-for-machines "Direct link to What is here for machines")

| Resource             | URL                                                                       | Use it for                                                                                      |
| -------------------- | ------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| Index                | `https://dzbuild.dev/llms.txt`                                            | The list of pages with one line each. Paste it into a chat or point an agent at it.             |
| Whole site           | `https://dzbuild.dev/llms-full.txt`                                       | Every page in one Markdown file.                                                                |
| Any page as Markdown | the page URL plus `.md`, for example `https://dzbuild.dev/oauth.md`       | One page without navigation. Arabic and French pages work the same way under `/ar/` and `/fr/`. |
| Agent skill          | `https://dzbuild.dev/skills/dzbuild-apps/SKILL.md`                        | The facts and rules an agent needs to build a DZBuild app.                                      |
| AGENTS.md template   | `https://dzbuild.dev/agents/AGENTS.md`                                    | A starting file for your app's repository.                                                      |
| OpenAPI description  | `https://dzbuild.dev/openapi/dzbuild-apps-v1.json`                        | Every operation an install token can call, with parameters, scopes and response shapes.         |
| Example app          | [dzbuild-app-starter](https://github.com/DZBuild-com/dzbuild-app-starter) | Three Cloudflare Worker presets and a Node.js example, each with tests.                         |

Every HTML page also carries `<link rel="alternate" type="text/markdown">` pointing at its Markdown twin, so a tool that reads the page can find the plain version on its own.

## Give your agent the skill[​](#give-your-agent-the-skill "Direct link to Give your agent the skill")

The skill file follows the Agent Skills format: a short description that tells the agent when to use it, then the instructions. Claude Code reads skills from `.claude/skills/` in your project or `~/.claude/skills/` on your machine:

```
mkdir -p .claude/skills/dzbuild-apps

curl -sSf https://dzbuild.dev/skills/dzbuild-apps/SKILL.md -o .claude/skills/dzbuild-apps/SKILL.md
```

For agents that read an `AGENTS.md` at the root of the repository (Codex, Cursor and others), start from the template and keep your own project rules under it:

```
curl -sSf https://dzbuild.dev/agents/AGENTS.md -o AGENTS.md
```

Both files repeat the rules of this site, so your agent works from the same facts you do.

## Give your agent the docs as an MCP server[​](#give-your-agent-the-docs-as-an-mcp-server "Direct link to Give your agent the docs as an MCP server")

`@dzbuild/docs-mcp` gives any MCP client these pages and the API reference, read from dzbuild.dev, with no credentials. The [/agents/connect](https://dzbuild.dev/agents/connect) page has the command or config for Claude Code, Codex, Cursor and Claude Desktop.

## Ask a question about one page[​](#ask-a-question-about-one-page "Direct link to Ask a question about one page")

Under every page there is a bar with **View as Markdown**, **Copy Markdown**, **Open in ChatGPT** and **Open in Claude**. The last two open a new chat that starts by reading that page. The prompt they send is:

```
Read https://dzbuild.dev/oauth.md so I can ask questions about it.
```

For a task rather than a question, give the agent the index and the skill together, then describe what the app does for the merchant:

```
Read https://dzbuild.dev/llms.txt and https://dzbuild.dev/skills/dzbuild-apps/SKILL.md.

Build a DZBuild app in Node.js that installs on a store through the OAuth flow,

stores one token per store, verifies webhooks, and posts a message to our Slack

channel when an order is confirmed. Secrets come from environment variables.
```

## Generate a client from the OpenAPI description[​](#generate-a-client-from-the-openapi-description "Direct link to Generate a client from the OpenAPI description")

The description is OpenAPI 3.1. Import it into Postman or Insomnia, or generate types and a client:

```
curl -sO https://dzbuild.dev/openapi/dzbuild-apps-v1.json

npx openapi-typescript dzbuild-apps-v1.json -o dzbuild-apps-v1.d.ts
```

The `dzOAuth` security scheme in the file lists every scope with its description. The file declares `https://api.dzbuild.app` as its server, which is the host your app calls.

## Keep secrets out of the chat[​](#keep-secrets-out-of-the-chat "Direct link to Keep secrets out of the chat")

An agent only needs to know that a secret exists, never its value.

* The client secret, the signing secret and every install token live in environment variables or a secret store on your server. Do not paste them into a prompt, a repository or a log line.
* If a secret reaches a chat or a commit, rotate it in the developer console. The old client secret stops at once; tokens already issued keep working, and rotating the signing secret changes it for every install at once, so deploy the new value right away.
* An agent must not sign in to the DZBuild dashboard as the merchant, script it, or scrape storefront pages. Store data is reached only through the REST API and webhooks, as the [security rules](https://dzbuild.dev/security.md) say.
* Redirect URIs are compared character for character. Register in the console the exact URI your code sends, on `https`, with the same trailing slash.

## What assistants get wrong without the docs[​](#what-assistants-get-wrong-without-the-docs "Direct link to What assistants get wrong without the docs")

These come up often when an app is written from general OAuth or webhook knowledge. The pages linked settle each one.

* Expecting `expires_in` and a refresh token. Install tokens have neither; they work until the merchant uninstalls or installs again. See [Core concepts](https://dzbuild.dev/concepts.md).
* Sending a write without an `Idempotency-Key`. `POST`, `PATCH` and `DELETE` answer `400` without one. See [Rate limits](https://dzbuild.dev/rate-limits.md).
* Parsing the webhook body before checking the signature. The HMAC covers the raw bytes, so a re-serialized body never matches. See [Webhooks](https://dzbuild.dev/webhooks.md).
* Registering the webhook through `POST /v1/webhooks`. Apps get `403` there; the webhook URL is set once on the app in the console. See [API reference](https://dzbuild.dev/api-reference.md).
* Asking for every scope. The merchant sees one line per resource on the consent screen, and the review compares the scopes with what the listing says the app does. See [Scopes](https://dzbuild.dev/scopes.md).
* Building a store switcher inside one token. A token reaches its own store only; use the token of each store from the `stores` list of the token response. See [OAuth](https://dzbuild.dev/oauth.md).
