> ## Documentation Index
> Fetch the complete documentation index at: https://docs.burn0.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Templates

> What silo init copies, and how to make your own

A template is a complete environment copied verbatim into your project. Once copied it is yours — Silo does not track it, update it, or own it.

```bash theme={null}
npx @burn0/silo init <name> --template blank|erp|crm
```

| Template  | Data | Tasks | Tools | Verifiers |
| --------- | ---- | ----- | ----- | --------- |
| **Blank** | 0    | 0     | 0     | 0         |
| **CRM**   | 9    | 6     | 42    | 6         |
| **ERP**   | 26   | 18    | 185   | 18        |

## Blank

The contract wired up and nothing in it.

```
state.ts          export type State = Record<string, unknown>
environment.ts    createState() returns {}
tools/index.ts    an empty registry
verifiers/index.ts an empty registry
```

Use it when you are modelling your own domain. It is the reference architecture — every other template has exactly this shape with contents filled in.

Start with [Build an Environment From Scratch](/silo/guides/build-from-scratch).

## CRM

A staged B2B sales pipeline. The best template to read, because it is populated but small enough to hold in your head.

**Collections** — accounts, contacts, leads, opportunities, activities, users, pipeline stages, an audit log.

**The domain rule that makes it interesting**: a deactivated user cannot act or own records. That single constraint turns "rehome the departed rep's pipeline" from a formality into a task an agent can get wrong.

**Tasks** — three that change the world, three that produce an answer:

| Task                                         | Shape          |
| -------------------------------------------- | -------------- |
| Convert a qualified maritime lead            | state-changing |
| Rehome a departed rep's open pipeline        | state-changing |
| Book the Lumen point-of-sale win             | state-changing |
| Report the weighted value of open pipeline   | answer         |
| Identify the rep with the most stalled deals | answer         |
| Find the weakest active rep against quota    | answer         |

The last two are a deliberate pair. One includes the deactivated rep; the other says *active* and excludes him. An agent that skims the qualifier answers the second with the first's answer.

CRM is also where the derived-value rule shows itself: an opportunity's weighted value is a **helper**, not a stored field, because the agent moves opportunities between stages mid-rollout.

## ERP

A mid-sized industrial distributor, and by far the largest environment: procure-to-pay, order-to-cash, inventory, and budgeting, connected as they would be in a real system.

**185 tools across 18 tasks.** Reach for it when you want to test an agent against genuine breadth — where choosing the right tool out of 185 is itself the difficulty.

It is the counterexample to CRM on derived values: ERP derives money totals **at load**, because every tool that changes a quantity also recomputes them. Both approaches are correct; which one applies depends on whether the agent can change the inputs. See [State](/silo/environments/state).

## Choosing

| If you want to...                    | Use             |
| ------------------------------------ | --------------- |
| See a working environment end to end | CRM             |
| Model your own domain                | Blank           |
| Test tool selection at scale         | ERP             |
| Learn how environments are built     | CRM, then Blank |

## Creating your own template

There is no separate template format. A template **is** an environment directory — the built-in ones live in the package's `templates/` folder and are copied verbatim.

To reuse a world across projects:

1. Build it in one project under `.silo/environments/<name>/`.
2. Copy the directory wherever you want it kept.
3. Copy it into the next project's `.silo/environments/`.

The only file that references the template is the manifest, which records where it came from:

```json silo.environment.json theme={null}
{
  "name": "demo",
  "template": "crm",
  "templateVersion": "0.3.0",
  "entrypoint": "./index.ts",
  "tools": []
}
```

`templateVersion` records the Silo version that scaffolded it. Nothing migrates an environment when Silo updates — a copied environment keeps working because it is plain TypeScript against a stable contract.

<Note>
  Adding a template to the `--template` flag itself requires a change to Silo's registry, so custom templates are copied by hand today rather than registered. If sharing templates matters to you, that is worth opening an issue about.
</Note>

## Things worth stealing

Whatever you build, these patterns from the built-in templates are worth copying:

* **`tools/contract.ts`** — pin `defineTool` to your `State` once, and keep schema builders and input readers beside it so each tool file imports one thing.
* **`tools/helpers.ts`** — lookups and shared rules (`requireX`, `assertOpen`) written once rather than per tool.
* **Split verifier files** — `verifiers/VER-001.ts` plus a barrel, not one large file.
* **A `shared.ts` for answer parsing** — reading a number out of free text in one place rather than per verifier.
* **An audit log** — an append-only array shows up in `state-diff.json`, which makes "who did what" visible after a rollout.