mirror of
https://github.com/getcargohq/cargo-skills.git
synced 2026-09-14 19:17:15 +08:00
docs/script-require-allowlist
21 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Auree Aubert
|
be823b3fcb |
Generate the cost table, and stop omitting the native actions (#111)
* Generate the cost table, and stop omitting the native actions
The credits price list was hand-kept. The first attempt to generate it read
`connection integration list`, which is connector-only — so its own header
claimed "every credits-based action in the cargo catalog" while silently
omitting every billed native action:
sendEmail 0.1 fixed
modelAsk 0.5 fixed
fileSearch 0.02 / 1k tokens
`sendEmail` is the whole outbound send path, priced at 0.1 in the mailbox
skill, and it was absent from the canonical price list.
It is now generated by `cargo-ai orchestration action cost-table --raw`
(getcargohq/cargo#5641), which lives beside `action list` and `action execute`
— the surface that spans connector, native, tool and agent. 197 credits-based
actions of the 534 the catalog exposes, up from the 145 the hand-kept table
claimed and the 194 a connector-only generator found.
What the hand-kept table got wrong, now that a generated one can be diffed
against it: 145 actions where there are 197, four prices quoted from memory,
and cost columns that concatenated every tier into an unreadable comma list —
`openAi.instruct` rendered 28 numbers. Per-config pricing moves to its own
section.
Two providers gain playbooks rather than staying unlisted: brightData
(Instagram/TikTok/Facebook/YouTube by URL, the catalog's only non-LinkedIn,
non-X social coverage) and proxycurl. An undocumented provider still shows up
in the cost table, so the acceptable-use framing is better stated than implied;
brightData.md opens with the consumer-targeting refusal that gates it. Only
openRouter remains without a playbook, and it has no credits-based actions.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TBfa73ishJJRe4pccyhTAa
* Pin the CLI at 1.0.66, and fix five commands that never existed (#117)
* Pin the CLI at 1.0.66, and fix five commands that never existed
The pin had drifted 19 releases behind npm, and the bundle now teaches
`orchestration action list`, which only exists in 1.0.66. The pin is what the
session-start refresh installs, so leaving it meant an agent following these
skills would reach for a command its CLI did not have.
Checked before moving it, not after: the CLI's whole command surface was diffed
across 1.0.47..1.0.66. The only removals are three billing commands no skill
documents; `update-payment-method`, which the skills do use, replaced one of
them and is still there. Everything else in the range is additive.
That verification then turned up five documented commands that do not exist —
and all five were already broken at the old pin, so this is old debt the bump
surfaced rather than caused:
- `orchestration draft-release {get,update,deploy}` (18 sites) is really
`orchestration release {get-draft,update-draft,deploy-draft}`.
- `ai template get <slug>` (6 sites) does not exist. `ai template list` already
returns each template in full, so the fix is to filter that response.
- `action execute --record` (5 sites) is `--data`.
- `storage model list --dataset-uuid` (4 sites): the command takes no options
at all, and every model carries `datasetUuid`, so filter client-side.
- `storage model get-ddl --model-uuid <uuid>` takes the uuid positionally.
Also folds in the skills half of getcargohq/cargo#5740: `get-output-schema`
takes an action plus an optional `--data` rather than demanding a `config`, so
the object `action list` returns now pastes into all four action commands
unchanged. The gotcha row about the 400 becomes a note about `--data`, which is
the part worth knowing.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TBfa73ishJJRe4pccyhTAa
* Mark --data on get-output-schema as CLI >= 1.0.67
getcargohq/cargo#5740 ships --data in CLI 1.0.67, one above the pin this PR
sets. The config-less --action works on the pinned 1.0.66 as soon as that
backend deploys; --data needs the next release, so it carries a version marker
like every other post-pin flag in the bundle.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Document the execution charge the pack said did not exist (#118)
Every node execution bills 0.01 credits (1 per 100) — structural natives
and errored executions included. Three places in the pack said otherwise,
and they reinforced each other:
- troubleshooting.md described executions[].creditsUsedCount as "native
nodes are zero", accurate about the field but read as pricing;
play-optimize-credits.md restated it and cited it as the authority.
- The generated cost table prices actions, and structural natives are
excluded from `action list` entirely, so branch/filter/switch/variables
appear in no price list here — read as free.
- cargo/SKILL.md said "Everything else is free" outright.
Verified live: `billing usage get-metrics --unit orchestration.executions`
returns success/error as execution counts, reconciling row-for-row with
`SELECT execution_status, count() FROM spans`. spans.execution_credits_used_count
reads 0 on natives that billed, so the charge is attributed to no node and
per-node profiling under-counts every graph.
Two adjacent bugs fixed while verifying:
- `--unit credits` was documented and 400s. The flag takes exactly
billing.credits | orchestration.executions | storage.records, and with
no --unit all three interleave in one items[] array with different
meanings for `count`.
- The example slugs `enrichment` / `ai_message` were invented (real:
integration.<slug>.action.<action>, native.<action>, success/error,
insert), as was `.totalUsage` — the response has one key, `metrics`.
Estimates now carry two terms: (provider cost × records) + (nodes ×
records / 100), measured on the pilot rather than inferred from the graph.
cargo-billing 1.1.0 -> 2.0.0 (agents relearn --unit and the slug shapes),
cargo-orchestration 1.11.0, cargo-gtm 1.19.0, cargo-diagnostics 1.4.0,
cargo 1.24.0 + the three plugin manifests.
Still upstream: `orchestration action cost-table` generates the header
"The other 337 actions ... cost no credits" — unfixable from this repo.
Claude-Session: https://claude.ai/code/session_01AbUvyTQMDABiexZgQCsGoe
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Source the cost table from action list, not a bespoke generator
`orchestration action cost-table` is being removed from the CLI: it read
`action list` twice and added no data, and the markdown it generated was
its only consumer. `action list` already returns a `credits` array on every
billed action, so the table is regenerated from that directly.
Regeneration is now two calls (`--kind connector`, `--kind native`) plus
the three cost shapes documented in the header, so a reader can render the
table without the generator's price-formatting logic. Notably `fixedCost`
adds to the metered rate rather than replacing it — the trap that made a
0.175 + 0.025/item search read as 0.025.
Two fixes that fall out of owning the header again:
- The opening line claimed the other 337 actions "cost no credits". True
of provider price, false of anything that runs in a workflow. It was
flagged as unfixable while the CLI generated it; it now states no
*provider* price and points at the execution charge.
- `stage-action-map.md` still carried 194/310 from the connector-only
generation, against 197/337 everywhere else.
Co-Authored-By: Auree Aubert <16732193+aureeaubert@users.noreply.github.com>
Co-Authored-By: replicas-connector[bot] <replicas-connector[bot]@users.noreply.github.com>
Co-authored-by: Auree Aubert <aureeaubert@users.noreply.github.com>
* Fix PACKAGE_EDITS patterns to match regenerated cost table format
Co-authored-by: Auree Aubert <aureeaubert@users.noreply.github.com>
* Add PACKAGE_EDITS rule to remove extractEventAttendees from stage-action-map.md
Co-authored-by: Auree Aubert <aureeaubert@users.noreply.github.com>
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: replicas-connector[bot] <replicas-connector[bot]@users.noreply.github.com>
Co-authored-by: Auree Aubert <aureeaubert@users.noreply.github.com>
Co-authored-by: Cursor Agent <cursoragent@cursor.com>
|
||
|
Auree Aubert
|
e61f67f105 |
New skill: cargo-mailbox-management, and Cargo sends now (#113)
`mailboxManagement` landed in the CLI (cargo#5493, plus warm-up stats in cargo#5646) and nothing in the bundle covered it. It is the first domain that makes Cargo own the inbox, so the gap was not one more capability skill — it was a skill whose absence let an agent send mail with no idea what it cost or what governed it. - New `cargo-mailbox-management` (the fifteenth capability skill): six command groups, the send that is deliberately not in them, and four references — the ramp arithmetic and fleet sizing, the `sendEmail` action, response shapes, troubleshooting — plus eight worked recipes. - The two facts an agent gets wrong without it. A mailbox is a recurring monthly credit charge (100-160 per mailbox per month), not a per-record one, and `mailbox remove` is the only way to stop it. And volume is a ramp, not a setting: 5/day to 40/day over 45 days from `warmupStartedAt`, pinned at 5/day forever if warm-up never started, reset to day 0 by `stop-warmup`, and `dailySendLimit` can only tighten it. - `cargo-gtm`'s acceptable use said the pack never sends. That paragraph is the substance of the plugin-directory remedy, and mailboxManagement made it false. Section 1 now says what is true, section 6 names the ramp and calls spreading one campaign across extra mailboxes what it is, and section 7 cross-references the new skill. - `cargo-cdk` gained `defineMailbox` and `defineDomain` in the same release and had documented neither. Both are now in the builder table with the create-only, monthly-fee and whole-zone rules that bite. - Known gap, filed rather than papered over: `mailbox create --domain-uuid` is required and no command lists sending domains. Counts move 17 to 18 across the router, README, AGENTS, CONTRIBUTING and the manifests. Seven new routing cases, two of them hard-tier negatives pinning the boundary the word "email" blurs. Core tier 93/93; lint, metadata, llms.txt, trigger slugs, cookbooks and hooks all clean. Claude-Session: https://claude.ai/code/session_01TF1ZRweJqqnPeGbVmUeGkY Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Auree Aubert
|
afb0e67fa5 |
Document relationships and unification, which the CLI has always had (#112)
* Document relationships and unification, which the CLI has always had The relationship section documented three flags that do not exist (`list --model-uuid`, `set --from-model-uuid/--to-model-uuid`). The real surface is `list` with no flags and `set --dataset-uuid --relationships <json array>`. Unification appeared nowhere in the pack at all, despite `model update --unification` shipping since well before 1.0.61. An agent reading this reasonably concluded both were UI-only, because every documented command it tried was rejected on an unknown flag. That conclusion then reached a customer conversation. Two behaviours worth stating outright, since neither is guessable and both are destructive to get wrong: - `relationship set` is a full replace scoped to the dataset. Entries without a `uuid` are created, entries with one are updated, and anything whose `uuid` is missing from the payload is deleted. Sending a single relationship to a dataset holding five removes four. - `--unification` only writes config. Unified rows are rebuilt by the model's sync run, so nothing merges until `storage run create`. Also records the real `relationship list` response (workspace-wide, carrying `fromDatasetUuid`/`toDatasetUuid`/`fromPropertySlug`), adds `unification` to the model shape, and adds routing triggers so "unify these models" and "merge duplicate accounts" land here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JU1NTvKaBEiLDaAAnFW2ho * Trim the router line to the one rule that fails silently "Not UI-only" was a rebuttal to a belief that only existed because the docs were broken, and those are fixed in this branch. What survives is the destructive half: `relationship set` deletes anything absent from the payload. That belongs next to the `conjonction` rule — the router is what's in context when an agent fires a one-off command without loading cargo-storage, which is exactly when it would remove four relationships to add one. The unification recompute stays in cargo-storage only: a silent no-op that a row count catches, not a data loss. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JU1NTvKaBEiLDaAAnFW2ho --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
replicas-connector[bot]
|
010ae38779 |
Playbooks for parallel and exa, and a 20x price error in the stage map (#107)
* Playbooks for parallel and exa, and a 20x price error in the stage map Section 11 claims every credits-based provider in the catalog has a playbook. Nine do not: brightData, builtwith, datachimp, exa, openRouter, parallel, proxycurl, sillage and x. This adds the two that matter most for research and leaves the claim to be squared with the other seven separately. Both are worth having because both beat what the recipes currently reach for. parallel.extract reads a known URL for 0.025, half of firecrawl.scrape. parallel.createTask is the only action in the catalog that fills a caller-supplied output schema, and at processor lite it is 0.125 against linkup.instruct at 1. exa.search is the only rung with a document-type category filter and publication-date bounds, which is what makes it worth 0.175 fixed plus 0.025 an item over a 0.05 flat search. Every action, input and price here was read from the live integration catalog rather than from documentation, per the lesson this pack keeps relearning: a capability claim needs the implementation, not the docs index. That is also how the error surfaced. references/stage-action-map.md priced serper.search at 1. It is 0.05, and provider-playbooks/serper.md had it right throughout, so the map was steering agents away from the cheapest search rung by a factor of twenty. alternatives.md carried the same wrong number for serper.searchPlaces. Both corrected, and the correction is stated in the table rather than made silently. The Web research table is rebuilt around the actual decision: known URL means parallel.extract, plain keyword means serper, document-type or date filter means exa, structured output means parallel.createTask at lite. The createTask ladder gets its own table and a warning. processor is required with no default, and the top rung is 60 credits per record, which is more than a full contact waterfall. Co-Authored-By: Auree Aubert <16732193+aureeaubert@users.noreply.github.com> Co-Authored-By: replicas-connector[bot] <replicas-connector[bot]@users.noreply.github.com> * Ban datachimp in code, and close three of the playbook gaps Two things, both about the same claim: section 11 said every credits-based provider has a playbook, and nine did not. Datachimp is removed everywhere and cannot come back. Aurelien's instruction, 2026-08-15. It appeared in the generated catalog and in two lines of cargo-storage prose. Deleting those would have lasted until the next --refresh, so the removal is enforced in code instead: a DENIED_INTEGRATIONS set filters it out of the catalog on both write and read, and skills-lint fails on the string anywhere in the repo, which is what catches the hand-written half no generator touches. It was also an integration with zero callable actions, so nothing was lost. Three playbooks added, each earning its place on price rather than on coverage. builtwith's getDomainSummary is FREE and answers most stack questions, so the playbook's whole argument is that it runs in front of enrichDomain (1); the current recipes reach straight for a paid rung. sillage's searchLeads is also free and is the only free signal rung in the catalog, which makes it first on any signal question by definition. x is fourteen actions at 0.02, the cheapest signal surface there is, and the playbook spends most of its length on why that is dangerous rather than on how to use it. Three are deliberately not written and the claim now names them instead of overstating. openRouter exposes a model lister and no credits-based actions, so there is nothing to document. proxycurl is excluded on instruction. brightData is excluded because its entire action set is consumer social-platform scraping (Instagram, TikTok, Facebook), which acceptable-use already refuses for person targeting: documenting it as a GTM provider would contradict the gate two files away. Every action, input and price read from the live integration catalog. Co-Authored-By: Auree Aubert <16732193+aureeaubert@users.noreply.github.com> Co-Authored-By: replicas-connector[bot] <replicas-connector[bot]@users.noreply.github.com> * x: a cost table a validator can read, not a grouping a human can The action list was grouped by input shape, which reads well and parses to nothing. Every other playbook here carries `| action | cost | inputs | use for |` and the downstream validator in getcargohq/gtm-skills asserts a skill's quoted price against that column, so a skill calling any x action would have failed with "not in that provider's cost table" and sent someone hunting for a missing price rather than a missing table shape. The four engagement-list actions keep their warning in the Use for column instead of only in the anti-patterns, since that column is what a reader scans. Co-Authored-By: Auree Aubert <16732193+aureeaubert@users.noreply.github.com> Co-Authored-By: replicas-connector[bot] <replicas-connector[bot]@users.noreply.github.com> * Install the whole bundle by default, and stop hand-counting installs skills.sh counts per skill, and one `skills add` sends a single event carrying every skill it installed. So the command in the README decides how many counters a real install moves. `--all` is now the documented form: it is shorthand for `--skill '*' --agent '*' -y` and behaves the same in a terminal, in CI, and inside an agent, where a bare add would drop into an interactive picker. Two stale hand-maintained facts removed rather than corrected, which is the same call this repo made about "sixteen skills" in the CLI help. The install total read "installed 54,885 times". The live figure is 58,245 across the seventeen skills. A number in prose that only moves when somebody remembers to move it will be wrong again next week, and this one is a public claim about traction, which is the worst kind to be casually wrong about. The gtm-skills section listed twelve skills by name. That repo has grown past twelve, so the list now points at its README instead: a hand-maintained copy of someone else's list is a copy that goes stale. Co-Authored-By: Auree Aubert <16732193+aureeaubert@users.noreply.github.com> Co-Authored-By: replicas-connector[bot] <replicas-connector[bot]@users.noreply.github.com> --------- Co-authored-by: replicas-connector[bot] <replicas-connector[bot]@users.noreply.github.com> Co-authored-by: Auree Aubert <16732193+aureeaubert@users.noreply.github.com> |
||
|
Auree Aubert
|
3708f8c955 |
Agent discoverability: trigger-shaped descriptions, routing evals, standalone bootstrap (#77)
* Agent discoverability: trigger-shaped descriptions, routing evals, standalone bootstrap The `description` field is the only text an agent weighs before deciding whether to load a skill. Everything else in the bundle is invisible until that decision is already made — and twelve of the seventeen descriptions read as "Manage <CLI nouns> using the Cargo CLI", which matches a user who is already thinking in Cargo's object model rather than one stating a job. This rebuilds that layer and, for the first time, tests it. Routing - Every description rewritten to a four-part template: job in the user's words -> literal quoted trigger phrases -> proper nouns -> an explicit `Skip when:` pointing at the sibling skill that owns the adjacent case. - Integration and provider names are generated, not hand-maintained. sync-trigger-slugs.ts fills cargo-gtm's `Providers:` list from the playbook tree and cargo-connection's `Integrations:` list from a committed catalog snapshot (138 integrations, 50 credits-based). `--refresh` re-pulls from a logged-in CLI; `--check` gates CI. - evals/routing.jsonl (92 prompts) + routing-eval.ts, wired into CI. Structural tier asserts the template and that each skill keeps >=5 terms unique to it; lexical tier requires the expected skill to rank first; an opt-in --llm tier asks a real model to route from descriptions alone. Deep paraphrases are tagged "hard" and reported rather than gated — a lexical proxy cannot judge them fairly. Standalone installs - `skills add --skill <one>` is a supported path and the registry lists each skill separately, but thirteen skills' only install instructions were a relative link to ../cargo/references/prerequisites.md, which does not exist in a single-skill install. Every SKILL.md now has a self-contained Bootstrap section, enforced by the linter. Coverage - New capability skill cargo-segmentation — the segmentation CLI domain, previously uncovered while segments were load-bearing in most recipes. Verified against the live CLI, including the flag traps. - Three cargo-gtm recipes: source-planning (probe and cost candidate sources per *hit* before any fan-out), ads-audience-activation (Google Customer Match / LinkedIn Matched Audiences), review-and-iterate (human review of judgment output, kept as an eval set). - Router gains a "these skills vs a workspace MCP server" section: Cargo has no first-party MCP server — a workspace builds one and serves it over `cargo-ai mcp` — so the routing rule is scale and reproducibility. Index and hygiene - llms.txt now lists every recipe and provider playbook with a generated summary: 17 entries -> ~80 job-named addressable URLs. - Router trimmed ~80 lines of per-skill summaries that restated each skill's own description; critical rules kept in full. - Linter: bootstrap check, skill-count claims validated against the tree, `doctor` and `mcp` added to the known CLI domains. - CONTRIBUTING.md, keyword-dense README opening, updated repo metadata. Also carries the aiArk/apolloio priority-stack promotion authored in a parallel session on this branch (cargo-gtm 1.12.0) — the two touch the same SKILL.md files and could not be split cleanly. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Surface the 100-credit free tier where an agent meets it There is no purchase gate between installing Cargo and producing a real deliverable — a new account starts with 100 free credits and no card — and nothing in the bundle said so. An agent that doesn't know the budget can't tell a first-time user whether the demo is a look around or a commitment, and defaults to hedging. Now stated at every point an agent encounters the question: - README opening and the generated llms.txt install block: an agent can install, sign the user up, and hand back a list in one turn. - Router install section and prerequisites.md, with anchors for what 100 credits buys (~5,000 sourced leads, ~1,000 verified-email enrichments, ~50 fully enriched contacts). - cargo-quickstart: the demo spends ~0.5 of the 100, and the skill now says so before the first paid call — that reframes the moment from a purchase decision into a look around, which is the job of a quickstart. - cargo-billing: a "what 100 credits buys" table, plus two new trigger phrases so free-tier questions route here at all. - cost-discipline.md: on a new account, receipts and next-step proposals must be framed against the free tier. "87.6 of your 100 free credits left" is a number the user can act on; "87.6 remaining" is not. Also warns that phone lookups (6-7/call) are the fastest way to burn a tier a first session should end with something left to try. Two routing eval cases added for free-tier questions (79/79 core). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Run the routing evals against a real model in CI The lexical tier passes 79/79, but it is a deterministic proxy written alongside the descriptions it grades — it cannot fail in a way that surprises us, which is what makes it weak evidence. The only honest scoreboard for the description rewrite is whether a real model, shown nothing but the 17 descriptions, routes the eval prompts correctly. That tier existed but had never run. Now it does, in its own workflow. - New .github/workflows/routing-evals-llm.yml, using the repo's ANTHROPIC_API_KEY. Deliberately not part of skills-lint: it costs money and is non-deterministic, so it must never stand between a typo fix and a merge. Triggers on PRs and pushes that touch a SKILL.md, the eval cases, or the runner; weekly on a schedule so model drift surfaces even when nobody edits a description; and on demand with a model override. - runLlm reworked for CI: 6-way concurrency (92 sequential calls is a slow job), retry with backoff on 429/5xx, tolerant answer parsing, and a core/hard/overall breakdown instead of one number. - Results are written to GITHUB_STEP_SUMMARY as a table, including every misroute with what the model picked instead — so a regression is readable on the run page without opening logs. - Optional --llm-min=<percent> floor, wired to the exit code. Left unset until the first runs establish a baseline; a floor guessed before the data would either never fire or block on noise. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Act on the first real-model routing run: 92/94, two fixes Baseline from the model tier (claude-haiku-4-5, judging from the 17 descriptions alone): 92/94 overall — core 79/79, hard 13/15. The lexical proxy's 3/15 on the hard tier was noise about the proxy, not the descriptions, which is what that tier existed to establish. Both misroutes were worth having: - "Our outbound is going to the wrong people — help me figure out who actually buys from us" routed to cargo-context instead of cargo-gtm. A real collision: cargo-context's triggers include "who do we sell to", which reads as ICP ownership. It owns *writing the conclusion down*; deriving it from won/lost data is cargo-gtm. Added that boundary to cargo-context's Skip when, and the two phrasings to cargo-gtm. - "Give the assistant access to our sales collateral so it stops making things up" routed to cargo-content instead of cargo-ai — and the model was right. As written the first step is getting the collateral into the workspace. Corrected the expectation and added the other side of the boundary as its own case ("attach the library we already uploaded to the agent"), which the lexical tier then failed, correctly: cargo-ai never said "library" or "release resources". Added both, so the content/ai split is now legible to a ranker and a model. Set --llm-min=93 now that a baseline exists. Deliberately below the observed 98%, not at it: a model tier that fails on one non-deterministic flip trains people to ignore it. Lexical 80/80 core. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Document cargo-ai mcp — the bridge that was written down nowhere Cargo reaches coding agents through two doors. Skills reach agents that implement skills.sh; a workspace MCP server reaches everything else — Claude Desktop, ChatGPT, and whatever ships next. The second door was fully built and documented in exactly one place: `cargo-ai mcp --help`. Worse, cargo-ai/SKILL.md taught `ai mcp-server create` (building a server) without ever mentioning the command that serves it, so an agent could construct one and have no idea how to connect it — and the section conflated publishing a server with consuming someone else's, which are unrelated surfaces. - MCP section rewritten around the two directions, with a table: publish (`ai mcp-server`, called by any MCP client, wired via `cargo-ai mcp`) vs consume (`ai mcp-client`, called by your agents, wired via `release update-draft --mcp-clients`). States plainly that there is no first-party Cargo MCP server — a workspace builds its own. - Documents `cargo-ai mcp` with the registration one-liner, the CARGO_MCP_SERVER_UUID fallback, and the stdout-is-protocol constraint. - Details verified against the live API rather than --help: actions take kind "tool" *or* "agent" (an agent is exposable as a callable MCP tool), resources take model or file, and `update` replaces the arrays wholesale instead of merging — a real footgun. - Routing rule for which door to use, pointing at the router section. - Two trigger phrases ("expose our tools as an MCP server", "use Cargo from Claude Desktop or ChatGPT") and two eval cases, so the publish direction is reachable from a description at all. It previously wasn't. Lexical 81/81 core. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
replicas-connector[bot]
|
e28aabd521 |
Point the skills at browserless login, and unpin agents from a CLI that lacks it (#73)
* Point the skills at browserless login, and unpin agents from a CLI that lacks it cargo-ai 1.0.47 (2026-08-10) added `login --email`: it mails a one-time code, creates the account on first use, and needs no browser at any point. All 16 skills still described sign-in as "browser sign-in via --oauth, or an API token". The load-bearing change is `cargo/cli-version`. The router tells every agent to run `npm install -g @cargo-ai/cli@$(cat cli-version)` at session start, and that pin was 1.0.29 (2026-07-09). Its `login` command exposes only --oauth, --token and --workspace-uuid, so documenting --email without moving the pin would ship a flag the installed binary does not have. - cargo/cli-version: 1.0.29 -> 1.0.47 - 16 compatibility lines rewritten - router + README install blocks lead with --email, and name the agent-shell behaviour (no terminal: first call sends the code and exits, re-run with --code) and the stdin form - patch version bump on each changed SKILL.md so clawhub republishes them Co-Authored-By: Auree Aubert <16732193+aureeaubert@users.noreply.github.com> Co-Authored-By: replicas-connector[bot] <replicas-connector[bot]@users.noreply.github.com> * Regenerate skill-metadata.json for the changed skills The bundle linter tracks a version and a contentHash per skill and failed with 19 stale entries. Regenerated with the documented command, so the diff is only the bumped versions and their matching hashes. Co-Authored-By: Auree Aubert <16732193+aureeaubert@users.noreply.github.com> Co-Authored-By: replicas-connector[bot] <replicas-connector[bot]@users.noreply.github.com> * Mirror the router version bump into the three plugin manifests The linter requires .claude-plugin, .codex-plugin and .cursor-plugin to carry the router's version. 1.17.0 -> 1.17.1. Co-Authored-By: Auree Aubert <16732193+aureeaubert@users.noreply.github.com> Co-Authored-By: replicas-connector[bot] <replicas-connector[bot]@users.noreply.github.com> --------- Co-authored-by: replicas-connector[bot] <replicas-connector[bot]@users.noreply.github.com> Co-authored-by: Auree Aubert <16732193+aureeaubert@users.noreply.github.com> |
||
|
Auree Aubert
|
0ce51d6bcc |
Document ingest (webhook-fed) models in cargo-storage (#69)
The webhook URL an ingest model exposes is built client-side by the app; no
CLI command or API field returns it. Document how to derive the same URL from
values the CLI already exposes, and how to push records to it.
Adds references/examples/ingest-webhook.md covering:
- the URL shape and the three commands that produce it
- the autoIngest guard — extractors where Cargo registers the hook with the
provider itself, and the URL must not be handed out
- the request body: flat object or array of flat objects, insert-only, 100 max
- creating an ingest model (connector -> its dataset -> model)
Verified end to end against a throwaway http/listenHook model: the derived URL
returns 200 for a single object, an array, and an Authorization header instead
of the token query param, and the rows land in storage. Sending the
{kind, records} envelope stores it literally as one row, so the doc calls that
out; update/remove are not reachable through the webhook.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
Auree Aubert
|
a92d53541a |
feat(storage): add "show the rows, not the schema" preview convention (#60)
Add a pack-wide interaction convention (cargo router §4 + cargo-storage) telling the agent to preview ~10 real rows once data lands, echo the schema (not an empty query) right after model/column creation, and treat an unexpectedly empty/null preview as a finding. Bump bundle to 1.14.1 across router + all three plugin manifests and regenerate skill metadata. Co-authored-by: Cursor <cursoragent@cursor.com> |
||
|
Auree Aubert
|
286aaaf981 |
feat: prompt library + generated skill metadata (#55)
Rebased onto main (post #53/#54 squash): 38 named parameterized LLM prompts in six sharded files with a grep-first index (temperature guidance scoped to the bulk tier; judgment-tier models that reject non-default sampling get no override), plus a generated skill-metadata.json per skill — typed doc catalog + deterministic content hash (code-unit ordering, locale-independent), produced by .github/scripts/skills-metadata.mjs (--write) and verified by skills-lint.mjs so stale metadata fails CI. Metadata regenerated over main's tree, which is why lint was failing before: the catalogs predated main's email_status recipe fix. cargo-gtm -> 1.4.0. Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
Auree Aubert
|
c7bec7d8c4 |
Share prerequisites, lint SKILL.md, deep-link the router (#33)
- Extract the duplicated install/login/output-conventions block from every capability skill into cargo/references/prerequisites.md. Each capability skill now links to it instead of redefining ~16 lines of boilerplate. - Add CHANGELOG.md so per-skill version bumps are tracked alongside the reason for each bump, and capture the current version snapshot as the historical baseline. - Add a CI skill-lint job (.github/workflows/skills-lint.yml + .github/scripts/skills-lint.mjs) that validates SKILL.md frontmatter shape, internal markdown links, fenced JSON snippets, and that bash examples reference real cargo-ai domains. Catches drift before users do. - Reorder cargo-connection so the integration/connector key concepts sit above Prerequisites (where they're needed before reading commands), and tighten the integration get vs native-integration get table with ✓/✗ markers to make mis-routing harder. - Deep-link the skill graph in cargo/SKILL.md so each row in the capability table jumps straight to the target SKILL.md, with the in-page recap available as a secondary link. - Bump versions on each touched skill. Co-authored-by: Claude <noreply@anthropic.com> |
||
|
Auree Aubert
|
5f0add1460 |
Pin @cargo-ai/cli to latest and add Claude Code session hook (#29)
* Add SessionStart hook and document staying current Adds a Claude Code SessionStart hook that auto-updates @cargo-ai/cli and the cargo-skills bundle at the start of every remote session, pins @latest in every openclaw install block, and adds a "Staying current" section to the README covering Claude Code, OpenClaw, and skills.sh agents. Ignores .claude/skills/ since the hook materializes it on each run. * Promote refresh-to-latest to first step in router SKILL.md Moves the update commands from a buried "if the user asks" conditional to a top-of-skill default that any agent loading the cargo router sees first. Fixes the broken `skills add ...@latest` syntax (the skills CLI parses @latest as a skill name filter and fails). Slims the lower section to cover only mid-session re-refresh triggers. * Remove Claude-Code-specific hook from repo root The SKILL.md "First step every session" guidance now covers refresh cross-agent via prompt-level instruction, so the .claude/ hook only served maintainers of this repo (not end users — skills add never propagated it). Removing it keeps cargo-skills agent-neutral. Users who want enforced (not prompt-level) refresh in Claude Code get the full hook + settings.json recipe inlined in the README's "Staying current > Claude Code" subsection. * Instruct Claude Code agents to offer scaffolding the SessionStart hook Adds a tightly-gated prompt-level instruction in cargo/SKILL.md: in Claude Code sessions where no SessionStart hook exists yet, the agent offers once to scaffold the auto-refresh hook using the recipe from the README. No-op for Cursor/Windsurf/OpenClaw/etc. * Drop bogus "report reply" mid-session refresh trigger The CLI exposes report create but no way to read replies, so the "workspaceManagement report reply confirms the issue is fixed" bullet described a feedback loop that doesn't exist. Removed — the remaining two triggers (shape mismatch, explicit user ask) are concrete. --------- Co-authored-by: Claude <noreply@anthropic.com> |
||
|
Auree Aubert
|
f607681791 |
Restructure skill metadata for OpenClaw compatibility (#25)
* Make cargo skills installable on OpenClaw via ClawHub Promote `version` to top-level frontmatter and add `metadata.openclaw` (requires.bins + install spec for @cargo-ai/cli) to every SKILL.md so the bundle resolves through ClawHub without a separate manifest. Adds a README install snippet for the `clawhub install` command. * Add GitHub Actions workflow to publish skills to ClawHub on release Triggers on `release: published` (and supports manual workflow_dispatch with optional dry_run). Iterates the ten skill directories, reads `version:` from each SKILL.md, and calls `clawhub skill publish` with the release notes as the changelog. Treats "version already published" as a skip so unchanged skills don't fail the run, and surfaces any other publish error. Auth uses the `CLAWHUB_AUTH` env var (avoids writing the token to disk) sourced from a `CLAWHUB_TOKEN` repo secret. README documents the one-time secret setup. * Fix ClawHub publish workflow against the real CLI surface The previous workflow was built from hallucinated WebFetch summaries. After reading openclaw/clawhub's docs/cli.md and docs/auth.md directly: - Auth uses `clawhub login --token <token>`, not a `CLAWHUB_AUTH` env var, so the workflow now runs a login step. Tokens are generated from the clawhub.ai web UI after GitHub sign-in (the previous `clawhub.openclaw.ai/settings/tokens` URL doesn't resolve). - `clawhub skill publish` only accepts `--version`, `--owner`, `--migrate-owner`, and `--clawscan-note`. The previous workflow's `--slug`, `--name`, and `--changelog` flags don't exist; slug is derived from folder name. Workflow now passes only `--version` plus `--owner getcargohq` so the bundle lives under the org publisher. - ClawHub requires semver three-part versions; bumped each SKILL.md `version:` from `1.0`/`1.1`/`1.4` to the matching `x.y.0` form so the CLI's semver check passes. - README updated with the corrected token URL (clawhub.ai) and a reminder to run `clawhub publisher create getcargohq` once before publishing under the org. * Drop redundant `license: MIT` from each SKILL.md frontmatter ClawHub publishes every skill under MIT-0 and its skill-format spec says: "Do not add conflicting license terms in SKILL.md; ClawHub does not support per-skill license overrides." The repo LICENSE at the root still applies to the source files; the per-skill frontmatter only needs to drop the field so the published bundle doesn't trip the metadata-conflict check. --------- Co-authored-by: Claude <noreply@anthropic.com> |
||
|
Claude
|
383f2d095c |
Move storage query docs from cargo-orchestration to cargo-storage
storage query execute / storage query download belong in the cargo-storage skill. cargo-orchestration now covers only orchestration query (ClickHouse: runs, batches, spans, records); the storage query SKILL section, queries reference, response shapes, and troubleshooting move to cargo-storage with cross-references in both directions. |
||
|
Claude
|
4c890af8ab | Refer to storage instead of data warehouse | ||
|
Claude
|
32a5674754 | docs(cargo-storage): drop warehouse-rewriting detail and 'system of record' phrasing | ||
|
Claude
|
61c462345d |
Merge remote-tracking branch 'origin/main' into claude/update-skills-storage-query-A2Zih
# Conflicts: # cargo-gtm/recipes/icp-discovery.md # index.md |
||
|
Claude
|
681cb9ab24 | docs(cargo-storage): drop all system-of-record references | ||
|
Claude
|
0b5769db73 |
docs: drop stale system-of-record client fetch references
`system-of-record client fetch` is no longer recommended for pagination. For paged result sets, use `LIMIT` / `OFFSET` directly inside `storage query execute` SQL — always with an `ORDER BY` for stable pages. Removes the misleading `--limit`/`--offset` example, narrows remaining legacy mentions to `system-of-record client download` (full exports) and `get-documentation` (SoR docs), which still require the warehouse-native table name from the DDL. |
||
|
Claude
|
2904c37dcc |
docs: switch SoR query examples from system-of-record client query to storage query execute
The legacy `cargo-ai system-of-record client query "<sql>"` command is
replaced with `cargo-ai storage query execute "<sql>"` for direct SQL
against the warehouse. The new command:
- references tables as `<datasetSlug>.<modelSlug>` (rewritten to the
underlying warehouse table under the hood) — no DDL lookup is needed
for the table name
- returns `{ rows: [...] }` on success; non-zero exit with
`{ errorMessage }` or `{ reason }` on error (no more `outcome` field)
Updates across cargo-orchestration, cargo-storage, cargo-gtm, GLOSSARY,
and index.md so skill examples, response shapes, and troubleshooting
guides reflect the new command. The legacy
`system-of-record client fetch | download | get-documentation`
commands are preserved for paginated reads, full exports, and SoR
documentation; those still use the warehouse-native table name from
the DDL.
|
||
|
Claude
|
4b6e37c5a9 |
docs(auth): recommend cargo-ai login --oauth, keep --token as alternative
The CLI now supports an OAuth 2.0 Device Authorization Flow via `cargo-ai login --oauth` (browser sign-in). Update every Prerequisites block, README, index, and troubleshooting table to surface --oauth as the recommended path, with --token retained for non-interactive use. |
||
|
Claude
|
0ca33f497f |
refactor: rename cargo-cli-* skills to cargo-*
Drop the redundant `-cli-` infix from the seven skill directory names and update all cross-references in the markdown docs to match. |