What makes cargo-diagnostics notable?

1.2K downloads. Trust evidence available

How should cargo-diagnostics be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

cargo-diagnostics

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.

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

1.2k

Updated

Oct 11, 2026

Version

1.4.0

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 1.2K downloads reported by the source. Last updated 10/11/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 11, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 11, 2026
Adoption signal: 1.2K downloadsadoption · observed Oct 11, 2026
Latest release: 1.4.0release · observed Sep 1, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s178dcd9wkfn0a2fqrygmt3jzn87j9e1:cargo-diagnostics

Install using `clawhub skill install s178dcd9wkfn0a2fqrygmt3jzn87j9e1:cargo-diagnostics` in an isolated environment before connecting it to live workloads.
No published capability contract is available yet, so validate auth and request/response behavior manually.
Review the upstream CLAWHUB listing at https://clawhub.ai/cargo-ai/cargo-diagnostics before using production credentials.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-cargo-ai-cargo-diagnostics/snapshot"

Documentation

CLAWHUB

146,686 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: cargo-diagnostics
description: "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."
version: "1.4.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 CLI — Diagnostics

Forensic runbooks for workflow behavior: trace one run, sweep a batch for errors, profile a play's credit spend. This skill is the **interpretation layer** — the raw surfaces (`run get`, orchestration SQL, billing metrics) are documented in `cargo-orchestration` and `cargo-billing`; each runbook here tells you which of them to pull, in what order, and what each output shape means.

## 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 [email protected]  # 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
```

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`. Credit attribution steps (`billing usage get-metrics`, `billing subscription get`) need a token with **admin access**; everything else works with a standard token. 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.

## Which runbook?

```
What are you diagnosing?
│
├── One run / one record ("why did this record fail?",
│   "run succeeded but the output is wrong/empty")
│   └── references/run-trace.md
│
├── Many runs ("the batch has errors", "error ra

_meta.json

{
  "ownerId": "kn7by8t6yt9yghbxtxz6hv0bts87k6bq",
  "slug": "cargo-diagnostics",
  "version": "1.4.0",
  "publishedAt": 1788305375039
}

references/batch-error-sweep.md

# Batch error sweep — group failures by root cause

Use this when many runs are involved and you don't yet know where to look: a batch reports errors, a play's error rate spiked, or "some records didn't come through". The output of a sweep is a **small table of failure groups with an exemplar run UUID each** — not a list of every failed run.

> SQL syntax, table columns, and query caps: [`../../cargo-orchestration/references/examples/queries.md`](../../cargo-orchestration/references/examples/queries.md). All queries below are read-only and workspace-scoped automatically.

## 1. Size the problem

```bash
# For one batch
cargo-ai orchestration query execute \
  "SELECT status, count() FROM runs WHERE batch_uuid = '<batch-uuid>' GROUP BY status"

# For a play/workflow over time
cargo-ai orchestration query execute \
  "SELECT countIf(status='error') / count() AS error_rate, count() AS total
   FROM runs
   WHERE workflow_uuid = '<workflow-uuid>' AND created_at > now() - INTERVAL 7 DAY"
```

Calibration: error rates under ~5% on connector-heavy workflows are often provider coverage, not defects (see the over-provision rule in [`cost-discipline.md`](../../cargo-gtm/references/cost-discipline.md)). A spike above that, or errors on native nodes, is worth the sweep.

## 2. Find where failures concentrate

```bash
# Which node fails most
cargo-ai orchestration query execute \
  "SELECT node_slug, count() AS failures
   FROM spans
   WHERE execution_status='error' AND execution_started_at > now() - INTERVAL 1 DAY
   GROUP BY node_slug
   ORDER BY failures DESC"
```

Scope with `batch_uuid`/`workflow_uuid` predicates when you have them. Two shapes to distinguish:

- **Concentrated** (one node owns most failures) → a config, credential, or expression defect at that node. Proceed to step 3 with that node.
- **Spread across connector nodes, clustered in time** → third-party rate limiting. Confirm with the "signs you are being rate-limited" checklist in [`troubleshooting.md`](../../cargo-orchestration/references/troubleshooting.md); the fix is retry config + smaller sub-batches, not per-run debugging.

## 3. Pick exemplars and read the actual errors

```bash
cargo-ai orchestration query execute \
  "SELECT uuid, created_at
   FROM runs
   WHERE batch_uuid = '<batch-uuid>' AND status='error'
   ORDER BY created_at ASC
   LIMIT 3"
```

Take 2–3 exemplars per failure group and trace each with [`run-trace.md`](run-trace.md) — the error detail lives in `run get`'s `runContext`, not in the SQL tables. Failures with the same node + same error pattern are one group; resist tracing every run.

## 4. Decide: fix, re-run, or report

| Root cause shape | Action |
| --- | --- |
| Expression/branch defect (same wrong output every time) | Fix the node, re-test on exemplar record IDs, then re-run only the failed records: `run download --statuses error` → fix → `batch create --data '{"kind":"recordIds",...}'` (sequence in [`troubleshooting.md`](../../cargo-orchestration/referen

references/play-optimize-credits.md

# Play cost profile — where credits go, and how to cut them

Use this when a play costs more than expected or the user asks to reduce spend. The procedure is: attribute (which workflow → which node → which provider), then apply levers in priority order. Never propose a lever before the attribution — "use a cheaper model" is noise if 90% of the spend is a phone-lookup connector.

Credit attribution needs an **admin** token (`billing` commands); the SQL steps work with any token.

## 1. Attribute spend to workflows

```bash
# Credit spend by workflow this month (SQL — fast, no admin needed)
cargo-ai orchestration query execute \
  "SELECT workflow_uuid, sum(credits_used_count) AS credits
   FROM batches
   WHERE created_at >= toStartOfMonth(now())
   GROUP BY workflow_uuid
   ORDER BY credits DESC"

# Billing source of truth, groupable by other dimensions too
cargo-ai billing usage get-metrics --from <YYYY-MM-DD> --to <YYYY-MM-DD> --group-by workflow_uuid
cargo-ai billing usage get-metrics --from <YYYY-MM-DD> --to <YYYY-MM-DD> --group-by integration_slug
```

Map UUIDs to names with `cargo-ai orchestration play list` / `tool list`. When SQL and billing disagree, billing wins.

## 2. Attribute spend to nodes inside the top workflow

Per-node cost lives on the run detail: each `run.executions[]` item carries `creditsUsedCount` — the **provider** cost, non-zero on agent and connector nodes, zero on native ones (see [`troubleshooting.md`](../../cargo-orchestration/references/troubleshooting.md)). Pull 2–3 recent representative runs and average:

```bash
cargo-ai orchestration query execute \
  "SELECT uuid FROM runs
   WHERE workflow_uuid = '<workflow-uuid>' AND status = 'success'
   ORDER BY created_at DESC LIMIT 3"

cargo-ai orchestration run get <run-uuid>   # read executions[].creditsUsedCount per nodeSlug
```

Also check **waste**: credits spent on runs that errored anyway —

```bash
cargo-ai orchestration query execute \
  "SELECT status, sum(credits_used_count) AS credits, count() AS runs
   FROM runs
   WHERE workflow_uuid = '<workflow-uuid>' AND created_at > now() - INTERVAL 30 DAY
   GROUP BY status"
```

A meaningful `error`-row credit sum means expensive nodes run **before** the failure point — reordering is a free win.

## 2b. Add the execution charge — it is in none of the above

`creditsUsedCount` is provider cost only. **Every node execution also bills 0.01 credits (1 per 100)**, structural natives included, and that charge is attributed to no node — so steps 1 and 2 systematically under-count, by an amount that scales with graph size rather than with spend. Attribute it separately, or a step-heavy play looks cheap right up until the invoice:

```bash
# Executions for the period, workspace-wide (admin) — credits = (success + error) / 100
cargo-ai billing usage get-metrics --from <YYYY-MM-DD> --to <YYYY-MM-DD> --unit orchestration.executions

# Per workflow, from the runtime tables (no admin needed) — agrees row-for-row
cargo-ai orchestr

references/run-trace.md

# Run trace — explain one run end-to-end

Use this when you have (or can find) a single run UUID and need to answer "what actually happened to this record?" — a hard failure, or the more common case: `status: "success"` with wrong or empty output.

> Field-by-field semantics for everything used here live in [`../../cargo-orchestration/references/troubleshooting.md`](../../cargo-orchestration/references/troubleshooting.md) ("Debugging a workflow run"). This runbook is the ordered procedure.

## 0. Find the run

Every step below needs a run UUID. Work down this ladder and stop at the first rung that matches what the user actually gave you — most of the time it's a symptom and a company name, not a UUID.

> **`run list` cannot answer "the last run".** `cargo-ai orchestration run list` **requires** `--workflow-uuid`; there is no unfiltered form, and a play's UUID is not a workflow UUID. Orchestration SQL has no such requirement, so it — not `run list` — is the entry point whenever you don't already know the workflow. Concluding "the run data isn't accessible" because `run list` refused is a wrong answer: `runs` is queryable with no filter at all.

**"Look at the last run" / "what just ran"** — no UUID, no workflow, nothing:

```bash
cargo-ai orchestration query execute \
  "SELECT uuid, workflow_uuid, record_title, status, created_at
   FROM runs
   ORDER BY created_at DESC
   LIMIT 10"
```

**A company, domain, or record the user names** ("the run for acme.com") — `record_title` carries the record's title, or for record-less runs the input payload, so a substring match finds it:

```bash
cargo-ai orchestration query execute \
  "SELECT uuid, workflow_uuid, record_title, status, created_at
   FROM runs
   WHERE record_title ILIKE '%acme.com%'
   ORDER BY created_at DESC
   LIMIT 10"
```

**A play or workflow by name** — resolve to a `workflowUuid` first, then filter. `runs` has no play column, so this hop is mandatory:

```bash
cargo-ai orchestration play list        # → find the play, take play.workflowUuid

cargo-ai orchestration query execute \
  "SELECT uuid, status, created_at, credits_used_count
   FROM runs
   WHERE workflow_uuid = '<play.workflowUuid>'
   ORDER BY created_at DESC
   LIMIT 20"
```

Play anatomy and the rest of the play surface: [`../../cargo-orchestration/references/examples/plays.md`](../../cargo-orchestration/references/examples/plays.md).

**Coming from a batch sweep** — you already have exemplar UUIDs; skip ahead.

### When the discovery query itself errors

| Error | Cause and fix |
| --- | --- |
| `Limit for number of columns to read exceeded. Requested: 51, maximum: 50.` | You ran `SELECT *`. `runs` is wider than the 50-column read cap — name the columns you need, as every query above does. |
| `Unknown expression identifier '<col>'` | That column doesn't exist. `runs` has no `play_uuid`, no `name`, and no trigger-source column; the ones used here (`uuid`, `workflow_uuid`, `release_uuid`, `batch_uuid`, `record_id`, `rec

Github ReposUpdated 1d agoRank 70

AionUi

Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.