6 Commits

Author	SHA1	Message	Date
Auree Aubert	bf23619313	Stop documenting the first-party enrichment provider (#122) ... * Stop documenting the first-party enrichment provider Its playbook, its 21 priced actions, and every recipe step that led with it are removed. Each one now leads with the rung the pack already named as its fallback, so nothing here is invented — the replacements were sitting in stage-action-map.md and alternatives.md the whole time. The substitutions: firmographics aiArk.enrichCompany (0.01) -> companyEnrich (0.25) -> waterfall (1) person aiArk.enrichPerson (0.1) -> waterfall.enrichContact (2) funding enrichCrm.getFunding (1), now the catalog's only one technographics builtwith.getDomainSummary (free) -> enrichDomain (1) dedupe free storage query against the workspace's own models That last line is the one worth reading twice. The match actions existed to mint an id the other actions required; every replacement keys on the domain or a LinkedIn URL, so a step that cost 0.5/record now costs nothing. The event feed has no replacement and the recipes say so. fetchBusinessEvents took a timestamp_from and nothing else in the catalog does, so funding-watch, re-engagement and lost-deal-revival are rewritten as a diff: re-pull, compare against the stored round date, keep what moved. Cadence becomes the only cost dial, which is why funding-watch's default drops from daily to weekly. Every credit budget was recomputed rather than relabelled: build-tam 2,955 -> 2,210 (500 companies + 1,500 contacts) prospecting P2 821 -> 107 (200 verified prospects) icp-discovery 602 -> 204 (200 deals) context bootstrap 3 -> 1 Catalog counts now follow the generated data file rather than the older hand-kept figure: 136 integrations, 176 credits-based actions of 513. Also bumps the CLI pin 1.0.66 -> 1.0.78. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019wkwbhrEoE5KW9A1CKBmcA * Fix the three generated artifacts the removal invalidated CI caught what the local lint could not: skills-lint.mjs is only one of five checks, and the other four all had something to say. llms.txt was stale — it is generated from the skill descriptions, and cargo-gtm's dropped a provider from its roster. The codex package build enforces override version == upstream version, so bumping only .github/package-overrides/cargo-quickstart.SKILL.md to 1.0.3 broke it. The guard exists to stop the override silently shipping last month's demo, so the fix is to bump both, not to revert the override. That build also patches literal source strings at package time, and one anchor ran through a line this branch rewrote: snitcher.searchSessions (0 cred) -> cargo.matchProspect snitcher.searchSessions (0 cred) -> aiArk.reverseLookup (0.05) The edit strips the visitor-de-anonymisation path from the packaged skill, so a silent miss would have shipped it. Re-anchored, and every other PACKAGE_EDITS find string verified against the tree — 1 broken, now 0. Also drops the packaged cargo-connection description from 138 integrations to 136, matching the repo. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019wkwbhrEoE5KW9A1CKBmcA * Say where revenue went, and that employee ratings went nowhere Removing the provider took two data points off the map without replacing the map entry, which is the failure mode this recipe's own feasibility gate exists to prevent: an attribute that quietly stops being answerable reads the same as one nobody asked for. They are not the same case, so they get different rows. Revenue and NAICS survive. companyEnrich.enrichByDomain (0.25) returns them in the same call as firmographics, employees, funding and socials — so it fills several rows at once and the row says that, because the per-account arithmetic in step 4 gets it wrong otherwise. Employee ratings have no successor at any price. Nothing credits-based in the catalog returns Glassdoor-style employer reputation. The row says none, and says to report it as a research note rather than substituting a scrape that reads like the real thing — which is the recipe's stated position on valuable attributes with no obtainable source, applied to itself. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019wkwbhrEoE5KW9A1CKBmcA * Fix the data-flow breaks the provider swap left behind Bugbot found eight, all real, and verifying them turned up five more. The pattern in every case is the same: I replaced an action but left the code that consumed its output reading the old response shape, so the step still runs, still bills, and quietly returns nothing. Response-shape breaks: funding-watch Pattern A still filtered funding_rounds[].announced_date while Pattern B read lastFundingDate. The 90-day select matched nothing, so the primary path returned an empty list after a paid pull. re-engagement Step 5 read .results[] and .events[] from a file step 3 now writes as a bare array. Funding branch always empty. lost-deal-revival Step 4 read .events[0] and expected a deal_id that getFunding does not return. Step 3b now carries deal_id through, which is the only place it exists. Wrong-source breaks: re-engagement The diff read last_funding_round_at off the Contacts segment. It is a Companies column, so the stored date was always empty and every account re-flagged every week. Now queries the Companies model, and fans the company-level signal back out to contacts, since step 5 unions on email. build-tam Step 4 keyed searchLeads on .linkedinId from the aiArk.enrichCompany output. No enrichment action returns a Sales Navigator accountId. Now carried from the sourcing step, with an explicit gate for rows that have none. guide snitcher.searchSessions identifies a COMPANY; I had chained it into aiArk.reverseLookup, which needs an email or phone. Its own playbook says to route identified domains through the enrich chain. Budget break: prospecting P2 step 5 ran FullEnrich over every lead while the budget quoted the residue. 200 credits against 60. P1 had the gate; P2 did not. Pre-existing, fixed because the fixes above sit inside them: icp-discovery [.[] | {domain}] over storage query execute output, which is {rows: [...]}. Enriched one null domain, not 200. jq inputs[N] `inputs` is a generator, not an array, so the union expressions in re-engagement and lost-deal-revival errored out. Slurped to [inputs] as $in. Every rewritten jq expression was run against fixtures rather than eyeballed. Also five provider mentions the sweep missed, because they wrote it as bare `cargo` with a price rather than cargo.actionName: societeInfo, snitcher, enrichCrm, linkedin, oceanio, apolloio, rocketreach. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019wkwbhrEoE5KW9A1CKBmcA * Make funding-watch Pattern B stand on its own It re-pulled two hardcoded example domains and then diffed them against /tmp/targets.json, a Pattern A artifact. Run Pattern B alone and the slurp fails; run both and it compares a fresh pull of one set against stored dates for a different set, so the "new round" filter cannot fire correctly either way. Both sides of a diff have to come from the same query. Now they do: one storage read supplies the domains to pull *and* the stored dates to compare against, so the sets align by construction and the pattern has no cross-dependency. Also states what a missing stored date means — it compares against "" and always passes, which is right on a first run and is exactly why the write-back step is not optional. Without it every run is a first run and the watch re-flags the whole segment forever. Verified against fixtures: an account whose round moved is kept, one whose stored date already matches is dropped, one with no stored date passes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019wkwbhrEoE5KW9A1CKBmcA * Route the questions people ask but the map never answered (#124) Measured instead of guessed. Of the 176 credits-based actions, 148 were reachable from a routing surface — the stage map, the phase guides, alternatives.md, a recipe. The other 28 were reachable only from their own provider playbook, which is findable if you already know which provider to open. That is the wrong way round. The worst of it: headcount had no section at all. It is the most-asked company attribute and the first row of the custom-datapoints feasibility gate, and not one of the four salesNavigator.find* actions appeared anywhere in the stage map. New section carries all four, plus the only historical series (companyEnrich.getWorkforce), plus linkedin.findCustomHeadcount for the roles the fixed buckets don't have, plus the companyId prerequisite that quietly turns a 0.25 action into 0.30 on a list that arrived without one. "Who works at this domain" was not a documented question either. It is not the same as searching a population by title, and it has two answers at very different prices. New section, with the trap stated: looping hunter.searchDomain to build a list is the pitfall its own playbook warns about. Also adds rocketreach, mixrank and societeInfo to Enrich/Sourcing — societeInfo reaches French registry data (NAF code, collective agreement, filed accounts) that nothing else in the catalog does — and gives Hiring intent a second index at the same price. 154/176 now. The remaining 22 stay unrouted on purpose, and the CHANGELOG says why for each: the four LinkedIn engagement actions would undercut the acceptable-use refusal to batch-blast them, three natives belong to other skills, searchLeadsLegacy costs 300x its replacement, and the rest are finer grain on an already-routed surface rather than separate questions. One thing the build caught: adding aiArk.analyzePersonality re-introduced a term the codex package deliberately strips, since the directory rejected person-level inference. Kept for the channels that carry it, with matching PACKAGE_EDITS so the package still removes it. Dropped the forager rung rather than add machinery for a last-resort action priced 20x above its own chain. All 67 anchors verified. Claude-Session: https://claude.ai/code/session_019wkwbhrEoE5KW9A1CKBmcA Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-02 16:40:18 -07:00
Auree Aubert	d91ab11e45	Point the CDK skill at cdk add, and stop documenting a template flag (#121) ... The cookbook guidance said there was no copy tool and the agent had to place the code itself. `cdk add cookbook/<slug>` is that tool now, so the skill says what it does, where it writes, and — the part an agent gets wrong — that the cookbook's own procedure has to be picked up at its Adapt section, because its opening steps assume you found the folder on GitHub and still have to place it. The command reference documented `--template <blank|full>` and `--list-templates` for `cdk init`. Neither flag exists: the scaffold never varies and a worked example comes from a cookbook. It also had no row for `add` or `cookbook` at all, which is the reference an agent reads to decide what to run. Fixed, along with the two recipes and the example that invoked `--template full`. Refreshes the cookbook snapshot, which had gone stale at two cookbooks while the catalog grew to three — `crm-enrichment` was missing from the menu. Regenerates llms.txt and the skill's metadata snapshot, both CI-gated. Co-authored-by: Cursor <cursoragent@cursor.com>	2026-09-01 22:12:45 -07:00
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>	2026-09-01 16:28:25 -07:00
Auree Aubert	fb95217c52	Make the cookbook menu a local file, and route on one-off vs standing (#110) ... * Make the cookbook menu a local file, and route on one-off vs standing cargo-cdk told the agent to "read the cookbook menu (the repo README's table)" — a network fetch to another GitHub repo, mid-task, which an agent may simply not make. When it does not, it authors from scratch a GTM outcome that was already sitting there written. A menu you have to go and get is a menu that gets skipped. So the menu becomes a local reference, generated from the cookbook repo: .github/data/cookbooks.json committed snapshot .github/scripts/sync-cookbooks.ts --refresh to re-pull, --check in CI cargo-cdk/references/cookbooks.md generated prose Same shape as sync-trigger-slugs.ts, deliberately: CI reads the snapshot and never the network, so a change in the cookbook repo cannot turn this build red on its own. Staleness is fixed on purpose, with --refresh. Two things the pointers got wrong, beyond being remote: Routing. cargo-cdk's description triggers on "as code", "in git", "Terraform for Cargo". Nobody says that when what they want is a rep cockpit. The real seam is one-off versus standing: "build our TAM" is cargo-gtm when the user wants a list today and a cookbook when they want a pipeline that keeps producing it. The words are identical, so both skills now say so explicitly and the description carries the outcome vocabulary. What a cookbook is. Both pointers called them "scaffoldable outcome templates", which invites copy-and-fill. The code is a worked example: each cookbook declares what may be reshaped, what must hold, and what must be answered, and installing one means adapting it until it is this company's code. Also carries the --force warning into both, because the damage is silent: `cdk init --force` into a non-empty directory replaces the project's package.json and reverts adapted cookbook code while cargo.state.json survives, so the next plan diffs a live workspace against code nobody wrote. Note: the snapshot includes `variations`, which land in cargo-cookbooks#3. Re-run --refresh once that merges. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Read the menu from SKILL.md frontmatter; leave "install a cookbook" to deploy-cookbook cargo-cookbooks folded cookbook.json into SKILL.md (every reader of the contract is an agent, and agents read markdown), so sync-cookbooks.ts now reads frontmatter (outcome, state, chain) plus `kind` and `requires` from cargo.scaffold.json, and the variations table under "## What you can change". Foundations take their one-liner from the README's first paragraph. No new dependency: the frontmatter is validated as real YAML in its own repo, so four scalar fields do not need a parser here. Two corrections to the previous commit on this branch: - cargo-cdk's description carried "install a cookbook" verbatim, which is deploy-cookbook's own trigger. With both installed the tie went to cargo-cdk, so the skill that merely points at cookbooks beat the one that installs them. cargo-cdk now carries discovery vocabulary ("is there a cookbook for this", "start from a cookbook") and leaves the install phrase to the skill that does the work. - `cargo-ai manifest add` is the way into an existing project (copy-in, existing files kept, every file hashed in manifest.json). It replaces the "scaffold to a temp dir and copy across" advice, which was a workaround for a command that already existed. skills-lint learns the `manifest` domain, shipped in 1.0.57. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * List every scaffoldable cookbook in the menu, not only the ones with a skill The menu hid 16 of 20 cookbooks because they had no SKILL.md yet. The old pointer sent the agent to a README that listed all 20, so this was a regression: a user asking for contact sourcing was told nothing existed while the code sat there and cdk init --from scaffolded it fine. Every outcome is listed now; the Skill column says whether the adaptation contract exists or the README and PLACEHOLDER comments are the interview. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * cargo-cdk: no session reload needed to reach a cookbook skill mid-task A cargo-skills user who asks for a cookbook outcome is one hop from the skill that installs it. Say exactly what to do in that hop: skills add, then read the two SKILL.md files directly; or `npx skills use` to read one without installing. And name the --dir default, which lands a cookbook in infra/ where a plain CDK project imports nothing from. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * menu: manifest add, not scaffold-to-temp, into an existing project Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * regenerate cargo-cdk metadata Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * menu: read state from the cookbook manifest, not from customer-facing frontmatter cargo-cookbooks moved state, approval and chain out of SKILL.md frontmatter into cargo.scaffold.json, because SKILL.md is what a customer installs and Cargo's bookkeeping is not their concern. The menu now takes everything from the manifest and each README's first paragraph; SKILL.md contributes only the variations table. One code path for foundations, unconverted and converted outcomes alike. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * regenerate metadata Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Point at gtm-skills' catalog.json: the CDK examples are skills there now cargo-cookbooks merged into gtm-skills as flat, self-contained skills, and that repo publishes one validated catalog.json. This script fetches it and parses no markdown; the menu lists the skills that carry a CDK example and the folders whose skill is not written yet. cargo-cdk and the router say what changed in the model: the agent copies the folder in and reconciles it, there is no scaffolder, and the shell comes from cdk init --template blank. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * menu: gtm-skills keeps only skills at the root, so no 'no skill yet' section Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Address review: GTM_SKILLS_ROOT accepts a dir or the catalog file; routing cases for cargo-cdk's new vocabulary Bugbot's third finding (foundation variations dropped from the menu) is moot: gtm-skills dissolved base-gtm and crm-sync into the skills that used them, so there are no foundations and nothing to render. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Name things what they are: CDK examples, not cookbooks The script, snapshot, reference file and type were named after the repo the examples came from before the merge. That repo is being archived and the examples are skills in gtm-skills now, so the names follow: sync-cdk-examples, .github/data/cdk-examples.json, references/cdk-examples.md, CdkExample. The llms.txt link to cargo-cookbooks goes; the linter's note that the CLI's manifest domain includes 'manifest add' goes too, ahead of its removal. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * cookbook is the name of the kind: rename the menu, snapshot and sync back to it gtm-skills#12 fixes metadata.source as one-off | cookbook. So the menu of gtm-skills that carry a worked CDK example is the cookbook menu, and the file, snapshot, script and type are named for the kind, not for the repo they once came from. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-18 17:57:26 -07:00
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>	2026-08-14 23:58:36 -07:00
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>	2026-08-12 10:18:32 -07:00