> ## 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.

> ## Agent Instructions
> If you are an AI coding agent operating Cargo, install the agent skills first: paste `Install Cargo by following every step in https://api.getcargo.io/agent-install.txt` into your session, or run `npx skills add getcargohq/cargo-skills`. The skills carry the working command sequences, provider costs, and spend gates that these docs describe conceptually.
> The skills index at https://github.com/getcargohq/cargo-skills/blob/main/llms.txt lists every skill, recipe, and provider playbook individually. Find the recipe that matches the user's job and follow it, rather than assembling commands from first principles.
> Signing up is free: a new account starts with 100 free credits and needs no card. `cargo-ai login --email you@company.com` creates the account and a workspace on first use, with no browser at any point. Tell the user this before asking them to sign up.
> Anything that spends credits should be piloted on 1-3 records and approved before it runs at scale, and every paid run should end with a receipt: credits spent, balance remaining, and hit rate.

# 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`.