Your GTM belongs in gitRegister
Blog

A Daily Go-to-Market Standup in Slack and a Weekly Plan from Your Repo

16 Oct
7min read

To run a daily go-to-market standup and a weekly plan without anyone writing them, deploy two Cargo cookbooks: standup recaps each day into your repo’s cadence log and posts a fifteen-second digest to one Slack channel, and weekly-planning ranks last week’s work against your active initiatives every Monday and opens one pull request per initiative. Both read what already happened (commits, pull requests, workspace runs) and neither merges its own pull request. Only the standup posts to Slack.

What the two cookbooks deploy, from their code in getcargohq/gtm-skills on 2026-10-16: standup is 5 resources on a daily cron at 05:00 UTC, weekly-planning is 4 resources on a Monday cron at 15:00 UTC, and each is one Claude Code harness agent plus a committed collector script, with no capability wired on the agent.

The problem, and the answer #

A standup written by hand is skipped on the busy days, which are the ones worth recording, and a weekly plan written from memory favors the loudest bet. The answer is to recap from evidence: a fixed script dumps what happened, an agent judges what it means against the initiatives you declared, and the result is a reviewable diff.

The daily standup, end to end #

  1. The cron fires at 05:00 UTC (0 5 * * *), 10pm Pacific during daylight time, so the day it recaps has ended. The day is computed in STANDUP_TIMEZONE.
  2. The agent clones your repository and runs the collector, scripts/standup/collect/day.ts. It writes one file, cadence/log/raw/standup/<date>.md: the day’s git commits, pull requests when gh is available, and the cadence files named for that date.
  3. It reads the workspace with Cargo’s own CLI, read-only: cargo-ai whoami, the day’s run counts and failures (cargo-ai orchestration run count, run list --statuses error), credits spent (cargo-ai billing usage get-metrics), and what is deployed (orchestration play list, ai agent list). If whoami fails, it says so on the pull request and works from the dump alone.
  4. It writes the log, cadence/log/<date>.md, in three sections: What moved, What is stuck, Worth remembering. Each is framed by the files in initiatives/ with status: active. Anything a founder would lead with (revenue won or lost, a customer escalating, a play failing more runs than it completes, an unplanned spend spike) goes first as “Outside the plan”.
  5. It opens one pull request, [cadence] log <date>, never merged by the agent.
  6. It posts the digest through Slack postMessage, with the channel, format and link unfurling locked on the action, and appends a link to the pull request. It posts once. If today’s three sections already exist, the run already happened and it stops.

The digest leads with one italic sentence saying what the day did to the active initiatives, then one section per initiative that moved or is blocked, a “No movement” line naming every initiative that did nothing, then Stuck and Needs a human. Twelve bullets at most. Counts of the engine’s own activity, such as pull requests merged, are never reported as the story of the day.

The weekly plan, end to end #

  1. The cron fires at 15:00 UTC on Mondays (0 15 * * 1), after Sunday’s standup has landed. The week is the previous complete ISO week in PLANNING_TIMEZONE.
  2. It runs the collector, scripts/weekly-planning/collect/week.ts, which writes cadence/log/raw/planning/<week>.md: last week’s commits, pull requests, initiative inventory, declared infrastructure, and cadence files dated in that week.
  3. It reads the workspace the same read-only way: what is deployed, last week’s runs and failures, usage.
  4. It writes one file per active initiative, cadence/plan/<week>-<initiative>.md, each with the gap and at most three recommendations, each with an owner. With no active initiatives, it writes one workspace file, cadence/plan/<week>.md, covering declared infrastructure, live runs and usage.
  5. It opens one pull request per file, titled [cadence] <initiative> <week>. Splitting them is the point: a reviewer can merge one bet’s plan and send another back, and a blocked bet cannot ride along unread behind one that is on track.

What they need and what they cost #

  • A go-to-market repository with cadence/ at its root, the shape cargo-ai project init scaffolds. initiatives/ is optional; without it, the standup groups by the work and the planner opens one workspace pull request.
  • GitHub and Anthropic connectors for both, and a Slack connector for the standup, with channelId set to the one channel the digest may land in.
  • Timezones and labels: STANDUP_TIMEZONE and STANDUP_TITLE (the name in the digest header), and PLANNING_TIMEZONE. Change each timezone together with its cron.
  • @cargo-ai/cdk 1.0.67 or later.

The collectors talk to git and GitHub from the agent’s environment, not through Cargo connector actions, and the read-only cargo-ai calls are API reads that bill nothing. Slack postMessage carries no credit price in Cargo’s action catalog. The recurring cost is the agent run itself, once a day for the standup and once a week for the planner, billed as language model tokens through your Anthropic connector. There is no per-record fan-out.

What they will not do #

  • Contact customers or write to a CRM.
  • Merge their own pull requests, or run a cargo-ai command that spends or deploys.
  • Edit or delete a raw dump, an existing log section or an existing plan file.
  • Promote a one-off claim into context/, or touch plan/ or infra/.
  • Post anywhere but the standup’s locked channel. The weekly planner never posts to Slack.

Both cookbooks are marked to-be-approved: their acceptance tests have not yet been run end to end against a live workspace, so review cargo-ai project plan before you deploy.

Deploy them #

shellscript
npm install -g @cargo-ai/cli
cargo-ai login --email you@company.com
cargo-ai project add cookbook/standup
cargo-ai project add cookbook/weekly-planning
cargo-ai project plan
cargo-ai project deploy

Signing up from the CLI needs no browser and no card, and comes with 100 free credits. Each cookbook installs on its own, so deploy one without the other if you only need the digest or only the plan. The standup cookbook page and the weekly-planning cookbook page list every resource and placeholder.

To ask questions of the same log from Slack between standups, add one Slack agent the whole team asks about go-to-market. Calls feed the log too: capture every sales call into your go-to-market repo.

Frequently asked questions #

AurelienOct 16, 2026

Give your agents a runtime

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