mirror of
https://github.com/getcargohq/cargo-skills.git
synced 2026-09-14 19:17:15 +08:00
Rename cargo-cdk to cargo-project, following the CLI's project group (#128)
* Rename cargo-cdk to cargo-project, following the CLI's `project` group @cargo-ai/cli renamed `cargo-ai cdk` to `cargo-ai project` and kept `cdk` as an alias. The skill directory, its name, every cross-link, and every command example now say project. The @cargo-ai/cdk package, its imports, `npx @cargo-ai/cdk`, cargo.state.json and the define* builders are unchanged. - hooks/approve-cli.sh gates `project deploy` and `project destroy` next to the cdk pairs; without them the renamed deploy auto-approved. - skills-lint knows `project` as a CLI domain. - The "deploy from CI" trigger becomes "deploy the workspace from CI". The CI routing case was a tie on main, won only because cargo-cdk sorted before cargo-hosting; cargo-project sorts after it. - No redirect stub at the old name. - cargo-project 2.0.0; patch bumps for the eight skills that link to it, and the plugin manifests follow the router to 1.25.1. Needs the CLI release that ships the project group, with cargo/cli-version bumped to it, before merge. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KRC3ERvnznXTw3WFLWrPaS * Keep cargo-cdk as a redirect to cargo-project `npx skills add` never deletes an installed skill that vanished upstream, and `skills update` skips the deletion non-interactively. A plain rename left every existing install with a frozen cargo-cdk routing next to cargo-project. cargo-cdk/SKILL.md is now a pointer (2.0.0), so the next refresh overwrites the stale copy, and a CLI that still hands off to cargo-cdk lands on it. Checked by installing main and then this branch into a throwaway HOME. It is marked `metadata.redirect: cargo-project`. skill-redirects.mjs lets lint (count, router check), the routing eval, llms.txt and the Codex package skip it; lint still lints the file and requires the target to be a skill. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KRC3ERvnznXTw3WFLWrPaS --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Auree Aubert
@@ -2,7 +2,7 @@
|
||||
"name": "cargo",
|
||||
"displayName": "Cargo",
|
||||
"description": "Build with Cargo in Claude Code — 19 skills over the cargo-ai CLI, plus the hosted MCP server (target lists, contact enrichment and verification from licensed data providers, lead scoring, CRM sync, signal monitoring, orchestration, storage, segments, CDK, diagnostics) plus prompt-free approval for safe cargo-ai calls.",
|
||||
"version": "1.25.0",
|
||||
"version": "1.25.1",
|
||||
"author": { "name": "getcargo" },
|
||||
"homepage": "https://github.com/getcargohq/cargo-skills",
|
||||
"skills": ["./"],
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"name": "cargo",
|
||||
"description": "Build with Cargo in Codex — 19 skills over the cargo-ai CLI, plus the hosted MCP server (target lists, contact enrichment and verification from licensed data providers, lead scoring, CRM sync, signal monitoring, orchestration, storage, segments, CDK, diagnostics) plus prompt-free approval for safe cargo-ai calls.",
|
||||
"version": "1.25.0",
|
||||
"version": "1.25.1",
|
||||
"author": { "name": "getcargo" },
|
||||
"homepage": "https://github.com/getcargohq/cargo-skills",
|
||||
"repository": "https://github.com/getcargohq/cargo-skills",
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"name": "cargo",
|
||||
"description": "Build with Cargo in Cursor — 19 skills over the cargo-ai CLI, plus the hosted MCP server (target lists, contact enrichment and verification from licensed data providers, lead scoring, CRM sync, signal monitoring, orchestration, storage, segments, CDK, diagnostics) plus prompt-free approval for safe cargo-ai calls.",
|
||||
"version": "1.25.0",
|
||||
"version": "1.25.1",
|
||||
"author": { "name": "getcargo" },
|
||||
"homepage": "https://github.com/getcargohq/cargo-skills",
|
||||
"logo": "assets/logo.svg",
|
||||
|
||||
@@ -58,6 +58,7 @@ import {
|
||||
} from "node:fs";
|
||||
import { dirname, join, resolve } from "node:path";
|
||||
import { writeAllMetadata } from "./skills-metadata.mjs";
|
||||
import { isRedirectSkill } from "./skill-redirects.mjs";
|
||||
import { fileURLToPath } from "node:url";
|
||||
|
||||
const repoRoot = resolve(dirname(fileURLToPath(import.meta.url)), "../..");
|
||||
@@ -152,7 +153,7 @@ const REMOVED_TERMS = [
|
||||
|
||||
// Excluding a skill leaves cross-references to it in the ones that remain: a
|
||||
// router table row, an ASCII diagram box, a recap section, link targets in
|
||||
// cargo-gtm and cargo-cdk. Each is removed here, in the packaged copy only.
|
||||
// cargo-gtm and cargo-project. Each is removed here, in the packaged copy only.
|
||||
// Every `find` must match exactly once or the build fails — these are anchored
|
||||
// to prose that will drift, and a silent no-op would ship a dangling link.
|
||||
const PACKAGE_EDITS = [
|
||||
@@ -217,17 +218,17 @@ const PACKAGE_EDITS = [
|
||||
replace: "The handoff target is the workspace's sequencer of choice (Outreach, Salesloft, Apollo, HubSpot Sequences, Salesforce Cadences). The recipe stops at \"send-ready variables\" and points at `cargo-ai connection integration get <slug>` for the final push.",
|
||||
},
|
||||
{
|
||||
file: "cargo-cdk/SKILL.md",
|
||||
file: "cargo-project/SKILL.md",
|
||||
find: "- **`defineMailbox` bills monthly, and `defineDomain` rewrites a DNS zone.** A\n mailbox is 100\u2013160 credits *per month* for as long as it exists (`cargo-ai\n mailboxManagement pricing get` for live figures), so a `+ create mailbox:\u2026` line\n in the plan is a recurring charge the user approves, not a one-off. Its `domain`,\n `username` and `type` are **create-only** \u2014 changing any of them is destroy +\n recreate, i.e. a brand-new inbox back at the bottom of a 45-day warm-up ramp. The\n deploy polls `refreshStatus` for up to 5 minutes waiting for `active`. On\n `defineDomain`, `dnsRecords` is the **whole zone, not a patch**: declaring it\n replaces every live record (including the ones the registrar wrote at purchase),\n and omitting it leaves the zone untouched. Use `adopt: true` for a domain or\n mailbox bought in the UI. Ramp, suppression and sending:\n [`../cargo-mailbox-management/SKILL.md`](../cargo-mailbox-management/SKILL.md).\n",
|
||||
replace: "",
|
||||
},
|
||||
{
|
||||
file: "cargo-cdk/references/resources.md",
|
||||
file: "cargo-project/references/resources.md",
|
||||
find: "| `defineMailbox(slug, spec)` | Sending inbox on a domain (**monthly credit charge**) | `domain`, `type` (`google`/`shared`/`private` \u2014 no `outlook`), `username?` (defaults to slug), `firstName`, `lastName`, `signature?`, `folder?`, `adopt?` | `domain`, `folder` | `uuid` |\n",
|
||||
replace: "",
|
||||
},
|
||||
{
|
||||
file: "cargo-cdk/references/resources.md",
|
||||
file: "cargo-project/references/resources.md",
|
||||
find: "| `defineDomain(name, spec)` | Sending domain + its DNS zone | `adopt?`, `dnsRecords?` (**replaces the whole zone**) | \u2014 | `uuid` |\n",
|
||||
replace: "",
|
||||
},
|
||||
@@ -602,11 +603,14 @@ if (typeof version !== "string" || /^\d+\.\d+\.\d+$/.test(version) === false) {
|
||||
}
|
||||
|
||||
// A skill is any top-level directory holding a SKILL.md — the same rule
|
||||
// skills-lint and skills-metadata use, so the three can never disagree.
|
||||
// skills-lint and skills-metadata use, so the three can never disagree. A
|
||||
// redirect stub at a renamed skill's old name is not one: a fresh package has
|
||||
// no stale copy for it to overwrite.
|
||||
const repoSkillDirs = readdirSync(repoRoot, { withFileTypes: true })
|
||||
.filter((e) => e.isDirectory())
|
||||
.map((e) => e.name)
|
||||
.filter((name) => existsSync(join(repoRoot, name, "SKILL.md")))
|
||||
.filter((name) => !isRedirectSkill(join(repoRoot, name)))
|
||||
.sort();
|
||||
|
||||
if (repoSkillDirs.length === 0) {
|
||||
|
||||
@@ -13,6 +13,7 @@
|
||||
import { readdirSync, readFileSync, writeFileSync, existsSync, statSync } from "node:fs";
|
||||
import { join, dirname, resolve } from "node:path";
|
||||
import { fileURLToPath } from "node:url";
|
||||
import { isRedirectSkill } from "./skill-redirects.mjs";
|
||||
|
||||
const repoRoot = resolve(dirname(fileURLToPath(import.meta.url)), "../..");
|
||||
const outPath = join(repoRoot, "llms.txt");
|
||||
@@ -53,7 +54,7 @@ function collectSkills(): Skill[] {
|
||||
const skills: Skill[] = [];
|
||||
for (const entry of readdirSync(repoRoot)) {
|
||||
const skillMd = join(repoRoot, entry, "SKILL.md");
|
||||
if (statSync(join(repoRoot, entry), { throwIfNoEntry: false })?.isDirectory() && existsSync(skillMd)) {
|
||||
if (statSync(join(repoRoot, entry), { throwIfNoEntry: false })?.isDirectory() && existsSync(skillMd) && !isRedirectSkill(join(repoRoot, entry))) {
|
||||
skills.push(parseFrontmatter(skillMd));
|
||||
}
|
||||
}
|
||||
@@ -133,7 +134,7 @@ function render(skills: Skill[]): string {
|
||||
|
||||
const recipes = [
|
||||
...collectDocs("cargo-gtm", "recipes", "A step-by-step GTM playbook."),
|
||||
...collectDocs("cargo-cdk", "recipes", "A step-by-step workspace-as-code playbook."),
|
||||
...collectDocs("cargo-project", "recipes", "A step-by-step workspace-as-code playbook."),
|
||||
];
|
||||
const recipeLines = recipes
|
||||
.map((r) => `- [${r.slug}](${repoUrl}/blob/main/${r.path}): ${r.summary}`)
|
||||
|
||||
@@ -42,6 +42,7 @@
|
||||
import { readdirSync, readFileSync, existsSync, statSync, appendFileSync } from "node:fs";
|
||||
import { join, dirname, resolve } from "node:path";
|
||||
import { fileURLToPath } from "node:url";
|
||||
import { isRedirectSkill } from "./skill-redirects.mjs";
|
||||
|
||||
const repoRoot = resolve(dirname(fileURLToPath(import.meta.url)), "../..");
|
||||
const verbose = process.argv.includes("--verbose");
|
||||
@@ -121,6 +122,8 @@ function loadSkills(): Skill[] {
|
||||
const skillMd = join(skillsRoot, entry, "SKILL.md");
|
||||
if (!statSync(join(skillsRoot, entry), { throwIfNoEntry: false })?.isDirectory()) continue;
|
||||
if (!existsSync(skillMd)) continue;
|
||||
// A redirect stub left at a renamed skill's old name is not a routing target.
|
||||
if (isRedirectSkill(join(skillsRoot, entry))) continue;
|
||||
const lines = readFileSync(skillMd, "utf8").split("\n");
|
||||
let name = "";
|
||||
let description = "";
|
||||
|
||||
@@ -0,0 +1,31 @@
|
||||
// skill-redirects.mjs — recognise redirect stubs left at a renamed skill's old
|
||||
// directory.
|
||||
//
|
||||
// `npx skills add` never deletes an installed skill that disappeared upstream,
|
||||
// and `skills update` only offers to, interactively. A plain rename therefore
|
||||
// leaves every existing install with a frozen copy under the old name, routing
|
||||
// next to the new one forever. Keeping the old name as a skill whose body is a
|
||||
// pointer is the only way the next refresh overwrites that copy.
|
||||
//
|
||||
// A redirect is not part of the pack: the skill count, routing evals, llms.txt
|
||||
// and the Codex package all skip it. It declares its target in frontmatter:
|
||||
//
|
||||
// metadata:
|
||||
// redirect: cargo-project
|
||||
|
||||
import { existsSync, readFileSync } from "node:fs";
|
||||
import { join } from "node:path";
|
||||
|
||||
/** The skill a SKILL.md redirects to, or null when it is a real skill. */
|
||||
export function redirectTarget(skillMdText) {
|
||||
if (!skillMdText.startsWith("---")) return null;
|
||||
const end = skillMdText.indexOf("\n---", 3);
|
||||
if (end === -1) return null;
|
||||
return /^\s+redirect:\s*"?([a-z0-9-]+)"?\s*$/m.exec(skillMdText.slice(0, end))?.[1] ?? null;
|
||||
}
|
||||
|
||||
/** True when `skillDir` holds a SKILL.md that is a redirect stub. */
|
||||
export function isRedirectSkill(skillDir) {
|
||||
const skillMd = join(skillDir, "SKILL.md");
|
||||
return existsSync(skillMd) && redirectTarget(readFileSync(skillMd, "utf8")) !== null;
|
||||
}
|
||||
@@ -17,6 +17,7 @@
|
||||
import { readFileSync, readdirSync, statSync, existsSync } from "node:fs";
|
||||
import { join, relative, resolve, dirname, basename } from "node:path";
|
||||
import { checkAllMetadata } from "./skills-metadata.mjs";
|
||||
import { isRedirectSkill, redirectTarget } from "./skill-redirects.mjs";
|
||||
|
||||
const repoRoot = resolve(process.argv[2] || ".");
|
||||
|
||||
@@ -24,7 +25,7 @@ const SKILL_DIRS = [
|
||||
"cargo",
|
||||
"cargo-quickstart",
|
||||
"cargo-gtm",
|
||||
"cargo-cdk",
|
||||
"cargo-project",
|
||||
"cargo-orchestration",
|
||||
"cargo-storage",
|
||||
"cargo-segmentation",
|
||||
@@ -53,7 +54,8 @@ const REQUIRED_FRONTMATTER_FIELDS = [
|
||||
const KNOWN_CLI_DOMAINS = new Set([
|
||||
"ai",
|
||||
"billing",
|
||||
"cdk",
|
||||
"cdk", // alias of `project` since @cargo-ai/cli renamed the group
|
||||
"project",
|
||||
"manifest", // shipped in @cargo-ai/cli 1.0.57: `manifest init`
|
||||
"doctor",
|
||||
"mcp",
|
||||
@@ -347,7 +349,7 @@ function main() {
|
||||
const diskSkillDirs = readdirSync(repoRoot).filter((d) => {
|
||||
if (d.startsWith(".") || d === "node_modules") return false;
|
||||
const p = join(repoRoot, d);
|
||||
return statSync(p).isDirectory() && existsSync(join(p, "SKILL.md"));
|
||||
return statSync(p).isDirectory() && existsSync(join(p, "SKILL.md")) && !isRedirectSkill(p);
|
||||
});
|
||||
for (const dir of diskSkillDirs) {
|
||||
if (!SKILL_DIRS.includes(dir)) {
|
||||
@@ -358,6 +360,19 @@ function main() {
|
||||
);
|
||||
}
|
||||
}
|
||||
// Redirect stubs (skill-redirects.mjs) are not skills, so they are left out of
|
||||
// the count and the router check above. They are still linted as files, and
|
||||
// must point at a real skill.
|
||||
for (const d of readdirSync(repoRoot)) {
|
||||
const p = join(repoRoot, d);
|
||||
if (d.startsWith(".") || !statSync(p).isDirectory() || !isRedirectSkill(p)) continue;
|
||||
const skillMd = join(p, "SKILL.md");
|
||||
lintFile(skillMd);
|
||||
const target = redirectTarget(readFileSync(skillMd, "utf8"));
|
||||
if (!SKILL_DIRS.includes(target)) {
|
||||
err(skillMd, 1, `Redirect points at \`${target}\`, which is not a skill in this repo.`);
|
||||
}
|
||||
}
|
||||
const routerPath = join(repoRoot, "cargo", "SKILL.md");
|
||||
if (existsSync(routerPath)) {
|
||||
const router = readFileSync(routerPath, "utf8");
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
/**
|
||||
* Keeps cargo-cdk aware of the cookbooks in getcargohq/gtm-skills: the skills
|
||||
* Keeps cargo-project aware of the cookbooks in getcargohq/gtm-skills: the skills
|
||||
* that carry a worked cookbook, the same jobs as the one-off skills there
|
||||
* as a deployed pipeline an agent adapts into a project.
|
||||
*
|
||||
* WHY THIS EXISTS
|
||||
*
|
||||
* `cargo-cdk/SKILL.md` used to tell the agent to go read a menu on GitHub,
|
||||
* `cargo-project/SKILL.md` used to tell the agent to go read a menu on GitHub,
|
||||
* mid-task, which an agent may simply not do. When it does not, it authors from
|
||||
* scratch an outcome that was already written. The menu has to be a local file.
|
||||
*
|
||||
@@ -29,7 +29,7 @@ import { fileURLToPath } from "node:url";
|
||||
|
||||
const repoRoot = resolve(dirname(fileURLToPath(import.meta.url)), "../..");
|
||||
const snapshotPath = join(repoRoot, ".github/data/cookbooks.json");
|
||||
const referencePath = join(repoRoot, "cargo-cdk/references/cookbooks.md");
|
||||
const referencePath = join(repoRoot, "cargo-project/references/cookbooks.md");
|
||||
const REPO = "getcargohq/gtm-skills";
|
||||
const CATALOG_URL = `https://raw.githubusercontent.com/${REPO}/main/catalog.json`;
|
||||
|
||||
@@ -93,19 +93,19 @@ function render(examples: Cookbook[]): string {
|
||||
L.push("jobs as the one-off skills there, as a deployed pipeline that keeps producing the result.");
|
||||
L.push("");
|
||||
L.push("**Every folder is self-contained** (its own models, connectors and folders; no shared");
|
||||
L.push("foundation, no requires graph). `cdk add` copies one into the project; the agent then");
|
||||
L.push("foundation, no requires graph). `project add` copies one into the project; the agent then");
|
||||
L.push("reconciles it with what is already declared (an existing accounts model, an existing CRM");
|
||||
L.push("connector), adapts it in place, plans, deploys on a yes, and walks its `Done when`. The");
|
||||
L.push("code is a worked example, not a template to fill in — and not something to regenerate");
|
||||
L.push("from the skill's prose.");
|
||||
L.push("");
|
||||
L.push("```sh");
|
||||
L.push("cargo-ai cdk add cookbook/<slug> # inside a CDK project: this is the copy step");
|
||||
L.push("cargo-ai cdk init <dir> --cookbook <slug> # no project yet: scaffold and install together");
|
||||
L.push("cargo-ai project add cookbook/<slug> # inside a CDK project: this is the copy step");
|
||||
L.push("cargo-ai project init <dir> --cookbook <slug> # no project yet: scaffold and install together");
|
||||
L.push(`npx skills add ${REPO}/<slug> # the procedure on its own, without the CDK resources`);
|
||||
L.push("```");
|
||||
L.push("");
|
||||
L.push("After either `cdk` command the files are in `infra/<slug>/` and `.claude/skills/<slug>/`.");
|
||||
L.push("After either `project` command the files are in `infra/<slug>/` and `.claude/skills/<slug>/`.");
|
||||
L.push("Start the skill at its Adapt section: its earlier steps assume you found the folder in");
|
||||
L.push("gtm-skills and still have to place it.");
|
||||
L.push("");
|
||||
@@ -135,9 +135,9 @@ function render(examples: Cookbook[]): string {
|
||||
L.push("producing it wants one of these. The same words describe both, so listen for whether the");
|
||||
L.push("result is meant to keep arriving.");
|
||||
L.push("");
|
||||
L.push("**Never `cargo-ai cdk init --force` into a directory that is not empty.** It replaces the");
|
||||
L.push("**Never `cargo-ai project init --force` into a directory that is not empty.** It replaces the");
|
||||
L.push("project's `package.json` and reverts adapted code while `cargo.state.json` survives, so the");
|
||||
L.push("next plan diffs a live workspace against code nobody wrote. Run `cdk add cookbook/<slug>`");
|
||||
L.push("next plan diffs a live workspace against code nobody wrote. Run `project add cookbook/<slug>`");
|
||||
L.push("in the project that is already there; it skips every file it would otherwise overwrite.");
|
||||
L.push("");
|
||||
return L.join("\n");
|
||||
@@ -159,7 +159,7 @@ if (process.argv.includes("--check")) {
|
||||
: "";
|
||||
if (current !== rendered) {
|
||||
console.error(
|
||||
"cargo-cdk/references/cookbooks.md is stale.\n Run: node .github/scripts/sync-cookbooks.ts",
|
||||
"cargo-project/references/cookbooks.md is stale.\n Run: node .github/scripts/sync-cookbooks.ts",
|
||||
);
|
||||
process.exit(1);
|
||||
}
|
||||
|
||||
@@ -37,8 +37,8 @@ OBFUSCATED_PROMPT_INJECTION:cargo-storage/references/examples/ingest-webhook.md
|
||||
# cargo-billing/SKILL.md — unicode-confusable false positive
|
||||
OBFUSCATED_PROMPT_INJECTION:cargo-billing/SKILL.md
|
||||
|
||||
# cargo-cdk/SKILL.md — unicode-normalization false positive
|
||||
OBFUSCATED_PROMPT_INJECTION:cargo-cdk/SKILL.md
|
||||
# cargo-project/SKILL.md — unicode-normalization false positive
|
||||
OBFUSCATED_PROMPT_INJECTION:cargo-project/SKILL.md
|
||||
|
||||
# cargo-diagnostics/SKILL.md — unicode-normalization false positive
|
||||
OBFUSCATED_PROMPT_INJECTION:cargo-diagnostics/SKILL.md
|
||||
|
||||
+13
-4
@@ -10,9 +10,18 @@ The format is loosely based on [Keep a Changelog](https://keepachangelog.com/en/
|
||||
|
||||
## [Unreleased]
|
||||
|
||||
### `cargo-project` → 2.0.0 (was `cargo-cdk`) — the `cdk` command group is now `project`
|
||||
|
||||
`@cargo-ai/cli` renamed `cargo-ai cdk` to `cargo-ai project` and kept `cdk` as an alias. The skill follows: `cargo-cdk/` is now [`cargo-project/`](cargo-project/SKILL.md), and every command example says `cargo-ai project …`. Unchanged on purpose: the `@cargo-ai/cdk` package and its imports, `npx @cargo-ai/cdk`, `cargo.state.json`, and the `define*` builders.
|
||||
|
||||
- **Needs the CLI release that ships the `project` group.** An older CLI answers `unknown command`; `cargo/cli-version` moves with it.
|
||||
- **`cargo-cdk` → 2.0.0 is a redirect to `cargo-project`.** `npx skills add` never deletes an installed skill that disappeared upstream, so a plain rename would have left every existing install with a frozen `cargo-cdk` routing next to `cargo-project`. The next refresh overwrites that copy with a pointer, and a CLI that still hands off to `cargo-cdk` lands on it. It is marked with `metadata.redirect` ([`skill-redirects.mjs`](.github/scripts/skill-redirects.mjs)), so the skill count, routing evals, `llms.txt` and the Codex package skip it.
|
||||
- **The approval hook gates `project deploy` and `project destroy`** alongside the `cdk` forms. Without the new pairs, the renamed deploy would have been auto-approved.
|
||||
- Patch bumps for the links and command examples that pointed at the old skill: `cargo` → 1.25.1, `cargo-gtm` → 2.1.1, `cargo-hosting` → 1.0.2, `cargo-mailbox-management` → 1.0.3, `cargo-mcp` → 1.0.3, `cargo-observability` → 1.0.3, `cargo-orchestration` → 1.11.3, `cargo-segmentation` → 1.0.1.
|
||||
|
||||
### `cargo-orchestration` → 1.11.2, `cargo-cdk` → 1.2.4 — JS script node's `require` allowlist
|
||||
|
||||
The `script` node was documented as shipping `lodash`. It also allows `axios`, `cheerio`, `crypto-js`, `date-fns`, `jsonschema`, `url`, `uuid`, and `zod`. `knex` is not available. Listed in [`references/node-selection.md`](cargo-orchestration/references/node-selection.md), [`references/nodes.md`](cargo-orchestration/references/nodes.md), and [`guides/authoring-resources.md`](cargo-cdk/guides/authoring-resources.md) next to `js()`.
|
||||
The `script` node was documented as shipping `lodash`. It also allows `axios`, `cheerio`, `crypto-js`, `date-fns`, `jsonschema`, `url`, `uuid`, and `zod`. `knex` is not available. Listed in [`references/node-selection.md`](cargo-orchestration/references/node-selection.md), [`references/nodes.md`](cargo-orchestration/references/nodes.md), and [`guides/authoring-resources.md`](cargo-project/guides/authoring-resources.md) next to `js()`.
|
||||
|
||||
### `cargo-gtm` → 2.1.0 — the routing surfaces answer more of the questions people actually ask
|
||||
|
||||
@@ -324,13 +333,13 @@ The `description` field is the only text an agent weighs before deciding whether
|
||||
|
||||
### `cargo-cdk` → 1.2.0
|
||||
|
||||
- **Documents the `defineAlert` builder** (the declarative front for the observability domain). [`references/resources.md`](cargo-cdk/references/resources.md) gains a Builders-table row and a "Notes on specific fields" entry: the scope↔threshold matched pair (TS narrows the metric menu by `scope.kind`), scope wiring by handle (`workflow`/`connector`/`tool`/`agent`/`model`), the `{ ref, config }` action wrapper with the typed `alertConnectorAction`/`alertToolAction` helpers and `{{event.*}}`/`{{alert.*}}` templating, and the slugless-identity note (state uuid, like a play).
|
||||
- [`guides/authoring-resources.md`](cargo-cdk/guides/authoring-resources.md) gains an Observability example wiring an alert to a `definePlay` handle with an agent action. [`SKILL.md`](cargo-cdk/SKILL.md) §6: `alert` added to the slugless "commit `cargo.state.json`" resources, and a new critical rule that a `defineAlert` whose actions call paid nodes re-bills on every breach (preview the threshold; prefer cheap notification actions). Cross-links to [`cargo-observability`](cargo-observability/SKILL.md) for the scope/threshold matrix and firing semantics.
|
||||
- **Documents the `defineAlert` builder** (the declarative front for the observability domain). [`references/resources.md`](cargo-project/references/resources.md) gains a Builders-table row and a "Notes on specific fields" entry: the scope↔threshold matched pair (TS narrows the metric menu by `scope.kind`), scope wiring by handle (`workflow`/`connector`/`tool`/`agent`/`model`), the `{ ref, config }` action wrapper with the typed `alertConnectorAction`/`alertToolAction` helpers and `{{event.*}}`/`{{alert.*}}` templating, and the slugless-identity note (state uuid, like a play).
|
||||
- [`guides/authoring-resources.md`](cargo-project/guides/authoring-resources.md) gains an Observability example wiring an alert to a `definePlay` handle with an agent action. [`SKILL.md`](cargo-project/SKILL.md) §6: `alert` added to the slugless "commit `cargo.state.json`" resources, and a new critical rule that a `defineAlert` whose actions call paid nodes re-bills on every breach (preview the threshold; prefer cheap notification actions). Cross-links to [`cargo-observability`](cargo-observability/SKILL.md) for the scope/threshold matrix and firing semantics.
|
||||
|
||||
### Batch sample gate (cross-skill)
|
||||
|
||||
- **Never enroll a full batch on the first attempt.** `batch create` / `action execute-batch` fan out across every record in the source, so a config mistake and the full bill arrive together. Every surface that can launch one now requires the same three steps: count the pool for free (`segment get` → `recordsCount`, a storage `count()`, `wc -l`), run a **10–20 record sample** through the exact workflow and config, then ask the user to approve the full enrollment with **both** the record count and the credit estimate in the question. Approval of the sample is explicitly not approval of the full run.
|
||||
- Applied in [`cargo-orchestration/SKILL.md`](cargo-orchestration/SKILL.md) (new "The sample gate" section with per-data-kind sampling mechanics — `kind: "filter"` + `limit`, `recordIds`, sliced `records`, truncated CSV — plus the note that `kind: "segment"`/`"change"` have no limit and can't be sampled directly), [`cargo-gtm/references/cost-discipline.md`](cargo-gtm/references/cost-discipline.md) §1 (pilot → **sample**: 1–3 rows proves a config, 10–20 records proves a hit-rate), [`cargo/references/interaction.md`](cargo/references/interaction.md) §1, [`cargo/references/gotchas.md`](cargo/references/gotchas.md), and [`cargo-cdk/SKILL.md`](cargo-cdk/SKILL.md) §6 (a deployed play's first batch, and the per-run re-bill of a scheduled one).
|
||||
- Applied in [`cargo-orchestration/SKILL.md`](cargo-orchestration/SKILL.md) (new "The sample gate" section with per-data-kind sampling mechanics — `kind: "filter"` + `limit`, `recordIds`, sliced `records`, truncated CSV — plus the note that `kind: "segment"`/`"change"` have no limit and can't be sampled directly), [`cargo-gtm/references/cost-discipline.md`](cargo-gtm/references/cost-discipline.md) §1 (pilot → **sample**: 1–3 rows proves a config, 10–20 records proves a hit-rate), [`cargo/references/interaction.md`](cargo/references/interaction.md) §1, [`cargo/references/gotchas.md`](cargo/references/gotchas.md), and [`cargo-cdk/SKILL.md`](cargo-project/SKILL.md) §6 (a deployed play's first batch, and the per-run re-bill of a scheduled one).
|
||||
- Aligned the downstream surfaces that quoted the old 1–3 row pilot: the execution-plan agent (both the role spec and the plugin mirror), `recipes/build-tam.md`, and `recipes/save-as-play.md` (play sample raised from 1 record to 10–20, with the reminder that a scheduled play's estimate is per-run).
|
||||
|
||||
### `cargo-orchestration` → 1.6.1
|
||||
|
||||
+1
-1
@@ -73,7 +73,7 @@ If you change any description, run `node .github/scripts/routing-eval.ts` and ad
|
||||
|
||||
## Adding a recipe or a provider playbook
|
||||
|
||||
Recipes live in `cargo-gtm/recipes/` (or `cargo-cdk/recipes/`), playbooks in `cargo-gtm/provider-playbooks/`. Both are discovered by filename, so:
|
||||
Recipes live in `cargo-gtm/recipes/` (or `cargo-project/recipes/`), playbooks in `cargo-gtm/provider-playbooks/`. Both are discovered by filename, so:
|
||||
|
||||
- Every recipe must appear in the `cargo-gtm/SKILL.md` recipe table **and** the README recipe table.
|
||||
- Every playbook must appear in the `cargo-gtm/SKILL.md` playbook catalog.
|
||||
|
||||
@@ -93,7 +93,7 @@ Install those **or** this pack, not both — each standalone skill defers to `ca
|
||||
|
||||
The repo also installs as a native **agent plugin**: one source, three targets, sharing the same nineteen skills plus three things `skills add` can't deliver:
|
||||
|
||||
- **An approval hook** ([`hooks/approve-cli.sh`](hooks/approve-cli.sh)) that auto-approves safe `cargo-ai` calls (reads, queries, run/batch operations) while credentials (`login`), token minting, report egress, `cdk deploy`/`destroy`, and any `remove`/`delete` always still prompt. Allow-only — it can never override a deny rule. Wired per target: `PreToolUse` (Claude Code), `PermissionRequest` (Codex), `beforeShellExecution` (Cursor).
|
||||
- **An approval hook** ([`hooks/approve-cli.sh`](hooks/approve-cli.sh)) that auto-approves safe `cargo-ai` calls (reads, queries, run/batch operations) while credentials (`login`), token minting, report egress, `project deploy`/`destroy`, and any `remove`/`delete` always still prompt. Allow-only — it can never override a deny rule. Wired per target: `PreToolUse` (Claude Code), `PermissionRequest` (Codex), `beforeShellExecution` (Cursor).
|
||||
- **Session-lifecycle hooks** (Claude Code only): plugin-bundled `SessionStart`/`Stop`/`SessionEnd` scripts keep the CLI at the bundle's pinned version and log the session to `workspace_management.sessions` — no installer needed. They defer automatically when the installer's copies exist under `~/.claude/hooks/`, so running both never double-registers a session. Unlike the installer's, the plugin's `SessionStart` does **not** run `skills add` (the plugin owns the skills).
|
||||
- **Native subagents** (Claude Code only): `cargo-execution-planner` (costed GTM plans with pilot + budget reconciliation, read-only) and `cargo-list-builder` (parallel sourcing fan-out that executes only pre-approved slices), both on the cheap model tier — [`agents/`](agents/).
|
||||
|
||||
@@ -198,7 +198,7 @@ Then bump the `version:` field in each changed `SKILL.md` (semver, e.g. `1.0.0`
|
||||
|
||||
## What this skill teaches
|
||||
|
||||
**Cargo** connects your data models (companies, contacts, deals) to external integrations (CRMs, enrichment providers, AI agents) and runs them as automated workflows. The repo ships nineteen skills at the root — one **router skill** (`cargo`, the overview / front door for any Cargo CLI task), one **onboarding skill** (`cargo-quickstart`, the guided first-run demo), one **outcome skill** (`cargo-gtm`, the front door for any GTM task), and sixteen **capability skills** (one per CLI domain, plus the cross-domain `cargo-diagnostics` and the hosted-MCP-server skill `cargo-mcp`). Most capability skills wrap the **imperative** CLI (one-off `cargo-ai <domain>` operations); `cargo-cdk` is the **declarative** one — define a whole workspace in code and deploy it — and `cargo-diagnostics` sequences the run/SQL/billing surfaces into forensic runbooks (trace a run, sweep a batch for errors, profile credit spend).
|
||||
**Cargo** connects your data models (companies, contacts, deals) to external integrations (CRMs, enrichment providers, AI agents) and runs them as automated workflows. The repo ships nineteen skills at the root — one **router skill** (`cargo`, the overview / front door for any Cargo CLI task), one **onboarding skill** (`cargo-quickstart`, the guided first-run demo), one **outcome skill** (`cargo-gtm`, the front door for any GTM task), and sixteen **capability skills** (one per CLI domain, plus the cross-domain `cargo-diagnostics` and the hosted-MCP-server skill `cargo-mcp`). Most capability skills wrap the **imperative** CLI (one-off `cargo-ai <domain>` operations); `cargo-project` is the **declarative** one — define a whole workspace in code and deploy it — and `cargo-diagnostics` sequences the run/SQL/billing surfaces into forensic runbooks (trace a run, sweep a batch for errors, profile credit spend).
|
||||
|
||||
### Router — `cargo`
|
||||
|
||||
@@ -255,7 +255,7 @@ The standard library. Load when you need the syntax for a specific CLI domain
|
||||
| **Hosting** | Scaffold, deploy, and promote hosted apps (Vite SPAs on `*.cargo.app`) and edge workers (serverless HTTP handlers), and manage their deployments |
|
||||
| **Mailboxes** | Provision sending inboxes Cargo owns on a sending domain, run provider warm-up and the 5→40/day send ramp, deliver with the `sendEmail` action (0.1 credits/send), and read back threads, replies, opens, clicks, and the workspace suppression list |
|
||||
| **Workspace** | Invite users, create and rotate API tokens, organize resources into folders, manage roles |
|
||||
| **CDK** *(declarative)* | Define an entire workspace in code (`define*` builders) and deploy it with `cargo-ai cdk` (init → types → plan → deploy → destroy). Spans every resource type; use for workspace-as-code / reproducible / version-controlled setups |
|
||||
| **CDK** *(declarative)* | Define an entire workspace in code (`define*` builders) and deploy it with `cargo-ai project` (init → types → plan → deploy → destroy). Spans every resource type; use for workspace-as-code / reproducible / version-controlled setups |
|
||||
| **Diagnostics** *(cross-domain)* | Explain workflow behavior after the fact: trace why one run misbehaved, sweep a batch or play for errors grouped by root cause, profile where a play's credits go. Forensic runbooks over the run / orchestration-SQL / billing surfaces |
|
||||
| **MCP** *(not a CLI domain)* | Drive Cargo from the hosted MCP server at `https://mcp.getcargo.io/mcp` with no CLI installed: connect a client over OAuth or a bearer token, discover and price an action with `search_actions`, execute it over one record or a batch, poll it, read models — and route between the MCP tools and the CLI |
|
||||
|
||||
|
||||
+1
-1
@@ -56,5 +56,5 @@ default branch or from the latest release, so "upgrade" is always the remedy.
|
||||
- The approval hook (`hooks/approve-cli.sh`) auto-approves only a plain
|
||||
`cargo-ai` invocation, and never one that chains, redirects, or substitutes
|
||||
another program. Login/logout, token minting, report egress, and
|
||||
`cdk deploy`/`destroy` are gated back to the normal approval prompt, as is any
|
||||
`project deploy`/`destroy` are gated back to the normal approval prompt, as is any
|
||||
invocation carrying a destructive verb.
|
||||
|
||||
+7
-276
@@ -1,285 +1,16 @@
|
||||
---
|
||||
name: cargo-cdk
|
||||
description: "Manage a whole Cargo workspace as code — declare connectors, models, plays, tools, agents, MCP servers, segments, context, folders, files, workers, and apps in TypeScript, then reconcile them with `cargo-ai cdk` (init → types → plan → deploy), the way you would run Pulumi or the AWS CDK. Triggers: \"as code\", \"in git\", \"version-controlled\", \"reproducible\", \"Terraform for Cargo\", \"set up a whole workspace\", \"staging and production\", \"deploy from CI\", \"review this in a PR\", \"cargo.state.json\", \"scaffold from a template\", \"is there a cookbook for this\", \"start from a cookbook\". Skills with a CDK example (TAM building, account scoring, contact sourcing, routing, AI SDR, rep cockpit) live in gtm-skills; menu in references/cookbooks.md. Skip when: it is a one-off operation, a read, or an ad-hoc query — use the matching capability skill."
|
||||
version: "1.2.4"
|
||||
compatibility: Requires @cargo-ai/cli (npm). Sign in or create an account with `cargo-ai login --email` (emailed code, no browser), `--oauth`, or an API token
|
||||
description: "Renamed to cargo-project. This entry exists only so installs from before the rename are replaced by a pointer. Skip when: always — load cargo-project."
|
||||
version: "2.0.0"
|
||||
compatibility: Requires @cargo-ai/cli (npm).
|
||||
homepage: https://github.com/getcargohq/cargo-skills
|
||||
metadata:
|
||||
author: getcargo
|
||||
openclaw:
|
||||
requires:
|
||||
bins:
|
||||
- cargo-ai
|
||||
install:
|
||||
- kind: node
|
||||
package: "@cargo-ai/cli@latest"
|
||||
bins:
|
||||
- cargo-ai
|
||||
homepage: https://github.com/getcargohq/cargo-skills
|
||||
redirect: cargo-project
|
||||
---
|
||||
|
||||
# Cargo CDK — declarative workspace-as-code
|
||||
# cargo-cdk is now cargo-project
|
||||
|
||||
Use this skill to define a Cargo workspace in TypeScript (`define*` builders from
|
||||
`@cargo-ai/cdk`) and reconcile it to live infrastructure with `cargo-ai cdk deploy`.
|
||||
It is the **declarative** counterpart to the imperative capability skills: instead
|
||||
of running one CLI command per resource, you write the whole graph once and deploy
|
||||
it repeatably, with a committed `cargo.state.json` linking your code to what Cargo
|
||||
created.
|
||||
Load [`cargo-project`](../cargo-project/SKILL.md) instead. It is this skill under its new name, following the CLI: `cargo-ai cdk` is now `cargo-ai project`, and `cdk` still works as an alias.
|
||||
|
||||
## Bootstrap
|
||||
|
||||
Already signed in (`cargo-ai whoami` returns a workspace)? Skip to the next section.
|
||||
|
||||
```bash
|
||||
npm install -g @cargo-ai/cli # no global install? prefix every command with `npx @cargo-ai/cli`
|
||||
cargo-ai login --email you@company.com # emailed code, no browser; creates the account on first use
|
||||
# alternatives: --oauth (browser) · --token <api-token> (CI)
|
||||
cargo-ai whoami # confirm the active workspace before any write
|
||||
cargo-ai cdk --help # `unknown command` = CLI too old; reinstall @cargo-ai/cli@latest
|
||||
```
|
||||
|
||||
Two CDK-specific extras: the project needs **`@cargo-ai/cdk` as a dependency** for the `define*` builders you import (`cargo-ai cdk init` scaffolds a `package.json` with it — then `npm install`), and the `cargo-ai cdk` domain ships with the CLI itself.
|
||||
|
||||
Every command prints JSON to stdout; failures exit non-zero with `{"errorMessage": "..."}`. Anything that creates a run or a batch is async — pass `--wait-until-finished` or poll the matching `get`. When the full skill bundle is installed, [`../cargo/references/prerequisites.md`](../cargo/references/prerequisites.md) adds the CLI version pin, token scopes, and the admin-only surface.
|
||||
|
||||
## 1) What this skill governs
|
||||
|
||||
- **Authoring** every Cargo resource with a `define*` builder that returns a
|
||||
**handle**; wiring resources by passing handles to each other (the dependency
|
||||
graph is your variable graph).
|
||||
- **Deploying** the graph: `plan` (offline diff) → `deploy` (create/update, write
|
||||
state) → `destroy` (tear down). Plus drift (`refresh`), adoption (`import`), and
|
||||
recovery (`rollback`).
|
||||
- **Typing** the config against your workspace's real integration schemas
|
||||
(`cargo-ai cdk types`).
|
||||
|
||||
The CDK spans **every** resource kind — so it overlaps every imperative capability
|
||||
skill (`cargo-connection`, `cargo-storage`, `cargo-ai`, `cargo-orchestration`,
|
||||
`cargo-content`, `cargo-hosting`, …). Which to reach for is the first decision:
|
||||
|
||||
## 2) CDK or the CLI? — the routing decision
|
||||
|
||||
> **Declarative (this skill) vs imperative (a capability skill).**
|
||||
|
||||
Use the **CDK** when the user is **managing resources as an artifact**:
|
||||
|
||||
- "Set up / stand up / bootstrap a whole workspace (as code / from a template)."
|
||||
- "Make this reproducible / version-controlled / in git / repeatable across
|
||||
environments (dev → prod)."
|
||||
- "Deploy these connectors + models + agents together" (a multi-resource graph
|
||||
wired by dependency).
|
||||
- Anything that should be re-runnable and diffable, where losing the definition
|
||||
would be a problem.
|
||||
|
||||
Use the matching **capability skill** (imperative `cargo-ai <domain>`) when the
|
||||
user is doing a **one-off operation** or **exploring**:
|
||||
|
||||
- "Create one connector", "add a column to this model", "list connectors",
|
||||
"run this workflow", "query storage", "read this agent's memory."
|
||||
- Any read, ad-hoc query, or single mutation that doesn't need to live in code.
|
||||
|
||||
When unsure, ask whether the result should be committed and re-deployable. If yes
|
||||
→ CDK. If it's a quick action or a read → the capability skill (see the
|
||||
[`cargo` router](../cargo/SKILL.md) to pick the right domain).
|
||||
|
||||
## 3) The lifecycle
|
||||
|
||||
```
|
||||
cargo-ai cdk init <dir> scaffold a project from a template (blank | full)
|
||||
│
|
||||
cargo-ai cdk types generate per-workspace types for typed config (optional)
|
||||
│
|
||||
(author define* files) importing a .ts file IS registration — no manifest
|
||||
│
|
||||
cargo-ai cdk plan offline: compile the graph, diff against cargo.state.json
|
||||
│
|
||||
cargo-ai cdk deploy create/update resources in dependency order, write state
|
||||
│
|
||||
cargo-ai cdk destroy tear down resources recorded in state
|
||||
```
|
||||
|
||||
> **`cdk plan` says what resources change; it doesn't show what a play does.**
|
||||
> For a `definePlay` / `defineTool` graph past three nodes, present a Mermaid
|
||||
> flowchart of the node graph alongside the plan — routing, fallbacks, and which
|
||||
> nodes bill on every scheduled run are what the reviewer is approving. Generate it
|
||||
> from the deployed release after the first deploy, or from the node array while
|
||||
> authoring:
|
||||
> [`../cargo-orchestration/references/node-diagram.md`](../cargo-orchestration/references/node-diagram.md).
|
||||
|
||||
Side branches: `cargo-ai cdk refresh` (read-only drift report) · `deploy --refresh`
|
||||
(re-apply code over out-of-band edits) · `deploy --prune` (delete resources removed
|
||||
from code) · `cargo-ai cdk import <id> <uuid>` (bind an existing live resource into
|
||||
state) · `cargo-ai cdk rollback` (restore the pre-deploy state snapshot).
|
||||
|
||||
## 4) Documentation hierarchy
|
||||
|
||||
- **Level 1** — `SKILL.md` (this file): the decision model, lifecycle, critical
|
||||
rules, and routing.
|
||||
- **Level 2** — Guides:
|
||||
[`guides/authoring-resources.md`](guides/authoring-resources.md),
|
||||
[`guides/deploy-and-state.md`](guides/deploy-and-state.md),
|
||||
[`guides/typed-config.md`](guides/typed-config.md).
|
||||
- **Level 2.5** — Recipes: [`recipes/*.md`](recipes/) — step-by-step playbooks to
|
||||
follow as your execution plan.
|
||||
- **References** — [`references/resources.md`](references/resources.md) (the full
|
||||
builder catalog), [`references/commands.md`](references/commands.md) (every
|
||||
`cargo-ai cdk` subcommand + flags),
|
||||
[`references/troubleshooting.md`](references/troubleshooting.md), and
|
||||
[`references/examples/full-workspace.md`](references/examples/full-workspace.md).
|
||||
|
||||
## 5) Read behavior — match the task to a doc and READ IT
|
||||
|
||||
| When the task involves… | Read this first | What it gives you |
|
||||
|---|---|---|
|
||||
| Writing `define*` files, wiring resources, `secret()`/`env()`, `defineWorkflow` bodies (tool/play logic) | [`guides/authoring-resources.md`](guides/authoring-resources.md) | The builder catalog, the handle/ref model, secrets, and how workflow bodies compile. |
|
||||
| `plan` / `deploy` / `destroy`, the state file, drift, adopting existing resources, CI | [`guides/deploy-and-state.md`](guides/deploy-and-state.md) | The deploy lifecycle, `cargo.state.json` semantics, drift/import/rollback, async builds. |
|
||||
| Typed config, `cargo-ai cdk types`, tsconfig wiring, `integrations.*` in workflow bodies | [`guides/typed-config.md`](guides/typed-config.md) | What `cdk types` generates and how to wire it into your project. |
|
||||
| A field/spec/output for a specific builder | [`references/resources.md`](references/resources.md) | Every builder → spec fields → which ref each takes → outputs. |
|
||||
| Exact command flags | [`references/commands.md`](references/commands.md) | Every `cargo-ai cdk` subcommand and its flags. |
|
||||
| A deploy error / footgun | [`references/troubleshooting.md`](references/troubleshooting.md) | The known failure modes and fixes. |
|
||||
| A known GTM outcome, before authoring one | [`references/cookbooks.md`](references/cookbooks.md) | The cookbook menu: gtm-skills that carry a worked CDK example, and the adaptations each supports. |
|
||||
|
||||
### Cookbooks — check the menu before authoring a known outcome from scratch
|
||||
|
||||
[`getcargohq/gtm-skills`](https://github.com/getcargohq/gtm-skills) holds, beside its
|
||||
one-off skills, **cookbooks**: skills that carry worked CDK resources, the same job as a deployed
|
||||
pipeline that keeps producing the result (TAM building, account scoring, contact
|
||||
sourcing, routing engine, AI SDR, rep cockpit, …). Every folder is self-contained: its
|
||||
own models, connectors and folders, no shared foundation, no requires graph.
|
||||
|
||||
**The menu is local: [`references/cookbooks.md`](references/cookbooks.md).** Read it
|
||||
before authoring a common GTM outcome from scratch. It is generated from gtm-skills'
|
||||
`catalog.json`, so it cannot drift.
|
||||
|
||||
**A cookbook is a worked example, not a template to fill in.** Each one declares in its `SKILL.md` what may be reshaped, what must hold or it stops
|
||||
working, and what has to be answered either way, and it carries its own procedure.
|
||||
`cdk add` is the copy step in that procedure:
|
||||
|
||||
```sh
|
||||
cargo-ai cdk add cookbook/tam-building # inside a CDK project
|
||||
cargo-ai cdk init my-project --cookbook tam-building # no project yet: both at once
|
||||
```
|
||||
|
||||
That writes the resources to `infra/tam-building/` and the procedure to
|
||||
`.claude/skills/tam-building/`, skipping any file it would overwrite. **Then start the
|
||||
skill at its Adapt section** — its opening steps are written for someone who found the
|
||||
folder on GitHub and still has to place it, so following them from the top scaffolds a
|
||||
second project and copies the folder in again.
|
||||
|
||||
What is left after the copy is the part only you can do: reconcile it with what is
|
||||
already declared, adapt the copied files **in place** to the project's real shape (do not
|
||||
regenerate them from the skill's prose — the safety lives in the TypeScript), plan and
|
||||
stop, deploy on a yes, walk its `Done when`.
|
||||
|
||||
**If you are mid-task and the skill is not in this session**, `npx skills add
|
||||
getcargohq/gtm-skills/<slug>` fetches the procedure alone and you can read
|
||||
`.agents/skills/<slug>/SKILL.md` directly; no reload needed. To read one without
|
||||
installing, `npx skills use getcargohq/gtm-skills@<slug>` prints it. Neither brings the
|
||||
CDK resources — for those you still want `cdk add`.
|
||||
|
||||
**Routing rule: one-off versus standing.** A user who wants the list today wants
|
||||
`cargo-gtm` (or gtm-skills' one-off `build-tam-list`); a user who wants a pipeline
|
||||
that keeps producing it wants `tam-building`. The same words describe both ("build
|
||||
our TAM"), so listen for whether the result is meant to keep arriving. A cookbook
|
||||
matches → install it and follow it. No match → author from the recipes below.
|
||||
|
||||
**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.
|
||||
|
||||
Caveat: the examples typecheck, but they are not yet deploy-verified against a live
|
||||
workspace, and every one is `to-be-approved`. Treat each skill's `Done when` as the
|
||||
acceptance test, and always review `cargo-ai cdk plan` before deploying.
|
||||
|
||||
### Recipes — follow step-by-step when one matches
|
||||
|
||||
| Recipe | Use when… |
|
||||
|---|---|
|
||||
| [`recipes/scaffold-a-workspace.md`](recipes/scaffold-a-workspace.md) | Standing up a new workspace from scratch (`init` → types → plan → deploy). |
|
||||
| [`recipes/add-connector-and-model.md`](recipes/add-connector-and-model.md) | Adding a data source + a model sourced from it, wired by handle. |
|
||||
| [`recipes/build-an-agent.md`](recipes/build-an-agent.md) | Composing a model + tool + agent (with `uses` / `models` / `tools`) and deploying. |
|
||||
| [`recipes/migrate-existing-workspace.md`](recipes/migrate-existing-workspace.md) | Bringing an already-live workspace under CDK management via `cdk import`. |
|
||||
| [`recipes/deploy-from-ci.md`](recipes/deploy-from-ci.md) | Deploying non-interactively from CI (token auth + committed state). |
|
||||
|
||||
## 6) Critical rules
|
||||
|
||||
- **Commit `cargo.state.json`.** It is the link from your code to the resources
|
||||
Cargo created — and the **only** handle on a deployed **play**, **agent**, or
|
||||
**alert** (they have no slug). Lose it and those resources orphan; recover a link
|
||||
with `cargo-ai cdk import`. It records only `{hash, uuid, outputs}` — never secret
|
||||
values. Git-ignore the working files (`cdk init` scaffolds this):
|
||||
```gitignore
|
||||
.cargo-ai/
|
||||
cargo.state.lock
|
||||
cargo.state.bak.json
|
||||
cargo.state.audit.jsonl
|
||||
```
|
||||
- **Secrets:** wire credentials with `secret("ENV_VAR")` (often
|
||||
`secret("HUBSPOT_API_KEY")`). The value is read from the environment **at deploy
|
||||
time**, kept out of the content hash and out of state, so rotating a token
|
||||
doesn't read as drift. Export the env var before deploying — a missing one fails
|
||||
the deploy with an unresolved `${ENV_VAR}` placeholder.
|
||||
- **Wire by handle, never by `.uuid`.** Pass a `define*` handle directly
|
||||
(`dataset: hubspot`, `tools: [enrich]`), or `xxRef("uuid")` for a resource you
|
||||
didn't define in code (`connectorRef`, `modelRef`, `folderRef`, `toolRef`,
|
||||
`agentRef`, …). Where a reference needs per-call options, wrap it as
|
||||
`{ ref, …options }` (e.g. `models: [{ ref: contacts, readOnly: true }]`).
|
||||
- **Run `cargo-ai cdk types` after workspace integrations change** — it
|
||||
regenerates `.cargo-ai/` so `defineConnector`/`defineModel` config (and
|
||||
`integrations.*` in workflow bodies) type-check against the real schemas. Typing
|
||||
is a bonus, never a gate: deploy works without it.
|
||||
- **Run `cdk` commands from the project root.** `npx`/`cargo-ai` resolve from the
|
||||
nearest `package.json`; run elsewhere and `.cargo-ai/` and `cargo.state.json`
|
||||
land in the wrong directory. Use `--dir <path>` to be explicit.
|
||||
- **`--yes` in CI.** `deploy` and `destroy` prompt for confirmation; non-interactive
|
||||
runs must pass `--yes`.
|
||||
- **A `definePlay`/`defineTool` graph with paid nodes gets a sample run before it
|
||||
goes wide.** Deploying is not running, but the first thing that runs a deployed
|
||||
play is usually a batch over the whole segment — and a scheduled play re-bills
|
||||
every node on every run. Before enrolling everything (or enabling a schedule),
|
||||
run the deployed workflow on **10–20 records** — `cargo-ai orchestration batch
|
||||
create --data '{"kind":"filter","modelUuid":"…","filter":…,"limit":15}'`, or
|
||||
`batch create --file ./plays/x.ts` to test-run the module without deploying —
|
||||
then ask the user to approve the full enrollment with the **record count** and
|
||||
**credit estimate**. Read the provider's playbook
|
||||
(`../cargo-gtm/provider-playbooks/<slug>.md`, esp. its *Recurring use* section)
|
||||
and the gate in
|
||||
[`../cargo-gtm/references/cost-discipline.md`](../cargo-gtm/references/cost-discipline.md).
|
||||
- **A `defineAlert` whose actions call paid nodes re-bills on every breach.** An
|
||||
alert's `actions` fire as real runs, so a badly-sized `threshold` on a tight
|
||||
`schedule` can breach — and bill — every tick. Size the threshold with
|
||||
`cargo-ai observability alert preview` before deploying, prefer cheap notification
|
||||
actions (an agent that posts, a connector notification) over anything that fans
|
||||
out, and apply the same cost gate above when an action calls a credits-based
|
||||
provider. Scope/threshold and firing semantics:
|
||||
[`../cargo-observability/SKILL.md`](../cargo-observability/SKILL.md).
|
||||
- **`defineMailbox` bills monthly, and `defineDomain` rewrites a DNS zone.** A
|
||||
mailbox is 100–160 credits *per month* for as long as it exists (`cargo-ai
|
||||
mailboxManagement pricing get` for live figures), so a `+ create mailbox:…` line
|
||||
in the plan is a recurring charge the user approves, not a one-off. Its `domain`,
|
||||
`username` and `type` are **create-only** — changing any of them is destroy +
|
||||
recreate, i.e. a brand-new inbox back at the bottom of a 45-day warm-up ramp. The
|
||||
deploy polls `refreshStatus` for up to 5 minutes waiting for `active`. On
|
||||
`defineDomain`, `dnsRecords` is the **whole zone, not a patch**: declaring it
|
||||
replaces every live record (including the ones the registrar wrote at purchase),
|
||||
and omitting it leaves the zone untouched. Use `adopt: true` for a domain or
|
||||
mailbox bought in the UI. Ramp, suppression and sending:
|
||||
[`../cargo-mailbox-management/SKILL.md`](../cargo-mailbox-management/SKILL.md).
|
||||
- **Route CDK-managed resources into a clearly-labelled folder.** Set `folder:` on
|
||||
each builder so everything CDK owns lands in a dedicated folder whose name signals
|
||||
"owned by code — don't hand-edit" to anyone in the UI (manual UI edits read back as
|
||||
drift on the next `plan`). Folders are per-kind, so give each kind its own but share
|
||||
one short, recognizable prefix — recommended: **`🔒 CDK`** (e.g. `🔒 CDK Models`,
|
||||
`🔒 CDK Agents`). Keep names short (long labels truncate in the folder tree); the
|
||||
lock emoji is the "don't touch" cue. See
|
||||
[`guides/authoring-resources.md`](guides/authoring-resources.md).
|
||||
|
||||
## Help
|
||||
|
||||
- `cargo-ai cdk --help` and `cargo-ai cdk <subcommand> --help` for the live flag
|
||||
surface.
|
||||
- When a documented command/flag/response doesn't match what you observe, file a
|
||||
report: `cargo-ai workspaceManagement report create` (see
|
||||
[`../cargo-workspace-management/SKILL.md`](../cargo-workspace-management/SKILL.md)).
|
||||
This directory holds no instructions. It is a redirect, and will be removed in a later release.
|
||||
|
||||
@@ -1,54 +0,0 @@
|
||||
# Command reference — `cargo-ai cdk`
|
||||
|
||||
All subcommands accept `--dir <path>` (the project root, default `.`) and `--json`
|
||||
(machine-readable output). Run from the project root so `.cargo-ai/` and
|
||||
`cargo.state.json` land in the right place. Confirm the surface live with
|
||||
`cargo-ai cdk <subcommand> --help`.
|
||||
|
||||
| Command | What it does |
|
||||
|---|---|
|
||||
| `cargo-ai cdk init <directory>` | Scaffold a GTM repo from `getcargohq/cargo-manifest`, with the CDK project in `infra/`. `--name <name>`, `--cookbook <slug>` (install a cookbook into the new project), `--force` (write into a non-empty directory). There is no template flag: the scaffold never varies, and what varies is the cookbook layered on top. |
|
||||
| `cargo-ai cdk add cookbook/<slug>` | Copy a worked example into this project — `infra/<slug>/` plus its procedure under the skills directories. `--overwrite` (replace existing files; default skips them), `--yes`. Omit the address to choose interactively. |
|
||||
| `cargo-ai cdk add connector/<integration>` | Authorize a connector in the browser and write its `defineConnector`. `--connector-uuid <uuid>` adopts one already created there. |
|
||||
| `cargo-ai cdk cookbook list\|search\|view` | Browse the cookbooks `add` installs — `view <slug>` shows what one deploys, what it will ask you for, and its declared adaptations. |
|
||||
| `cargo-ai cdk types` | Generate per-workspace types into `.cargo-ai/` for typed config. |
|
||||
| `cargo-ai cdk plan` | Offline: compile the graph and diff against `cargo.state.json`. No API calls. |
|
||||
| `cargo-ai cdk deploy` | Create/update resources in dependency order; write state. Prompts unless `--yes`. |
|
||||
| `cargo-ai cdk refresh` | Read-only: report resources that drifted from code (changed/deleted out of band). |
|
||||
| `cargo-ai cdk import <id> <uuid>` | Bind an existing live resource (`kind:slug`) to a uuid in state. |
|
||||
| `cargo-ai cdk rollback` | Restore `cargo.state.json` from the pre-deploy snapshot. |
|
||||
| `cargo-ai cdk destroy` | Tear down resources recorded in state. `--target <id>` for one, `--all` for everything. |
|
||||
|
||||
## Common flags
|
||||
|
||||
- `--dir <path>` — project root (default `.`).
|
||||
- `--yes` — skip the confirmation prompt (**required in CI / non-interactive**).
|
||||
- `--json` — machine-readable output.
|
||||
- `--force` — steal a stale `cargo.state.lock`.
|
||||
|
||||
## `deploy` modifiers
|
||||
|
||||
- `cargo-ai cdk deploy --prune` — also **delete** resources that are in state but
|
||||
removed from code (reverse dependency order; adopted resources are released, not
|
||||
deleted).
|
||||
- `cargo-ai cdk deploy --refresh` — re-read live resources and re-apply your code
|
||||
over any out-of-band changes.
|
||||
|
||||
## `destroy` targets
|
||||
|
||||
- `cargo-ai cdk destroy --target <kind:slug>` — remove one resource (refused if
|
||||
other state resources still depend on it).
|
||||
- `cargo-ai cdk destroy --all` — remove everything in state, dependents first.
|
||||
|
||||
## Examples
|
||||
|
||||
```bash
|
||||
cargo-ai cdk init acme # scaffold
|
||||
cargo-ai cdk add cookbook/tam-building --dir acme # layer a worked example on
|
||||
cargo-ai cdk types --dir acme # type config
|
||||
cargo-ai cdk plan --dir acme # preview
|
||||
cargo-ai cdk deploy --dir acme --yes # apply (non-interactive)
|
||||
cargo-ai cdk refresh --dir acme # drift report
|
||||
cargo-ai cdk import agent:sdr <uuid> --dir acme # adopt a live agent
|
||||
cargo-ai cdk destroy --dir acme --all --yes # tear down
|
||||
```
|
||||
@@ -1,78 +1,13 @@
|
||||
{
|
||||
"$comment": "Generated by .github/scripts/skills-metadata.mjs — do not hand-edit. Regenerate with: node .github/scripts/skills-metadata.mjs --write .",
|
||||
"name": "cargo-cdk",
|
||||
"version": "1.2.4",
|
||||
"version": "2.0.0",
|
||||
"documents": [
|
||||
{
|
||||
"path": "SKILL.md",
|
||||
"kind": "entrypoint",
|
||||
"title": "Cargo CDK — declarative workspace-as-code"
|
||||
},
|
||||
{
|
||||
"path": "guides/authoring-resources.md",
|
||||
"kind": "guide",
|
||||
"title": "Authoring resources"
|
||||
},
|
||||
{
|
||||
"path": "guides/deploy-and-state.md",
|
||||
"kind": "guide",
|
||||
"title": "Deploy & state"
|
||||
},
|
||||
{
|
||||
"path": "guides/typed-config.md",
|
||||
"kind": "guide",
|
||||
"title": "Typed config — `cargo-ai cdk types`"
|
||||
},
|
||||
{
|
||||
"path": "recipes/add-connector-and-model.md",
|
||||
"kind": "recipe",
|
||||
"title": "Recipe: add a connector and a model sourced from it"
|
||||
},
|
||||
{
|
||||
"path": "recipes/build-an-agent.md",
|
||||
"kind": "recipe",
|
||||
"title": "Recipe: build an agent (model + tool + agent)"
|
||||
},
|
||||
{
|
||||
"path": "recipes/deploy-from-ci.md",
|
||||
"kind": "recipe",
|
||||
"title": "Recipe: deploy from CI"
|
||||
},
|
||||
{
|
||||
"path": "recipes/migrate-existing-workspace.md",
|
||||
"kind": "recipe",
|
||||
"title": "Recipe: bring an existing workspace under CDK management"
|
||||
},
|
||||
{
|
||||
"path": "recipes/scaffold-a-workspace.md",
|
||||
"kind": "recipe",
|
||||
"title": "Recipe: scaffold a workspace from scratch"
|
||||
},
|
||||
{
|
||||
"path": "references/commands.md",
|
||||
"kind": "reference",
|
||||
"title": "Command reference — `cargo-ai cdk`"
|
||||
},
|
||||
{
|
||||
"path": "references/cookbooks.md",
|
||||
"kind": "reference",
|
||||
"title": "Cookbooks: worked CDK examples, before you author one from scratch"
|
||||
},
|
||||
{
|
||||
"path": "references/examples/full-workspace.md",
|
||||
"kind": "example",
|
||||
"title": "Example: a full GTM workspace end-to-end"
|
||||
},
|
||||
{
|
||||
"path": "references/resources.md",
|
||||
"kind": "reference",
|
||||
"title": "Resource reference"
|
||||
},
|
||||
{
|
||||
"path": "references/troubleshooting.md",
|
||||
"kind": "reference",
|
||||
"title": "Troubleshooting"
|
||||
"title": "cargo-cdk is now cargo-project"
|
||||
}
|
||||
],
|
||||
"contentHash": "425289a3fabd441c910f21eaf58e45d0e12d0a1c7129b4a5c151e65cc98bef8f"
|
||||
"contentHash": "ad9701a71bd37558bd7ee80fff01428241f40a31b21598f547c5be5560965a92"
|
||||
}
|
||||
|
||||
+1
-1
@@ -1,7 +1,7 @@
|
||||
---
|
||||
name: cargo-gtm
|
||||
description: "Do business-to-business go-to-market work on Cargo — research accounts and buying committees, enrich and verify B2B contact records from licensed data providers, score and qualify leads, draft permission-based outreach for the user's own sequencer, sync to CRM, and monitor buying signals. Consent basis, suppression lists, and volume limits gate every step that touches a person (`references/acceptable-use.md`); bulk unsolicited messaging, purchased or scraped lists, and consumer targeting are refused. Triggers: \"build me a list of\", \"find 50 <title> at <segment>\", \"who works at\", \"find work emails for these accounts\", \"enrich this CSV\", \"verify these emails\", \"build a TAM\", \"who fits our ICP\", \"who actually buys from us\", \"what data points should we collect on accounts\", \"our outbound is reaching the wrong people\", \"score these leads\", \"write a first-touch email\", \"push these to my CRM\", \"who changed jobs\", \"who just raised funding\", \"companies using <tech>\", \"who is hiring <role>\", \"find the buying committee\", \"portfolio companies of <investor>\", \"upload this audience to Google/Meta/LinkedIn ads\". Providers: aiArk, anthropic, apolloio, bouncer, brightData, builtwith, cleon1, companyEnrich, contactOut, datagma, dropcontact, enrichCrm, enrichley, enrowio, exa, findyMail, firecrawl, forager, FullEnrich, g2, gemini, hunter, icypeas, kitt, leadMagic, linkedin, linkup, mixrank, neverBounce, oceanio, openAi, parallel, peopleDataLabs, perplexity, piloterr, prospeo, proxycurl, reverseContact, rocketreach, salesNavigator, serper, sillage, snitcher, societeInfo, theirStack, theSwarm, waterfall, x, zeroBounce. Reads phase guides, recipes, and per-provider playbooks before any paid call. Skip when: a run already happened and misbehaved — use cargo-diagnostics."
|
||||
version: "2.1.0"
|
||||
version: "2.1.1"
|
||||
compatibility: Requires @cargo-ai/cli (npm). Sign in or create an account with `cargo-ai login --email` (emailed code, no browser), `--oauth`, or an API token
|
||||
homepage: https://github.com/getcargohq/cargo-skills
|
||||
metadata:
|
||||
|
||||
@@ -140,11 +140,11 @@ Once parity passes, the chain becomes a play ([`save-as-play.md`](save-as-play.m
|
||||
Then offer the part Clay has no answer to at all:
|
||||
|
||||
```bash
|
||||
cargo-ai cdk init
|
||||
cargo-ai cdk plan # a diffed resource tree; runs with no Cargo credentials at all
|
||||
cargo-ai project init
|
||||
cargo-ai project plan # a diffed resource tree; runs with no Cargo credentials at all
|
||||
```
|
||||
|
||||
A Clay table is a spreadsheet: no diff, no review, no rollback, and the person who built it is the only one who knows why a column is there. Declared in `cargo-cdk`, the same table is a file that goes through a pull request. `plan` needs no credentials, so the user can see exactly what they would deploy before committing to anything; `deploy` is the only credential-gated step in the sequence. Full flow in [`../../cargo-cdk/SKILL.md`](../../cargo-cdk/SKILL.md).
|
||||
A Clay table is a spreadsheet: no diff, no review, no rollback, and the person who built it is the only one who knows why a column is there. Declared in `cargo-project`, the same table is a file that goes through a pull request. `plan` needs no credentials, so the user can see exactly what they would deploy before committing to anything; `deploy` is the only credential-gated step in the sequence. Full flow in [`../../cargo-project/SKILL.md`](../../cargo-project/SKILL.md).
|
||||
|
||||
Say this out loud when the parity table lands. It is the argument the cost comparison cannot make, and it is the one that does not erode when a provider changes its price.
|
||||
|
||||
|
||||
@@ -113,7 +113,7 @@ Play mechanics (batch data kinds, `playNotCompatible`, monitoring): [`../../carg
|
||||
|
||||
## Managing the workspace as code?
|
||||
|
||||
If the workspace is CDK-managed (`cargo-ai cdk` — resources defined in TypeScript and deployed via plan/deploy), don't create the play imperatively: add it as a `definePlay`/`defineTool` in the CDK project instead, so it's versioned with the rest of the infra. An imperatively-created play in a CDK workspace is drift.
|
||||
If the workspace is CDK-managed (`cargo-ai project` — resources defined in TypeScript and deployed via plan/deploy), don't create the play imperatively: add it as a `definePlay`/`defineTool` in the CDK project instead, so it's versioned with the rest of the infra. An imperatively-created play in a CDK workspace is drift.
|
||||
|
||||
## Close the loop
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"$comment": "Generated by .github/scripts/skills-metadata.mjs — do not hand-edit. Regenerate with: node .github/scripts/skills-metadata.mjs --write .",
|
||||
"name": "cargo-gtm",
|
||||
"version": "2.1.0",
|
||||
"version": "2.1.1",
|
||||
"documents": [
|
||||
{
|
||||
"path": "SKILL.md",
|
||||
@@ -534,5 +534,5 @@
|
||||
"kind": "script"
|
||||
}
|
||||
],
|
||||
"contentHash": "04a7078c6b3234ca57dca9e974205f2dcf75447f36e3733f90552d73745e1821"
|
||||
"contentHash": "0cc862403e313823ca2b805e318055398d9148545ac9a64d780d5745338c1eaa"
|
||||
}
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
name: cargo-hosting
|
||||
description: "Put something on the internet from Cargo — Vite single-page apps served at https://<slug>.cargo.app and serverless edge workers that answer HTTP requests, plus the deployments that build and promote them. Triggers: \"build me a dashboard for this\", \"host this app\", \"give me a URL to share\", \"deploy this\", \"I need a webhook endpoint\", \"make it live\", \"promote to production\", \"put it on cargo.app\", \"ship a UI for my team\". Skip when: the app or worker should be declared as committed workspace code — use cargo-cdk."
|
||||
version: "1.0.1"
|
||||
description: "Put something on the internet from Cargo — Vite single-page apps served at https://<slug>.cargo.app and serverless edge workers that answer HTTP requests, plus the deployments that build and promote them. Triggers: \"build me a dashboard for this\", \"host this app\", \"give me a URL to share\", \"deploy this\", \"I need a webhook endpoint\", \"make it live\", \"promote to production\", \"put it on cargo.app\", \"ship a UI for my team\". Skip when: the app or worker should be declared as committed workspace code — use cargo-project."
|
||||
version: "1.0.2"
|
||||
compatibility: Requires @cargo-ai/cli (npm). Sign in or create an account with `cargo-ai login --email` (emailed code, no browser), `--oauth`, or an API token
|
||||
homepage: https://github.com/getcargohq/cargo-skills
|
||||
metadata:
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"$comment": "Generated by .github/scripts/skills-metadata.mjs — do not hand-edit. Regenerate with: node .github/scripts/skills-metadata.mjs --write .",
|
||||
"name": "cargo-hosting",
|
||||
"version": "1.0.1",
|
||||
"version": "1.0.2",
|
||||
"documents": [
|
||||
{
|
||||
"path": "SKILL.md",
|
||||
@@ -34,5 +34,5 @@
|
||||
"title": "Hosting troubleshooting"
|
||||
}
|
||||
],
|
||||
"contentHash": "5a919e446a59160d7f12000e800253616619cb4a1e839a136b05d0e15641e70f"
|
||||
"contentHash": "ad4c6518a0be45c6a713e9de33e572a226a353c872a769f8dd95707dd5b8c2c0"
|
||||
}
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
name: cargo-mailbox-management
|
||||
description: "Send mail from inboxes Cargo owns — provision mailboxes on a sending domain, run provider warm-up and the 5→40/day send ramp, deliver with the `sendEmail` action, and read back threads, replies, delivery events, and the workspace suppression list. Triggers: \"set up a sending mailbox\", \"provision inboxes for outbound\", \"warm up this mailbox\", \"how many sends do I have left today\", \"send this from Cargo\", \"did they reply\", \"who unsubscribed\", \"suppress this recipient\", \"take me off your list\", \"never email them again\", \"what do mailboxes cost\", \"my mailbox is stuck pending\". A mailbox is a recurring monthly credit charge, and every send is gated on basis, suppression, and relevance. Skip when: writing the copy or building the audience — use cargo-gtm; the mailbox belongs in git — use cargo-cdk."
|
||||
version: "1.0.2"
|
||||
description: "Send mail from inboxes Cargo owns — provision mailboxes on a sending domain, run provider warm-up and the 5→40/day send ramp, deliver with the `sendEmail` action, and read back threads, replies, delivery events, and the workspace suppression list. Triggers: \"set up a sending mailbox\", \"provision inboxes for outbound\", \"warm up this mailbox\", \"how many sends do I have left today\", \"send this from Cargo\", \"did they reply\", \"who unsubscribed\", \"suppress this recipient\", \"take me off your list\", \"never email them again\", \"what do mailboxes cost\", \"my mailbox is stuck pending\". A mailbox is a recurring monthly credit charge, and every send is gated on basis, suppression, and relevance. Skip when: writing the copy or building the audience — use cargo-gtm; the mailbox belongs in git — use cargo-project."
|
||||
version: "1.0.3"
|
||||
compatibility: Requires @cargo-ai/cli (npm). Sign in or create an account with `cargo-ai login --email` (emailed code, no browser), `--oauth`, or an API token
|
||||
homepage: https://github.com/getcargohq/cargo-skills
|
||||
metadata:
|
||||
@@ -304,7 +304,7 @@ For the inbox itself, **prefer CDK** — the `mailbox create` help says so, and
|
||||
a mailbox is long-lived infrastructure with a monthly cost, which is exactly what belongs in
|
||||
git and in a plan you can review. `defineMailbox` (with `defineDomain` for the sending domain)
|
||||
covers it; `adopt: true` binds a mailbox bought in the web app instead of provisioning a second
|
||||
one. See [`../cargo-cdk/SKILL.md`](../cargo-cdk/SKILL.md) and "Declarative vs imperative" in
|
||||
one. See [`../cargo-project/SKILL.md`](../cargo-project/SKILL.md) and "Declarative vs imperative" in
|
||||
[`../cargo/SKILL.md`](../cargo/SKILL.md).
|
||||
|
||||
Use this skill's imperative commands for one-off provisioning, and for everything CDK does not
|
||||
|
||||
@@ -179,4 +179,4 @@ billing stops — there is no pause. Threads, messages, and events already recor
|
||||
readable; the suppression list is workspace-wide and is unaffected.
|
||||
|
||||
If the mailbox was declared with CDK's `defineMailbox`, remove it there instead and
|
||||
`cargo-ai cdk deploy`, or the next deploy will provision it again.
|
||||
`cargo-ai project deploy`, or the next deploy will provision it again.
|
||||
|
||||
@@ -11,8 +11,8 @@ UUID, and `domainManagement` has an API but **no `cargo-ai` commands**. Two ways
|
||||
|
||||
- **Web app** — open the sending domain in Cargo and take the UUID from the URL.
|
||||
- **CDK** — declare it with `defineDomain` (`adopt: true` for a domain already bought in the
|
||||
app), `cargo-ai cdk deploy`, and read the UUID back from `cargo.state.json`. See
|
||||
[`../../cargo-cdk/SKILL.md`](../../cargo-cdk/SKILL.md).
|
||||
app), `cargo-ai project deploy`, and read the UUID back from `cargo.state.json`. See
|
||||
[`../../cargo-project/SKILL.md`](../../cargo-project/SKILL.md).
|
||||
|
||||
Say this to the user rather than guessing a UUID, and file it:
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"$comment": "Generated by .github/scripts/skills-metadata.mjs — do not hand-edit. Regenerate with: node .github/scripts/skills-metadata.mjs --write .",
|
||||
"name": "cargo-mailbox-management",
|
||||
"version": "1.0.2",
|
||||
"version": "1.0.3",
|
||||
"documents": [
|
||||
{
|
||||
"path": "SKILL.md",
|
||||
@@ -34,5 +34,5 @@
|
||||
"title": "Warm-up and the send ramp"
|
||||
}
|
||||
],
|
||||
"contentHash": "d343f42fdf3e32dd0c02e576185585abd0b68c95bf8c106a26080e4eca0ea9e5"
|
||||
"contentHash": "946c083af24ffef1a02e01adfb893da8184060fc239e1960deaf9dc7fe2f8584"
|
||||
}
|
||||
|
||||
+2
-2
@@ -1,7 +1,7 @@
|
||||
---
|
||||
name: cargo-mcp
|
||||
description: "Drive Cargo from its hosted MCP server at https://mcp.getcargo.io/mcp — connect a client, discover and price an action, run it over one record or a batch, poll it, and read workspace models, with no CLI install. Also when to call an MCP tool instead of shelling out to `cargo-ai`. Triggers: \"connect Cargo to Claude Desktop\", \"add Cargo to ChatGPT\", \"Cargo MCP server\", \"mcp.getcargo.io\", \"use Cargo without installing anything\", \"which Cargo tool do I call\", \"search_actions\", \"execute_action_batch\", \"MCP server is showing the wrong workspace\". Tools: whoami, search_actions, get_action_schema, execute_action, execute_action_batch, get_run, query_models. Skip when: you have a shell and the job is a workflow, a CDK deploy, warehouse SQL, or a mailbox — use the CLI skills; when publishing an MCP server out of your own workspace or attaching one to a Cargo agent — use cargo-ai."
|
||||
version: "1.0.2"
|
||||
version: "1.0.3"
|
||||
compatibility: Requires the hosted Cargo MCP server at https://mcp.getcargo.io/mcp — OAuth (discovered from the 401 challenge) or a workspace-scoped API token as a bearer. The CLI is needed only for the jobs this skill routes away
|
||||
homepage: https://github.com/getcargohq/cargo-skills
|
||||
metadata:
|
||||
@@ -41,7 +41,7 @@ which.**
|
||||
| Read records off a model | either |
|
||||
| Warehouse SQL, aggregates, joins | **CLI** ([`cargo-storage`](../cargo-storage/SKILL.md)) |
|
||||
| Build or edit a multi-step workflow, tool, or play | **CLI** ([`cargo-orchestration`](../cargo-orchestration/SKILL.md)) |
|
||||
| Workspace as code, plan and deploy | **CLI** ([`cargo-cdk`](../cargo-cdk/SKILL.md)) |
|
||||
| Workspace as code, plan and deploy | **CLI** ([`cargo-project`](../cargo-project/SKILL.md)) |
|
||||
| Provision mailboxes, warm up, send | **CLI** ([`cargo-mailbox-management`](../cargo-mailbox-management/SKILL.md)) |
|
||||
| Segments, connectors, content libraries, alerts, hosting, billing admin | **CLI** |
|
||||
| No shell at all (ChatGPT, Claude Desktop, claude.ai, n8n) | **MCP**, and say plainly what is out of reach |
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"$comment": "Generated by .github/scripts/skills-metadata.mjs — do not hand-edit. Regenerate with: node .github/scripts/skills-metadata.mjs --write .",
|
||||
"name": "cargo-mcp",
|
||||
"version": "1.0.2",
|
||||
"version": "1.0.3",
|
||||
"documents": [
|
||||
{
|
||||
"path": "SKILL.md",
|
||||
@@ -9,5 +9,5 @@
|
||||
"title": "Cargo — the hosted MCP server"
|
||||
}
|
||||
],
|
||||
"contentHash": "ee773f7c2cedc61d842a4c3b68e8b27a8243a7f08ea6d4b4288b516e670761c6"
|
||||
"contentHash": "2b8432ffb310e38c94d8c05bfc7cb5780ee80cbfbf788de7d453e7506bf42664"
|
||||
}
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
name: cargo-observability
|
||||
description: "Watch a Cargo workspace and get told when something breaks — scheduled threshold alerts over workflow telemetry (spans, runs, records), a storage model freshness or row count, or any SQL query, firing a connector, tool, or agent when a metric breaches. Triggers: \"alert me when\", \"notify me if\", \"let me know when the error rate\", \"monitor this workflow\", \"tell me if the sync stops\", \"warn me before I run out of credits\", \"dead man’s switch\", \"is this still running\", \"set up monitoring\", plus listing, previewing, editing, and reviewing an alert firing history. Skip when: diagnosing something that already went wrong — use cargo-diagnostics."
|
||||
version: "1.0.2"
|
||||
version: "1.0.3"
|
||||
compatibility: Requires @cargo-ai/cli (npm). Sign in or create an account with `cargo-ai login --email` (emailed code, no browser), `--oauth`, or an API token
|
||||
homepage: https://github.com/getcargohq/cargo-skills
|
||||
metadata:
|
||||
@@ -128,7 +128,7 @@ The lifecycle — cron windows and the ClickHouse indexing lag, the **at-most-on
|
||||
|
||||
## Declarative alternative: `defineAlert` (CDK)
|
||||
|
||||
This skill is the **imperative** surface — one-off `cargo-ai observability alert …` calls. To manage an alert **as code** (in git, reproducible, deployed alongside the workflow it watches), use CDK's `defineAlert` builder instead — see [`../cargo-cdk/SKILL.md`](../cargo-cdk/SKILL.md) and "Declarative vs imperative" in the router. Same scope/threshold/action model; different authoring mode.
|
||||
This skill is the **imperative** surface — one-off `cargo-ai observability alert …` calls. To manage an alert **as code** (in git, reproducible, deployed alongside the workflow it watches), use CDK's `defineAlert` builder instead — see [`../cargo-project/SKILL.md`](../cargo-project/SKILL.md) and "Declarative vs imperative" in the router. Same scope/threshold/action model; different authoring mode.
|
||||
|
||||
## Cost discipline
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"$comment": "Generated by .github/scripts/skills-metadata.mjs — do not hand-edit. Regenerate with: node .github/scripts/skills-metadata.mjs --write .",
|
||||
"name": "cargo-observability",
|
||||
"version": "1.0.2",
|
||||
"version": "1.0.3",
|
||||
"documents": [
|
||||
{
|
||||
"path": "SKILL.md",
|
||||
@@ -24,5 +24,5 @@
|
||||
"title": "Scopes & thresholds — the compatibility matrix"
|
||||
}
|
||||
],
|
||||
"contentHash": "315b4177e66c254ba8f5ffdd14db8adaed0bc7f8e49badbb61d3ee94c7afb201"
|
||||
"contentHash": "08683568fc29d3613e339821aeb169edfc42e02db816dcb52a5bd4d1430da8dc"
|
||||
}
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
name: cargo-orchestration
|
||||
description: "Make Cargo actually run something, or show what it would run — execute one connector action, run a multi-step workflow, trigger a batch across a whole segment or model, message an AI agent, build or edit a node graph, draw a workflow, tool or play as a diagram, and query the runtime tables (runs, batches, spans, records) with SQL. Triggers: \"run this on all my contacts\", \"execute the action\", \"kick off a batch\", \"build a workflow\", \"schedule a play\", \"make it run every morning\", \"ask the agent\", \"show me the workflow\", \"what does this tool do\", \"visualize this play\", \"draw the graph\", \"explain this workflow\", \"how many runs failed today\", \"what is the output schema for this action\", \"add a step that\". Skip when: explaining why a run misbehaved — use cargo-diagnostics; downloading result files — use cargo-analytics; committing the workflow as code — use cargo-cdk."
|
||||
version: "1.11.2"
|
||||
description: "Make Cargo actually run something, or show what it would run — execute one connector action, run a multi-step workflow, trigger a batch across a whole segment or model, message an AI agent, build or edit a node graph, draw a workflow, tool or play as a diagram, and query the runtime tables (runs, batches, spans, records) with SQL. Triggers: \"run this on all my contacts\", \"execute the action\", \"kick off a batch\", \"build a workflow\", \"schedule a play\", \"make it run every morning\", \"ask the agent\", \"show me the workflow\", \"what does this tool do\", \"visualize this play\", \"draw the graph\", \"explain this workflow\", \"how many runs failed today\", \"what is the output schema for this action\", \"add a step that\". Skip when: explaining why a run misbehaved — use cargo-diagnostics; downloading result files — use cargo-analytics; committing the workflow as code — use cargo-project."
|
||||
version: "1.11.3"
|
||||
compatibility: Requires @cargo-ai/cli (npm). Sign in or create an account with `cargo-ai login --email` (emailed code, no browser), `--oauth`, or an API token
|
||||
homepage: https://github.com/getcargohq/cargo-skills
|
||||
metadata:
|
||||
|
||||
@@ -13,7 +13,7 @@ means the pin hasn't moved yet — bump per [`../../cargo/SKILL.md`](../../cargo
|
||||
|
||||
## When to draw one
|
||||
|
||||
- **At the plan gate**, before `release deploy-draft` / `cdk deploy` — the diagram
|
||||
- **At the plan gate**, before `release deploy-draft` / `project deploy` — the diagram
|
||||
*is* the "nodes and data flow" half of the plan ([`../../cargo/references/interaction.md`](../../cargo/references/interaction.md) §1).
|
||||
- **When explaining an existing workflow, tool, or play** — "what does this play
|
||||
do?" is one command against its `workflowUuid`.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"$comment": "Generated by .github/scripts/skills-metadata.mjs — do not hand-edit. Regenerate with: node .github/scripts/skills-metadata.mjs --write .",
|
||||
"name": "cargo-orchestration",
|
||||
"version": "1.11.2",
|
||||
"version": "1.11.3",
|
||||
"documents": [
|
||||
{
|
||||
"path": "SKILL.md",
|
||||
@@ -79,5 +79,5 @@
|
||||
"title": "Troubleshooting"
|
||||
}
|
||||
],
|
||||
"contentHash": "83f1fea579b1e029cd3e19e1b812f0c5e8a16cc113c805b73b80a66deeb58ff4"
|
||||
"contentHash": "a5c74a6303c494879833a164fb6053c959737b025d1dea727a192c0603d60d2e"
|
||||
}
|
||||
|
||||
@@ -0,0 +1,285 @@
|
||||
---
|
||||
name: cargo-project
|
||||
description: "Manage a whole Cargo workspace as code — declare connectors, models, plays, tools, agents, MCP servers, segments, context, folders, files, workers, and apps in TypeScript, then reconcile them with `cargo-ai project` (init → types → plan → deploy), the way you would run Pulumi or the AWS CDK. Triggers: \"as code\", \"in git\", \"version-controlled\", \"reproducible\", \"Terraform for Cargo\", \"set up a whole workspace\", \"staging and production\", \"deploy the workspace from CI\", \"review this in a PR\", \"cargo.state.json\", \"scaffold from a template\", \"is there a cookbook for this\", \"start from a cookbook\". Skills with a CDK example (TAM building, account scoring, contact sourcing, routing, AI SDR, rep cockpit) live in gtm-skills; menu in references/cookbooks.md. Skip when: it is a one-off operation, a read, or an ad-hoc query — use the matching capability skill."
|
||||
version: "2.0.0"
|
||||
compatibility: Requires @cargo-ai/cli (npm). Sign in or create an account with `cargo-ai login --email` (emailed code, no browser), `--oauth`, or an API token
|
||||
homepage: https://github.com/getcargohq/cargo-skills
|
||||
metadata:
|
||||
author: getcargo
|
||||
openclaw:
|
||||
requires:
|
||||
bins:
|
||||
- cargo-ai
|
||||
install:
|
||||
- kind: node
|
||||
package: "@cargo-ai/cli@latest"
|
||||
bins:
|
||||
- cargo-ai
|
||||
homepage: https://github.com/getcargohq/cargo-skills
|
||||
---
|
||||
|
||||
# Cargo project — declarative workspace-as-code
|
||||
|
||||
Use this skill to define a Cargo workspace in TypeScript (`define*` builders from
|
||||
`@cargo-ai/cdk`) and reconcile it to live infrastructure with `cargo-ai project deploy`.
|
||||
It is the **declarative** counterpart to the imperative capability skills: instead
|
||||
of running one CLI command per resource, you write the whole graph once and deploy
|
||||
it repeatably, with a committed `cargo.state.json` linking your code to what Cargo
|
||||
created.
|
||||
|
||||
## Bootstrap
|
||||
|
||||
Already signed in (`cargo-ai whoami` returns a workspace)? Skip to the next section.
|
||||
|
||||
```bash
|
||||
npm install -g @cargo-ai/cli # no global install? prefix every command with `npx @cargo-ai/cli`
|
||||
cargo-ai login --email you@company.com # emailed code, no browser; creates the account on first use
|
||||
# alternatives: --oauth (browser) · --token <api-token> (CI)
|
||||
cargo-ai whoami # confirm the active workspace before any write
|
||||
cargo-ai project --help # `unknown command` = CLI too old; reinstall @cargo-ai/cli@latest
|
||||
```
|
||||
|
||||
Two CDK-specific extras: the project needs **`@cargo-ai/cdk` as a dependency** for the `define*` builders you import (`cargo-ai project init` scaffolds a `package.json` with it — then `npm install`), and the `cargo-ai project` domain ships with the CLI itself.
|
||||
|
||||
Every command prints JSON to stdout; failures exit non-zero with `{"errorMessage": "..."}`. Anything that creates a run or a batch is async — pass `--wait-until-finished` or poll the matching `get`. When the full skill bundle is installed, [`../cargo/references/prerequisites.md`](../cargo/references/prerequisites.md) adds the CLI version pin, token scopes, and the admin-only surface.
|
||||
|
||||
## 1) What this skill governs
|
||||
|
||||
- **Authoring** every Cargo resource with a `define*` builder that returns a
|
||||
**handle**; wiring resources by passing handles to each other (the dependency
|
||||
graph is your variable graph).
|
||||
- **Deploying** the graph: `plan` (offline diff) → `deploy` (create/update, write
|
||||
state) → `destroy` (tear down). Plus drift (`refresh`), adoption (`import`), and
|
||||
recovery (`rollback`).
|
||||
- **Typing** the config against your workspace's real integration schemas
|
||||
(`cargo-ai project types`).
|
||||
|
||||
The CDK spans **every** resource kind — so it overlaps every imperative capability
|
||||
skill (`cargo-connection`, `cargo-storage`, `cargo-ai`, `cargo-orchestration`,
|
||||
`cargo-content`, `cargo-hosting`, …). Which to reach for is the first decision:
|
||||
|
||||
## 2) CDK or the CLI? — the routing decision
|
||||
|
||||
> **Declarative (this skill) vs imperative (a capability skill).**
|
||||
|
||||
Use the **CDK** when the user is **managing resources as an artifact**:
|
||||
|
||||
- "Set up / stand up / bootstrap a whole workspace (as code / from a template)."
|
||||
- "Make this reproducible / version-controlled / in git / repeatable across
|
||||
environments (dev → prod)."
|
||||
- "Deploy these connectors + models + agents together" (a multi-resource graph
|
||||
wired by dependency).
|
||||
- Anything that should be re-runnable and diffable, where losing the definition
|
||||
would be a problem.
|
||||
|
||||
Use the matching **capability skill** (imperative `cargo-ai <domain>`) when the
|
||||
user is doing a **one-off operation** or **exploring**:
|
||||
|
||||
- "Create one connector", "add a column to this model", "list connectors",
|
||||
"run this workflow", "query storage", "read this agent's memory."
|
||||
- Any read, ad-hoc query, or single mutation that doesn't need to live in code.
|
||||
|
||||
When unsure, ask whether the result should be committed and re-deployable. If yes
|
||||
→ CDK. If it's a quick action or a read → the capability skill (see the
|
||||
[`cargo` router](../cargo/SKILL.md) to pick the right domain).
|
||||
|
||||
## 3) The lifecycle
|
||||
|
||||
```
|
||||
cargo-ai project init <dir> scaffold a project from a template (blank | full)
|
||||
│
|
||||
cargo-ai project types generate per-workspace types for typed config (optional)
|
||||
│
|
||||
(author define* files) importing a .ts file IS registration — no manifest
|
||||
│
|
||||
cargo-ai project plan offline: compile the graph, diff against cargo.state.json
|
||||
│
|
||||
cargo-ai project deploy create/update resources in dependency order, write state
|
||||
│
|
||||
cargo-ai project destroy tear down resources recorded in state
|
||||
```
|
||||
|
||||
> **`project plan` says what resources change; it doesn't show what a play does.**
|
||||
> For a `definePlay` / `defineTool` graph past three nodes, present a Mermaid
|
||||
> flowchart of the node graph alongside the plan — routing, fallbacks, and which
|
||||
> nodes bill on every scheduled run are what the reviewer is approving. Generate it
|
||||
> from the deployed release after the first deploy, or from the node array while
|
||||
> authoring:
|
||||
> [`../cargo-orchestration/references/node-diagram.md`](../cargo-orchestration/references/node-diagram.md).
|
||||
|
||||
Side branches: `cargo-ai project refresh` (read-only drift report) · `deploy --refresh`
|
||||
(re-apply code over out-of-band edits) · `deploy --prune` (delete resources removed
|
||||
from code) · `cargo-ai project import <id> <uuid>` (bind an existing live resource into
|
||||
state) · `cargo-ai project rollback` (restore the pre-deploy state snapshot).
|
||||
|
||||
## 4) Documentation hierarchy
|
||||
|
||||
- **Level 1** — `SKILL.md` (this file): the decision model, lifecycle, critical
|
||||
rules, and routing.
|
||||
- **Level 2** — Guides:
|
||||
[`guides/authoring-resources.md`](guides/authoring-resources.md),
|
||||
[`guides/deploy-and-state.md`](guides/deploy-and-state.md),
|
||||
[`guides/typed-config.md`](guides/typed-config.md).
|
||||
- **Level 2.5** — Recipes: [`recipes/*.md`](recipes/) — step-by-step playbooks to
|
||||
follow as your execution plan.
|
||||
- **References** — [`references/resources.md`](references/resources.md) (the full
|
||||
builder catalog), [`references/commands.md`](references/commands.md) (every
|
||||
`cargo-ai project` subcommand + flags),
|
||||
[`references/troubleshooting.md`](references/troubleshooting.md), and
|
||||
[`references/examples/full-workspace.md`](references/examples/full-workspace.md).
|
||||
|
||||
## 5) Read behavior — match the task to a doc and READ IT
|
||||
|
||||
| When the task involves… | Read this first | What it gives you |
|
||||
|---|---|---|
|
||||
| Writing `define*` files, wiring resources, `secret()`/`env()`, `defineWorkflow` bodies (tool/play logic) | [`guides/authoring-resources.md`](guides/authoring-resources.md) | The builder catalog, the handle/ref model, secrets, and how workflow bodies compile. |
|
||||
| `plan` / `deploy` / `destroy`, the state file, drift, adopting existing resources, CI | [`guides/deploy-and-state.md`](guides/deploy-and-state.md) | The deploy lifecycle, `cargo.state.json` semantics, drift/import/rollback, async builds. |
|
||||
| Typed config, `cargo-ai project types`, tsconfig wiring, `integrations.*` in workflow bodies | [`guides/typed-config.md`](guides/typed-config.md) | What `project types` generates and how to wire it into your project. |
|
||||
| A field/spec/output for a specific builder | [`references/resources.md`](references/resources.md) | Every builder → spec fields → which ref each takes → outputs. |
|
||||
| Exact command flags | [`references/commands.md`](references/commands.md) | Every `cargo-ai project` subcommand and its flags. |
|
||||
| A deploy error / footgun | [`references/troubleshooting.md`](references/troubleshooting.md) | The known failure modes and fixes. |
|
||||
| A known GTM outcome, before authoring one | [`references/cookbooks.md`](references/cookbooks.md) | The cookbook menu: gtm-skills that carry a worked CDK example, and the adaptations each supports. |
|
||||
|
||||
### Cookbooks — check the menu before authoring a known outcome from scratch
|
||||
|
||||
[`getcargohq/gtm-skills`](https://github.com/getcargohq/gtm-skills) holds, beside its
|
||||
one-off skills, **cookbooks**: skills that carry worked CDK resources, the same job as a deployed
|
||||
pipeline that keeps producing the result (TAM building, account scoring, contact
|
||||
sourcing, routing engine, AI SDR, rep cockpit, …). Every folder is self-contained: its
|
||||
own models, connectors and folders, no shared foundation, no requires graph.
|
||||
|
||||
**The menu is local: [`references/cookbooks.md`](references/cookbooks.md).** Read it
|
||||
before authoring a common GTM outcome from scratch. It is generated from gtm-skills'
|
||||
`catalog.json`, so it cannot drift.
|
||||
|
||||
**A cookbook is a worked example, not a template to fill in.** Each one declares in its `SKILL.md` what may be reshaped, what must hold or it stops
|
||||
working, and what has to be answered either way, and it carries its own procedure.
|
||||
`project add` is the copy step in that procedure:
|
||||
|
||||
```sh
|
||||
cargo-ai project add cookbook/tam-building # inside a CDK project
|
||||
cargo-ai project init my-project --cookbook tam-building # no project yet: both at once
|
||||
```
|
||||
|
||||
That writes the resources to `infra/tam-building/` and the procedure to
|
||||
`.claude/skills/tam-building/`, skipping any file it would overwrite. **Then start the
|
||||
skill at its Adapt section** — its opening steps are written for someone who found the
|
||||
folder on GitHub and still has to place it, so following them from the top scaffolds a
|
||||
second project and copies the folder in again.
|
||||
|
||||
What is left after the copy is the part only you can do: reconcile it with what is
|
||||
already declared, adapt the copied files **in place** to the project's real shape (do not
|
||||
regenerate them from the skill's prose — the safety lives in the TypeScript), plan and
|
||||
stop, deploy on a yes, walk its `Done when`.
|
||||
|
||||
**If you are mid-task and the skill is not in this session**, `npx skills add
|
||||
getcargohq/gtm-skills/<slug>` fetches the procedure alone and you can read
|
||||
`.agents/skills/<slug>/SKILL.md` directly; no reload needed. To read one without
|
||||
installing, `npx skills use getcargohq/gtm-skills@<slug>` prints it. Neither brings the
|
||||
CDK resources — for those you still want `project add`.
|
||||
|
||||
**Routing rule: one-off versus standing.** A user who wants the list today wants
|
||||
`cargo-gtm` (or gtm-skills' one-off `build-tam-list`); a user who wants a pipeline
|
||||
that keeps producing it wants `tam-building`. The same words describe both ("build
|
||||
our TAM"), so listen for whether the result is meant to keep arriving. A cookbook
|
||||
matches → install it and follow it. No match → author from the recipes below.
|
||||
|
||||
**Never `cargo-ai project 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.
|
||||
|
||||
Caveat: the examples typecheck, but they are not yet deploy-verified against a live
|
||||
workspace, and every one is `to-be-approved`. Treat each skill's `Done when` as the
|
||||
acceptance test, and always review `cargo-ai project plan` before deploying.
|
||||
|
||||
### Recipes — follow step-by-step when one matches
|
||||
|
||||
| Recipe | Use when… |
|
||||
|---|---|
|
||||
| [`recipes/scaffold-a-workspace.md`](recipes/scaffold-a-workspace.md) | Standing up a new workspace from scratch (`init` → types → plan → deploy). |
|
||||
| [`recipes/add-connector-and-model.md`](recipes/add-connector-and-model.md) | Adding a data source + a model sourced from it, wired by handle. |
|
||||
| [`recipes/build-an-agent.md`](recipes/build-an-agent.md) | Composing a model + tool + agent (with `uses` / `models` / `tools`) and deploying. |
|
||||
| [`recipes/migrate-existing-workspace.md`](recipes/migrate-existing-workspace.md) | Bringing an already-live workspace under CDK management via `project import`. |
|
||||
| [`recipes/deploy-from-ci.md`](recipes/deploy-from-ci.md) | Deploying non-interactively from CI (token auth + committed state). |
|
||||
|
||||
## 6) Critical rules
|
||||
|
||||
- **Commit `cargo.state.json`.** It is the link from your code to the resources
|
||||
Cargo created — and the **only** handle on a deployed **play**, **agent**, or
|
||||
**alert** (they have no slug). Lose it and those resources orphan; recover a link
|
||||
with `cargo-ai project import`. It records only `{hash, uuid, outputs}` — never secret
|
||||
values. Git-ignore the working files (`project init` scaffolds this):
|
||||
```gitignore
|
||||
.cargo-ai/
|
||||
cargo.state.lock
|
||||
cargo.state.bak.json
|
||||
cargo.state.audit.jsonl
|
||||
```
|
||||
- **Secrets:** wire credentials with `secret("ENV_VAR")` (often
|
||||
`secret("HUBSPOT_API_KEY")`). The value is read from the environment **at deploy
|
||||
time**, kept out of the content hash and out of state, so rotating a token
|
||||
doesn't read as drift. Export the env var before deploying — a missing one fails
|
||||
the deploy with an unresolved `${ENV_VAR}` placeholder.
|
||||
- **Wire by handle, never by `.uuid`.** Pass a `define*` handle directly
|
||||
(`dataset: hubspot`, `tools: [enrich]`), or `xxRef("uuid")` for a resource you
|
||||
didn't define in code (`connectorRef`, `modelRef`, `folderRef`, `toolRef`,
|
||||
`agentRef`, …). Where a reference needs per-call options, wrap it as
|
||||
`{ ref, …options }` (e.g. `models: [{ ref: contacts, readOnly: true }]`).
|
||||
- **Run `cargo-ai project types` after workspace integrations change** — it
|
||||
regenerates `.cargo-ai/` so `defineConnector`/`defineModel` config (and
|
||||
`integrations.*` in workflow bodies) type-check against the real schemas. Typing
|
||||
is a bonus, never a gate: deploy works without it.
|
||||
- **Run `cdk` commands from the project root.** `npx`/`cargo-ai` resolve from the
|
||||
nearest `package.json`; run elsewhere and `.cargo-ai/` and `cargo.state.json`
|
||||
land in the wrong directory. Use `--dir <path>` to be explicit.
|
||||
- **`--yes` in CI.** `deploy` and `destroy` prompt for confirmation; non-interactive
|
||||
runs must pass `--yes`.
|
||||
- **A `definePlay`/`defineTool` graph with paid nodes gets a sample run before it
|
||||
goes wide.** Deploying is not running, but the first thing that runs a deployed
|
||||
play is usually a batch over the whole segment — and a scheduled play re-bills
|
||||
every node on every run. Before enrolling everything (or enabling a schedule),
|
||||
run the deployed workflow on **10–20 records** — `cargo-ai orchestration batch
|
||||
create --data '{"kind":"filter","modelUuid":"…","filter":…,"limit":15}'`, or
|
||||
`batch create --file ./plays/x.ts` to test-run the module without deploying —
|
||||
then ask the user to approve the full enrollment with the **record count** and
|
||||
**credit estimate**. Read the provider's playbook
|
||||
(`../cargo-gtm/provider-playbooks/<slug>.md`, esp. its *Recurring use* section)
|
||||
and the gate in
|
||||
[`../cargo-gtm/references/cost-discipline.md`](../cargo-gtm/references/cost-discipline.md).
|
||||
- **A `defineAlert` whose actions call paid nodes re-bills on every breach.** An
|
||||
alert's `actions` fire as real runs, so a badly-sized `threshold` on a tight
|
||||
`schedule` can breach — and bill — every tick. Size the threshold with
|
||||
`cargo-ai observability alert preview` before deploying, prefer cheap notification
|
||||
actions (an agent that posts, a connector notification) over anything that fans
|
||||
out, and apply the same cost gate above when an action calls a credits-based
|
||||
provider. Scope/threshold and firing semantics:
|
||||
[`../cargo-observability/SKILL.md`](../cargo-observability/SKILL.md).
|
||||
- **`defineMailbox` bills monthly, and `defineDomain` rewrites a DNS zone.** A
|
||||
mailbox is 100–160 credits *per month* for as long as it exists (`cargo-ai
|
||||
mailboxManagement pricing get` for live figures), so a `+ create mailbox:…` line
|
||||
in the plan is a recurring charge the user approves, not a one-off. Its `domain`,
|
||||
`username` and `type` are **create-only** — changing any of them is destroy +
|
||||
recreate, i.e. a brand-new inbox back at the bottom of a 45-day warm-up ramp. The
|
||||
deploy polls `refreshStatus` for up to 5 minutes waiting for `active`. On
|
||||
`defineDomain`, `dnsRecords` is the **whole zone, not a patch**: declaring it
|
||||
replaces every live record (including the ones the registrar wrote at purchase),
|
||||
and omitting it leaves the zone untouched. Use `adopt: true` for a domain or
|
||||
mailbox bought in the UI. Ramp, suppression and sending:
|
||||
[`../cargo-mailbox-management/SKILL.md`](../cargo-mailbox-management/SKILL.md).
|
||||
- **Route CDK-managed resources into a clearly-labelled folder.** Set `folder:` on
|
||||
each builder so everything CDK owns lands in a dedicated folder whose name signals
|
||||
"owned by code — don't hand-edit" to anyone in the UI (manual UI edits read back as
|
||||
drift on the next `plan`). Folders are per-kind, so give each kind its own but share
|
||||
one short, recognizable prefix — recommended: **`🔒 CDK`** (e.g. `🔒 CDK Models`,
|
||||
`🔒 CDK Agents`). Keep names short (long labels truncate in the folder tree); the
|
||||
lock emoji is the "don't touch" cue. See
|
||||
[`guides/authoring-resources.md`](guides/authoring-resources.md).
|
||||
|
||||
## Help
|
||||
|
||||
- `cargo-ai project --help` and `cargo-ai project <subcommand> --help` for the live flag
|
||||
surface.
|
||||
- When a documented command/flag/response doesn't match what you observe, file a
|
||||
report: `cargo-ai workspaceManagement report create` (see
|
||||
[`../cargo-workspace-management/SKILL.md`](../cargo-workspace-management/SKILL.md)).
|
||||
+1
-1
@@ -239,7 +239,7 @@ defineWorkflow(
|
||||
- **`uses.<key>(input)`** calls a referenced tool/agent; it's typed to that
|
||||
resource's input and returns a `Ref` you can dot-access (`enriched.company`).
|
||||
- **`integrations.<slug>.<action>({…})`** calls a connector action. The
|
||||
`integrations` registry is **empty until you run `cargo-ai cdk types`** (see
|
||||
`integrations` registry is **empty until you run `cargo-ai project types`** (see
|
||||
[`typed-config.md`](typed-config.md)); `native.*` works without a sync.
|
||||
- Control flow lowers idiomatically: `if/else` → branch, `else if` → switch,
|
||||
`for (const x of xs)` → group. `ai("…")` inline-completes; `js(({nodes}) => …)`
|
||||
@@ -11,15 +11,15 @@ For every flag, see [`../references/commands.md`](../references/commands.md).
|
||||
|
||||
```bash
|
||||
# Offline: compile the graph and diff against cargo.state.json. No API calls.
|
||||
cargo-ai cdk plan --dir my-workspace
|
||||
cargo-ai project plan --dir my-workspace
|
||||
|
||||
# Create/update resources in dependency order; write cargo.state.json.
|
||||
cargo-ai cdk deploy --dir my-workspace # prompts for confirmation
|
||||
cargo-ai cdk deploy --dir my-workspace --yes # non-interactive (CI)
|
||||
cargo-ai project deploy --dir my-workspace # prompts for confirmation
|
||||
cargo-ai project deploy --dir my-workspace --yes # non-interactive (CI)
|
||||
|
||||
# Tear down.
|
||||
cargo-ai cdk destroy --dir my-workspace --target model:contacts # one resource
|
||||
cargo-ai cdk destroy --dir my-workspace --all # everything in state
|
||||
cargo-ai project destroy --dir my-workspace --target model:contacts # one resource
|
||||
cargo-ai project destroy --dir my-workspace --all # everything in state
|
||||
```
|
||||
|
||||
Re-running `deploy` only changes what changed — an unchanged workspace is a no-op.
|
||||
@@ -38,7 +38,7 @@ have no slug (unlike connectors and models, which self-heal by slug). Losing sta
|
||||
orphans those resources. If it happens, re-establish a link with `import` (below).
|
||||
|
||||
Git-ignore the generated types and the CDK's working files (but **not**
|
||||
`cargo.state.json`). `cargo-ai cdk init` scaffolds this:
|
||||
`cargo.state.json`). `cargo-ai project init` scaffolds this:
|
||||
|
||||
```gitignore
|
||||
.cargo-ai/
|
||||
@@ -61,7 +61,7 @@ that would make a typo destructive. To also remove resources that are in state b
|
||||
no longer in code:
|
||||
|
||||
```bash
|
||||
cargo-ai cdk deploy --dir my-workspace --prune
|
||||
cargo-ai project deploy --dir my-workspace --prune
|
||||
```
|
||||
|
||||
Prune deletes in reverse dependency order (dependents before their dependencies).
|
||||
@@ -74,8 +74,8 @@ A resource can change outside the CDK (someone edits an agent in the Cargo UI).
|
||||
The CDK captures a fingerprint of each resource at deploy and compares on refresh:
|
||||
|
||||
```bash
|
||||
cargo-ai cdk refresh --dir my-workspace # read-only: report what drifted
|
||||
cargo-ai cdk deploy --dir my-workspace --refresh # re-read live, re-apply your code over drift
|
||||
cargo-ai project refresh --dir my-workspace # read-only: report what drifted
|
||||
cargo-ai project deploy --dir my-workspace --refresh # re-read live, re-apply your code over drift
|
||||
```
|
||||
|
||||
`refresh` reports resources changed or deleted out-of-band; `deploy --refresh`
|
||||
@@ -87,7 +87,7 @@ To bring an already-live resource under CDK management, bind it into state by
|
||||
mapping its **code id** to its **live uuid**:
|
||||
|
||||
```bash
|
||||
cargo-ai cdk import model:contacts 6f0c8e2a-… --dir my-workspace
|
||||
cargo-ai project import model:contacts 6f0c8e2a-… --dir my-workspace
|
||||
```
|
||||
|
||||
The code id is `kind:slug` (e.g. `connector:hubspot`, `model:contacts`,
|
||||
@@ -103,7 +103,7 @@ by matching slug; uuid-only kinds (play, agent, capacity, territory, segment) ne
|
||||
wrong, restore the snapshot:
|
||||
|
||||
```bash
|
||||
cargo-ai cdk rollback --dir my-workspace
|
||||
cargo-ai project rollback --dir my-workspace
|
||||
```
|
||||
|
||||
This restores the state file — it does not undo live API changes already made;
|
||||
@@ -1,16 +1,16 @@
|
||||
# Typed config — `cargo-ai cdk types`
|
||||
# Typed config — `cargo-ai project types`
|
||||
|
||||
`defineConnector`/`defineModel` config and the `integrations.*` registry in
|
||||
workflow bodies are typed against **your workspace's real integration schemas**.
|
||||
Those types aren't bundled (they're workspace-specific) — you generate them:
|
||||
|
||||
```bash
|
||||
cargo-ai cdk types --dir my-workspace
|
||||
cargo-ai project types --dir my-workspace
|
||||
```
|
||||
|
||||
Typing is a **bonus, never a gate**: an integration you haven't synced (or a
|
||||
custom one) falls back to a loose `Record<string, unknown>`, so `deploy` works
|
||||
without ever running `cdk types`.
|
||||
without ever running `project types`.
|
||||
|
||||
## What it generates
|
||||
|
||||
@@ -28,12 +28,12 @@ Everything lands in `.cargo-ai/` (git-ignored):
|
||||
`registerNative` calls so those slugs are **callable at runtime** in workflow
|
||||
bodies.
|
||||
|
||||
Re-run `cargo-ai cdk types` whenever your workspace's integrations change (added a
|
||||
Re-run `cargo-ai project types` whenever your workspace's integrations change (added a
|
||||
connector, changed an extractor).
|
||||
|
||||
## Wiring it into your project
|
||||
|
||||
`cdk init` sets this up; for a hand-rolled project, two steps:
|
||||
`project init` sets this up; for a hand-rolled project, two steps:
|
||||
|
||||
1. **Add the glob to `tsconfig.json` `include`.** A bare `.cargo-ai` (a dot-dir) is
|
||||
ignored by TypeScript — you must use an explicit glob:
|
||||
@@ -54,7 +54,7 @@ connector, changed an extractor).
|
||||
in every workspace, so their types ship with the SDK. Tools and agents are not a
|
||||
registry either — reference them by handle through `defineWorkflow`'s `uses`.)
|
||||
|
||||
## Symptoms that mean "run `cdk types`"
|
||||
## Symptoms that mean "run `project types`"
|
||||
|
||||
- `config` on a `defineConnector` isn't autocompleting / isn't rejecting a wrong
|
||||
credential shape → types not generated (or `.cargo-ai/**/*.d.ts` not in
|
||||
+3
-3
@@ -51,15 +51,15 @@ point at a specific dataset.
|
||||
## 3. Type the config (optional but recommended)
|
||||
|
||||
```bash
|
||||
cargo-ai cdk types # now `config` on both builders type-checks against HubSpot's schema
|
||||
cargo-ai project types # now `config` on both builders type-checks against HubSpot's schema
|
||||
```
|
||||
|
||||
## 4. Deploy
|
||||
|
||||
```bash
|
||||
export HUBSPOT_API_KEY=...
|
||||
cargo-ai cdk plan # shows: create connector:hubspot, create model:contacts
|
||||
cargo-ai cdk deploy
|
||||
cargo-ai project plan # shows: create connector:hubspot, create model:contacts
|
||||
cargo-ai project deploy
|
||||
git add cargo.state.json && git commit -m "Add HubSpot connector + contacts model"
|
||||
```
|
||||
|
||||
@@ -43,7 +43,7 @@ export const enrich = defineTool("enrich", {
|
||||
});
|
||||
```
|
||||
|
||||
> `integrations.*` is typed and callable only after `cargo-ai cdk types` (it reads
|
||||
> `integrations.*` is typed and callable only after `cargo-ai project types` (it reads
|
||||
> your workspace's integrations). `native.*` works without it. See
|
||||
> [`../guides/typed-config.md`](../guides/typed-config.md).
|
||||
|
||||
@@ -79,11 +79,11 @@ raw connector action with
|
||||
## 4. Deploy
|
||||
|
||||
```bash
|
||||
cargo-ai cdk types # so integrations.* in the workflow body typecheck
|
||||
cargo-ai cdk plan # orders: connector → tool (+ its workflow) → model → agent
|
||||
cargo-ai cdk deploy
|
||||
cargo-ai project types # so integrations.* in the workflow body typecheck
|
||||
cargo-ai project plan # orders: connector → tool (+ its workflow) → model → agent
|
||||
cargo-ai project deploy
|
||||
git add cargo.state.json && git commit -m "Add SDR agent"
|
||||
```
|
||||
|
||||
Because `agent:sdr` has no slug, `cargo.state.json` is the **only** handle on it —
|
||||
commit it, or the next deploy can't find it (recover with `cdk import agent:sdr <uuid>`).
|
||||
commit it, or the next deploy can't find it (recover with `project import agent:sdr <uuid>`).
|
||||
@@ -1,6 +1,6 @@
|
||||
# Recipe: deploy from CI
|
||||
|
||||
**Use when** the user wants `cargo-ai cdk deploy` to run non-interactively — on
|
||||
**Use when** the user wants `cargo-ai project deploy` to run non-interactively — on
|
||||
push, on merge, or on a schedule — so the workspace stays in sync with the repo.
|
||||
|
||||
## Prerequisites
|
||||
@@ -24,7 +24,7 @@ npm ci
|
||||
cargo-ai login --token "$CARGO_API_TOKEN"
|
||||
|
||||
# 3. Deploy — --yes is REQUIRED (no TTY to confirm at); --json for machine-readable output
|
||||
cargo-ai cdk deploy --yes --json
|
||||
cargo-ai project deploy --yes --json
|
||||
```
|
||||
|
||||
## Critical CI rules
|
||||
@@ -38,7 +38,7 @@ cargo-ai cdk deploy --yes --json
|
||||
creates resources writes new uuids into `cargo.state.json`; if CI doesn't commit
|
||||
them, the next run won't know they exist. Either commit the file from the CI job,
|
||||
or make deploys only ever run from a branch whose state is already current.
|
||||
- **Preview safely** with `cargo-ai cdk plan --json` (offline, no API calls) on pull
|
||||
- **Preview safely** with `cargo-ai project plan --json` (offline, no API calls) on pull
|
||||
requests, and gate `deploy` to the protected branch.
|
||||
- **Prune deliberately.** Add `--prune` only when you want CI to delete resources
|
||||
removed from code; leave it off to make deploys purely additive.
|
||||
@@ -51,7 +51,7 @@ cargo-ai cdk deploy --yes --json
|
||||
- run: cargo-ai login --token "$CARGO_API_TOKEN"
|
||||
env:
|
||||
CARGO_API_TOKEN: ${{ secrets.CARGO_API_TOKEN }}
|
||||
- run: cargo-ai cdk deploy --yes --json
|
||||
- run: cargo-ai project deploy --yes --json
|
||||
env:
|
||||
HUBSPOT_API_KEY: ${{ secrets.HUBSPOT_API_KEY }}
|
||||
```
|
||||
+6
-6
@@ -4,7 +4,7 @@
|
||||
imperative CLI) and the user wants to manage them as code going forward — without
|
||||
creating duplicates.
|
||||
|
||||
The tool is `cargo-ai cdk import <id> <uuid>`, which binds a resource's **code id**
|
||||
The tool is `cargo-ai project import <id> <uuid>`, which binds a resource's **code id**
|
||||
(`kind:slug`) to its **live uuid** in `cargo.state.json`. After import, `deploy`
|
||||
updates that resource in place instead of creating a new one.
|
||||
|
||||
@@ -36,9 +36,9 @@ cargo-ai storage model list # find the model's uuid
|
||||
## 3. Import each resource into state
|
||||
|
||||
```bash
|
||||
cargo-ai cdk import model:contacts <model-uuid> --dir my-workspace
|
||||
cargo-ai cdk import connector:hubspot <connector-uuid> --dir my-workspace
|
||||
cargo-ai cdk import agent:sdr <agent-uuid> --dir my-workspace
|
||||
cargo-ai project import model:contacts <model-uuid> --dir my-workspace
|
||||
cargo-ai project import connector:hubspot <connector-uuid> --dir my-workspace
|
||||
cargo-ai project import agent:sdr <agent-uuid> --dir my-workspace
|
||||
```
|
||||
|
||||
- The id is `kind:slug` — the same id the plan output uses.
|
||||
@@ -50,7 +50,7 @@ cargo-ai cdk import agent:sdr <agent-uuid> --dir my-workspace
|
||||
## 4. Verify with a plan
|
||||
|
||||
```bash
|
||||
cargo-ai cdk plan --dir my-workspace
|
||||
cargo-ai project plan --dir my-workspace
|
||||
```
|
||||
|
||||
Imported resources should show as **update** or **no-op**, not **create**. A
|
||||
@@ -60,7 +60,7 @@ Imported resources should show as **update** or **no-op**, not **create**. A
|
||||
## 5. Deploy and commit
|
||||
|
||||
```bash
|
||||
cargo-ai cdk deploy --dir my-workspace
|
||||
cargo-ai project deploy --dir my-workspace
|
||||
git add cargo.state.json && git commit -m "Adopt existing workspace into CDK"
|
||||
```
|
||||
|
||||
+9
-9
@@ -6,15 +6,15 @@ reproducibly. Follow these steps as your execution plan.
|
||||
## 1. Scaffold
|
||||
|
||||
```bash
|
||||
cargo-ai cdk init my-workspace # the repo, empty
|
||||
cargo-ai cdk init my-workspace --cookbook tam-building # the repo plus a worked example
|
||||
cargo-ai project init my-workspace # the repo, empty
|
||||
cargo-ai project init my-workspace --cookbook tam-building # the repo plus a worked example
|
||||
```
|
||||
|
||||
The scaffold itself never varies — it is one GTM repo from
|
||||
`getcargohq/cargo-manifest`, with the CDK project in `infra/`. What varies is
|
||||
whether a cookbook is layered on top, so reach for `--cookbook <slug>` when the
|
||||
user wants a working pipeline to adapt rather than an empty project.
|
||||
`cargo-ai cdk cookbook list` names them; see
|
||||
`cargo-ai project cookbook list` names them; see
|
||||
[`references/cookbooks.md`](../references/cookbooks.md).
|
||||
|
||||
## 2. Install and authenticate
|
||||
@@ -28,7 +28,7 @@ cargo-ai whoami # confirm the selected workspace
|
||||
## 3. (Optional) Generate typed config
|
||||
|
||||
```bash
|
||||
cargo-ai cdk types # types config against this workspace's integrations
|
||||
cargo-ai project types # types config against this workspace's integrations
|
||||
```
|
||||
|
||||
Not required to deploy, but it makes `defineConnector`/`defineModel` config and
|
||||
@@ -49,8 +49,8 @@ A missing env var fails the deploy with an unresolved `${NAME}` placeholder.
|
||||
## 5. Plan, then deploy
|
||||
|
||||
```bash
|
||||
cargo-ai cdk plan # offline diff — review what will be created
|
||||
cargo-ai cdk deploy # create everything, write cargo.state.json
|
||||
cargo-ai project plan # offline diff — review what will be created
|
||||
cargo-ai project deploy # create everything, write cargo.state.json
|
||||
```
|
||||
|
||||
`deploy` prompts for confirmation. Review the plan output first; it lists each
|
||||
@@ -64,15 +64,15 @@ git add cargo.state.json && git commit -m "Deploy initial workspace"
|
||||
|
||||
`cargo.state.json` is the link from code to the deployed resources — and the only
|
||||
handle on deployed plays/agents. Commit it. The `.gitignore` scaffolded by
|
||||
`cdk init` already excludes `.cargo-ai/`, the lock, backup, and audit files.
|
||||
`project init` already excludes `.cargo-ai/`, the lock, backup, and audit files.
|
||||
|
||||
## 7. Iterate
|
||||
|
||||
Edit `define*` files, then `cargo-ai cdk plan` → `cargo-ai cdk deploy` again — only
|
||||
Edit `define*` files, then `cargo-ai project plan` → `cargo-ai project deploy` again — only
|
||||
what changed is applied. To tear the workspace back down:
|
||||
|
||||
```bash
|
||||
cargo-ai cdk destroy --all
|
||||
cargo-ai project destroy --all
|
||||
```
|
||||
|
||||
See [`../guides/authoring-resources.md`](../guides/authoring-resources.md) to add
|
||||
@@ -0,0 +1,54 @@
|
||||
# Command reference — `cargo-ai project`
|
||||
|
||||
All subcommands accept `--dir <path>` (the project root, default `.`) and `--json`
|
||||
(machine-readable output). Run from the project root so `.cargo-ai/` and
|
||||
`cargo.state.json` land in the right place. Confirm the surface live with
|
||||
`cargo-ai project <subcommand> --help`.
|
||||
|
||||
| Command | What it does |
|
||||
|---|---|
|
||||
| `cargo-ai project init <directory>` | Scaffold a GTM repo from `getcargohq/cargo-manifest`, with the CDK project in `infra/`. `--name <name>`, `--cookbook <slug>` (install a cookbook into the new project), `--force` (write into a non-empty directory). There is no template flag: the scaffold never varies, and what varies is the cookbook layered on top. |
|
||||
| `cargo-ai project add cookbook/<slug>` | Copy a worked example into this project — `infra/<slug>/` plus its procedure under the skills directories. `--overwrite` (replace existing files; default skips them), `--yes`. Omit the address to choose interactively. |
|
||||
| `cargo-ai project add connector/<integration>` | Authorize a connector in the browser and write its `defineConnector`. `--connector-uuid <uuid>` adopts one already created there. |
|
||||
| `cargo-ai project cookbook list\|search\|view` | Browse the cookbooks `add` installs — `view <slug>` shows what one deploys, what it will ask you for, and its declared adaptations. |
|
||||
| `cargo-ai project types` | Generate per-workspace types into `.cargo-ai/` for typed config. |
|
||||
| `cargo-ai project plan` | Offline: compile the graph and diff against `cargo.state.json`. No API calls. |
|
||||
| `cargo-ai project deploy` | Create/update resources in dependency order; write state. Prompts unless `--yes`. |
|
||||
| `cargo-ai project refresh` | Read-only: report resources that drifted from code (changed/deleted out of band). |
|
||||
| `cargo-ai project import <id> <uuid>` | Bind an existing live resource (`kind:slug`) to a uuid in state. |
|
||||
| `cargo-ai project rollback` | Restore `cargo.state.json` from the pre-deploy snapshot. |
|
||||
| `cargo-ai project destroy` | Tear down resources recorded in state. `--target <id>` for one, `--all` for everything. |
|
||||
|
||||
## Common flags
|
||||
|
||||
- `--dir <path>` — project root (default `.`).
|
||||
- `--yes` — skip the confirmation prompt (**required in CI / non-interactive**).
|
||||
- `--json` — machine-readable output.
|
||||
- `--force` — steal a stale `cargo.state.lock`.
|
||||
|
||||
## `deploy` modifiers
|
||||
|
||||
- `cargo-ai project deploy --prune` — also **delete** resources that are in state but
|
||||
removed from code (reverse dependency order; adopted resources are released, not
|
||||
deleted).
|
||||
- `cargo-ai project deploy --refresh` — re-read live resources and re-apply your code
|
||||
over any out-of-band changes.
|
||||
|
||||
## `destroy` targets
|
||||
|
||||
- `cargo-ai project destroy --target <kind:slug>` — remove one resource (refused if
|
||||
other state resources still depend on it).
|
||||
- `cargo-ai project destroy --all` — remove everything in state, dependents first.
|
||||
|
||||
## Examples
|
||||
|
||||
```bash
|
||||
cargo-ai project init acme # scaffold
|
||||
cargo-ai project add cookbook/tam-building --dir acme # layer a worked example on
|
||||
cargo-ai project types --dir acme # type config
|
||||
cargo-ai project plan --dir acme # preview
|
||||
cargo-ai project deploy --dir acme --yes # apply (non-interactive)
|
||||
cargo-ai project refresh --dir acme # drift report
|
||||
cargo-ai project import agent:sdr <uuid> --dir acme # adopt a live agent
|
||||
cargo-ai project destroy --dir acme --all --yes # tear down
|
||||
```
|
||||
@@ -6,19 +6,19 @@ Skills in [`getcargohq/gtm-skills`](https://github.com/getcargohq/gtm-skills) th
|
||||
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). `cdk add` copies one into the project; the agent then
|
||||
foundation, no requires graph). `project add` copies one into the project; the agent then
|
||||
reconciles it with what is already declared (an existing accounts model, an existing CRM
|
||||
connector), adapts it in place, plans, deploys on a yes, and walks its `Done when`. The
|
||||
code is a worked example, not a template to fill in — and not something to regenerate
|
||||
from the skill's prose.
|
||||
|
||||
```sh
|
||||
cargo-ai cdk add cookbook/<slug> # inside a CDK project: this is the copy step
|
||||
cargo-ai cdk init <dir> --cookbook <slug> # no project yet: scaffold and install together
|
||||
cargo-ai project add cookbook/<slug> # inside a CDK project: this is the copy step
|
||||
cargo-ai project init <dir> --cookbook <slug> # no project yet: scaffold and install together
|
||||
npx skills add getcargohq/gtm-skills/<slug> # the procedure on its own, without the CDK resources
|
||||
```
|
||||
|
||||
After either `cdk` command the files are in `infra/<slug>/` and `.claude/skills/<slug>/`.
|
||||
After either `project` command the files are in `infra/<slug>/` and `.claude/skills/<slug>/`.
|
||||
Start the skill at its Adapt section: its earlier steps assume you found the folder in
|
||||
gtm-skills and still have to place it.
|
||||
|
||||
@@ -60,7 +60,7 @@ skill (or `cargo-gtm`, when this pack is installed); a user who wants a pipeline
|
||||
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
|
||||
**Never `cargo-ai project 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. Run `cdk add cookbook/<slug>`
|
||||
next plan diffs a live workspace against code nobody wrote. Run `project add cookbook/<slug>`
|
||||
in the project that is already there; it skips every file it would otherwise overwrite.
|
||||
+7
-7
@@ -2,8 +2,8 @@
|
||||
|
||||
This walks a complete, runnable Cargo workspace defined in code that exercises
|
||||
every resource type and wires them by **handle**. It is a reading example, not
|
||||
something a command scaffolds: `cargo-ai cdk init` produces one repo shape, and a
|
||||
worked pipeline comes from `cargo-ai cdk add cookbook/<slug>`.
|
||||
something a command scaffolds: `cargo-ai project init` produces one repo shape, and a
|
||||
worked pipeline comes from `cargo-ai project add cookbook/<slug>`.
|
||||
|
||||
## The graph
|
||||
|
||||
@@ -81,22 +81,22 @@ export const sdr = defineAgent("sdr", {
|
||||
cd my-workspace && npm install
|
||||
|
||||
cargo-ai login # authenticate + select the workspace
|
||||
cargo-ai cdk types # type defineConnector/defineModel config against this workspace
|
||||
cargo-ai project types # type defineConnector/defineModel config against this workspace
|
||||
export HUBSPOT_API_KEY=... # matches secret("HUBSPOT_API_KEY")
|
||||
|
||||
cargo-ai cdk plan
|
||||
cargo-ai project plan
|
||||
# → lists every resource as create / update / no-op, in dependency order:
|
||||
# create connector:hubspot, create connector:open_ai (adopt), create folder:crm-models, …
|
||||
|
||||
cargo-ai cdk deploy
|
||||
cargo-ai project deploy
|
||||
# → creates each in order, writing cargo.state.json after each resource.
|
||||
# Workers/apps build server-side (slower). Live URLs appear as webhook.url / dashboard.url.
|
||||
|
||||
git add cargo.state.json && git commit -m "Deploy full workspace"
|
||||
```
|
||||
|
||||
Re-run `cargo-ai cdk deploy` after editing a file — only the changed resource is
|
||||
applied. Tear it all down with `cargo-ai cdk destroy --all`.
|
||||
Re-run `cargo-ai project deploy` after editing a file — only the changed resource is
|
||||
applied. Tear it all down with `cargo-ai project destroy --all`.
|
||||
|
||||
Secrets referenced with `secret("HUBSPOT_API_KEY")` resolve from the environment at
|
||||
deploy time and stay out of the content hash — only `{hash, uuid, outputs}` land in
|
||||
@@ -57,7 +57,7 @@ export const leads = defineModel("leads", {
|
||||
|
||||
- **`defineConnector` `config`** is a per-integration shape — a discriminated union
|
||||
for auth (e.g. HubSpot `method: "privateApp" | "oauth"`). `secret()` is accepted
|
||||
only on credential/encryption fields. Run `cargo-ai cdk types` to type it (see
|
||||
only on credential/encryption fields. Run `cargo-ai project types` to type it (see
|
||||
[`../guides/typed-config.md`](../guides/typed-config.md)).
|
||||
- **`adopt: true`** on `defineConnector` links an existing authenticated connector
|
||||
by slug instead of creating one — for OAuth/key connectors you can't declare.
|
||||
@@ -85,7 +85,7 @@ export const leads = defineModel("leads", {
|
||||
error, not a silent `{}`). Prefer the typed helpers `alertConnectorAction({ ref:
|
||||
slack.actions.postMessage, config })` / `alertToolAction({ ref: enrich, config })` —
|
||||
`config` is checked against the action/tool input schema (connector schemas need
|
||||
`cargo-ai cdk types` to have run) — or a bare `{ ref: agent, config, release?,
|
||||
`cargo-ai project types` to have run) — or a bare `{ ref: agent, config, release?,
|
||||
waitUntilFinished? }`. Every `config` leaf accepts a `{{ … }}` template
|
||||
(`{{event.value}}`, `{{alert.name}}`, `{{alert.url}}`, …) interpolated against the
|
||||
firing context. Like a play, an alert has **no author-set wire slug** — its identity
|
||||
+6
-6
@@ -10,7 +10,7 @@ expects an encryption envelope, and `secret("ENV_VAR")` produces it. Fix:
|
||||
config: { method: "privateApp", accessToken: secret("HUBSPOT_API_KEY") }, // not a bare string
|
||||
```
|
||||
|
||||
Run `cargo-ai cdk types` so the config type-checks against the real schema at
|
||||
Run `cargo-ai project types` so the config type-checks against the real schema at
|
||||
author time and surfaces the required shape (see
|
||||
[`../guides/typed-config.md`](../guides/typed-config.md)). The deploy error now also
|
||||
surfaces the API's structured detail (which field, the reason) — read past the
|
||||
@@ -23,7 +23,7 @@ The CDK refuses to send a literal `${NAME}` to the API. Export it first:
|
||||
|
||||
```bash
|
||||
export NAME=...
|
||||
cargo-ai cdk deploy
|
||||
cargo-ai project deploy
|
||||
```
|
||||
|
||||
## Deploy refuses: workspace mismatch
|
||||
@@ -40,10 +40,10 @@ Run `cdk` commands from the project root, or pass `--dir <project-root>` explici
|
||||
|
||||
## `integrations.<slug>` is `any` / not callable, or `config` isn't type-checked
|
||||
|
||||
Types aren't generated or aren't wired in. Run `cargo-ai cdk types`, ensure
|
||||
Types aren't generated or aren't wired in. Run `cargo-ai project types`, ensure
|
||||
`tsconfig.json` `include` has the explicit glob `".cargo-ai/**/*.d.ts"` (a bare
|
||||
`.cargo-ai` dot-dir is ignored by TypeScript), and `import "./.cargo-ai/cargo-register.js";`
|
||||
at the top of workflow modules that use `integrations.*`. Re-run `cdk types` after
|
||||
at the top of workflow modules that use `integrations.*`. Re-run `project types` after
|
||||
changing workspace integrations.
|
||||
|
||||
## `could not parse the workflow body`
|
||||
@@ -65,14 +65,14 @@ Ensure the worker bundle dir has a built `index.js` (+ `manifest.json`,
|
||||
|
||||
Plays and agents have no slug, so `cargo.state.json` is the only link to them.
|
||||
**Commit the state file.** If it's lost, find the live uuid via the matching
|
||||
capability skill and rebind: `cargo-ai cdk import agent:<slug> <uuid>`. Never
|
||||
capability skill and rebind: `cargo-ai project import agent:<slug> <uuid>`. Never
|
||||
delete `cargo.state.json` to "start clean" — you'll orphan every play/agent it
|
||||
tracked.
|
||||
|
||||
## `plan` shows `create` for a resource that already exists
|
||||
|
||||
Its `kind:slug` id didn't match state. Either the slug in the `define*` changed, or
|
||||
you migrated a workspace without importing — bind it: `cargo-ai cdk import <kind:slug> <uuid>`
|
||||
you migrated a workspace without importing — bind it: `cargo-ai project import <kind:slug> <uuid>`
|
||||
(see [`../recipes/migrate-existing-workspace.md`](../recipes/migrate-existing-workspace.md)).
|
||||
|
||||
## Still stuck
|
||||
@@ -0,0 +1,78 @@
|
||||
{
|
||||
"$comment": "Generated by .github/scripts/skills-metadata.mjs — do not hand-edit. Regenerate with: node .github/scripts/skills-metadata.mjs --write .",
|
||||
"name": "cargo-project",
|
||||
"version": "2.0.0",
|
||||
"documents": [
|
||||
{
|
||||
"path": "SKILL.md",
|
||||
"kind": "entrypoint",
|
||||
"title": "Cargo project — declarative workspace-as-code"
|
||||
},
|
||||
{
|
||||
"path": "guides/authoring-resources.md",
|
||||
"kind": "guide",
|
||||
"title": "Authoring resources"
|
||||
},
|
||||
{
|
||||
"path": "guides/deploy-and-state.md",
|
||||
"kind": "guide",
|
||||
"title": "Deploy & state"
|
||||
},
|
||||
{
|
||||
"path": "guides/typed-config.md",
|
||||
"kind": "guide",
|
||||
"title": "Typed config — `cargo-ai project types`"
|
||||
},
|
||||
{
|
||||
"path": "recipes/add-connector-and-model.md",
|
||||
"kind": "recipe",
|
||||
"title": "Recipe: add a connector and a model sourced from it"
|
||||
},
|
||||
{
|
||||
"path": "recipes/build-an-agent.md",
|
||||
"kind": "recipe",
|
||||
"title": "Recipe: build an agent (model + tool + agent)"
|
||||
},
|
||||
{
|
||||
"path": "recipes/deploy-from-ci.md",
|
||||
"kind": "recipe",
|
||||
"title": "Recipe: deploy from CI"
|
||||
},
|
||||
{
|
||||
"path": "recipes/migrate-existing-workspace.md",
|
||||
"kind": "recipe",
|
||||
"title": "Recipe: bring an existing workspace under CDK management"
|
||||
},
|
||||
{
|
||||
"path": "recipes/scaffold-a-workspace.md",
|
||||
"kind": "recipe",
|
||||
"title": "Recipe: scaffold a workspace from scratch"
|
||||
},
|
||||
{
|
||||
"path": "references/commands.md",
|
||||
"kind": "reference",
|
||||
"title": "Command reference — `cargo-ai project`"
|
||||
},
|
||||
{
|
||||
"path": "references/cookbooks.md",
|
||||
"kind": "reference",
|
||||
"title": "Cookbooks: worked CDK examples, before you author one from scratch"
|
||||
},
|
||||
{
|
||||
"path": "references/examples/full-workspace.md",
|
||||
"kind": "example",
|
||||
"title": "Example: a full GTM workspace end-to-end"
|
||||
},
|
||||
{
|
||||
"path": "references/resources.md",
|
||||
"kind": "reference",
|
||||
"title": "Resource reference"
|
||||
},
|
||||
{
|
||||
"path": "references/troubleshooting.md",
|
||||
"kind": "reference",
|
||||
"title": "Troubleshooting"
|
||||
}
|
||||
],
|
||||
"contentHash": "e98e3703791cd2ccee054f171f5f61e74b0016ff19774b2d50b967059787c3c3"
|
||||
}
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
name: cargo-segmentation
|
||||
description: "Define and use segments — named, saved filters over a Cargo model that become the audience for a batch run, a play trigger, or an export. Triggers: \"build a segment of\", \"filter my contacts where\", \"who matches this criteria\", \"save this as a list\", \"how many companies match\", \"the Closed-Won segment\", \"everyone who has not been emailed\", \"target only accounts that\", \"what is in this segment\", \"narrow this down to\". Filter JSON uses `conjonction` (not `conjunction`) — misspelling it fails silently. Skip when: running something over the segment — use cargo-orchestration; exporting its rows — use cargo-analytics; ad-hoc SQL over the model — use cargo-storage."
|
||||
version: "1.0.0"
|
||||
version: "1.0.1"
|
||||
compatibility: Requires @cargo-ai/cli (npm). Sign in or create an account with `cargo-ai login --email` (emailed code, no browser), `--oauth`, or an API token
|
||||
homepage: https://github.com/getcargohq/cargo-skills
|
||||
metadata:
|
||||
@@ -167,7 +167,7 @@ Segments are an input, not an outcome. Once one exists:
|
||||
- **Export it** — [`../cargo-analytics/SKILL.md`](../cargo-analytics/SKILL.md) (`segment download` needs `--model-uuid`, *not* `--segment-uuid` — a frequent 400).
|
||||
- **Watch it** — alert when the audience empties, stalls, or spikes: [`../cargo-observability/SKILL.md`](../cargo-observability/SKILL.md).
|
||||
- **Act on it as GTM** — signal segments (job change, funding, tech intent) drive the recipes in [`../cargo-gtm/SKILL.md`](../cargo-gtm/SKILL.md).
|
||||
- **Declare it as code** — `defineSegment` in [`../cargo-cdk/SKILL.md`](../cargo-cdk/SKILL.md) when the audience should live in git.
|
||||
- **Declare it as code** — `defineSegment` in [`../cargo-project/SKILL.md`](../cargo-project/SKILL.md) when the audience should live in git.
|
||||
|
||||
## Gotchas
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"$comment": "Generated by .github/scripts/skills-metadata.mjs — do not hand-edit. Regenerate with: node .github/scripts/skills-metadata.mjs --write .",
|
||||
"name": "cargo-segmentation",
|
||||
"version": "1.0.0",
|
||||
"version": "1.0.1",
|
||||
"documents": [
|
||||
{
|
||||
"path": "SKILL.md",
|
||||
@@ -19,5 +19,5 @@
|
||||
"title": "Segmentation — troubleshooting"
|
||||
}
|
||||
],
|
||||
"contentHash": "da2782accfe8faa32c343e316869b1769273aaf0dce1144e00a238dbaf18cf0f"
|
||||
"contentHash": "36eb77b3e82b3032cb592911c4c1ceade1d134de7c58e6f87e03d24acfc50b6f"
|
||||
}
|
||||
|
||||
+20
-20
@@ -1,7 +1,7 @@
|
||||
---
|
||||
name: cargo
|
||||
description: "Router for the Cargo CLI skill bundle — load first for anything Cargo, and whenever a task spans two Cargo domains. Explains what each skill owns, declarative workspace-as-code (cargo-cdk) vs the imperative CLI, the UUID and slug flow between skills, async polling of runs and batches, end-to-end use cases, and the gotchas that fail silently (`conjonction` spelling, run vs batch, model-uuid vs segment-uuid). Triggers: \"set up Cargo\", \"what can Cargo do\", \"which Cargo skill\", \"bootstrap my workspace\", \"I have a Cargo account\", \"cargo-ai …\", or any `cargo-ai` command whose domain you are unsure of. Skip when: the task obviously belongs to one skill — load that skill directly."
|
||||
version: "1.25.0"
|
||||
description: "Router for the Cargo CLI skill bundle — load first for anything Cargo, and whenever a task spans two Cargo domains. Explains what each skill owns, declarative workspace-as-code (cargo-project) vs the imperative CLI, the UUID and slug flow between skills, async polling of runs and batches, end-to-end use cases, and the gotchas that fail silently (`conjonction` spelling, run vs batch, model-uuid vs segment-uuid). Triggers: \"set up Cargo\", \"what can Cargo do\", \"which Cargo skill\", \"bootstrap my workspace\", \"I have a Cargo account\", \"cargo-ai …\", or any `cargo-ai` command whose domain you are unsure of. Skip when: the task obviously belongs to one skill — load that skill directly."
|
||||
version: "1.25.1"
|
||||
compatibility: Requires @cargo-ai/cli (npm). Sign in or create an account with `cargo-ai login --email` (emailed code, no browser), `--oauth`, or an API token
|
||||
homepage: https://github.com/getcargohq/cargo-skills
|
||||
metadata:
|
||||
@@ -33,7 +33,7 @@ This repository contains 19 skills at the repo root: this **router** (`cargo`),
|
||||
- **`cargo-quickstart`** — guided first-run demo. Fresh workspace → real deliverable (25 leads for the user's persona, with a cost receipt) in under two minutes, ending by saving the demo as a recurring play. Load for new users, demo/tour requests, or empty workspaces.
|
||||
- **`cargo-gtm`** — application library. The front door for any GTM task ("build a TAM list", "find 5 fintech CTOs", "monitor job changes"). Routes via internal recipes (`../cargo-gtm/recipes/*.md`) and provider playbooks (`../cargo-gtm/provider-playbooks/*.md`).
|
||||
- **Capability skills** — standard library. One per CLI domain (orchestration, storage, segmentation, connection, AI, content, context, analytics, billing, observability, hosting, cdk, mailbox management, workspace management), plus `cargo-diagnostics` (cross-domain forensics over runs, batches, and credit spend) and `cargo-mcp` (the hosted MCP server, the one surface that is not the CLI). Loaded by `cargo-gtm`, or directly when you need a specific CLI domain.
|
||||
- **`cargo-cdk`** — the declarative one. Where the other capability skills wrap **imperative** one-off `cargo-ai <domain>` calls, `cargo-cdk` defines the whole workspace as code (`define*` builders + `cargo-ai cdk deploy`) and reconciles it. It spans every resource type — see "Declarative vs imperative" below to route between it and the imperative skills.
|
||||
- **`cargo-project`** — the declarative one. Where the other capability skills wrap **imperative** one-off `cargo-ai <domain>` calls, `cargo-project` defines the whole workspace as code (`define*` builders + `cargo-ai project deploy`) and reconciles it. It spans every resource type — see "Declarative vs imperative" below to route between it and the imperative skills.
|
||||
|
||||
`cargo-gtm` delegates to capability skills; capability skills never reference `cargo-gtm` (one-way dependency).
|
||||
|
||||
@@ -198,12 +198,12 @@ If `gh` is missing or unauthenticated, don't fix it and don't offer a workaround
|
||||
Two ways to create/manage the same Cargo resources. Decide which the task wants
|
||||
before picking a domain:
|
||||
|
||||
- **Declarative → [`cargo-cdk`](../cargo-cdk/SKILL.md).** The user is managing
|
||||
- **Declarative → [`cargo-project`](../cargo-project/SKILL.md).** The user is managing
|
||||
resources **as an artifact**: "set up / bootstrap a whole workspace as code",
|
||||
"make this reproducible / version-controlled / in git", "deploy these
|
||||
connectors + models + agents together", or anything that should be re-runnable
|
||||
and diffable across environments. Define it in `define*` files and
|
||||
`cargo-ai cdk deploy`.
|
||||
`cargo-ai project deploy`.
|
||||
- **Imperative → the matching capability skill below.** The user is doing a
|
||||
**one-off operation** or **exploring**: "create one connector", "add a column",
|
||||
"list connectors", "run this workflow", "query storage", "read a memory". A read,
|
||||
@@ -246,7 +246,7 @@ Load for a specific CLI domain. The first link in each row jumps to the actual S
|
||||
| [`cargo-content`](../cargo-content/SKILL.md) ([recap](#cargo-content)) | Upload and organize knowledge files, build native/connector-backed knowledge libraries for RAG (the `content` domain) |
|
||||
| [`cargo-context`](../cargo-context/SKILL.md) ([recap](#cargo-context)) | Browse/read/write/edit the workspace's git-backed GTM context repo, run commands in its runtime sandbox, inspect the knowledge graph |
|
||||
| [`cargo-hosting`](../cargo-hosting/SKILL.md) ([recap](#cargo-hosting)) | Scaffold, deploy, and promote hosted apps (Vite SPAs on `*.cargo.app`) and edge workers (serverless HTTP handlers), and manage their deployments |
|
||||
| [`cargo-cdk`](../cargo-cdk/SKILL.md) ([recap](#cargo-cdk)) | **Declarative — spans every resource type.** Define a whole workspace in code (`define*` builders) and deploy it with `cargo-ai cdk` (init → types → plan → deploy). Use for workspace-as-code / reproducible / version-controlled setups; see "Declarative vs imperative" above. |
|
||||
| [`cargo-project`](../cargo-project/SKILL.md) ([recap](#cargo-project)) | **Declarative — spans every resource type.** Define a whole workspace in code (`define*` builders) and deploy it with `cargo-ai project` (init → types → plan → deploy). Use for workspace-as-code / reproducible / version-controlled setups; see "Declarative vs imperative" above. |
|
||||
| [`cargo-mailbox-management`](../cargo-mailbox-management/SKILL.md) ([recap](#cargo-mailbox-management)) | Provision sending mailboxes Cargo owns, run warm-up and the 5→40/day send ramp, send with the `sendEmail` action, and read threads, replies, delivery events, and suppressions |
|
||||
| [`cargo-workspace-management`](../cargo-workspace-management/SKILL.md) ([recap](#cargo-workspace-management)) | Invite users, create API tokens, organize folders, manage roles, report CLI issues to management |
|
||||
| [`cargo-mcp`](../cargo-mcp/SKILL.md) ([recap](#cargo-mcp)) | Drive Cargo from the hosted MCP server at `https://mcp.getcargo.io/mcp` with no CLI install — connect a client, discover and price an action, execute one record or a batch, poll it, read models; and route between the MCP tools and the CLI |
|
||||
@@ -353,10 +353,10 @@ The CLI exposes several domains that no capability skill wraps yet. Reach for th
|
||||
(orthogonal: not part of the workflow flow)
|
||||
|
||||
┌───────────────────────────────────────┐
|
||||
│ cargo-cdk │
|
||||
│ cargo-project │
|
||||
│ Declarative authoring layer: define │
|
||||
│ connectors/models/plays/agents/… as │
|
||||
│ code, deploy with `cargo-ai cdk`. │
|
||||
│ code, deploy with `cargo-ai project`. │
|
||||
└───────────────────────────────────────┘
|
||||
(cross-cutting: PRODUCES the same resources the imperative
|
||||
skills manage — an alternative mode, not a workflow stage)
|
||||
@@ -389,11 +389,11 @@ The CLI exposes several domains that no capability skill wraps yet. Reach for th
|
||||
- `cargo-storage`, `cargo-connection`, and `cargo-ai` are peer skills that supply UUIDs to `cargo-orchestration`. They don't depend on each other.
|
||||
- `cargo-content` owns workspace **files** and **libraries** (the `content` domain). It produces file/library UUIDs that `cargo-ai` consumes as agent release `resources` (RAG). Uploaded content files also surface read-only under `.files/` in the `cargo-context` runtime sandbox.
|
||||
- `cargo-mailbox-management` owns **sending inboxes** (the `mailboxManagement` domain) — provisioning, warm-up, the send ramp, threads, events, and the workspace suppression list. It deliberately does **not** send: delivery is the `sendEmail` native action under `cargo-orchestration`, which is why a send inherits orchestration's pacing, retry and credit accounting. The mailbox itself is also declarable as code via CDK's `defineMailbox` (with `defineDomain` for the sending domain).
|
||||
- `cargo-cdk` is **cross-cutting**: it's a declarative *authoring mode* that produces the very connectors/models/plays/agents/etc. the imperative capability skills manage one at a time. Route to it when the task is "manage the workspace as code" (reproducible, in git, multi-resource); route to the imperative domain skills for one-off ops, reads, and ad-hoc queries. See "Declarative vs imperative" under Skills at a glance.
|
||||
- `cargo-project` is **cross-cutting**: it's a declarative *authoring mode* that produces the very connectors/models/plays/agents/etc. the imperative capability skills manage one at a time. Route to it when the task is "manage the workspace as code" (reproducible, in git, multi-resource); route to the imperative domain skills for one-off ops, reads, and ad-hoc queries. See "Declarative vs imperative" under Skills at a glance.
|
||||
- `cargo-context` is **orthogonal** to the workflow-execution flow. It touches the git-backed GTM knowledge base (markdown/MDX), not storage or workflow runs. Use it for capturing/editing the workspace's prose context — personas, plays, proof, objections, signals — and for inspecting the typed knowledge graph.
|
||||
- For SQL queries against storage, use `cargo-ai storage query execute "<sql>"` (tables as `<datasetSlug>.<modelSlug>`). Load `cargo-storage` to discover dataset and model slugs, and to fetch the DDL when you need column types or the SQL dialect.
|
||||
- For SQL queries against orchestration runtime tables (`runs`, `batches`, `spans`, `records`) — error rates, per-node failures, time-series — use `cargo-ai orchestration query execute "<sql>"`. Workspace scoping is automatic; tables are referenced without a schema prefix.
|
||||
- Before building a workflow node graph, load `cargo-connection` to get `connectorUuid` and `actionSlug`. If any node calls a **credits-based provider action**, also load `cargo-gtm` and read that provider's playbook (`../cargo-gtm/provider-playbooks/<slug>.md`) — including its **Recurring use** section whenever the workflow is a scheduled tool or play, since a bad config or wrong cadence re-bills on every run. This applies even when the task arrived through `cargo-orchestration` or `cargo-cdk` directly, without a GTM framing.
|
||||
- Before building a workflow node graph, load `cargo-connection` to get `connectorUuid` and `actionSlug`. If any node calls a **credits-based provider action**, also load `cargo-gtm` and read that provider's playbook (`../cargo-gtm/provider-playbooks/<slug>.md`) — including its **Recurring use** section whenever the workflow is a scheduled tool or play, since a bad config or wrong cadence re-bills on every run. This applies even when the task arrived through `cargo-orchestration` or `cargo-project` directly, without a GTM framing.
|
||||
- Before executing a workflow that uses an agent node, load `cargo-ai` to get `agentUuid`.
|
||||
- After runs complete, load `cargo-analytics` to download results or measure performance. **For action output retrieval, prefer `cargo-ai orchestration run download-outputs` over `run download` — the former returns a signed-URL CSV/JSON of just the output node's data.**
|
||||
- Load `cargo-billing` to understand credit consumption for any of the above.
|
||||
@@ -492,7 +492,7 @@ The non-obvious rules for each skill — the things that fail silently or cost m
|
||||
- **Empty window vs real zero.** Most metrics report an idle window as `empty` (healthy, no fire). Only `count` and `recordsCount` return a real `0` — pair with `lte 0` for a **dead-man's switch** (alert when a workflow *stops*, a model *empties*).
|
||||
- **Firing is at-most-once and costs credits.** Actions fire as runs (`runUuids` on the event); a sustained breach re-fires once per tick it's still true, never on the same rows twice. If an action calls a paid provider, apply `../cargo-gtm/references/cost-discipline.md` — a scheduled alert re-bills on every breach.
|
||||
- **`--enabled` is strict** (`true`/`false` only); model-scope `filter` uses the segmentation shape spelled **`conjonction`**.
|
||||
- Permissions are `observability:read` / `observability:write` (not admin-only). The declarative equivalent is CDK's `defineAlert` — see `cargo-cdk`.
|
||||
- Permissions are `observability:read` / `observability:write` (not admin-only). The declarative equivalent is CDK's `defineAlert` — see `cargo-project`.
|
||||
|
||||
### cargo-storage
|
||||
|
||||
@@ -576,18 +576,18 @@ See `../cargo-ai/SKILL.md` for model and temperature guidance by use case.
|
||||
- `--app-uuid` / `--worker-uuid` are mutually exclusive on deployment commands; `remove` cascades to deployments.
|
||||
- Folders come from [`cargo-workspace-management`](#cargo-workspace-management); `--folder-uuid null` moves to root.
|
||||
|
||||
### cargo-cdk
|
||||
### cargo-project
|
||||
|
||||
entire Cargo workspace in TypeScript (`defineConnector`/`defineModel`/`defineAgent`/
|
||||
`definePlay`/`defineTool`/`defineMcpServer`/`defineContext`/`defineSegment`/
|
||||
`defineFolder`/`defineFile`/`defineWorker`/`defineApp`/`defineAlert`/`defineDomain`/
|
||||
`defineMailbox`) and reconcile
|
||||
it to live infra with `cargo-ai cdk`. Spans **every** resource type, so it overlaps
|
||||
it to live infra with `cargo-ai project`. Spans **every** resource type, so it overlaps
|
||||
every imperative capability skill — route with "Declarative vs imperative" above.
|
||||
|
||||
**Lifecycle:** `cdk init` (scaffold from a template) → `cdk types` (type config
|
||||
against the workspace) → author `define*` files → `cdk plan` (offline diff) →
|
||||
`cdk deploy` (create/update, write state) → `cdk destroy`. Plus `refresh` (drift),
|
||||
**Lifecycle:** `project init` (scaffold from a template) → `project types` (type config
|
||||
against the workspace) → author `define*` files → `project plan` (offline diff) →
|
||||
`project deploy` (create/update, write state) → `project destroy`. Plus `refresh` (drift),
|
||||
`import` (adopt existing), `rollback`.
|
||||
|
||||
**Critical rules:**
|
||||
@@ -598,11 +598,11 @@ against the workspace) → author `define*` files → `cdk plan` (offline diff)
|
||||
- **Secrets** go through `secret("ENV_VAR")` — resolved at deploy, never written to
|
||||
state or the content hash. Export the env var first.
|
||||
- **`--yes`** is required for non-interactive `deploy`/`destroy` (CI).
|
||||
- **Run `cargo-ai cdk types`** after workspace integrations change so config
|
||||
- **Run `cargo-ai project types`** after workspace integrations change so config
|
||||
type-checks; typing is a bonus, deploy works without it.
|
||||
- **`definePlay`/`defineTool` graphs with credits-based connector actions:** read
|
||||
the provider's playbook in `../cargo-gtm/provider-playbooks/` (esp. its
|
||||
**Recurring use** section) before `cdk deploy` — a deployed play re-bills its
|
||||
**Recurring use** section) before `project deploy` — a deployed play re-bills its
|
||||
nodes on every scheduled run.
|
||||
|
||||
**Recipes shipped:** `recipes/scaffold-a-workspace.md`, `add-connector-and-model.md`,
|
||||
@@ -612,7 +612,7 @@ against the workspace) → author `define*` files → `cdk plan` (offline diff)
|
||||
inbound flow, contact sourcing, account scoring, AI SDR, …) live in
|
||||
[`getcargohq/gtm-skills`](https://github.com/getcargohq/gtm-skills) beside its one-off
|
||||
skills. The menu is local:
|
||||
[`../cargo-cdk/references/cookbooks.md`](../cargo-cdk/references/cookbooks.md).
|
||||
[`../cargo-project/references/cookbooks.md`](../cargo-project/references/cookbooks.md).
|
||||
Check it before authoring a common GTM outcome from scratch.
|
||||
|
||||
**The routing question is one-off versus standing.** "Build our TAM" is `cargo-gtm`
|
||||
@@ -621,7 +621,7 @@ keeps producing it. The words are the same; listen for whether the result is mea
|
||||
keep arriving. Each cookbook is a self-contained worked example the installing agent
|
||||
copies into the project and adapts, not a template to fill in:
|
||||
`npx skills add getcargohq/gtm-skills/<name>`. See the section in
|
||||
`../cargo-cdk/SKILL.md` for the caveats and the `--force` warning.
|
||||
`../cargo-project/SKILL.md` for the caveats and the `--force` warning.
|
||||
|
||||
### cargo-mailbox-management
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ Before creating or editing a node graph, deploying a release, or launching anyth
|
||||
|
||||
Treat this as a hard gate: don't start building from an unconfirmed plan. It complements the **cost gate** in [`../../cargo-gtm/references/cost-discipline.md`](../../cargo-gtm/references/cost-discipline.md), which stays authoritative for spend (sample → approval → full run): the plan gate approves the *design*, the sample gate approves the *spend*. A trivial change (fix one expression, rename a node) doesn't need the ceremony — say what you changed and why.
|
||||
|
||||
**Batches get their own gate, every time.** Launching a batch is the one action that turns a design mistake into a full bill in a single command, so it never goes straight to full scope: run 10–20 records, show what came back and what it cost, then ask whether to enroll the rest — with the **record count** and the **credit estimate** in the question, not just "proceed?". This holds even when the plan gate already passed, and even when the batch arrived through `cargo-orchestration` or `cargo-cdk` with no GTM framing. Mechanics per data kind: [`../../cargo-orchestration/SKILL.md`](../../cargo-orchestration/SKILL.md) → "Create a batch".
|
||||
**Batches get their own gate, every time.** Launching a batch is the one action that turns a design mistake into a full bill in a single command, so it never goes straight to full scope: run 10–20 records, show what came back and what it cost, then ask whether to enroll the rest — with the **record count** and the **credit estimate** in the question, not just "proceed?". This holds even when the plan gate already passed, and even when the batch arrived through `cargo-orchestration` or `cargo-project` with no GTM framing. Mechanics per data kind: [`../../cargo-orchestration/SKILL.md`](../../cargo-orchestration/SKILL.md) → "Create a batch".
|
||||
|
||||
## 2. Real choices: ask, with a recommended default
|
||||
|
||||
@@ -60,4 +60,4 @@ Storage queries are free and fast, so this preview costs nothing but a line of o
|
||||
- Building or editing plays/workflows (`cargo-orchestration`, and node-graph steps in `cargo-gtm` recipes).
|
||||
- Activating GTM recipes end-to-end (`cargo-gtm` — the pilot gate already encodes §1's spirit for spend).
|
||||
- Reporting diagnostics (`cargo-diagnostics` — conclusion-first tables).
|
||||
- CDK plans (`cargo-cdk` — `cdk plan` output is the plan-gate artifact; present the diff, not the raw state).
|
||||
- CDK plans (`cargo-project` — `project plan` output is the plan-gate artifact; present the diff, not the raw state).
|
||||
|
||||
@@ -41,7 +41,7 @@ Always confirm `workspace.name` before any write — there is no dry-run mode fo
|
||||
|
||||
## Permission prompts
|
||||
|
||||
When the Cargo plugin (or the installer's hook scaffolding) is present, an approval hook — wired per agent as `PreToolUse` (Claude Code), `PermissionRequest` (Codex), or `beforeShellExecution` (Cursor) — auto-approves ordinary `cargo-ai` calls — reads, queries, run/batch operations, and pipelines through read-only helpers (`jq`, `grep`, `head`, …) — so they don't prompt. Four categories always still prompt, deliberately: credentials (`login`/`logout`), token minting (`workspaceManagement token …`), report egress (`workspaceManagement report …` — reports can carry session traces, so consent stays explicit), and destruction/deploys (`cdk deploy`/`destroy`, any `remove`/`delete`). The hook is allow-only: it can skip a prompt but never override a deny rule. Don't restructure commands to dodge a prompt — if one of these prompts appears, it's supposed to.
|
||||
When the Cargo plugin (or the installer's hook scaffolding) is present, an approval hook — wired per agent as `PreToolUse` (Claude Code), `PermissionRequest` (Codex), or `beforeShellExecution` (Cursor) — auto-approves ordinary `cargo-ai` calls — reads, queries, run/batch operations, and pipelines through read-only helpers (`jq`, `grep`, `head`, …) — so they don't prompt. Four categories always still prompt, deliberately: credentials (`login`/`logout`), token minting (`workspaceManagement token …`), report egress (`workspaceManagement report …` — reports can carry session traces, so consent stays explicit), and destruction/deploys (`project deploy`/`destroy`, any `remove`/`delete`). The hook is allow-only: it can skip a prompt but never override a deny rule. Don't restructure commands to dodge a prompt — if one of these prompts appears, it's supposed to.
|
||||
|
||||
## Admin-only commands
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"$comment": "Generated by .github/scripts/skills-metadata.mjs — do not hand-edit. Regenerate with: node .github/scripts/skills-metadata.mjs --write .",
|
||||
"name": "cargo",
|
||||
"version": "1.25.0",
|
||||
"version": "1.25.1",
|
||||
"documents": [
|
||||
{
|
||||
"path": "SKILL.md",
|
||||
@@ -43,5 +43,5 @@
|
||||
"title": "UUID flow between skills"
|
||||
}
|
||||
],
|
||||
"contentHash": "ba8a5a2a66ca4284bf13d7af408c9f1dd84d2aa3c2862d2dada10129ae3b9ed8"
|
||||
"contentHash": "7bd94ef43c418dcbf9f2917722895b4c0886c1b550a861d8a70b37bec246e692"
|
||||
}
|
||||
|
||||
+8
-8
@@ -3,7 +3,7 @@
|
||||
// Add a case whenever you change a description, so the intended behavior is pinned.
|
||||
// `why` explains what the case is guarding against; it is printed on failure.
|
||||
{"prompt": "Find me 50 VPs of Sales at Series B fintech companies and verify their emails", "expect": "cargo-gtm", "why": "The flagship prospecting request; must not be captured by storage or segmentation."}
|
||||
{"prompt": "Build a TAM list of seed-stage SaaS companies in Europe", "expect": "cargo-gtm", "why": "A list today. cargo-cdk now carries pipeline vocabulary (worked example, keep it current) and must not steal the one-off pull."}
|
||||
{"prompt": "Build a TAM list of seed-stage SaaS companies in Europe", "expect": "cargo-gtm", "why": "A list today. cargo-project now carries pipeline vocabulary (worked example, keep it current) and must not steal the one-off pull."}
|
||||
{"prompt": "Enrich this CSV with company size and funding stage", "expect": "cargo-gtm"}
|
||||
{"prompt": "Who just raised a Series A in healthtech?", "expect": "cargo-gtm", "why": "Funding-signal phrasing with no Cargo vocabulary at all."}
|
||||
{"prompt": "Show me companies hiring data engineers that also run Snowflake", "expect": "cargo-gtm"}
|
||||
@@ -78,10 +78,10 @@
|
||||
{"prompt": "Deploy this app and promote it to production", "expect": "cargo-hosting"}
|
||||
{"prompt": "I need a webhook endpoint that receives form submissions", "expect": "cargo-hosting"}
|
||||
|
||||
{"prompt": "Set up our whole workspace as code so I can review it in a PR", "expect": "cargo-cdk"}
|
||||
{"prompt": "I want this version-controlled and reproducible across staging and production", "expect": "cargo-cdk"}
|
||||
{"prompt": "Deploy the workspace definition from CI", "expect": "cargo-cdk"}
|
||||
{"prompt": "Is there something like Terraform for Cargo?", "expect": "cargo-cdk"}
|
||||
{"prompt": "Set up our whole workspace as code so I can review it in a PR", "expect": "cargo-project"}
|
||||
{"prompt": "I want this version-controlled and reproducible across staging and production", "expect": "cargo-project"}
|
||||
{"prompt": "Deploy the workspace definition from CI", "expect": "cargo-project"}
|
||||
{"prompt": "Is there something like Terraform for Cargo?", "expect": "cargo-project"}
|
||||
|
||||
{"prompt": "Invite my teammate to the workspace", "expect": "cargo-workspace-management"}
|
||||
{"prompt": "Create an API token for CI", "expect": "cargo-workspace-management"}
|
||||
@@ -113,7 +113,7 @@
|
||||
{"prompt": "Our outbound is going to the wrong people — help me figure out who actually buys from us", "expect": "cargo-gtm", "tier": "hard"}
|
||||
{"prompt": "Something in the nightly pipeline produced garbage last night and I need to know what", "expect": "cargo-diagnostics", "why": "Paraphrase of 'why did this fail' with no shared words.", "tier": "hard"}
|
||||
{"prompt": "I want a Slack ping the moment our data freshness slips", "expect": "cargo-observability", "tier": "hard"}
|
||||
{"prompt": "Can I keep the definition of all this in version control?", "expect": "cargo-cdk", "tier": "hard"}
|
||||
{"prompt": "Can I keep the definition of all this in version control?", "expect": "cargo-project", "tier": "hard"}
|
||||
{"prompt": "Give my teammates a link where they can see these numbers", "expect": "cargo-hosting", "tier": "hard"}
|
||||
{"prompt": "Pull the finished rows down so I can hand them to the SDR team", "expect": "cargo-analytics", "tier": "hard"}
|
||||
{"prompt": "Am I going to run out of budget before the end of the quarter?", "expect": "cargo-billing", "tier": "hard"}
|
||||
@@ -130,8 +130,8 @@
|
||||
{"prompt": "Expose our CRM tools as an MCP server so I can call them from Claude Desktop", "expect": "cargo-ai", "why": "The publish direction of MCP. Was previously reachable from no description at all."}
|
||||
{"prompt": "How do I use Cargo from ChatGPT?", "expect": "cargo-mcp", "why": "Cargo now runs a hosted MCP server at mcp.getcargo.io/mcp, so a client with no shell connects to that rather than publishing one first. Was cargo-ai until the hosted server shipped.", "tier": "hard"}
|
||||
{"prompt": "Explain this automation to someone who has never seen it — I need a picture, not JSON", "expect": "cargo-orchestration", "why": "No CLI vocabulary at all; the job is rendering a graph.", "tier": "hard"}
|
||||
{"prompt": "Is there a skill that already builds account scoring, or do I write it from scratch?", "expect": "cargo-cdk", "why": "cargo-cdk gained the worked-example vocabulary: it owns the menu of gtm-skills that carry a CDK example and must catch the 'before I author it' question."}
|
||||
{"prompt": "Start from a worked example for a TAM pipeline and adapt it to our workspace", "expect": "cargo-cdk", "why": "'worked example' and a deployed pipeline are the standing-side words; the pack's CDK skill routes them, and its menu hands off to tam-building."}
|
||||
{"prompt": "Is there a skill that already builds account scoring, or do I write it from scratch?", "expect": "cargo-project", "why": "cargo-project gained the worked-example vocabulary: it owns the menu of gtm-skills that carry a CDK example and must catch the 'before I author it' question."}
|
||||
{"prompt": "Start from a worked example for a TAM pipeline and adapt it to our workspace", "expect": "cargo-project", "why": "'worked example' and a deployed pipeline are the standing-side words; the pack's CDK skill routes them, and its menu hands off to tam-building."}
|
||||
{"prompt": "Write me a first-touch email for these fintech CTOs", "expect": "cargo-gtm", "why": "Copywriting and audience, not sending infrastructure — must NOT be pulled to cargo-mailbox-management by the word email.", "tier": "hard"}
|
||||
{"prompt": "What did that email-sending workflow cost us last month?", "expect": "cargo-billing", "why": "Credit spend is billing even when the subject is mail; the mailbox skill owns the fleet, not the invoice.", "tier": "hard"}
|
||||
{"prompt": "Connect Cargo to Claude Desktop", "expect": "cargo-mcp", "why": "Pointing a client at the hosted server, not publishing one out of a workspace."}
|
||||
|
||||
@@ -29,11 +29,11 @@ allowed_helpers="jq cat head tail wc grep sort uniq column tr echo printf"
|
||||
# session data, destruction, and deploys always reach the user:
|
||||
# - first words: credential/session commands
|
||||
# - pairs: token minting, report egress (consent stays explicit -- reports can
|
||||
# carry session traces), and CDK deploy/destroy
|
||||
# carry session traces), and project deploy/destroy (plus the `cdk` alias)
|
||||
# - tokens: destructive verbs anywhere in the invocation (`storage model
|
||||
# remove`, `hosting app remove`, ...)
|
||||
gated_first="login logout"
|
||||
gated_pairs="workspaceManagement token,workspaceManagement report,cdk deploy,cdk destroy"
|
||||
gated_pairs="workspaceManagement token,workspaceManagement report,project deploy,project destroy,cdk deploy,cdk destroy"
|
||||
gated_tokens="remove delete destroy"
|
||||
|
||||
# Harden: no globbing, and unset variables are errors so a typo can't silently
|
||||
@@ -104,7 +104,7 @@ esac
|
||||
# - the cargo segment is gated POSITION-INDEPENDENTLY: a credential command
|
||||
# token (login, logout), a destructive verb token (remove, delete,
|
||||
# destroy), or a gated adjacent pair (workspaceManagement token,
|
||||
# workspaceManagement report, cdk deploy, cdk destroy) ANYWHERE in the
|
||||
# workspaceManagement report, project|cdk deploy, project|cdk destroy) ANYWHERE in the
|
||||
# segment refuses it. Positional checks alone are bypassable -- valid
|
||||
# prefixes like `npx -p @cargo-ai/cli cargo-ai login` or a global flag
|
||||
# with a value shift the real subcommand out of the first argument slots,
|
||||
@@ -232,7 +232,7 @@ verdict="$(printf '%s' "$cmd_stripped" | awk -v helpers="$allowed_helpers" -v ga
|
||||
# Gates, anywhere in the segment: credential first-words (login,
|
||||
# logout), destructive verbs (remove, delete, destroy), and gated
|
||||
# pairs as adjacent tokens (workspaceManagement token/report,
|
||||
# cdk deploy/destroy).
|
||||
# project|cdk deploy/destroy).
|
||||
for (j = s2; j <= n2; j++) {
|
||||
if (ct[j] in D) exit
|
||||
if (ct[j] in G) exit
|
||||
|
||||
@@ -22,22 +22,22 @@ A new account starts with **100 free credits, no card** — roughly 5,000 leads
|
||||
|
||||
## Skills
|
||||
|
||||
- [cargo](https://github.com/getcargohq/cargo-skills/blob/main/cargo/SKILL.md): Router for the Cargo CLI skill bundle — load first for anything Cargo, and whenever a task spans two Cargo domains. Explains what each skill owns, declarative workspace-as-code (cargo-cdk) vs the imperative CLI, the UUID and slug flow between skills, async polling of runs and batches, end-to-end use cases, and the gotchas that fail silently (`conjonction` spelling, run vs batch, model-uuid vs segment-uuid). Triggers: \"set up Cargo\", \"what can Cargo do\", \"which Cargo skill\", \"bootstrap my workspace\", \"I have a Cargo account\", \"cargo-ai …\", or any `cargo-ai` command whose domain you are unsure of. Skip when: the task obviously belongs to one skill — load that skill directly.
|
||||
- [cargo](https://github.com/getcargohq/cargo-skills/blob/main/cargo/SKILL.md): Router for the Cargo CLI skill bundle — load first for anything Cargo, and whenever a task spans two Cargo domains. Explains what each skill owns, declarative workspace-as-code (cargo-project) vs the imperative CLI, the UUID and slug flow between skills, async polling of runs and batches, end-to-end use cases, and the gotchas that fail silently (`conjonction` spelling, run vs batch, model-uuid vs segment-uuid). Triggers: \"set up Cargo\", \"what can Cargo do\", \"which Cargo skill\", \"bootstrap my workspace\", \"I have a Cargo account\", \"cargo-ai …\", or any `cargo-ai` command whose domain you are unsure of. Skip when: the task obviously belongs to one skill — load that skill directly.
|
||||
- [cargo-quickstart](https://github.com/getcargohq/cargo-skills/blob/main/cargo-quickstart/SKILL.md): Guided first-run demo for Cargo — one persona question to 25 real leads with a cost receipt in under two minutes, ending by saving the pull as a recurring play. Triggers: \"show me what Cargo can do\", \"give me a demo\", \"take me on a tour\", \"quickstart\", \"getting started with Cargo\", \"I just installed Cargo\", \"my workspace is empty\", \"does this actually work\". Skip when: the user has a real job to run (build a list, enrich a CSV, find emails) — use cargo-gtm; when they want CLI reference or routing — use the cargo router skill.
|
||||
- [cargo-gtm](https://github.com/getcargohq/cargo-skills/blob/main/cargo-gtm/SKILL.md): Do business-to-business go-to-market work on Cargo — research accounts and buying committees, enrich and verify B2B contact records from licensed data providers, score and qualify leads, draft permission-based outreach for the user's own sequencer, sync to CRM, and monitor buying signals. Consent basis, suppression lists, and volume limits gate every step that touches a person (`references/acceptable-use.md`); bulk unsolicited messaging, purchased or scraped lists, and consumer targeting are refused. Triggers: \"build me a list of\", \"find 50 <title> at <segment>\", \"who works at\", \"find work emails for these accounts\", \"enrich this CSV\", \"verify these emails\", \"build a TAM\", \"who fits our ICP\", \"who actually buys from us\", \"what data points should we collect on accounts\", \"our outbound is reaching the wrong people\", \"score these leads\", \"write a first-touch email\", \"push these to my CRM\", \"who changed jobs\", \"who just raised funding\", \"companies using <tech>\", \"who is hiring <role>\", \"find the buying committee\", \"portfolio companies of <investor>\", \"upload this audience to Google/Meta/LinkedIn ads\". Providers: aiArk, anthropic, apolloio, bouncer, brightData, builtwith, cleon1, companyEnrich, contactOut, datagma, dropcontact, enrichCrm, enrichley, enrowio, exa, findyMail, firecrawl, forager, FullEnrich, g2, gemini, hunter, icypeas, kitt, leadMagic, linkedin, linkup, mixrank, neverBounce, oceanio, openAi, parallel, peopleDataLabs, perplexity, piloterr, prospeo, proxycurl, reverseContact, rocketreach, salesNavigator, serper, sillage, snitcher, societeInfo, theirStack, theSwarm, waterfall, x, zeroBounce. Reads phase guides, recipes, and per-provider playbooks before any paid call. Skip when: a run already happened and misbehaved — use cargo-diagnostics.
|
||||
- [cargo-ai](https://github.com/getcargohq/cargo-skills/blob/main/cargo-ai/SKILL.md): Build and configure AI agents inside Cargo — create an agent, choose its model and temperature, write its prompt, attach knowledge for retrieval (RAG), connect MCP tool servers, manage memories, and deploy releases. Triggers: \"create an agent\", \"make an agent that\", \"give the agent our docs\", \"attach this knowledge base\", \"attach this library to the agent\", \"add resources to the agent release\", \"connect an MCP server\", \"expose our tools as an MCP server\", \"use Cargo from Claude Desktop or ChatGPT\", \"change the agent model\", \"what does the agent remember\", \"deploy the agent\", \"the agent is answering wrong\". Skip when: uploading the knowledge files themselves — use cargo-content; sending the agent a message or running it over records — use cargo-orchestration.
|
||||
- [cargo-analytics](https://github.com/getcargohq/cargo-skills/blob/main/cargo-analytics/SKILL.md): Get data out of Cargo and measure what ran — download a run output, export a segment or model to CSV or JSON, and pull run and batch success and error counts. Triggers: \"download the results\", \"export this to CSV\", \"give me the file\", \"how many succeeded\", \"what is my error rate\", \"send me the enriched list\", \"get the output of that run\", \"how many records did it write\". Skip when: asking why something failed or where credits went — use cargo-diagnostics; asking about credits, plans, or invoices — use cargo-billing.
|
||||
- [cargo-billing](https://github.com/getcargohq/cargo-skills/blob/main/cargo-billing/SKILL.md): Understand what Cargo is costing — remaining credits, usage broken down by workflow, connector, or agent, subscription state, and invoice history. Triggers: \"how many credits do I have left\", \"what did that cost\", \"why is my bill so high\", \"am I about to run out\", \"will this fit in our budget\", \"show me my invoices\", \"how much have I spent this month\", \"what plan am I on\", \"what do I get for free\", \"how many free credits\", \"can I afford this run\", \"add a card\", \"update my payment method\", \"why was my card declined\". Needs a token with admin access. Skip when: attributing spend to specific nodes or cutting a play cost — use cargo-diagnostics.
|
||||
- [cargo-cdk](https://github.com/getcargohq/cargo-skills/blob/main/cargo-cdk/SKILL.md): Manage a whole Cargo workspace as code — declare connectors, models, plays, tools, agents, MCP servers, segments, context, folders, files, workers, and apps in TypeScript, then reconcile them with `cargo-ai cdk` (init → types → plan → deploy), the way you would run Pulumi or the AWS CDK. Triggers: \"as code\", \"in git\", \"version-controlled\", \"reproducible\", \"Terraform for Cargo\", \"set up a whole workspace\", \"staging and production\", \"deploy from CI\", \"review this in a PR\", \"cargo.state.json\", \"scaffold from a template\", \"is there a cookbook for this\", \"start from a cookbook\". Skills with a CDK example (TAM building, account scoring, contact sourcing, routing, AI SDR, rep cockpit) live in gtm-skills; menu in references/cookbooks.md. Skip when: it is a one-off operation, a read, or an ad-hoc query — use the matching capability skill.
|
||||
- [cargo-connection](https://github.com/getcargohq/cargo-skills/blob/main/cargo-connection/SKILL.md): Connect Cargo to an external system and find out what it can do — authenticate connectors, browse the integration catalog, and resolve the `connectorUuid` and `actionSlug` a workflow node needs. Triggers: \"connect my HubSpot\", \"is Salesforce connected\", \"what integrations do you support\", \"can Cargo talk to <tool>\", \"what actions does <provider> have\", \"I need the connector UUID\", \"set up the API key for\", \"it is asking for credentials again\", \"why is this connector failing auth\", \"list my connectors\". Integrations: amplemarket, amplitude, attio, bigQuery, calendly, closecom, contrast, csv, customerio, dbt, emailBison, expandi, googleAds, googleSheets, heyReach, http, hubspot, hubspotMcp, instantly, instantlyV2, intercom, jira, kitt, lemlist, lgm, linkedinAds, linkedinMatchedAudience, livestorm, manus, marketo, metabase, microsoftTeams, mixpanel, netsuite, netsuiteSoap, notionMcp, octave, onesignal, outreach, pipedrive, postgresql, redshift, resend, rift, salesforce, salesforceMcp, salesloft, Sendgrid, sillage, slack, smartlead, snowflake, sql, stripe, and 82 more. Skip when: choosing between enrichment providers for a GTM job — use cargo-gtm and its provider playbooks.
|
||||
- [cargo-content](https://github.com/getcargohq/cargo-skills/blob/main/cargo-content/SKILL.md): Manage the knowledge a Cargo workspace holds — upload files (PDF, CSV, text), rename and organize them, and build native or connector-backed libraries that sync from an external source, so agents can retrieve them (RAG). Triggers: \"upload this PDF\", \"add these docs as knowledge\", \"build a knowledge base\", \"sync our help center into Cargo\", \"what files are in the workspace\", \"index this folder\", \"attach our pricing sheet\". Skip when: wiring the file or library into an agent — use cargo-ai; uploading a CSV that drives a batch run — that is a workspace-management file upload.
|
||||
- [cargo-context](https://github.com/getcargohq/cargo-skills/blob/main/cargo-context/SKILL.md): Read and write the workspace GTM knowledge base — the git-backed repository of markdown describing ICPs, personas, plays, proof points, objections, competitors, and signals — plus its runtime sandbox and typed knowledge graph. Triggers: \"document our ICP\", \"write up this persona\", \"what is our positioning\", \"add a battlecard\", \"capture this objection\", \"what do we know about <segment>\", \"update our context\", \"what is in the context repo\", \"who do we sell to\". Skip when: discovering who actually buys from you by analyzing won/lost data — that is cargo-gtm (this skill writes the conclusion down, it does not derive it); storing structured records rather than prose — use cargo-storage; attaching documents to an agent for RAG — use cargo-content.
|
||||
- [cargo-diagnostics](https://github.com/getcargohq/cargo-skills/blob/main/cargo-diagnostics/SKILL.md): Explain what a Cargo run or batch actually did, after the fact — trace one run node by node, draw the graph it executed with the failing step marked, sweep a batch or play for errors grouped by root cause, and attribute credit spend down to the node and the provider. Triggers: \"why did this fail\", \"it succeeded but the output is wrong\", \"half my rows are empty\", \"why is this column blank\", \"what broke in this batch\", \"why did that cost so much\", \"which node is burning credits\", \"it worked yesterday\", \"these results look wrong\", \"it went down the wrong path\", \"this step never ran\", \"show me what the run did\". Skip when: setting up an alert for next time — use cargo-observability; just downloading the data — use cargo-analytics.
|
||||
- [cargo-hosting](https://github.com/getcargohq/cargo-skills/blob/main/cargo-hosting/SKILL.md): Put something on the internet from Cargo — Vite single-page apps served at https://<slug>.cargo.app and serverless edge workers that answer HTTP requests, plus the deployments that build and promote them. Triggers: \"build me a dashboard for this\", \"host this app\", \"give me a URL to share\", \"deploy this\", \"I need a webhook endpoint\", \"make it live\", \"promote to production\", \"put it on cargo.app\", \"ship a UI for my team\". Skip when: the app or worker should be declared as committed workspace code — use cargo-cdk.
|
||||
- [cargo-mailbox-management](https://github.com/getcargohq/cargo-skills/blob/main/cargo-mailbox-management/SKILL.md): Send mail from inboxes Cargo owns — provision mailboxes on a sending domain, run provider warm-up and the 5→40/day send ramp, deliver with the `sendEmail` action, and read back threads, replies, delivery events, and the workspace suppression list. Triggers: \"set up a sending mailbox\", \"provision inboxes for outbound\", \"warm up this mailbox\", \"how many sends do I have left today\", \"send this from Cargo\", \"did they reply\", \"who unsubscribed\", \"suppress this recipient\", \"take me off your list\", \"never email them again\", \"what do mailboxes cost\", \"my mailbox is stuck pending\". A mailbox is a recurring monthly credit charge, and every send is gated on basis, suppression, and relevance. Skip when: writing the copy or building the audience — use cargo-gtm; the mailbox belongs in git — use cargo-cdk.
|
||||
- [cargo-hosting](https://github.com/getcargohq/cargo-skills/blob/main/cargo-hosting/SKILL.md): Put something on the internet from Cargo — Vite single-page apps served at https://<slug>.cargo.app and serverless edge workers that answer HTTP requests, plus the deployments that build and promote them. Triggers: \"build me a dashboard for this\", \"host this app\", \"give me a URL to share\", \"deploy this\", \"I need a webhook endpoint\", \"make it live\", \"promote to production\", \"put it on cargo.app\", \"ship a UI for my team\". Skip when: the app or worker should be declared as committed workspace code — use cargo-project.
|
||||
- [cargo-mailbox-management](https://github.com/getcargohq/cargo-skills/blob/main/cargo-mailbox-management/SKILL.md): Send mail from inboxes Cargo owns — provision mailboxes on a sending domain, run provider warm-up and the 5→40/day send ramp, deliver with the `sendEmail` action, and read back threads, replies, delivery events, and the workspace suppression list. Triggers: \"set up a sending mailbox\", \"provision inboxes for outbound\", \"warm up this mailbox\", \"how many sends do I have left today\", \"send this from Cargo\", \"did they reply\", \"who unsubscribed\", \"suppress this recipient\", \"take me off your list\", \"never email them again\", \"what do mailboxes cost\", \"my mailbox is stuck pending\". A mailbox is a recurring monthly credit charge, and every send is gated on basis, suppression, and relevance. Skip when: writing the copy or building the audience — use cargo-gtm; the mailbox belongs in git — use cargo-project.
|
||||
- [cargo-mcp](https://github.com/getcargohq/cargo-skills/blob/main/cargo-mcp/SKILL.md): Drive Cargo from its hosted MCP server at https://mcp.getcargo.io/mcp — connect a client, discover and price an action, run it over one record or a batch, poll it, and read workspace models, with no CLI install. Also when to call an MCP tool instead of shelling out to `cargo-ai`. Triggers: \"connect Cargo to Claude Desktop\", \"add Cargo to ChatGPT\", \"Cargo MCP server\", \"mcp.getcargo.io\", \"use Cargo without installing anything\", \"which Cargo tool do I call\", \"search_actions\", \"execute_action_batch\", \"MCP server is showing the wrong workspace\". Tools: whoami, search_actions, get_action_schema, execute_action, execute_action_batch, get_run, query_models. Skip when: you have a shell and the job is a workflow, a CDK deploy, warehouse SQL, or a mailbox — use the CLI skills; when publishing an MCP server out of your own workspace or attaching one to a Cargo agent — use cargo-ai.
|
||||
- [cargo-observability](https://github.com/getcargohq/cargo-skills/blob/main/cargo-observability/SKILL.md): Watch a Cargo workspace and get told when something breaks — scheduled threshold alerts over workflow telemetry (spans, runs, records), a storage model freshness or row count, or any SQL query, firing a connector, tool, or agent when a metric breaches. Triggers: \"alert me when\", \"notify me if\", \"let me know when the error rate\", \"monitor this workflow\", \"tell me if the sync stops\", \"warn me before I run out of credits\", \"dead man’s switch\", \"is this still running\", \"set up monitoring\", plus listing, previewing, editing, and reviewing an alert firing history. Skip when: diagnosing something that already went wrong — use cargo-diagnostics.
|
||||
- [cargo-orchestration](https://github.com/getcargohq/cargo-skills/blob/main/cargo-orchestration/SKILL.md): Make Cargo actually run something, or show what it would run — execute one connector action, run a multi-step workflow, trigger a batch across a whole segment or model, message an AI agent, build or edit a node graph, draw a workflow, tool or play as a diagram, and query the runtime tables (runs, batches, spans, records) with SQL. Triggers: \"run this on all my contacts\", \"execute the action\", \"kick off a batch\", \"build a workflow\", \"schedule a play\", \"make it run every morning\", \"ask the agent\", \"show me the workflow\", \"what does this tool do\", \"visualize this play\", \"draw the graph\", \"explain this workflow\", \"how many runs failed today\", \"what is the output schema for this action\", \"add a step that\". Skip when: explaining why a run misbehaved — use cargo-diagnostics; downloading result files — use cargo-analytics; committing the workflow as code — use cargo-cdk.
|
||||
- [cargo-orchestration](https://github.com/getcargohq/cargo-skills/blob/main/cargo-orchestration/SKILL.md): Make Cargo actually run something, or show what it would run — execute one connector action, run a multi-step workflow, trigger a batch across a whole segment or model, message an AI agent, build or edit a node graph, draw a workflow, tool or play as a diagram, and query the runtime tables (runs, batches, spans, records) with SQL. Triggers: \"run this on all my contacts\", \"execute the action\", \"kick off a batch\", \"build a workflow\", \"schedule a play\", \"make it run every morning\", \"ask the agent\", \"show me the workflow\", \"what does this tool do\", \"visualize this play\", \"draw the graph\", \"explain this workflow\", \"how many runs failed today\", \"what is the output schema for this action\", \"add a step that\". Skip when: explaining why a run misbehaved — use cargo-diagnostics; downloading result files — use cargo-analytics; committing the workflow as code — use cargo-project.
|
||||
- [cargo-project](https://github.com/getcargohq/cargo-skills/blob/main/cargo-project/SKILL.md): Manage a whole Cargo workspace as code — declare connectors, models, plays, tools, agents, MCP servers, segments, context, folders, files, workers, and apps in TypeScript, then reconcile them with `cargo-ai project` (init → types → plan → deploy), the way you would run Pulumi or the AWS CDK. Triggers: \"as code\", \"in git\", \"version-controlled\", \"reproducible\", \"Terraform for Cargo\", \"set up a whole workspace\", \"staging and production\", \"deploy the workspace from CI\", \"review this in a PR\", \"cargo.state.json\", \"scaffold from a template\", \"is there a cookbook for this\", \"start from a cookbook\". Skills with a CDK example (TAM building, account scoring, contact sourcing, routing, AI SDR, rep cockpit) live in gtm-skills; menu in references/cookbooks.md. Skip when: it is a one-off operation, a read, or an ad-hoc query — use the matching capability skill.
|
||||
- [cargo-segmentation](https://github.com/getcargohq/cargo-skills/blob/main/cargo-segmentation/SKILL.md): Define and use segments — named, saved filters over a Cargo model that become the audience for a batch run, a play trigger, or an export. Triggers: \"build a segment of\", \"filter my contacts where\", \"who matches this criteria\", \"save this as a list\", \"how many companies match\", \"the Closed-Won segment\", \"everyone who has not been emailed\", \"target only accounts that\", \"what is in this segment\", \"narrow this down to\". Filter JSON uses `conjonction` (not `conjunction`) — misspelling it fails silently. Skip when: running something over the segment — use cargo-orchestration; exporting its rows — use cargo-analytics; ad-hoc SQL over the model — use cargo-storage.
|
||||
- [cargo-storage](https://github.com/getcargohq/cargo-skills/blob/main/cargo-storage/SKILL.md): Work with the data inside a Cargo workspace — models (Companies, Contacts, Deals…), datasets, columns, relationships, records, and SQL over workspace storage. Triggers: \"what models do I have\", \"show me the schema\", \"add a column for\", \"how many contacts do I have\", \"SELECT … FROM\", \"query my companies table\", \"join contacts to companies\", \"what is the DDL\", \"set up a webhook-fed model\", \"where does this field live\", \"import this into a model\", \"unify these models\", \"merge duplicate accounts\", \"link contacts to companies\", \"set up a relationship between\". Skip when: querying run or batch telemetry rather than business data — use cargo-orchestration; naming a reusable filtered audience — use cargo-segmentation.
|
||||
- [cargo-workspace-management](https://github.com/getcargohq/cargo-skills/blob/main/cargo-workspace-management/SKILL.md): Administer a Cargo workspace and talk back to the Cargo team — invite and manage members, mint and rotate API tokens, organize plays, tools, and agents into folders, inspect roles, upload batch input files, and file reports. Triggers: \"invite my teammate\", \"create an API token for CI\", \"who has access\", \"organize these into folders\", \"rotate that token\", \"upload this CSV for a batch\" — and for feedback: \"report this bug to Cargo\", \"send feedback to the Cargo team\", \"this CLI command is broken\", \"share this session with Cargo\", \"request a feature\". Most commands need a token with admin access. Skip when: the question is about credits, plans, or invoices — use cargo-billing.
|
||||
@@ -65,11 +65,11 @@ Step-by-step playbooks for a specific job. An agent loads the parent skill, then
|
||||
- [save-as-play](https://github.com/getcargohq/cargo-skills/blob/main/cargo-gtm/recipes/save-as-play.md): Convert whatever was just run ad-hoc (a search, an enrichment chain, a signal pull) into a scheduled, always-on workflow in the workspace.
|
||||
- [source-planning](https://github.com/getcargohq/cargo-skills/blob/main/cargo-gtm/recipes/source-planning.md): Use this recipe when the user asks a research or list-building question whose answer source is not obvious, and the wrong first guess is expensive.
|
||||
- [tech-intent](https://github.com/getcargohq/cargo-skills/blob/main/cargo-gtm/recipes/tech-intent.md): Use this recipe when the user wants to find or prioritize companies based on what they use (tech stack) or what they're hiring for (role intent).
|
||||
- [add-connector-and-model](https://github.com/getcargohq/cargo-skills/blob/main/cargo-cdk/recipes/add-connector-and-model.md): Use when the user wants a new data source plus a model built from it, managed
|
||||
- [build-an-agent](https://github.com/getcargohq/cargo-skills/blob/main/cargo-cdk/recipes/build-an-agent.md): Use when the user wants an AI agent with a data model, a tool, and an LLM
|
||||
- [deploy-from-ci](https://github.com/getcargohq/cargo-skills/blob/main/cargo-cdk/recipes/deploy-from-ci.md): Use when the user wants cargo-ai cdk deploy to run non-interactively — on
|
||||
- [migrate-existing-workspace](https://github.com/getcargohq/cargo-skills/blob/main/cargo-cdk/recipes/migrate-existing-workspace.md): Use when a workspace already has live resources (built in the UI or the
|
||||
- [scaffold-a-workspace](https://github.com/getcargohq/cargo-skills/blob/main/cargo-cdk/recipes/scaffold-a-workspace.md): Use when the user wants to stand up a new Cargo workspace as code,
|
||||
- [add-connector-and-model](https://github.com/getcargohq/cargo-skills/blob/main/cargo-project/recipes/add-connector-and-model.md): Use when the user wants a new data source plus a model built from it, managed
|
||||
- [build-an-agent](https://github.com/getcargohq/cargo-skills/blob/main/cargo-project/recipes/build-an-agent.md): Use when the user wants an AI agent with a data model, a tool, and an LLM
|
||||
- [deploy-from-ci](https://github.com/getcargohq/cargo-skills/blob/main/cargo-project/recipes/deploy-from-ci.md): Use when the user wants cargo-ai project deploy to run non-interactively — on
|
||||
- [migrate-existing-workspace](https://github.com/getcargohq/cargo-skills/blob/main/cargo-project/recipes/migrate-existing-workspace.md): Use when a workspace already has live resources (built in the UI or the
|
||||
- [scaffold-a-workspace](https://github.com/getcargohq/cargo-skills/blob/main/cargo-project/recipes/scaffold-a-workspace.md): Use when the user wants to stand up a new Cargo workspace as code,
|
||||
|
||||
## Provider playbooks
|
||||
|
||||
|
||||
+1
-1
@@ -64,7 +64,7 @@
|
||||
"description": "Hosted apps and edge workers, sending mailboxes, workspace-as-code, members, tokens, and folders.",
|
||||
"skills": [
|
||||
"cargo-hosting",
|
||||
"cargo-cdk",
|
||||
"cargo-project",
|
||||
"cargo-mailbox-management",
|
||||
"cargo-workspace-management"
|
||||
]
|
||||
|
||||
Reference in New Issue
Block a user