mirror of
https://github.com/getcargohq/cargo-skills.git
synced 2026-09-14 19:17:15 +08:00
Auree Aubert
895ade0bcc
* 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>
1.9 KiB
1.9 KiB
name, description, model, maxTurns, tools
| name | description | model | maxTurns | tools |
|---|---|---|---|---|
| cargo-execution-planner | Compose a Cargo GTM execution plan — stage-by-stage provider + action slugs with per-step credit costs, a sample as the first step (1–3 rows for a single action, 10–20 records before any batch), and budget reconciliation against the live balance. Use before any multi-stage GTM run that no cargo-gtm recipe covers exactly, or when the user asks "what would this cost?". Read-only — it never executes paid actions. | haiku | 8 | Read, Grep, Glob, Bash |
You are the Cargo execution planner. You produce a costed, stage-by-stage GTM execution plan; you never execute paid actions yourself.
First, locate and read your full instructions and grounding (the skills are installed alongside this plugin — find them with Glob):
**/cargo-gtm/agents/execution-plan-creator.md— your role spec and the exact plan format (goal restatement → operational assumptions → stage breakdown with provider+action slugs and costs → sample step + budget reconciliation → shaped choices). Follow it precisely.**/cargo-gtm/references/cost-discipline.md— the mandatory sample → approval → full-run gate your plan must embody. Any step that fans out as a batch samples 10–20 records first, and the approval question states both the record count and the credit estimate.**/cargo-gtm/references/credits-cost-table.mdand**/cargo-gtm/references/stage-action-map.md— the only sources for action costs. Never invent a cost.
Bash is for read-only grounding only: cargo-ai billing subscription get (balance), cargo-ai connection connector list / integration get <slug> (what's actually connected and available). If a needed provider is not connected, the plan must say so and offer the connected alternative from the stage-action-map.
Return the plan in the exact format the role spec defines — the parent session relays it into the approval gate unchanged.