cargo

██████    ████    █████    ██████   ██████
██    ░  ██  ██░  ██  ██   ██    ░  ██  ██░
██       ██████░  █████ ░  ██ ███   ██  ██░
██       ██  ██░  ██ ██    ██  ██░  ██  ██░
██████   ██  ██░  ██  ██   ██████░  ██████░
 ░░░░░░   ░░  ░░   ░░  ░░   ░░░░░░   ░░░░░░

Cargo CLI — Skills Overview

This repository contains 17 skills at the repo root: this router (cargo), one onboarding skill (cargo-quickstart), one outcome skill (cargo-gtm), and fourteen capability skills.

• 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, workspace management), plus cargo-diagnostics (cross-domain forensics over runs, batches, and credit spend). 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 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-gtm delegates to capability skills; capability skills never reference cargo-gtm (one-way dependency).

Glossary: See references/glossary.md for term-by-term definitions (UUIDs, slugs, conjonction, run/batch/play/tool, signal/persona/ICP, etc.).

Interaction conventions: See references/interaction.md for the pack-wide defaults on when to stop and ask (plan gate before building, recommended-default choices) and how to present results (narrate, summarize — never dump raw JSON).

Installation

npm install -g @cargo-ai/cli

# Recommended: emailed code, no browser at any point.
# Creates the account and a workspace on first use — there is no separate sign-up step.
cargo-ai login --email you@company.com            # sends the code, then exits
cargo-ai login --email you@company.com --code 123456

# Alternatives
cargo-ai login --oauth                            # browser sign-in (OAuth device flow)
cargo-ai login --token            # existing workspace-scoped API token (CI)

# Optional: pick the workspace at login instead of being prompted
cargo-ai login --email you@company.com --workspace-name "Acme GTM"

# Verify
cargo-ai whoami

A new account starts with 100 free credits and needs no card, so an agent can sign a user up and produce a real deliverable in the same turn — there is no purchase gate between install and first value. Useful anchors for what that buys: ~5,000 leads sourced (salesNavigator.searchLeads, 0.02/record), ~1,000 profile+verified-email enriches (aiArk.enrichPerson, 0.1), ~1,000 email verifications (waterfall.verifyEmail, 0.1), or ~50 fully enriched contacts (waterfall.enrichContact, 2). The quickstart demo spends about 0.5. Say the free balance out loud before the first paid call on a new account.

--email is the one to reach for in an agent or sandbox shell: it never opens a browser, and where there is no terminal to prompt at, the first call sends the code and exits so you re-run with --code. To keep the code out of shell history, pass it on stdin: echo 123456 | cargo-ai login --email you@company.com --code -. Signing in with an address that already has an account resolves to its existing workspace rather than creating one, so this is safe to re-run.

--oauth runs the same OAuth 2.0 Device Authorization Flow it always did, and still needs a human at the verification URL. Use --token for CI, with a workspace-scoped token from Settings > API; token values are shown only once, so store one immediately in a secrets manager.

Without a global install, prefix every command with npx @cargo-ai/cli instead of cargo-ai.

These skills also install as a native agent plugin for Claude Code, Codex, and Cursor (one repo, three targets) — plugin users get the same skills plus the approval hook and session-lifecycle hooks bundled, with no separate installer. See the repo README.md for per-target install steps, and use one channel: plugin or skills add, never both (duplicates every skill).

All commands output JSON to stdout. Failed commands exit non-zero and return {"errorMessage": "..."}. For the full setup conventions that every capability skill links to (token scopes, async polling, admin-only commands), see references/prerequisites.md.

Every Cargo session has three jobs

Automated on Claude Code. Jobs 1 and 3 (refresh + session register/finalize) run on their own when either the Cargo plugin is installed (its bundled SessionStart/Stop/SessionEnd hooks handle them) or the hooks from the Cargo bootstrap installer — documented under Staying current → Claude Code in the repo README.md — are present. The Stop hook also checkpoints the session row each turn, so a session that never reaches SessionEnd still shows recent context instead of a bare placeholder. Do these by hand only when neither is installed (or on agents without lifecycle hooks). Job 2 (reporting) is always your responsibility — it can't be automated, and neither can the two asks at the end of Job 3 (share the session, star the repo): a hook can print, but it can't take a Y/N.

Never run that installer on the user's behalf without asking. Its documented form pipes a network-fetched script into a shell, so it is the user's call, made by the user, in their own terminal — point them at the README rather than reaching for the command yourself. If they want to inspect it first, the README also gives the download-once-then-run form; tell them to prefer it, because fetching twice (read, then pipe) proves nothing about what the second request serves.

1. At session start — refresh and register

Before any other Cargo command, refresh the CLI and skills, then register the session in workspace management:

# Refresh — idempotent, ~10s. Skills first, then the CLI at the version the
# bundle pins. The pin file `cli-version` sits in the same directory as this
# SKILL.md — read it from wherever you loaded this skill (on Claude Code with
# `skills add` that is ~/.claude/skills/cargo/; plugin installs handle this
# automatically via their SessionStart hook). Fall back to latest.
npx -y skills add getcargohq/cargo-skills
npm install -g "@cargo-ai/cli@$(cat /cli-version 2>/dev/null || echo latest)"

# Register the session (placeholders OK — overwritten at session end)
cargo-ai workspaceManagement session upsert \
  --session-id  \
  --title "Agent session " \
  --summary "Session in progress."

Skip the refresh only if the user explicitly pinned a version — and skip the skills add entirely if the skills came from a plugin (the plugin owns them; a parallel skills add duplicates every skill). Skip the session upsert only if the user opted out or no session id is available.

Why the pin: cargo/cli-version is bumped in lockstep with these skills (a PR from the CLI release pipeline), so the CLI you install is the one this bundle was written against — no docs/CLI drift mid-session. If the pin file is missing or unreadable, latest is the safe fallback. To move the pin, merge the pending version-bump PR on getcargohq/cargo-skills (or edit cargo/cli-version) — the next session refresh converges automatically.

The pin is also what keeps this refresh from being a blind auto-update: the version installed is a reviewed constant committed to this repo, not whatever latest resolved to this morning, and moving it is a human merge. Two things follow for you as the agent. The refresh installs a global npm package and rewrites the skills bundle on disk — surface that the first time you run it in a session rather than doing it silently, and skip it entirely if the user has pinned a version or asks you not to. And treat the pin as read-only: bump cargo/cli-version only when the user explicitly asks, never to work around a failing command.

2. Mid-session — re-refresh, or escalate when stuck

Re-refresh the CLI and skills mid-session when:

• A documented CLI flag or response shape doesn't match what you observe (a fix may have shipped since session start).
• The user explicitly asks ("bump cargo", "make sure I'm on latest").

Send a workspace management report when the CLI is failing in a way the skill references and --help cannot resolve, the user or agent is repeatedly retrying the same command without progress, the syntax for a flag / JSON payload is unclear, or a needed capability seems missing:

cargo-ai workspaceManagement report create \
  --title "" \
  --description ""

Trigger conditions (any one is enough):

• A command failed ≥ 2 times in a row on the same task and the cause is not obvious.
• The CLI is being misused and the correct usage is not discoverable from the skills, examples, or --help.
• A documented behavior contradicts what you observe.
• A feature appears to be missing entirely.

This is the official feedback channel — every report is reviewed by the Cargo team and used to improve the CLI and these skills. It carries wins as well as failures: a session-share (below) files through the same command. Do not give up silently — file a report. See ../cargo-workspace-management/SKILL.md (Reports section) and ../cargo-workspace-management/references/examples/reports.md for templates.

3. At session end — finalize the session row, then ask to share

Produce a short title (5–8 words) and a 1–2 sentence summary of what the session actually worked on, then overwrite the placeholder row and stamp finished_at:

cargo-ai workspaceManagement session upsert \
  --session-id  \
  --title "<5-8 word title>" \
  --summary "<1-2 sentence summary of what was accomplished or attempted>" \
  --finished

--title and --summary are required (NOT NULL). --finished stamps finished_at = now; pass --finished-at for an explicit timestamp.

Then ask once, at the natural end of the session:

"Send this session's activity to the Cargo team so they can improve the experience? (Y/N)"

On yes, file a session-share report (consented session traces are the fastest product-learning loop the team has):

cargo-ai workspaceManagement report create \
  --title "Session share: <5-8 word session title>" \
  --description ""

On no, don't ask again this session. Skip the ask entirely for trivial sessions (a single lookup, no paid actions). See ../cargo-workspace-management/references/examples/reports.md for the session-share template.

Then, if the session went well — offer to star the repo

A star is the user's endorsement, not yours. Never run the command unprompted; ask, and act only on an explicit yes. Silently starring from a skill file is astroturfing with someone else's GitHub account.

Ask only when all of these hold:

• The session produced a real deliverable (same bar as the session-share ask — skip trivial sessions).
• Nothing is still failing or unresolved. Asking after a broken session reads as tone-deaf.
• The marker file ~/.config/cargo-ai/.star-asked does not exist — this is a once per machine ask, not once per session.

# gate
test -f ~/.config/cargo-ai/.star-asked || echo "ask"

"Glad that worked. Want me to star getcargohq/cargo-skills for you? (Y/N)"

On yes (gh must be authenticated with the repo or public_repo scope — note there is no gh repo star subcommand):

gh api -X PUT /user/starred/getcargohq/cargo-skills   # 204 No Content = starred

Touch the marker on either answer, so a no is never re-asked and a yes is never double-asked:

mkdir -p ~/.config/cargo-ai && touch ~/.config/cargo-ai/.star-asked

If gh is missing or unauthenticated, don't fix it and don't offer a workaround — say the repo is at https://github.com/getcargohq/cargo-skills and move on. This is the lowest-stakes item in the session; it never becomes a task.

---

Skills at a glance

Declarative (CDK) vs imperative (CLI) — pick the mode first

Two ways to create/manage the same Cargo resources. Decide which the task wants before picking a domain:

• Declarative → cargo-cdk. 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.
• 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, ad-hoc query, or single mutation that needn't live in code.

When unsure: should the result be committed and re-deployable? Yes → CDK. A quick action or a read → the capability skill.

Onboarding skill

Load for a brand-new user or an empty workspace.

Outcome skill

Load when the user states a real-world goal.

Capability skills

Load for a specific CLI domain. The first link in each row jumps to the actual SKILL.md; the parenthetical jumps to the recap on this page.

Agent knowledge for RAG: files + libraries live in the content domain → cargo-content; how they attach to an agent → cargo-ai. (Files/libraries moved out of the old ai file … path in CLI ≥ 1.0.19.)

These skills vs a workspace MCP server

There is no first-party "Cargo MCP server". What Cargo offers is the ability to build one: a workspace picks the actions and resources it wants to expose (cargo-ai ai mcp-server create --actions … --resources …, see ../cargo-ai/SKILL.md), and the CLI can serve that curated set to any stdio MCP client:

cargo-ai ai mcp-server list                       # find the server UUID
claude mcp add cargo -- cargo-ai mcp --server    # Claude Code, Cursor, Claude Desktop…

cargo-ai mcp bridges over stdio using the CLI's own credentials — no token to paste into client config. With no --server, it uses CARGO_MCP_SERVER_UUID or the workspace's only MCP server.

Route between the two surfaces by shape of the request:

Rule of thumb: anything touching more than a handful of records, or that the user will want to re-run, belongs in the CLI. Never fan an MCP tool out record-by-record over a list — that is what orchestration action execute-batch exists for, and it is cheaper and observable. Conversely, when the workspace has already curated a tool for a job, calling it beats hand-assembling the same thing from raw actions.

CLI domains without a dedicated skill yet

The CLI exposes several domains that no capability skill wraps yet. Reach for them directly (cargo-ai --help) when a task needs them, and file a workspaceManagement report if the surface is unclear:

---

How the skills relate

            ┌─────────────────────────────────────┐
            │              cargo-gtm              │
            │   Outcome / front door for GTM      │
            │   Recipes, guides, provider-playbks │
            └─────────────────┬───────────────────┘
                              │ delegates to ↓ (one-way)
       ┌──────────────────────┴──────────────────────┐
       │                                             │
┌──────────────────────────────────────────────────────────────┐
│              cargo-workspace-management                      │
│         Authentication, users, tokens, folders               │
└──────────────────────────────────────────────────────────────┘

  ┌─────────────────┐   ┌────────────────────┐   ┌─────────────────┐
  │  cargo-storage  │   │  cargo-connection  │   │    cargo-ai     │
  │ Models, columns,│   │ Connectors,        │   │ Agents, docs,   │
  │ datasets        │   │ integration actions│   │ MCP, memory     │
  └────────┬────────┘   └─────────┬──────────┘   └────────┬────────┘
                                              (cargo-content feeds
                                               files/libraries to agents)
           │                      │  (UUIDs flow down)    │
           └──────────────────────┼───────────────────────┘
                                  ▼
             ┌───────────────────────────────────────┐
             │          cargo-orchestration          │
             │   Runs, batches, plays, tools, SoR    │
             └───────────────┬───────────────────────┘
                             │
              ┌──────────────┴──────────────┐
              ▼                             ▼
 ┌────────────────────────┐  ┌───────────────────────────┐
 │    cargo-analytics     │  │       cargo-billing       │
 │  Results, metrics,     │  │    Credit usage, costs    │
 │  exports               │  │                           │
 └────────────────────────┘  └───────────────────────────┘

             ┌───────────────────────────────────────┐
             │             cargo-context             │
             │  Git-backed GTM markdown knowledge:   │
             │  personas, plays, proof, signals…     │
             └───────────────────────────────────────┘
           (orthogonal: not part of the workflow flow)

             ┌───────────────────────────────────────┐
             │               cargo-cdk               │
             │  Declarative authoring layer: define  │
             │  connectors/models/plays/agents/… as  │
             │  code, deploy with `cargo-ai cdk`.    │
             └───────────────────────────────────────┘
    (cross-cutting: PRODUCES the same resources the imperative
     skills manage — an alternative mode, not a workflow stage)

             ┌───────────────────────────────────────┐
             │           cargo-observability         │
             │  Scheduled threshold alerts over the  │
             │  telemetry above (spans/runs/records), │
             │  a model's health, or a SQL query —    │
             │  fire actions as runs on breach.       │
             └───────────────────────────────────────┘
     (watches orchestration/storage; fires orchestration
      actions — proactive counterpart to cargo-diagnostics)

Dependency rules in practice:

• cargo-gtm delegates to capability skills via relative paths (../cargo-orchestration/...). Capability skills never reference cargo-gtm.
• cargo-workspace-management provides auth context for every skill — set it up first.
• 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-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-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 "" (tables as .). 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 "". 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/.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 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.
• When a run failed, a run "succeeded but looks wrong", a batch has errors, or a play costs too much, load cargo-diagnostics — it sequences the run get / orchestration-SQL / billing surfaces into forensic runbooks (trace one run, sweep a batch, profile credit spend).
• To be told about a problem before you go looking — an error-rate spike, a cost ceiling, a slow node, a stalled sync, a workflow that stopped running — load cargo-observability. It creates alerts: scheduled threshold checks over the same telemetry (spans/runs/records), a model's health, or a SQL query, that fire actions on breach. Diagnostics is reactive (explain what happened); observability is proactive (watch for it). Alerts can also be declared as code via CDK's defineAlert.

---

Per-skill critical rules

The non-obvious rules for each skill — the things that fail silently or cost money if you guess. Each skill's own SKILL.md carries the full surface; these are the ones worth knowing before you pick.

cargo-gtm

Recipes shipped:

Priority provider stack (recipes lead with these): salesNavigator (sourcing), cargo native (firmographics + signals), aiArk (LinkedIn-anchored enrich + cheapest search), waterfall (multi-source enrichment + email verify + job-change), FullEnrich (premium contact lookup), apolloio (1-credit niche-coverage enrich), theirStack (tech-stack + hiring intent), peopleDataLabs (heavyweight backfill). Already have LinkedIn URLs (or an event URL)? Don't source — go straight to aiArk.enrichPerson (0.1, profile + verified email, bills 0 on no-email), or linkedin (enrichProfile/enrichCompany 0.25, extractEventAttendees) when you don't need the email; these are the cheapest URL-anchored enriches and easy to miss because the stack above is sourcing-first.

Critical rules:

• Acceptable use gates every step that touches a person (../cargo-gtm/references/acceptable-use.md): B2B professional identities from licensed providers only, three free blocking checks before any outreach step (basis, suppression, relevance), and a refusal list — undifferentiated fan-out, consumer targeting, lists with no stated origin, contacting a suppressed record, filter or identity evasion, auto-dialing, batch-blasting LinkedIn engagement actions. The pack never sends: outreach stops at send-ready variables for the user's own sequencer.
• All recipes use credits-based actions (cargo-ai connection integration list → 145 credits-based actions across 120 integrations).
• Action shape: {"kind":"connector","integrationSlug":"","actionSlug":"","config":{}} — no connectorUuid in config.
• Output retrieval: cargo-ai orchestration run download-outputs --output-node-slug (NOT run download).
• peopleDataLabs filter shape: searchX uses cargo's {conjonction, groups, conditions} shape; queryX takes a PDL SQL string — never Elasticsearch.

cargo-orchestration

Critical rules:

• See the decision flowchart at the top of ../cargo-orchestration/SKILL.md for when to use action execute vs run create vs batch create.
• Never enroll a full batch on the first attempt. batch create / action execute-batch fan out across every record in the source. Sample 10–20 records, report observed cost + hit-rate, then ask the user to approve the full enrollment — quoting the record count and the credit estimate. Mechanics: ../cargo-orchestration/SKILL.md → "Create a batch"; spend rules: ../cargo-gtm/references/cost-discipline.md §1.
• action execute is the default for running an operation; node execute is debug-only. Use node execute only to test a single node of a workflow you're authoring — it requires --workflow-uuid, --release-uuid, --node, --computed-config and --context (all five). Anything else — enrich a record, call a connector action, invoke a tool or agent — goes through action execute / action execute-batch.
• Prefer built-in actions + expressions when building a node graph. Avoid python, script (JS), and raw HTTP nodes unless necessary: use variables for transforms, the native agent node for LLM calls, the integration's dedicated connector action for APIs, and branch/filter/switch for routing. See ../cargo-orchestration/references/node-selection.md.
• Show a node graph, don't describe it. Before deploying a draft, and whenever the user asks what a workflow or play does: cargo-ai orchestration node diagram --workflow-uuid --raw (free, runs nothing, CLI ≥ 1.0.54; references/node-diagram.md). Routing, fallback edges, and which nodes bill are what's being approved. Let the command draw it rather than transcribing — node slugs repeat within a release, so a hand-drawn diagram keyed on slug merges nodes that aren't the same.
• Filter JSON uses conjonction (not conjunction) — breaks silently if misspelled.
• Query orchestration runtime tables (ClickHouse) with cargo-ai orchestration query execute "" against runs, batches, spans, records (no schema prefix; workspace scoping is automatic).
• For SQL against workspace storage (Companies, Contacts, …), use cargo-ai storage query execute "" — documented in cargo-storage.
• All operations are async — poll or pass --wait-until-finished. See Async polling.

cargo-analytics

Critical rules:

• segment download requires --model-uuid, not --segment-uuid.
• For batch result download, get the output-node-slug from release get → nodes[].slug.
• For billing and credit usage, use cargo-billing instead.
• Analytics answers "what happened" (metrics, counts, exports). When the question is why — a failing run, a batch full of errors, surprising cost — hand off to cargo-diagnostics; its sweep runbook picks up exactly where analytics' error counts leave off.

cargo-billing

Critical rules:

• Requires a token with admin access.
• Invoice amounts are in cents — divide by 100 for dollars.
• subscriptionAvailableCreditsCount - subscriptionCreditsUsedCount from subscription get = remaining credits.

cargo-diagnostics

Critical rules:

• Start with the sweep when you don't know which run to look at; it ends with exemplar UUIDs for the trace.
• runContext is the source of truth for what a node produced; an execution's title is a truncated summary — never evidence.
• Credit attribution (billing …) needs an admin token; the SQL and run get steps don't.
• Any fix that re-runs paid nodes goes through the pilot gate in ../cargo-gtm/references/cost-discipline.md.
• Diagnostics explains; it doesn't export. For bulk retrieval after the diagnosis (run download-outputs, batch download, segment download) go back to cargo-analytics.
• Present conclusions first, evidence as compact tables — per references/interaction.md (in the cargo router skill).

cargo-observability

Critical rules:

• preview before create. alert preview --scope … --threshold … [--window-minutes 60] evaluates now without firing — the only way to size a threshold against reality and to catch an invalid scope/threshold pairing (outcome: "notComputed") before it becomes a schedule that errors every tick.
• Scope and threshold are a matched pair. Telemetry metrics (errorRate, duration+aggregation, credits+aggregation, count) need spans/runs/records; query needs a query scope; recordsCount/recordsShare/freshness/syncDuration need model. Full matrix + units in references/scopes-and-thresholds.md.
• 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.

cargo-storage

Critical rules:

• Query via cargo-ai storage query execute "" (or storage query download --query "" for full exports) using . table names (e.g. default.companies). model get-ddl is optional — useful for column types and SQL dialect.
• For SQL against orchestration runtime tables (runs/batches/spans/records), use cargo-ai orchestration query execute "" — documented in cargo-orchestration.
• For advanced record queries (filtering, sorting, pagination), use segmentation segment fetch — documented in cargo-segmentation.

cargo-segmentation

Critical rules:

• Filter JSON uses conjonction (not conjunction). A misspelling is not an error — the filter silently matches nothing.
• Size before you spend. segment fetch --limit 1 counts an inline filter for free; a saved segment's recordsCount is the authoritative size. Quote it before proposing any paid run over the audience.
• segment download takes --model-uuid plus the filter, never --segment-uuid.
• change list needs --segment-uuid; change fetch needs the change UUID plus --kinds (added/updated/removed/unchanged).
• updatedRecordsCount stays 0 unless the segment was created with --tracking-column-slugs — those columns define what "updated" means.
• Segments named GENERATED_PLAY_SEGMENT (fromPlay: true) are owned by a play. Never edit or remove them b