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

15 Commits

Author SHA1 Message Date
Auree Aubert 69f8642cb5 cargo-analytics 1.5.0: describe what the run exports actually return (#98) 
* cargo-analytics 1.5.0: describe what the run exports actually return

`run download` was documented as returning "each run as a JSON object with
status, timing, executions, and runContext.<nodeSlug> containing per-node
outputs". It returns a signed URL to a gzipped CSV with one column per node
slug holding that execution's `title` — the truncated summary the diagnostics
runbooks call "never evidence". No runContext, no executions, not JSON.

- Rewrites the run download section around the real columns, with a warning
  to treat it as a status board across runs, not as node output.
- Corrects run download-outputs: --output-node-slug is optional (falls back to
  the last executed node), each row is input + output, and without --limit the
  file covers every matching run.
- Adds a section answering "can I get runContext for several runs at once" —
  you can't: it is a per-run S3 object and run get is the only command that
  hydrates it. Orchestration SQL is ruled out explicitly.
- Marks --is-finished broken in the six snippets that taught it; it returns
  400 unrecognized_keys on all four run commands. Replaced with
  --statuses success,error.
- Fixes the partial-retry pattern in polling.md, which piped run download
  stdout into jq '.recordId' — impossible against a signed URL to a gzipped
  CSV whose column is _record_id.
- response-shapes.md gains entries for both run exports and corrects batch
  download, which also returns {"url": …} rather than streaming to stdout.
- Adds the 500 case to analytics troubleshooting.

Verified against CLI 1.0.52 and the backend source. Underlying defects are
fixed in getcargohq/cargo#5579; these docs describe today's behavior.

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

* Drop the --is-finished caveats; the fix is a backend deploy

The caveats dated the docs against a deploy the bundle can't observe, and my
stated reason for them was wrong: cargo#5579 changes no CLI code for
isFinished (0 occurrences in its packages/cli diff) — the flag was always
sent, the API route schemas rejected it. So the fix lands when the backend
deploys, independent of the cli-version pin.

Examples keep --statuses success,error, which expresses the same filter and
is correct before and after that deploy, so nothing here expires. The specific
400 is replaced by a generic `400 unrecognized_keys` troubleshooting row that
stays useful whatever the flag, and points at report create.

Also drops "until the fix ships" from the 500 row, for the same reason.

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

* Restore --is-finished: it is wider than success+error

Swapping the flag for `--statuses success,error` was semantically wrong, not
just verbose. `isFinished` maps to `finished_at IS NOT NULL`, and cancelled
(cancelRuns.ts:94) and skipped (launchRuns.ts:151) runs stamp finishedAt too.
Skipped is routine — checkToSkipRuns marks records skipped as ordinary dedupe
behaviour — so the substitution would silently under-report on any play that
skips records.

exports.md and run-analytics.md revert to their original content: their
--is-finished examples were correct all along. The run download section now
shows both forms with a note that they are not interchangeable.

The flag still 400s until cargo#5579 reaches production, which is a backend
deploy independent of the CLI release; the generic 400 unrecognized_keys row
in troubleshooting.md covers that window without dating the docs.

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

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-14 17:24:10 -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
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 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 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>
 2026-07-09 18:41:11 -07:00
Auree Aubert c7bec7d8c4 Share prerequisites, lint SKILL.md, deep-link the router (#33) 
- Extract the duplicated install/login/output-conventions block from every
  capability skill into cargo/references/prerequisites.md. Each capability
  skill now links to it instead of redefining ~16 lines of boilerplate.
- Add CHANGELOG.md so per-skill version bumps are tracked alongside the
  reason for each bump, and capture the current version snapshot as the
  historical baseline.
- Add a CI skill-lint job (.github/workflows/skills-lint.yml +
  .github/scripts/skills-lint.mjs) that validates SKILL.md frontmatter
  shape, internal markdown links, fenced JSON snippets, and that bash
  examples reference real cargo-ai domains. Catches drift before users do.
- Reorder cargo-connection so the integration/connector key concepts sit
  above Prerequisites (where they're needed before reading commands), and
  tighten the integration get vs native-integration get table with ✓/✗
  markers to make mis-routing harder.
- Deep-link the skill graph in cargo/SKILL.md so each row in the
  capability table jumps straight to the target SKILL.md, with the
  in-page recap available as a secondary link.
- Bump versions on each touched skill.

Co-authored-by: Claude <noreply@anthropic.com>
 2026-05-28 15:11:38 -07:00
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>
 2026-05-28 12:53:17 -07:00
Auree Aubert 1b62ca6f0f Normalise reference layout across skills (#28) 
Move per-command examples in cargo-orchestration from
references/*.md into references/examples/*.md to match the
established standard used by cargo-ai, cargo-analytics,
cargo-billing, cargo-connection, cargo-storage, and
cargo-workspace-management. Concept references (filter-syntax,
nodes, polling, response-shapes, troubleshooting) stay at the
references/ root.

Add a cargo-context/references/response-shapes.md stub so context
also matches the standard layout. conventions.md keeps its
top-level slot as a concept reference (the same pattern that
filter-syntax/nodes/polling occupy in orchestration).

Rewrites all inbound cross-references in cargo-analytics,
cargo-gtm (SKILL, agent, guides, recipes), cargo-orchestration,
and cargo-workspace-management.

Co-authored-by: Claude <noreply@anthropic.com>
 2026-05-28 12:26:49 -07:00
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>
 2026-05-28 11:17:40 -07:00
Claude 4c890af8ab Refer to storage instead of data warehouse 2026-05-12 20:25:36 +00:00
Claude ebff1e4a1a Document orchestration query and drop systemOfRecordIntegration query references 
The CLI exposes two read-only SQL surfaces: storage query (data warehouse,
<datasetSlug>.<modelSlug>) and the newer orchestration query (runtime
tables: runs, batches, spans, records). Skills now teach both and stop
referencing the deprecated systemOfRecordIntegration query/download/fetch
and other system-of-record subcommands.
 2026-05-12 18:37:38 +00:00
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.
 2026-04-29 01:38:08 +00:00
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>
 2026-04-27 15:25:33 -07:00
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>
 2026-04-27 14:03:20 -07:00
Claude 0ca33f497f refactor: rename cargo-cli-* skills to cargo-* 
Drop the redundant `-cli-` infix from the seven skill directory names
and update all cross-references in the markdown docs to match.
 2026-04-27 03:25:05 +00:00