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 #
- 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 inSTANDUP_TIMEZONE. - 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 whenghis available, and the cadence files named for that date. - 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). Ifwhoamifails, it says so on the pull request and works from the dump alone. - It writes the log,
cadence/log/<date>.md, in three sections: What moved, What is stuck, Worth remembering. Each is framed by the files ininitiatives/withstatus: 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”. - It opens one pull request,
[cadence] log <date>, never merged by the agent. - 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 #
- 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 inPLANNING_TIMEZONE. - It runs the collector,
scripts/weekly-planning/collect/week.ts, which writescadence/log/raw/planning/<week>.md: last week’s commits, pull requests, initiative inventory, declared infrastructure, and cadence files dated in that week. - It reads the workspace the same read-only way: what is deployed, last week’s runs and failures, usage.
- 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. - 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 shapecargo-ai project initscaffolds.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
channelIdset to the one channel the digest may land in. - Timezones and labels:
STANDUP_TIMEZONEandSTANDUP_TITLE(the name in the digest header), andPLANNING_TIMEZONE. Change each timezone together with its cron. @cargo-ai/cdk1.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-aicommand 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 touchplan/orinfra/. - 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 #
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 #
The day’s git commits and pull requests, the cadence files dated that day, and the workspace through read-only Cargo CLI calls: run counts, failures, credits spent and what is deployed. It never asks anyone for an update.
No. It opens one pull request per active initiative. The daily standup is the only one of the two that posts to Slack.
The standup groups the digest by the work itself, and the weekly planner opens one workspace pull request covering what is deployed, what ran and what it cost.
No. The channel is locked on the Slack action in code. The agent fills only the message body.