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

# Package and Publish Your Substrate Workflow as a Template

> How to package a Substrate workflow as a shareable template, add a substrate-template.json manifest, and apply someone else's template.

A Substrate template is a workflow — boards with their groups, `field_schema`, and policies. It never includes tasks, comments, or any database state. Applying a template forks it into the consumer's project: they own their copy from that moment on and can evolve it independently.

## Publish a Template

<Steps>
  <Step title="Copy your board JSON out">
    Take `.substrate/boards/*.json` into a repo or folder. Board files are already pure substrate-as-code — there is nothing to strip before sharing them.
  </Step>

  <Step title="Add a manifest">
    Create a `substrate-template.json` file at the root of the template directory:

    ```json substrate-template.json theme={null}
    {
      "name": "Your Workflow",
      "description": "What this workflow is and who it's for.",
      "version": "1.0.0",
      "boards": ["boards/your-board.json"]
    }
    ```

    All four fields — `name`, `description`, `version`, and `boards` — are required. `version` is your own author metadata; Substrate never enforces it. Unknown keys are rejected.

    <Note>
      Without a manifest, a folder still resolves by convention if its boards live under `.substrate/boards/` or `boards/`. A manifest is recommended for anything you intend to share.
    </Note>
  </Step>

  <Step title="Share the repo URL">
    Consumers clone the repo and apply from the local directory. See `examples/web-delivery` for a complete working template — manifest plus board — that you can use as a reference.
  </Step>
</Steps>

## Apply Someone Else's Template

<Warning>
  The CLI is network-free — it never fetches URLs. `<path>` is always a local directory. Clone the template repo first, then apply from the clone.
</Warning>

**Into an existing `.substrate/`:**

```sh theme={null}
substrate add <clone-dir>           # preview — validates and writes nothing
substrate add <clone-dir> --yes     # apply transactionally
```

**Into a fresh project:**

```sh theme={null}
substrate init --template <clone-dir>
```

### How `add` Works

`add` is a **dry run by default** — it validates the template and prints what it would create, but writes nothing until you pass `--yes`.

Board-id collisions are refused. If the incoming template has a single board whose id conflicts with an existing one, use `--as <id>` to rename it so it can sit alongside:

```sh theme={null}
substrate add <clone-dir> --as my-delivery --yes
```

An apply that fails partway rolls back only the files it created. Pre-existing boards are never modified.

## What Does Not Travel

<CardGroup cols={1}>
  <Card title="Members (v0.7.0 gap)" icon="users">
    A bundled template ships its default members, but a path template carries boards only — registry files are not part of the template format. A shared board whose `team` references members arrives with dangling references, each resolved as `unresolved` (a warning, not a failure). Consumers author their own `.substrate/members/<id>.json` to fill them in.
  </Card>
</CardGroup>

<Note>
  A first-party `substrate template export` command to scaffold the manifest automatically is planned. In v0.7.0 you hand-write it.
</Note>

***

<CardGroup cols={1}>
  <Card title="substrate add CLI reference" icon="terminal" href="/cli/add">
    Full flag reference and examples for the `substrate add` command.
  </Card>
</CardGroup>