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

# Manifest

> Scaffold a GTM repo and grow it with copy-in modules

Manifest is the repo framework for GTM engineering: one conventional,
version-controlled repository holding everything your go-to-market runs on,
readable by humans and coding agents alike. `cargo-ai manifest` scaffolds that
repo and installs modules into it.

A Manifest repo has six layers:

| Layer   | Directory         | One sentence                                                                  |
| ------- | ----------------- | ----------------------------------------------------------------------------- |
| Context | `context/`        | What the company knows: the GTM brain every agent reads before acting         |
| Skills  | `.claude/skills/` | What agents know how to do in this specific repo                              |
| Infra   | `infra/`          | What runs in production, declared with the [CDK](/get-started/project-layout) |
| Scripts | `scripts/`        | What you run by hand, for surfaces the CDK cannot declare yet                 |
| Evals   | `evals/`          | What keeps agents honest: prompt regression tests in CI                       |
| Outputs | `outputs/`        | What happened: the append-only archive agents read as memory                  |

The layers that execute (`infra/`, modules) need a Cargo workspace. The rest
(context, skills, evals, outputs, the context linter) work in any repo with no
account at all.

## `manifest init`

```bash theme={null}
# scaffold a fresh repo
cargo-ai manifest init acme-gtm

# or adopt an existing GTM repo in place: lays the layer structure
# around your files and never overwrites anything that exists
cd our-gtm-repo && cargo-ai manifest init
```

Options:

* `--from <source>` — template source, `owner/repo[@ref]` or a github.com URL
  (default: the official template, `getcargohq/cargo-manifest`)
* `--name <name>` — repo name written into `package.json` / `manifest.json`
  (default: the directory name)
* `--force` — scaffold into a non-empty directory (existing files are still
  kept, never overwritten)

The adopt-in-place form reports every file it kept, so running it on an
existing repo is safe by construction.

## `manifest add`

```bash theme={null}
cargo-ai manifest add inbound-flow
cargo-ai manifest add ai-sdr contact-sourcing
cargo-ai manifest add my-play --from my-org/our-cookbooks
cargo-ai manifest add inbound-flow --from my-org/monorepo/cookbooks
```

Modules install **copy-in**: the files land in your repo (under `infra/` by
default) and are yours to edit from then on — there is no runtime dependency
on the source. A module's transitive requirements come along automatically
(installing `inbound-flow` also brings `base-gtm`), driven by the source
repo's `cargo.scaffold.json`.

Every install is recorded in `manifest.json` with its source, git ref, and
per-file content hashes, so future tooling can show how your copy has diverged
from upstream.

Options:

* `--from <source>` — module source, `owner/repo[/folder][@ref]` or a
  github.com URL (default: `getcargohq/cargo-cookbooks`). A trailing folder
  scopes the module root (scaffold manifest + module folders) to that path
  inside the repo.
* `--dir <dir>` — install directory relative to the repo root (default:
  `infra`)
* `--force` — overwrite files that already exist locally; without it,
  collisions are kept and reported

Anyone can publish modules: any GitHub repo of folders works as a source, with
an optional `cargo.scaffold.json` at the module root to declare `shared` files
and per-folder `requires`.