mirror of
https://github.com/getcargohq/cargo-skills.git
synced 2026-09-14 19:17:15 +08:00
docs/script-require-allowlist
39 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 replicas-connector[bot]
|
5680754126 |
Add cargo-mcp, and correct the router on the hosted MCP server (#116)
mcp.getcargo.io/mcp is live and serves thirteen platform tools plus whatever a workspace published with defineMcpServer. Nothing in the bundle covered it, and cargo/SKILL.md asserted "There is no first-party 'Cargo MCP server'" - true when written, wrong now, and the one claim an agent would act on. - cargo-mcp/SKILL.md (1.0.0): connect, the discover to price to execute to poll spine, and the routing table for MCP tool vs cargo-ai. - cargo/SKILL.md (1.22.0): the MCP section becomes a three-way disambiguation. Hosted server, workspace server served over stdio by cargo-ai mcp, and an MCP client attached to a Cargo agent are three things sharing a name and sharing no answers. - evals/routing.jsonl: "How do I use Cargo from ChatGPT?" now expects cargo-mcp; three cases added for the new surface. - Counts, catalogs, plugin manifests, SKILL_DIRS, llms.txt, metadata. skills-lint, routing-eval, sync-trigger-slugs and the cargo-gtm script fixtures all pass. Co-authored-by: Cargo FSD <fsd@getcargo.io> Co-authored-by: Auree Aubert <16732193+aureeaubert@users.noreply.github.com> Co-authored-by: replicas-connector[bot] <replicas-connector[bot]@users.noreply.github.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> |
||
|
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
|
7f5582595a |
cargo-gtm 1.14.0: design custom datapoints, don't just fill them (#99)
* cargo-gtm 1.14.0: design custom datapoints, don't just fill them Every recipe in the pack assumed the field was already named: source-planning sources one field you asked for, icp-discovery needs closed deals to mine. Nothing covered the blank page — "what should we even be collecting?" — which is where the GTM conversation starts, and which a model will answer with ten plausible attributes, four of which have no obtainable source at any price. New recipes/custom-datapoints.md: research the seller from fetched pages rather than model recall, draft candidates against the discriminator test, gate each one on a real catalog action + credit cost + probed hit rate, present a costed shortlist with the cut list and the full fan-out arithmetic, then wire the survivors into columns, scoring, a segment, and a refresh cadence. The gate is the point — a candidate with no action slug is a research note, and saying so beats padding to ten. Attribute vs signal, mechanically: in Cargo a live signal is a tracked column diff, so the recipe ends by putting the signal-bearing attributes into --tracking-column-slugs at segment creation and reading the delta feed — the step whose omission leaves updatedRecordsCount at 0 forever. Two prompts in the data-extraction shard: custom-attribute-extraction (one defined attribute from page text, with a confidence band and a verbatim evidence quote — Unknown is a first-class answer, because an unsupported value in a scoring column is a decision made on noise) and technology-adoption-state (mixed evidence to individual_usage … company_standard, with a hard rule that one job posting never establishes company-wide adoption). First-party fields — product usage, activation, billing, visitor sessions — are called out as structurally unavailable for net-new accounts and routed to account-expansion instead of quietly ranking customers above prospects. Routed from the router table, the cargo-gtm recipe table, the README and llms.txt; cargo 1.19.1 and the three plugin manifests follow. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Fix Bugbot findings on the custom-datapoints recipe Four issues, all verified against the pack's own docs rather than taken at face value. - **`linkup.instruct` payload was invalid.** Step 2 passed `prompt` and no `depth`. Per `provider-playbooks/linkup.md`, `instruct` takes `q` plus a required `depth`, and a sourced answer needs `outputType: "sourcedAnswer"`. As written the seller-research call — the step the recipe says determines everything after it — fails. - **`change fetch --change-uuid` does not exist.** The flag is `--uuid` (the change UUID from `change list`), as `cargo-segmentation` documents in three places. The delta read 400s as written. - **The signal-watch filter matched every record.** `conditions` sat beside an empty `groups`, and `{"conjonction":"and","groups":[]}` is the match-everything filter — so tracking and refresh spend would have run over the whole model instead of the ICP. Conditions now nest inside a group, in the `{kind, columnSlug, operator, values}` shape the sibling recipes use. - **The `estimated` confidence band was unreachable.** The prompt listed it, then told the model to return `unknown` for anything below the `inferred` bar — dropping exactly the calculated values Step 7 tells agents to store with a companion confidence column. `confirmed`, `inferred`, and `estimated` are now all reportable, with `estimated` scoped to arithmetic on figures actually in the text. Also rebased onto main, which shipped router 1.19.1 in #97, so this moves to **1.19.2** across `cargo/SKILL.md` and the three plugin manifests. skills-lint 0/0 · skills-metadata --write clean · sync-trigger-slugs --check up to date · routing-eval 81/81 core, all gating evals pass. Co-Authored-By: Auree Aubert <16732193+aureeaubert@users.noreply.github.com> Co-Authored-By: replicas-connector[bot] <replicas-connector[bot]@users.noreply.github.com> * Fix second Bugbot round: ID prereqs, billing shape, shortlist math, snitcher Four more findings on the recipe's pre-existing content. All four hold up against the provider playbooks. - **`salesNavigator.find*` ID prerequisite was missing.** All four `find*` actions key on a LinkedIn `companyId`, not a domain (playbook, Inputs column). The recipe carefully amortized `cargo.matchBusiness` and said nothing about the equivalent fee here, so probes fail on domain-only lists and every shortlist under-quotes. Now a named cost mechanic alongside `matchBusiness`, at 0.05/account via `searchAccounts`. - **"`salesNavigator.*` bills per returned row" was wrong for the actions this recipe leads with.** Per-row billing is the search/extract family; `findEmployeesDistribution` and `findCompanyMetrics` are flat 0.25 per account. Split the two families explicitly. - **The Step 6 approval example did not reconcile.** It quoted ~7,400 credits, then claimed dropping two 1-credit attributes over 4,100 accounts saved ~4,200. The table also stopped at row 4 with an ellipsis, so the total could not be checked against it. All six rows plus both ID prereqs are now explicit and every figure is derived: 3.55/account → ~14,600 full, ~4,300 cheaper cut, ~3,200 narrow cut. The cut now makes the point the old numbers obscured — dropping both cargo enrichments also drops the 0.50 match, so the saving is 2.50/account, not 2.00. Step 8's refresh figure is rederived from the same table (~5,100/month for the monthly-cadence fields). - **Snitcher was filed as unavailable for net-new.** Visitor ID surfaces companies browsing the seller's site — mostly cold. The pack's own playbook calls them "the warmest cold segment there is" and files them in the SIGNAL stage, routed to outreach-activation, not expansion. It belongs in a net-new schema; what disqualifies it from the sourced shortlist is that it is arrival-driven, not that the prospect never logged in. Reframed on that axis, with the `fetchOrganisations` 3/company recurring cost called out. Arithmetic verified numerically, not by eye. skills-lint 0/0 · routing-eval 81/81 core · llms.txt regenerates clean. Co-Authored-By: Auree Aubert <16732193+aureeaubert@users.noreply.github.com> Co-Authored-By: replicas-connector[bot] <replicas-connector[bot]@users.noreply.github.com> * Fix row-billed pricing for theirStack across the gate and the shortlist Bugbot's third round, one finding, and it lands on an inconsistency the previous commit introduced: that commit sharpened "search-shaped actions bill per returned row" while leaving the hiring-intent row priced at a flat 0.5/account. `cost-discipline.md` uses this exact case as its worked example of an estimate missing by 2x ("theirStack billed per returned job posting, and 12 companies had >5 postings each"), so the recipe was demonstrating the failure its own reference warns about. - **Gate table** now prices both theirStack rows as `unit x rows`, with `limit` named as the cap. `searchTechnologies` had the same defect — cost-discipline §4 is explicit that search actions bill on returned rows, not matched totals, so it is not specific to `searchJobs`. - **Step 5** measures rows-per-account as a recorded output, median *and* max, since the max is what `limit` has to cap. Without that multiplier a per-row price gets copied into the shortlist as if it were per-account, which is the whole mechanism of this bug. - **Step 6** prices #5 as 0.5 x `limit: 3` = 1.50, states the probe's median (3) and max (9), and notes that uncapped the top decile costs 4.50. Every downstream figure rederived: 4.55/account, ~18,700 full, ~8,400 cheaper cut, ~4,100 narrow, ~16,400 all-six monthly. - **Step 8** adds the annual arithmetic on the fastest field, which is where row billing actually hurts: #5 weekly over the full list is ~6,200/week and ~320,000/year, more than the first fill of everything else combined. The fix is a narrower audience, not a lower price. - **Probe budget** moved 10-40 -> 30-80; the Step 6 schema alone probes at ~46, so the old range was unreachable. - Noted the provider inversion this exposes: theirStack at 0.5/row only undercuts cargo's flat-1 technographics while an account returns one row. Compare per-account totals, not unit prices — which is also why Step 6 picks the flat action for #4. All 16 figures verified numerically against the table. skills-lint 0/0 · routing-eval 81/81 core. Co-Authored-By: Auree Aubert <16732193+aureeaubert@users.noreply.github.com> Co-Authored-By: replicas-connector[bot] <replicas-connector[bot]@users.noreply.github.com> * Rebase onto main (#101) and true up the changelog entry `main` picked up #101 (the Clay migration recipe). Conflicts were all in generated files — `llms.txt` and two `skill-metadata.json` — resolved by re-running the generators rather than hand-merging, then verified: both recipes appear exactly once, 92 metadata entries, zero duplicates, and a regenerate-after produces no diff. Two corrections to the changelog entry while here: - **The snitcher bullet still described the pre-fix behavior**, calling visitor sessions structurally unavailable for net-new and routing them to expansion — the exact claim the round-2 review corrected in the recipe. The entry now says what the recipe says. - **Added the costing bullet**, since per-account vs per-row pricing and the two ID prerequisites are now a substantive part of what the recipe teaches and were not mentioned at all. Also noted that this bump publishes #101's recipe: that PR added `clay-to-cargo.md` without moving `cargo-gtm` off 1.13.0, so 1.14.0 is the release that ships it. Drop that line if a separate bump is planned. Router stays at 1.19.2 — #101 did not touch it. All 15 figures in the recipe re-verified numerically post-rebase. skills-lint 0/0 · routing-eval 81/81 core · sync-trigger-slugs up to date. 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: 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 <16732193+aureeaubert@users.noreply.github.com> |
||
|
replicas-connector[bot]
|
1fb253e0a9 |
Migrate the configuration, not the CSV: a Clay recipe (#101)
`import-gtm-data.md` closes by saying it deliberately carries no per-tool mappings, because source tools change their internals and CSV export is universal. That reasoning holds for every source except the one this product is most often replacing, and the universal advice actively costs accuracy there: a CSV export destroys the per-row cost, the waterfall order and the run conditions, which are exactly what a rebuild depends on. The exception is argued in both files rather than left to be discovered as a contradiction. The recipe leads with extraction because that decides everything after it. A Clay CSV says a column was filled; it does not say which provider filled it, in what order, or under which condition, and none of that is recoverable from the results. Three paths in descending fidelity, and a run on the weakest one has to say so out loud. Then: the column-family map across sourcing, contact data, company data and the non-enrichment columns; the four Clay concepts that do not map one to one (waterfalls, run conditions, auto-update, partial runs), each invisible in an export; and a parity check whose sample deliberately includes rows Clay FAILED to fill, since a sample of Clay's wins measures nothing. Two claims that stop this reading as a sales document. On an email disagreement, the verified value wins rather than the source. And a Clay credit is never compared to a Cargo credit: they are different units, so the comparison is what one sample cost end to end on each side. All twenty action slugs and prices check against the provider playbooks. The maintenance rule is the pack's: the playbook wins, and an unmapped Clay column is reported as unmapped rather than guessed at. 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
|
84a9a94f4f |
Name the pack Cargo Skills in the README title (#89)
We were shipping three names: "Cargo" in every plugin manifest and marketplace.json, "Cargo Skills" in the CLI's npm README, and "Cargo Agent Skills" here. Three names build recall for none. Settling on two, deliberately: "Cargo" in-product, where the install is `cargo@cargo` and context disambiguates, and "Cargo Skills" everywhere external. The external name matches the repo slug that renders beside it in every listing, and it avoids the collision a bare "Cargo" has with Rust's package manager -- searching a 2,281-plugin registry for "cargo" returns only Rust tooling. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Auree Aubert
|
68d854b2b1 |
Document Hermes Agent support and group the skills for repo pages (#87)
Hermes reads the same SKILL.md standard and already installs these skills unchanged -- verified: `npx skills add getcargohq/cargo-skills --agent hermes-agent` copies all 17 into .hermes/skills/ with zero broken cross-references. Nothing in the repo said so. - README: a Hermes section with the three working install paths, the tap caveat (our skills sit at the repo root, not under skills/), and what does not carry over -- Hermes pre_tool_call hooks can only block a call, never pre-approve one, so the plugin's approval hook has no equivalent there. - skills.sh.json: groupings per the skills.sh schema. Sections the repo page on skills.sh, and Hermes reads the same file for Skills Hub categorization instead of guessing from tags. All 17 skills grouped exactly once. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Auree Aubert
|
f9238b4ec6 |
Add version, license, and skills.sh badges to the README (#86)
Also state the skills.sh install total in the manual-install section — it is the strongest adoption signal the project has and it appeared nowhere on the repo. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Auree Aubert
|
8afa8ecd95 |
Close the ClawHub security-audit documentation gaps (cargo 1.18.2) (#84)
* Close the ClawHub security-audit documentation gaps (cargo 1.18.2) The automated audit of the published bundle returned Review with five findings. Three were real documentation gaps — places where the bundle assumed the reader had the whole thing in context. No behavior changes. - use-cases.md §6 opened on `token create` as a bare numbered step. The "shown once → secrets manager" rule lived in ~10 other files but not this one, so an agent loading only the use-cases reference never saw it. Added token handling, least-privilege scoping, and a confirm-first note on the steps that change who can access the workspace. - README.md and cargo/SKILL.md now say what `curl … install.sh | sh` actually is, how to read it first, and the by-hand equivalent. sessions.md already pointed at the installer source; the two more-read files did not. The router also tells the agent never to run it on the user's behalf without asking. - "Why the pin" now documents cli-version as the reason session-start refresh is not a blind auto-update, tells the agent to surface a global npm install rather than doing it silently, and marks the pin read-only. The other two findings need no change: the flagged egress is the product's own API, and the script-fetching match is the same installer. Plugin manifests bumped in lockstep (linter enforces they mirror the router). skills-lint clean, llms.txt and trigger slugs in sync, routing evals 81/81 core. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Make the audit response survive an actual audit Review of the 1.18.2 branch found the trust paragraph pointing readers at `apps/backend/src/http/routes/install.sh` in `getcargohq/cargo` — a private repo. Every external reader following that gets a 404, from the one paragraph whose entire job is making `curl | sh` auditable. Removed from README.md and cargo/SKILL.md; neither now sends anyone somewhere they cannot go. `curl … | less` followed by `curl … | sh` is two fetches, and the server can serve different bytes to the second, so reading first guarantees nothing about what runs. Replaced with download-once-then-execute in both files. The use-case gate named the wrong steps: step 9 is `folder create` (no access change) and step 2 is `role list` (read-only). The steps that actually grant access are 1 (`token create`) and 3 (`user create`), so an agent was pausing on a benign organizational step and skipping a credential mint. Also: README pointed "below" at the plugin install, which is above it — now an anchor link; and cargo-workspace-management/SKILL.md still inlined the bare pipe-to-shell command the rest of this change set was written to caveat. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Auree Aubert
|
97680e41fe |
Point the pack at the standalone single-job skills (#82)
getcargohq/gtm-skills packages twelve of these outcomes as skills named after the job — find-work-email, find-stakeholders, track-job-changes — for people who want one thing rather than the whole workstation. Nothing here pointed at them, which wasted the best backlink available: this repo is public, indexed, and already crawled, and that one is brand new. Adds the pointer in two places that matter — the README install section, where someone is choosing what to install, and llms.txt, which is what LLM-facing crawlers read. Both state the exclusivity rule, since installing both sides would put two skills in front of the same request. The llms.txt section is generated, not hand-written, so it cannot drift from the pack it advertises. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.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> |
||
|
Auree Aubert
|
f93cac3f05 |
Improve agent distribution: paste-prompt install, llms.txt, provider routing, cookbook wiring (#66)
- README now leads with the one-line agent-paste install (agent-install.txt)
and documents Claude Cowork setup (network egress, no-TTY token sign-in,
folder-persisted auth)
- Add CI-generated llms.txt (.github/scripts/generate-llms-txt.ts, TS via
native type-stripping) with a --check step in skills-lint so the index can
never drift from the shipped skill tree
- cargo-gtm frontmatter description now lists every provider slug so naming a
provider ("enrich with FullEnrich") triggers routing into the skill
- Route cargo-cdk (and the router recap) to the cargo-cookbooks menu before
hand-authoring common GTM outcomes, with the deploy-unverified caveat
- Version bumps: cargo 1.16.0, cargo-gtm 1.10.0, cargo-cdk 1.1.0; plugin
manifests mirrored; skill-metadata regenerated
Co-authored-by: Auree Aubert <aureeaubert@users.noreply.github.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
|
f6d752d869 |
Add cargo-observability skill — scheduled threshold alerts (#72)
* Add cargo-observability skill for the alerts domain
Introduces a new capability skill documenting the observability CLI
domain (cargo-ai observability alert/event) shipped in the backend/api.
Alerts are scheduled threshold checks: measure a scope (spans/runs/
records/orchestrationQuery/storageQuery/model), compare to a threshold
(metric + gte/lte + value), and fire actions as runs on breach.
New skill: cargo-observability/
- SKILL.md — commands, the preview-before-create discipline, the
scope/threshold/action model, permissions, and cost discipline
- references/scopes-and-thresholds.md — the scope↔threshold matrix,
metric meanings/units, and the empty-window-vs-real-zero rule
- references/alert-lifecycle.md — cron windows, at-most-once firing,
dead-man's switches, and the {{alert.*}}/{{event.*}} templating
- references/examples/recipes.md — seven copy-paste alert recipes
Pack integration:
- Router cargo/SKILL.md → 1.17.0: table row, recap, dependency rule,
diagram box, defineAlert added to the CDK builder list, counts
(15→16 skills; twelve→thirteen capability skills)
- README.md, AGENTS.md: counts + Observability capability row + a
"get alerted when something breaks" use case
- Plugin manifests bumped to 1.17.0 to mirror the router
- skills-lint.mjs: cargo-observability in SKILL_DIRS, observability
in the known-CLI-domains allowlist
- CHANGELOG entries; regenerated skill-metadata.json
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017UzK9huhSm588ThVFS1GcE
* Document defineAlert in the cargo-cdk skill
Wires the new observability domain into the declarative skill so alerts
can be managed as workspace-as-code, not only via the imperative CLI.
cargo-cdk → 1.2.0:
- references/resources.md: defineAlert Builders-table row + a "Notes on
specific fields" entry — the scope↔threshold matched pair (TS narrows
the metric menu by scope.kind), scope wiring by handle, the {ref,config}
action wrapper + alertConnectorAction/alertToolAction helpers +
{{event.*}}/{{alert.*}} templating, and the slugless-identity note
- guides/authoring-resources.md: an Observability example wiring an alert
to a definePlay handle with an agent action
- SKILL.md §6: alert added to the slugless "commit cargo.state.json"
resources; 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
Also: cargo-observability scopes reference now states telemetry duration is
in seconds (confirmed authoritative from the CDK builder types).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017UzK9huhSm588ThVFS1GcE
---------
Co-authored-by: Claude <noreply@anthropic.com>
|
||
|
Auree Aubert
|
eb2be77cc4 |
feat(gtm): tool-agnostic import recipe (#57)
* feat(gtm): tool-agnostic import recipe Rebased onto main as an independent PR (needs only the QA scripts and prompt library, both merged): recipes/import-gtm-data.md — CSV-first export, column mapping with a source_tool_id idempotency key, batch load, free QA-script audit on arrival, selective rebuild of recurring logic as plays, and a 10-row pilot-gated parity check. No per-tool extractors or name mappings. cargo-gtm -> 1.6.0 (1.5.0 reserved by the open subagents/statusline PR). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(gtm): import recipe uses the documented --column JSON shape storage column create takes --column '{slug,type,label,kind}' per cargo-storage — the recipe's --slug/--type flags don't exist, so the source_tool_id idempotency column was never created before load. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(gtm): import recipe audits the stored rows, not the source export Step 4 ran the QA scripts on contacts-export.csv — but step 3 had already deduped and column-mapped the set into the model, so QA graded rows that never landed and its verdicts touched nothing stored. Step 4 now pulls the loaded rows back out (storage query download filtered on source_tool_id), audits those, and writes audit_action back onto the stored records keyed on source_tool_id — activation segments filter SEND, VERIFY re-verifies (pilot-gated), REMOVE rows are excluded and only bulk-deleted after review. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
Auree Aubert
|
3610dc442c |
feat: native subagents + opt-in statusline (#56)
* feat: native subagents + opt-in statusline Rebased onto main (post #55): cargo-execution-planner and cargo-list-builder ship as Claude Code plugin subagents (haiku tier; canonical role specs in cargo-gtm/agents/ for every channel), plus hooks/cargo-statusline.mjs — an opt-in statusline (workspace, credits, CLI pin state) whose render path is cache-only with a detached refresh. README documents the settings.json wiring and the plugin's subagent benefit. cargo -> 1.14.0 (manifests lockstep), cargo-gtm -> 1.5.0 (list-builder + §2 fan-out routing). Metadata regenerated over main's tree. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(statusline): exact semver pin match; single-flight refresh lock - The pin check used a substring test, so 21.0.29 / 1.0.290 / 10.0.29 all satisfied pin 1.0.29 and rendered as pinned. Extract the semver from --version output and require exact equality. - render() spawned a detached --refresh child on every call while the cache was missing/stale, with no in-flight guard — frequent statusline updates stacked overlapping cargo-ai processes until the first refresh landed. A lock file created atomically (flag "wx", stale after 60s for crashed children) makes refresh single-flight; the child releases it after writing the cache, and a failed spawn frees it immediately. Verified: 6 parallel cold renders spawn exactly 1 refresh child; lock releases after the cache write; warm render never spawns; all tricky version shapes (21.0.29, 1.0.290, 10.0.29, "Loading..." prefix) compare correctly. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(statusline): refresh preserves the previous cache across failures refresh() rebuilt the cache from scratch, so one transient CLI failure blanked fields that were still valid (workspace, credits, pin state) and a fresh `at` was stamped even when nothing was fetched — pushing the retry a full TTL away. It now starts from the previous cache, overwrites a field only on a successful fetch, and advances `at` only when at least one fetch succeeded; a fully failed refresh leaves the file byte-identical so the next render retries immediately (rate-limited by the refresh lock). Verified with a stub cargo-ai (bypassing volta's PATH re-injection): total failure leaves the cache byte-identical; partial failure (--version only) keeps workspace/credits, updates the pin segment, advances the clock. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
Auree Aubert
|
92e24be8eb |
Document the analytics/diagnostics boundary; surface both in the README (#52)
cargo-analytics and cargo-diagnostics overlapped on error handling with
no routing between them. This draws the line — analytics measures and
exports ("what happened"), diagnostics explains ("why") — and documents
it on every surface an agent might load first:
- cargo-analytics: new "Scope — measure and export, not explain"
section with a question-shape routing table; the partial-batch-
failures runbook now hands root-causing off to the batch-error-sweep
runbook instead of duplicating it; frontmatter description routes
"why did it fail" to diagnostics (bump 1.4.1 -> 1.4.2).
- cargo-diagnostics: mirror "Boundary with cargo-analytics" note —
diagnoses start from an analytics signal and end back in analytics
for bulk retrieval (bump 1.0.0 -> 1.0.1).
- cargo router: one reciprocal critical-rule line in each recap.
- README: capabilities table renamed to "Capabilities", the missing
Diagnostics row added, and CDK + Diagnostics moved to the bottom as
the two marked cross-cutting entries.
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
|
||
|
Auree Aubert
|
a418d76ee7 |
Fan the plugin out to Codex and Cursor; bundle session-lifecycle hooks (#50)
* Fan the plugin out to Codex and Cursor; bundle session-lifecycle hooks - One plugin source, three targets: .agents/plugins/marketplace.json (Codex) + .cursor-plugin/marketplace.json, with .codex-plugin/ and .cursor-plugin/ plugin manifests version-locked to the router (linter-enforced across all three, negative-tested). The approval hook is wired per target - PreToolUse (Claude Code), PermissionRequest via hooks/codex-hooks.json (Codex), beforeShellExecution via hooks/cursor-hooks.json (Cursor) - reusing approve-cli.sh's existing per-agent verdict dispatch. - Plugin-bundled lifecycle hooks (Claude Code): session-start (pinned CLI refresh from the plugin's own cli-version + placeholder session row; deliberately no skills add - the plugin owns the skills), session-checkpoint (Stop; jq-derived title, 45s throttle), and session-end (sync finalize + detached claude -p refinement). Each defers when the installer's counterpart exists at ~/.claude/hooks/, so installer + plugin never double-register a session. - .gitignore: un-ignore .agents/plugins/ (vendored skills stay ignored). - README: per-target install steps; router 1.11.0, plugins 1.11.0. Verified: lint 0/0; scripts behavior-tested with stubbed npm/cargo-ai (pin read from plugin root, defer guards, checkpoint derivation + throttle, --finished finalize); live plugin install on Claude Code 2.1.205 shows all four hook events and both extra manifests in the 1.11.0 cache. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Make the plugin the single source of truth; agent-portable docs - session-start.sh now also refreshes the plugin itself (marketplace update + plugin update, detached, effective next session) - the plugin channel's replacement for the installer's skills-add refresh, with zero duplication by construction. - Docs made agent-portable: the pinned-install command in cargo/SKILL.md and prerequisites.md reads cli-version from the skill directory the agent loaded instead of hardcoding ~/.claude/skills/ (which silently degraded Codex/Cursor to @latest); manual-path session titles are agent-neutral; job 1 says to skip skills add when skills came from a plugin; the permission-prompts note covers all three agents' events. - README Claude Code section describes the refactored installer flow (installs the plugin; skills add only as fallback; legacy scaffolding migrated away). cargo 1.12.0, plugins 1.12.0. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Single-source the lifecycle scripts: dual-mode plugin/standalone The three hooks/session-*.sh scripts are now the only copies of the session lifecycle - the installer's fallback channel downloads them instead of embedding heredocs. Mode auto-detects from location (~/.claude/hooks/ = standalone; anywhere else = plugin) with an explicit plugin|standalone arg override: - standalone: skills add refresh, pin from ~/.claude/skills/cargo/, no plugin self-update, never defers. - plugin: pin from plugin root, detached plugin self-update, no skills add, defers when a standalone copy exists (exactly one lifecycle runs). Log lines carry the mode. Behavior-tested both modes of all three scripts with stubbed npm/npx/cargo-ai/claude (mode detection, defer, no-self-defer, per-mode pin paths, per-mode refresh, mode-aware logs). cargo 1.13.0, plugins 1.13.0. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(lifecycle): registration-aware defer, wider PATH, checkpoint hygiene Review feedback on the lifecycle scripts: - Defer guard now requires the standalone copy to be REGISTERED in ~/.claude/settings.json, not merely present - an unregistered leftover file no longer suppresses the plugin copy (which would silently skip CLI pinning and session logging). Falls back to file existence when jq is unavailable. - session-start's PATH widening for the detached plugin self-update now matches session-end's full list (Volta, asdf shims, nvm version dirs, /opt/node*) so `claude` resolves under version managers and the update isn't silently skipped. - Checkpoint prompt snippets strip control characters. The reported command-substitution injection does not exist - shell assignments and quoted expansions never evaluate a value's content, and the upsert passes --title/--summary as single argv words (verified empirically: $(touch ...) and backticks pass through as literal data) - but control chars could mangle logs/rows, so they are removed and the inertness is documented in a comment for future reviewers. Verified: unregistered leftover -> plugin runs; registered standalone -> plugin defers; clean env -> runs; injection payload inert with ESC sequences stripped from the stored title. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(lifecycle): run when standalone registration is unverifiable Review follow-up: the defer guard's no-jq / no-settings.json fallback returned "owned" (defer), which silently skipped CLI pinning and session logging whenever registration couldn't be checked - exactly the failure the registration-awareness was meant to prevent. Flipped: when jq or settings.json is unavailable, default to NOT owned so the plugin copy runs. Safe direction - the session upsert is idempotent, so a duplicate with an active standalone is harmless, whereas a wrong defer is a silent skip. Unit-tested all five branches (registered->defer; not-registered, no-settings, no-jq, no-file->run). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
Auree Aubert
|
1cb3ee755b |
Claude Code plugin channel, cargo-ai approval hook, and CLI version pin (#51)
* Add Claude Code plugin channel and cargo-ai auto-approve hook - .claude-plugin/marketplace.json + plugin.json: the repo root doubles as a Claude Code plugin (skills scan root "./" discovers all 15 top-level skill dirs with no restructuring; plugin version mirrors the router's, now linter-enforced). - hooks/approve-cli.sh: allow-only PreToolUse hook that auto-approves cargo-ai / npx @cargo-ai/cli calls and read-only pipe helpers after a quote-aware structural pass. Never auto-approves: login/logout, workspaceManagement token/report, cdk deploy/destroy, or any remove/delete/destroy token. Verified with a 49-case harness plus a live end-to-end test (clean permissions: whoami auto-approved, token list fell through to prompt). - README: plugin install path + pick-one-channel note; prerequisites.md gains a "Permission prompts" section. cargo 1.9.0, plugin 1.9.0. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Pin the CLI version in cargo/cli-version - New cargo/cli-version (1.0.29): single-line semver pin, the source of truth for which @cargo-ai/cli these skills were written against. Lives inside the router skill so it ships with skills add and the ClawHub bundle; session hooks read it locally with a latest fallback, so the pin can never block an install. - Linter asserts the pin exists and is bare semver, and that openclaw install blocks stay @cargo-ai/cli@latest (bootstrap only; the session hook converges to the pin). - Docs: router session job 1 reordered (skills add -> pinned npm install) with a "why the pin" note; prerequisites.md and README refresh snippets use the pinned form. cargo 1.10.0, plugin 1.10.0. The producer side (CLI release pipeline PRs pin bumps here; install.sh consumes the raw pin URL) lands in getcargohq/cargo separately. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(approve-cli): position-independent gating closes token-shift bypass Review finding: gated checks only examined the first two non-flag tokens after the binary/package. Valid invocation prefixes shift the real subcommand out of those slots - `npx -p @cargo-ai/cli cargo-ai login` puts a literal cargo-ai before login (confirmed auto-approved), and a global flag with a value would shift the domain word the same way. Fix: normalize the cargo segment's token stream once, drop leading `cargo-ai` binary tokens, and gate position-independently - credential tokens (login/logout), destructive verbs (remove/delete/destroy), and gated adjacent pairs (workspaceManagement token/report, cdk deploy/destroy) anywhere in the segment refuse approval. Accepted cost, documented: a gated word as a literal inside a quoted argument (SQL containing "login") now falls through to the prompt - the safe direction for an allow-only hook. Harness extended to 62 cases: all -p/token-shift/flag-shift bypass shapes prompt; safe -p usage still auto-approves. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
Auree Aubert
|
f5566657fa |
Add cargo-diagnostics skill, interaction conventions, and catalog fixes (#48)
- New capability skill cargo-diagnostics: forensic runbooks (run-trace, batch-error-sweep, play-optimize-credits) that sequence run get, orchestration SQL, and billing metrics into diagnoses, linking existing references instead of duplicating them. - New shared reference cargo/references/interaction.md: plan gate before building, recommended-default choices, presenting defaults. - Catalog hygiene: stale skill counts fixed (AGENTS.md said ten, router said thirteen, README said fourteen -> fifteen everywhere), ClawHub publish loop catches up cargo-quickstart/cargo-content/cargo-hosting and adds cargo-diagnostics, README owner prose matches CLAWHUB_OWNER. - Version bumps: cargo 1.8.0, cargo-gtm 1.1.1, cargo-orchestration 1.5.1, cargo-billing 1.0.2, cargo-diagnostics 1.0.0 (new). CHANGELOG updated. Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
Auree Aubert
|
915b5a29bb |
Terminal-experience quick wins: quickstart, cost discipline, save-as-play, anti-drift (#45)
* Terminal-experience quick wins: quickstart, cost discipline, save-as-play, anti-drift From the 2026-07-08 terminal-experience eval: - New cargo-quickstart skill: persona question → 25 leads in <2 min → receipt → save as a recurring play (fast path verified live; fields, retrieval flow, and the 25-row minimum page documented from observation) - New cargo-gtm/references/cost-discipline.md: blocking pilot→approval→ full-run gate, per-run receipts (credits + balance + hit-rate + estimate-vs-actual), 1.4×N over-provision, count-first sizing, pay-on-success and phone guards, context discipline — wired into cargo-gtm SKILL.md, the plan agent, waterfall-strategy, build-tam - New cargo-gtm/recipes/save-as-play.md: ad-hoc run → durable play/tool with cadence defaults per signal and recurring-cost approval - Grounded next-step spec (5-part shape) + end-of-session share ask (consented session traces via workspaceManagement report) - Provider playbooks: Anti-patterns sections (field-name case traps, billed-on-returned-rows, PDL parameters wrapper), waterfall position + dynamic demotion rules; verification hard rules (independent validation, catch-all double-confirmation) - Anti-drift: linter now lints cargo-content/cargo-hosting (previously skipped), and fails on skills or recipes missing from the router / recipe tables; fixed the drifted README recipe table and skill counts - Removed the --is-finished flag from download-outputs snippets (API rejects it; CLI bug reported) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(cargo-quickstart): fallback rung 3 must ask before exceeding the demo's paid cap waterfall.searchProspects at 3/record × 5 rows (~15 credits) blows the ~1-credit demo budget — gate it behind an explicit yes (with the free connect-Sales-Navigator alternative offered) instead of just explaining the cap after the fact. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
Auree Aubert
|
d2ff86b5b5 |
Add cargo-cdk skill for declarative workspace-as-code (#43)
Adds the cargo-cdk capability skill covering the cdk CLI domain (@cargo-ai/cdk): SKILL.md with the declarative-vs-imperative decision model and init → types → plan → deploy → destroy lifecycle, three guides (authoring-resources, deploy-and-state, typed-config), five recipes, and references (resources, commands, troubleshooting, full-workspace example). Registers it everywhere: router (cargo/SKILL.md → 1.6.0, skill count 11→12, decision block + table row + recap + dependency-diagram box), README (12→13 skills, CDK table row), CHANGELOG, skills-lint SKILL_DIRS + cdk domain, and the clawhub publish loop. Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
Auree Aubert
|
d2116111af |
docs: document the per-turn Stop checkpoint hook in the session lifecycle (#41)
The installer now scaffolds three Claude Code hooks, not a pair. Update the skills to match: - cargo/SKILL.md: "three jobs" callout now lists SessionStart + Stop + SessionEnd and explains the per-turn checkpoint (v1.5.1). - cargo-workspace-management/SKILL.md + sessions.md: describe all three hooks, the cheap no-LLM Stop checkpoint (throttled, no --finished), the SessionEnd diagnostic log, and correct the opt-out env var to CARGO_INSTALL_HOOKS=0 (was mis-documented as CARGO_INSTALL_NO_HOOKS=1) (workspace-management v1.1.0). - README.md + CHANGELOG.md: same three-hook description and env-var fix. Skill-lint passes (0 errors, 0 warnings). Claude-Session: https://claude.ai/code/session_01MbC6Bq8sF1MAy7eezubvAx Co-authored-by: Claude <noreply@anthropic.com> |
||
|
Auree Aubert
|
53a1a86a7f |
Add cargo-hosting skill for app and worker deployment (#40)
* Add cargo-hosting capability skill
Document the `hosting` CLI domain (apps, workers, deployments) as a
dedicated capability skill, following the one-skill-per-CLI-domain
convention.
- cargo-hosting/SKILL.md: init -> create -> deploy -> promote lifecycle
for Vite SPA apps (*.cargo.app) and edge workers, with critical rules
and async polling.
- references/examples/{apps,workers,deployments}.md, response-shapes.md,
troubleshooting.md.
- Register in the cargo router (skill count 10->11, capability table row,
recap, removed hosting from the no-skill-yet table, synced frontmatter
count) and bump cargo 1.4.0 -> 1.5.0.
- README capability table + skill count (11 -> 12).
- CHANGELOG entries for cargo-hosting 1.0.0 and cargo 1.5.0.
https://claude.ai/code/session_018LeD9abpD7LYBhGGkDxSup
* Add hosting terms to glossary
Add app/appUuid, deployment/deploymentUuid, hosting, worker/workerUuid
entries to cargo/references/glossary.md, and correct the capability-skill
domain list (was missing content and hosting). CHANGELOG updated.
https://claude.ai/code/session_018LeD9abpD7LYBhGGkDxSup
* Pin hosting response shapes from backend types
Replace inferred shapes/caveats in cargo-hosting with the authoritative
App/Worker/Deployment structures: kind app/worker discriminant,
promotedDeployment, chargedUntil, and the deployment status enum
(pending/building/success/error/cancelled, terminal at the last three).
Polling + build-failure docs now cite the real status/errorMessage/
buildLogS3Filename fields, and a critical rule notes monthly hosting
credits per resource.
https://claude.ai/code/session_018LeD9abpD7LYBhGGkDxSup
---------
Co-authored-by: Claude <noreply@anthropic.com>
|
||
|
Auree Aubert
|
7f8e1344ca |
docs: move session-lifecycle hooks to the installer (#37)
The Claude Code SessionStart/SessionEnd hooks are now scaffolded by the Cargo bootstrap installer, so the hand-rolled scaffolding recipes are removed from cargo/SKILL.md, README.md, and the workspace-management sessions example; those docs now point at the installer. The agent's three-session-jobs guidance stays as the manual fallback, and reporting (job 2) is unchanged since it can't be automated. Bumps cargo 1.3.0 -> 1.4.0 and cargo-workspace-management 1.0.1 -> 1.0.2. https://claude.ai/code/session_017VAhep38mC31RPRE7xJwV4 Co-authored-by: Claude <noreply@anthropic.com> |
||
|
Auree Aubert
|
4c933393dd |
Extract content domain into dedicated cargo-content skill (#35)
* Migrate file/library docs to the new content domain + register new CLI surfaces The CLI moved workspace files and knowledge libraries out of the `ai` domain into a new top-level `content` domain (`content file`, `content library`), and added inline `ai document`. The old `cargo-ai ai file ...` commands no longer exist. - cargo-ai (2.0.0): migrate every `ai file` reference to `content file`; document `content library` (native vs connector-backed) and `ai document`; rename the Files section and add a command-surface-change callout. - cargo (1.2.0): register the content domain in the recap/table, add a "CLI domains without a dedicated skill yet" table (segmentation, expression, system-of-record, revenue-organization, hosting, user-management), add glossary entries for the content domain and libraries. - cargo-context (1.0.2), cargo-orchestration: fix cross-skill RAG examples. - skills-lint: add the new CLI domains to the known-domain allowlist. * cargo-context/cargo-ai: document content files exposed read-only under .files/ Uploaded `content file` knowledge surfaces in the context runtime sandbox under a read-only `.files/` directory that sits outside the committed context tree, so sandbox commands can consume content uploads without round-tripping them back into the context repo. * Split the content domain into a dedicated cargo-content skill The content CLI domain (files + libraries) was documented inside cargo-ai. Per the repo's one-skill-per-CLI-domain convention, extract it into its own cargo-content capability skill: - New cargo-content/ skill: files + libraries command docs, the moved examples/files.md walkthrough, response shapes, and troubleshooting. - cargo-ai keeps inline documents (ai document) and the attach-to-agent wiring; cross-links cargo-content for files/libraries. - Register cargo-content across the router overview (cargo/SKILL.md table, recap, dependency diagram/rules, counts), glossary, README, and AGENTS.md. - cargo-context documents content files mounted read-only under .files/. - Version bumps: cargo 1.3.0, cargo-ai 2.1.0, cargo-content 1.0.0, cargo-context 1.1.0; CHANGELOG updated. * Drop ai document from cargo-ai; correct content file response shape - Remove the low-value ai document (inline documents) commands from cargo-ai and scrub document references from the router overview, README, glossary, and the cargo-content files.md walkthrough. - Reframe cargo-ai's knowledge section around files & libraries only. - Update the content file list response shape to match the workspace File type: libraryUuid, userUuid, isIndexedInOpenAiVectorStore, externalId, deletedAt, and the native/connector kind union (connectorUuid). --------- Co-authored-by: Claude <noreply@anthropic.com> |
||
|
Auree Aubert
|
022fd8ddb3 |
Add Claude Code session tracking via workspace management (#32)
* Document workspaceManagement session tracking + Claude Code hook recipe Adds documentation for cargo-ai workspaceManagement session upsert mirroring the existing reports pattern: a Sessions section in the workspace-management skill, a worked example with the SessionStart + SessionEnd hook recipe (including claude -p transcript summarization), and a Tracking sessions block in the repo README alongside the existing CLI-refresh hook docs. Follows the same agent-neutral approach as the CLI-refresh hook: recipe is documented for users to adopt; nothing is materialized in .claude/ at the repo root. * Move session agent guidance into cargo/SKILL.md Match the split already in place for reports: cargo/SKILL.md carries the when/why and the Claude Code SessionStart + SessionEnd hook scaffolding offer, and cargo-workspace-management/SKILL.md keeps just the CLI surface (upsert syntax, idempotency rules, --finished flag). * Restructure cargo/SKILL.md around the per-session lifecycle Pulls the repo orientation + Installation above the per-session guidance, then collapses four scattered sections (First step / Re- refresh / Send a report / Tracking sessions) into a single "Every Cargo session has three jobs" section organized as start / mid / end. Unifies the two Claude Code hook scaffolding offers (one for auto- refresh, one for session tracking) into one. The agent asks a single yes/no question and the resulting hook pair does both. --------- 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
|
4c04034e4d |
Promote repo-root router into an installable cargo skill
The repo-root AGENTS.md and GLOSSARY.md held the cross-skill router (skill graph, UUID flow, async polling, end-to-end use cases, common gotchas) and term reference, but the skillpack installer (`npx skills add`) only ships the `cargo-*/` skill folders — anyone installing the package never received the router content. Wrap the router as a tenth skill (`cargo/SKILL.md`) with the required frontmatter (name, description, license, compatibility, metadata) and move the glossary into `cargo/references/glossary.md` so both ship via the installer. Rewrite sibling-skill references inside the new SKILL.md to use `../cargo-*` paths so they resolve once installed into `~/.claude/skills/`. Collapse root AGENTS.md to a pointer for AGENTS.md-aware tools and repoint CLAUDE.md at the new skill so Claude Code still inlines the full router on session start. |
||
|
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 | ||
|
Auree Aubert
|
c5837c56cb |
Document cargo-context in README, GLOSSARY, and AGENTS
- README.md: bump skill count (8 → 9), add Context row to capability table, add a "Edit the workspace's GTM context" use case. - GLOSSARY.md: add `context`, `context repository`, `knowledge graph`, `runtime sandbox`; cross-link from `persona`, `play`, `signal`, `ICP`, `slug`, `system of record`, `memory`, `template`, `workspace`. - AGENTS.md: bump count, add cargo-context to capability tables and skill details, note its orthogonality in the dependency map, add an authoring use case and two context-specific gotchas. |
||
|
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. |
||
|
Aurelien
|
73a21a7345 |
docs(readme): fix stale recipes/tam-build.md references (file is build-tam.md)
Same typo we fixed in index.md and cargo-gtm/SKILL.md — README had two more occurrences in the recipes table and the example prompts. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Aurelien
|
ad11f201f1 |
refactor: consolidate to flat catalog — single cargo-gtm meta-skill
Drops the cargo-outcome/ and cargo-infra/ folder split. All capability
skills move back to repo root. cargo-gtm becomes the single outcome
skill at repo root, holding ALL GTM content (guides, recipes,
provider-playbooks, references, agents) in one place.
Folds the 6 Tier 1 outcome skills (cargo-tam-build, cargo-prospecting,
cargo-job-change-monitoring, cargo-funding-watch, cargo-tech-intent,
cargo-portfolio-prospecting, cargo-icp-discovery) into
cargo-gtm/recipes/{name}.md. Each scenario has exactly one home.
cargo-prospecting's three sub-recipes (P1/P2/P3) collapsed into
cargo-gtm/recipes/prospecting.md. cargo-prospecting's alternatives.md
moved to cargo-gtm/references/alternatives.md (it's a general fallback
reference, not prospecting-specific).
Final structure: 8 skills at root — cargo-gtm + 7 capability skills.
Mirrors deepline's actual flat catalog. Eliminates the recipe-location
inconsistency the user flagged (Pattern A vs Pattern B drift). Single
source of truth per scenario; no cross-skill navigation needed once
cargo-gtm loads.
Updated:
- Top-level SKILL.md, README.md, GLOSSARY.md to reflect flat catalog
- All cross-references (cargo-infra/X → X; ../../X → ../X for cargo-gtm
depth-1 refs; ../../../X → ../../X for cargo-gtm/{guides,recipes,
references,playbooks,agents}/ depth-2 refs)
- Removed cargo-outcome/ and cargo-infra/ directories entirely
Verified: 54/54 markdown links resolve; 0 connectorUuid in config blocks;
0 ES-style PDL queries (`bool/must/term/match`); 0 stale cargo-infra/
or cargo-outcome/ references; 0 clearbit references in cargo-gtm/;
npx skills add --list --full-depth discovers all 8 skills.
Supersedes #14 entirely. PR #15 (this branch) now represents the
complete restructure as approved.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
Aurelien
|
6da0b922bd |
refactor: split skills into cargo-outcome/ and cargo-infra/ layers
Move all 7 capability skills into cargo-infra/ (the standard library — CLI domain references). Create cargo-outcome/ as the home for the new application library: job-shaped skills the agent loads when the user states a real-world goal. Top-level SKILL.md and README.md updated with two-tier navigation, revised dependency diagram, and a "What can I ask for?" section. Document cargo-ai orchestration run download-outputs in cargo-infra/cargo-analytics/SKILL.md — previously undocumented despite being the canonical way to retrieve action outputs (signed URL to a CSV/JSON of the output node's data; faster and cheaper than full run record downloads). cargo-outcome/ ships empty in this commit; cargo-gtm and cargo-prospecting follow in subsequent commits within the same PR. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Claude
|
8b136f766a |
docs: polish README, add action execute use case, bump versions
- Add "Execute a single action" use case to README and root SKILL.md - Update orchestration description to mention actions - Update skills-at-a-glance table to lead with actions - Bump cargo-cli-orchestration to v1.4, cargo-cli-ai to v1.1 - Renumber end-to-end use cases (1-7) https://claude.ai/code/session_01BFtdCQiK6YE6WLimLzPhz6 |
||
|
Aurelien
|
7312a0d4f5 | Initial commit |