Manifest

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

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

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.

Get started

Resources

Deploy

CLI

Skills

Reference

`manifest init`

`manifest add`

​manifest init

​manifest add

`manifest init`

`manifest add`