skills/cargo-cdk/references/cookbooks.md

<!-- Generated by .github/scripts/sync-cookbooks.ts from gtm-skills' catalog.json. Do not edit by hand. -->

# Cookbooks: worked CDK examples, before you author one from scratch

Skills in [`getcargohq/gtm-skills`](https://github.com/getcargohq/gtm-skills) that are cookbooks: worked CDK resources, the same
jobs as the one-off skills there, as a deployed pipeline that keeps producing the result.

**Every folder is self-contained** (its own models, connectors and folders; no shared
foundation, no requires graph). The agent installing one copies it into the project as a
sibling of what is there, reconciles it with what is already declared (an existing accounts
model, an existing CRM connector), adapts it, plans, deploys on a yes, and walks its `Done
when`. The code is a worked example, not a template to fill in.

```sh
npx skills add getcargohq/gtm-skills/<slug>       # then say what you want; the skill carries its own procedure
cargo-ai cdk init <dir> --template blank      # only if there is no CDK project yet: the shell comes from the CLI
```

## With a skill

| Skill | Deploys | State |
| --- | --- | --- |
| `account-scoring` | Keep every account scored and tiered against your written ICP by a deployed agent that re-scores as accounts arrive and as the ICP changes, writing the rationale back to the CRM. | to-be-approved |
| `tam-building` | Stand up your account universe as a deployed pipeline: a Sales Navigator company search split past the 1,000 extraction cap, resolved to real domains, deduped into a shared accounts model. | to-be-approved |

## When one does not fit as written

Declared adaptations, not forks. Reach for one before concluding a skill is the wrong start.

**`account-scoring`**

- `deterministic-scoring` — You need fixed cost and exact reproducibility, or an LLM judgement is not acceptable to your team. Costs: The criteria move out of the ICP markdown and into code, so they stop being reviewable by non-engineers, and you lose the rationale entirely.
- `skip-crm-roundtrip` — You want the score on the model directly and do not need it visible in the CRM. Costs: Reps lose the score and rationale where they actually work. The native's input is untyped, so confirm the field shape on the first run.
- `no-crm-at-all` — You have no CRM, or you do not want to hand this skill a CRM credential. Costs: Every other CRM-dependent skill you install later brings a CRM connector of its own; reuse one.

**`tam-building`**

- `non-linkedin-source` — You do not want to source from LinkedIn at all, or Sales Nav does not cover your market. Costs: You lose the Sales Nav facet taxonomy that makes the split tactic mechanical, and the splitting has to be redesigned around the new source's own limits.
- `land-without-promoting` — You want to see and filter the raw market before paying to enrich it. Costs: Nothing reaches `accounts`, so no downstream skill (scoring, contact sourcing, signals) has anything to work with until you promote.
- `sample-first` — The market search is large and you want to see the cost curve before committing. Costs: Your TAM is deliberately incomplete until you widen it, so do not score or report on coverage from a sample.

## Routing

**One-off versus standing is the whole test.** A user who wants a list today wants a one-off
skill (or `cargo-gtm`, when this pack is installed); a user who wants a pipeline that keeps
producing it wants one of these. The same words describe both, so listen for whether the
result is meant to keep arriving.

**Never `cargo-ai cdk init --force` into a directory that is not empty.** It replaces the
project's `package.json` and reverts adapted code while `cargo.state.json` survives, so the
next plan diffs a live workspace against code nobody wrote. Copy the skill folder in as a
sibling instead; that is what its own procedure says.