skills/getcargohq__cargo-skills
1
0
Fork 0
mirror of https://github.com/getcargohq/cargo-skills.git synced 2026-09-14 19:17:15 +08:00
Code Issues Packages Projects Releases Wiki Activity
167 Commits 109 Branches 0 Tags
docs/script-require-allowlist
Commit Graph

13 Commits

Author SHA1 Message Date
Aurelien 49a0e739ee Document the JS script node's require allowlist. 
Agents were told it ships lodash; the sandbox also allows axios, cheerio, crypto-js, date-fns, jsonschema, url, uuid, and zod, and knex is gone.

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-09-10 11:10:46 -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 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>
 2026-08-23 21:47:30 -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
Auree Aubert 8b36982db4 cargo-orchestration 1.7.0: draw the workflow (#100) 
* cargo-orchestration 1.7.0: draw the workflow

Nothing in the bundle told an agent to show a node graph as a picture. The
only nudge was one line in interaction.md — "a compact node-flow sketch or
table beats prose" — which left the format to the model, so the plan gate
asked users to approve a graph they had to reconstruct from prose. Every
surface these skills print into renders Mermaid.

- references/node-diagram.md: when to draw one (plan gate, "what does this
  play do", trace reporting), when not to, the shape/edge mapping per node
  kind, cost marking, and the rules that make a diagram true.
- scripts/workflow-to-mermaid.ts: zero-dep TS (Node >= 22.18, 6 fixture
  cases) taking release get / get-draft / template get / an ad-hoc run get /
  a raw node array. Flags: --title, --direction, --paid, --highlight.
- Two doc defects found against a live workspace: release get's documented
  nodes[] was a {uuid, slug, name} summary of the full graph it actually
  returns, and run get carries nodes XOR releaseUuid depending on whether
  the run came from a deployed release.
- Node slugs are not unique within a release (six `variables` in one shipped
  waterfall), so anything walking the graph keys on uuid. Recorded as router
  gotchas, with the knock-on for {{nodes.<slug>...}} ambiguity.
- Call sites wired: plan gate and presenting defaults, router rules,
  nodes.md, the diagnostics trace runbook, and cdk plan.
- CI runs fixtures for every cargo-*/scripts/*.ts, not only cargo-gtm's.

Verified against CLI 1.0.52: every diagram in the reference is script output
from a real release, and each parses under mermaid 11.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* Move the diagram generator into the CLI

`cargo-ai orchestration node diagram` replaces the skill script the reference
was prototyped against. It belongs next to `node validate` — same input, same
free/runs-nothing character — and the sequence now reads validate → diagram →
deploy without leaving the CLI.

- scripts/workflow-to-mermaid.ts and its fixtures deleted; the CI fixture glob
  goes back to cargo-gtm/scripts/*.ts.
- node-diagram.md documents the command: one source per call (--nodes / --file
  / --workflow-uuid / --draft / --release-uuid / --run-uuid), the JSON shape,
  and reading `warnings` out loud rather than drawing over a broken graph.
- --run-uuid absorbs the nodes-XOR-releaseUuid split, so the diagnostics
  runbook no longer has to explain which kind of run it was handed.
- Requires CLI >= 1.0.54 (getcargohq/cargo#5580); the cli-version pin moves in
  the follow-up that ships with that release.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* Refresh skill-metadata content hashes after rebase

The rebase onto main took both sides of the version conflicts in cargo/SKILL.md
and cargo-orchestration/SKILL.md (this branch's 1.20.0 / 1.7.0, which stay ahead
of main's 1.19.2 / 1.6.3), which left the recorded contentHash in the two
skill-metadata.json files stale. Regenerated with skills-metadata.mjs --write;
skills-lint is back to 0 errors.

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>
 2026-08-14 18:06:35 -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
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>
 2026-08-12 00:58:31 -07:00
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>
 2026-08-11 14:42:02 -07:00
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>
 2026-08-09 15:57:34 -07:00
Auree Aubert 895ade0bcc Require a 10–20 record sample and explicit approval before enrolling a full batch (#70) 
* Require a 10–20 record sample and explicit approval before enrolling a full batch

`batch create` / `action execute-batch` fan out across every record in their
data source, so a config mistake and the full bill arrive together. Every
surface that can launch one now requires the same three steps: count the pool
for free, sample 10–20 records through the exact workflow and config, then ask
the user to approve the full enrollment with both the record count and the
credit estimate in the question.

The canonical gate lives in cargo-orchestration ("The sample gate"), with the
sampling mechanics per data kind — `kind: "filter"` + `limit`, `recordIds`, a
sliced `records` array, a truncated CSV — and the note that `kind: "segment"`
and `kind: "change"` take no limit, so they can't be sampled directly.

The GTM cost gate was a 1–3 row pilot, which can't produce a hit-rate, and
hit-rate is what drives the estimate. Split it: 1–3 rows proves one action's
config shape, 10–20 records before any batch. The approval message now states
how many records the full run enrolls alongside what they cost, and approval of
the sample is explicitly not approval of the full run.

Propagated to the router recap, gotchas, and interaction conventions (the gate
holds even when a batch arrives through cargo-orchestration or cargo-cdk with
no GTM framing), and to cargo-cdk (a deployed play's first batch, and the
per-run re-bill of a scheduled one). Aligned the downstream copy that quoted
the old 1–3 row pilot: the execution-planner agent, build-tam, and save-as-play
(whose play pilot was a single record).

Verified against the live CLI: `batch create --help` for where `limit` is
accepted, `segment list` for `recordsCount`/`filter`, and `file upload --file`.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* Bump plugin versions to 1.16.0 and regenerate skill-metadata.json files

Co-authored-by: Auree Aubert <aureeaubert@users.noreply.github.com>

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Cursor Agent <cursoragent@cursor.com>
Co-authored-by: Auree Aubert <aureeaubert@users.noreply.github.com>
 2026-08-08 14:19:47 -07:00
Auree Aubert 9011d5de7c Document folder organization best practice for CDK resources (#62) 
* cargo-cdk: recommend routing managed resources into a labelled folder

Add a best-practice recommendation to place every CDK-managed resource
under a dedicated, clearly-named folder (via each builder's folder:) so
UI users can tell at a glance the resources are owned by code and should
not be hand-edited. Recommend a name convention (⚙️ Managed by CDK — do
not edit / [CDK] <kind> prefix). Documented in the authoring guide and
as a critical rule in SKILL.md.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WQq9CVTLfaX2FHsrojoWny

* cargo-cdk: shorten recommended CDK folder name to a compact prefix

Use a short '🔒 CDK' prefix (e.g. 🔒 CDK Models, 🔒 CDK Agents) instead of
a long label that truncates in the folder tree.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WQq9CVTLfaX2FHsrojoWny

* cargo-cdk: regenerate skill-metadata.json content hash

SKILL.md changed; refresh the derived contentHash so the skills-lint
staleness check passes.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WQq9CVTLfaX2FHsrojoWny

---------

Co-authored-by: Claude <noreply@anthropic.com>
 2026-07-22 15:01:13 -07:00
Auree Aubert 286aaaf981 feat: prompt library + generated skill metadata (#55) 
Rebased onto main (post #53/#54 squash): 38 named parameterized LLM prompts in
six sharded files with a grep-first index (temperature guidance scoped to the
bulk tier; judgment-tier models that reject non-default sampling get no
override), plus a generated skill-metadata.json per skill — typed doc catalog
+ deterministic content hash (code-unit ordering, locale-independent),
produced by .github/scripts/skills-metadata.mjs (--write) and verified by
skills-lint.mjs so stale metadata fails CI. Metadata regenerated over main's
tree, which is why lint was failing before: the catalogs predated main's
email_status recipe fix. cargo-gtm -> 1.4.0.

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
 2026-07-10 00:26:04 -07:00
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>
 2026-07-08 18:41:23 -07:00