Your GTM belongs in gitRegister
Cookbooks
Operations

Goal coverage

Find what your goal needs that the workspace has not built: once a week a deployed agent reads the company goal, takes stock of every play, agent, model and connector in the workspace, and suggests at most five missing pipelines from the published catalog, each opened with what it noticed ("thousands of accounts, none scored"), as a pull request you can decline lines in and a Slack post.

Installation
Set up the goal-coverage cookbook in this project. 1. If the Cargo CLI is not installed yet, follow every step in https://api.getcargo.io/INSTALL.md 2. From the Cargo project, run: cargo-ai project add cookbook/goal-coverage 3. Then follow .claude/skills/goal-coverage/SKILL.md. Stop for my approval before any paid call, and stop at "cargo-ai project plan" before deploying anything.
Paste it into Claude Code, Cursor, Codex, Gemini CLI, Devin or Replicas.

Say this to your agent

Every week, look at our goal and what we have running, and tell us which pipelines we are missing.

Illustrative output #

Fictional records, to show the shape of what comes back.

text
Goal coverage, 2026-W44: "Reach $8M ARR by 2026-12-31, up from $5.2M on 2026-06-30."

1. Outbound to mid-market is a third of the forecast and nothing tells you
   when to reach out: 1,840 tier A accounts, none watched for a new hire. Flag
   the week a tier A account hires the role you sell to (`new-hire-detection`).
2. Expansion is $1.1M of the plan and no account is watched for it: 312
   customers, no usage or seat signal on any. Flag the customers ready to grow
   (`expansion-signals`). Needs the HubSpot connector first.
3. Still missing, first suggested 2026-W42: every demo request answered on the
   page (`inbound-qualification`).

Decline or adopt in the pull request: github.example/acme/gtm/pull/212

Three suggestions where five were allowed, each opening on a number from the workspace, and the scoring model declined in W43 is not among them.

Done when #

  • node --import tsx evals/contract.mjs passes: a claudeCode harness bound to an Anthropic connector and a model, runAs a viewer service user, no capability, exactly one connector action (slack.postMessage with the channel locked), and a COVERAGE_GOAL env entry
  • cargo-ai project plan reports the agent, its folder, and the three connectors
  • the first run opened one unmerged pull request titled [cadence] coverage <YYYY-Www> whose diff is exactly cadence/coverage/<YYYY-Www>.md, with the goal quoted verbatim and at most five suggestions, each ending status: open
  • no suggestion names a pipeline that is installed by any of the three signals, or one that is not in the catalog
  • every observation’s number appears in a read listed under ## Checked
  • the Slack post went to the locked channel, once, and links the pull request
  • a second run the same week opened nothing and posted nothing
  • after a suggestion was merged as status: declined: <reason>, the next week’s run did not suggest it

What it costs #

The recurring cost is the harness run once a week, billed as LLM tokens through the bound Anthropic connector. It scales with what the agent reads: the plan file, a few list commands, one or two aggregate queries, the catalog, and up to eight earlier coverage files. The workspace reads are API calls, not connector actions, so they bill nothing, and the run never executes an action that spends. The Slack post is one connector action a week.

Once a week a Claude Code harness agent reads the company goal, takes stock of what the workspace runs, and suggests at most five missing pipelines from the published catalog. Each suggestion opens on what it noticed in the workspace’s own numbers. They land as one pull request and one Slack post.

shellscript
cargo-ai project add cookbook/goal-coverage

Why it is built this way #

  • A harness agent, because the memory is a file. A suggestion declined last week must not come back this week. The reviewer declines by editing a status: line in cadence/coverage/<week>.md before merging, and the next run reads those files. Only an agent with a working tree can write them, and only a pull request lets a human decline in writing.
  • Slack as well, because the reader is not always an engineer. A revenue leader reads the post; whoever merges reads the pull request. Both carry the same suggestions.
  • The catalog is fetched every run. New pipelines show up without a redeploy, and a pipeline that was renamed is never suggested under its old name.
  • Installed means any of three signals: infra/<name>/, a workspace folder named after the pipeline (every cookbook files under one), or a matching play or agent slug. The folder convention is what makes the check cheap and reliable.
  • It does not grade existing work. That is weekly-planning (are the bets on track) and workspace-health (is what we deployed broken). Three agents reporting the same failing play is how a team stops reading all three.
  • At most five. A workspace can install twenty-five pipelines. The point is to say which five matter to this goal, in build order.

Files #

FileWhat it is
infra/agents/goal-coverage.tsthe agent: weekly cron, harness, the locked Slack post, COVERAGE_GOAL
infra/agents/goal-coverage.prompt.tsthe contract: goal, reads, menu, memory, choice, file, PR, post
infra/connectors/Anthropic, GitHub and Slack, all bound with default: true
infra/folders/index.tsthe agent folder, named after the cookbook
evals/contract.mjsthe boundaries schema validation cannot express
evals/acceptance.mdthe walk-through after the first run

Give your agents a runtime

Bring the agents you have.Start free, deploy in one command.