Templates

A template is a whole working app you can install into a space: its tables, its interface, its sample rows, and — the part that makes it different from a folder of tables — the manual its author wrote for agents. Installing one gives your agent something it can act on without you explaining your schema first.

Mechanically, a template is a package that is also an Agent Skill. The same directory carries a root SKILL.md next to busabase.json and content/:

busa-email/
├── SKILL.md          ← what an agent reads
├── references/       ← carried alongside it
├── busabase.json     ← manifest, with a `template` object
└── content/          ← a plain busabase-package@1 tree

Everything under content/ is byte-for-byte an ordinary package. That has three consequences worth knowing up front:

• A template directory is already a valid package — busabase-cli install could always install it; it just wouldn't land the manual, stamp ownership, or merge the sample rows.
• Any package becomes a template by adding a root SKILL.md and a template object. No migration, no format v2.
• A package that fails the template rules is never refused — it installs as a plain package, exactly as it did before templates existed.

Two ways in, one set of resources

There are two doors into your space, and which one a person uses is a matter of where they already are:

Both create the same resources, and both write the same ownership stamp on every node they create — an appId, a stable resourceKey, and a schemaVersion in the node's metadata. That stamp is the only thing that lets the two doors recognise each other's work: install from the gallery, then run the same skill in your terminal, and it finds its own Folder and its own tables instead of trying to create a second copy. (If the stamps ever disagreed, the skill would refuse with SETUP_CONFLICT rather than touch data it can't prove is its own — see Template format.)

Browse the Template Center

Templates sits in the dashboard sidebar, alongside Activity and Install from GitHub…, and opens the gallery for the space you are in.

The gallery is a grid of cards. Each card shows a screenshot (or a placeholder if the author shipped none), the name, a category badge, the description, and one line of arithmetic — "3 tables · 1 app · 7 sample rows" — read off the package itself rather than typed by hand. The search box filters on name, description, category and tags. The link in the top right is the repository the catalog was built from, so you can always see whose templates you are looking at.

Opening a card gives you the detail view, ordered by what you actually decide on:

1. Screenshots — what it looks like.
2. "What you can ask an agent, once it is installed" — the author's ready-made prompts. These are the shortest honest answer to "what would I even ask it?", and they work because the template installs the manual next to the tables.
3. "What installing this creates" — tables, apps, documents, sample rows, files, and whether an agent manual is included.
4. Read the source, plus license and author.

The catalog is fetched by the server, not your browser, and cached for an hour. When it can't be fetched you get the reason in red — "Could not reach the template catalog at …" — because an empty gallery and a broken one look identical, and only one of them is something you can act on.

The gallery also works in the demo workspace: the catalog lists public repositories and has nothing to do with your data. Installing does not.

Install one

Install on the detail page opens the same Install from GitHub… dialog the sidebar opens, pre-filled with the template's repository URL and a target folder name. That reuse is deliberate: browsing and installing must never disagree about what a package is, who may install it, or what it will create — and they can't, if the preview you confirm is literally the same preview.

So the three steps are the ones documented in Install & Export: URL → preview → confirm. What changes is what the server does once it recognises the package as a template.

What a template install does differently

The slug prefix exists because generic names collide: two templates that both ship a settings or a contacts table would otherwise fight over the name the first time you install both. Relation fields pointing at a prefixed Base are rewritten to match, and a slug that already carries the prefix is not prefixed twice.

Merging the sample rows is what makes "install it and it works" true rather than aspirational — but it is also why the format caps them at 50 rows per Base. Merged rows fire webhooks and automations, enter commit history, and are read by agents as real data. A template seeds a demo; it does not ship a dataset.

Structure now, everything that runs after review

The rule from Install & Export still holds, and it is the part that surprises people:

• Created immediately: the folder, the Bases, their fields and views. A pending Base has no id, and without an id there is nowhere to hang a view, a field, or a row.
• Merged immediately (templates only): the sample rows.
• Waiting for your review: the AirApp's source, the Skill node carrying the manual, drives, and any documents.

So a fresh install typically ends with "3 change requests are waiting for you" and a link to your Inbox. Until you merge them, the tables are there but the app cannot boot and the agent cannot read the manual — the Skill node doesn't exist yet.

Install from the command line

npx busabase-cli install https://github.com/busabase/templates/tree/main/busa-email

Everything on the install page applies. Two flags matter for templates:

Start with --dry-run. The git ref in the URL is the version pin: a tag installs that tag's content forever, even after the branch moves on.

After it's installed

1. Review what's waiting. Open the Inbox and read the change requests — most importantly the AirApp's source and the manual, since those are what will run and what your agent will follow. Merging is what makes the app real.

2. Point an agent at it. Once the Skill node is merged, an agent connected over MCP can find it on its own:

The session instructions tell every agent to check apps before acting on an app's data, precisely because guessing a schema an app already documents is how rows end up in the wrong table. The listing is a tool call rather than a block of text in the instructions, so a workspace with forty apps doesn't pay for thirty-nine irrelevant manuals on every session.

3. Use the author's prompts. The ones on the detail page are the intended starting points — they were written by someone who knows what the app is for.

What templates don't do yet

Worth knowing before you plan around them:

• No upgrade path. There is no install --upgrade yet. The root Folder's stamp records which repo, ref and version it came from, which is what makes an upgrade offer possible later; today, re-installing a newer version means installing into a different folder.
• Secrets are declared, not created. A template's secrets and vaultNamespace tell you which Vault keys the app expects. The package format has no slot for secret values and must not grow one — you fill them in yourself, and install does not currently prompt you to.
• Installing does not open the app. The primary AirApp is resolved when the template is validated, but install ends at the change-request summary, not at a running app.

Related

• Install & Export (packages) — the format templates extend, and the install dialog they reuse
• Template format — what's in a template directory, and the rules a validator enforces
• Publish a template — turn a folder you built into one
• Node types — Skill and AirApp nodes, which templates lean on