To draft LinkedIn posts every week from your own proof points, have an agent read what your go-to-market repository already says (proof points, client stories, objections, dated insights, the last two weeks of the team log), write three drafts for one named author with the source file under each, cut any claim it cannot cite, and open one pull request. The LinkedIn content cookbook deploys that as one Claude Code harness agent on a Monday cron. Nothing is published automatically: the agent has no LinkedIn action at all, and the author copies a draft into LinkedIn by hand, or does not.
The problem: the results, customer stories and lessons the team writes down stay in a repository nobody outside go-to-market reads, while the founder stares at a blank post on Sunday night. Generic ghostwriting fills the gap with claims nobody can back up, and a number with no source is how a customer ends up correcting the author in the comments.
How it works, end to end #
- Monday 14:00 UTC, the agent checks for this week first. The week is the ISO week (
2026-W42). If an open pull request titled[linkedin-content] <week>exists, it replies with the link and stops, so a second trigger never opens a duplicate. - It reads, in order:
context/global/(positioning and offerings),context/proof/andcontext/client/,context/insight/(newest first),context/objection/andcontext/alternative/, the last 14 days ofcadence/log/, and the last eight weeks ofcadence/content/so it does not repeat an angle. Nothing else: no web, no CRM, no Slack, no LinkedIn. - It drafts three posts, one per kind. One built on a proof point, one that answers an objection without naming a competitor, one from something the team learned this week. Each is first person as the author, under 1,300 characters, opens on a hook line, and ends on one question or one action, never on “thoughts?”.
- Every claim has a file. Every number, customer, quote or result in a draft is in a file it read, and the draft lists that file under Sources. A claim it cannot point to is cut, not softened. A customer whose
client/file does not grant reference permission is described (“a 200-person logistics company”), never named. If the context cannot support a kind, it writes fewer drafts and says which file would fill the gap. - One file, one pull request. The drafts land as
cadence/content/<week>.mdin a pull request titled[linkedin-content] <week>, whose body lists each hook and its sources. The agent never merges it. To ask for a redraft, close the pull request and run it again.
A draft looks like this (illustrative, fictional records):
## 1. Proof point: routing fixed in a week
**Hook:** A 240-person freight-audit company stopped losing one inbound lead in six.
Their routing broke every time someone renamed a CRM field...
**Sources:** context/proof/fabrikam-routing-leak.md, context/client/fabrikam.md
Run it #
npm install -g @cargo-ai/cli
cargo-ai login --email you@company.com # emailed code, no browser, 100 free credits, no card
cargo-ai project cookbook view linkedin-content
cargo-ai project init my-gtm --cookbook linkedin-content && cd my-gtm && npm install
# already have a Cargo project? from its root:
cargo-ai project add cookbook/linkedin-content
Set CONTENT_AUTHOR in infra/agents/content-writer.ts to the person the posts are written as, the way they sign their name (the agent refuses to run while it reads PLACEHOLDER), and set languageModel. cargo-ai project plan shows the agent, the two connectors and the folder; cargo-ai project deploy applies it. Before the first run, make sure context/ holds at least one file under global/ and one under proof/ or insight/: the agent can only draft what is written down.
What it needs and what it costs #
| Needs | Why |
|---|---|
| An authorized GitHub connector | The only write path: one branch, one pull request |
| An authorized Anthropic connector | The harness runs on Cargo’s model proxy, billed to it |
Proof points, insights and objections in context/ | The only material a draft may use |
Cost, from the code: no connector action runs. The agent reads files in its checkout and opens a pull request through GitHub, so the recurring cost is model usage for one harness run a week, scaling with how much of context/ and cadence/ there is to read. There is no LinkedIn connector to authorize and no credit-priced action on the agent.
The material has to come from somewhere. A monthly win-loss review writes dated insights and objections from closed deals, and weekly web capture writes what changed on your site and your competitors’. Both land in the same context/ this agent reads.
What it will not do #
- It does not post, like, comment, connect, follow or message on LinkedIn, or anywhere else. The cookbook’s contract fails if any LinkedIn write action is added to the agent.
- It does not write under
context/: it reads the knowledge layer and never changes it. - It does not read the web, the CRM or Slack.
- It does not name a customer without reference permission, or invent a metric, quote or date.
- It does not merge its own pull request or open a second one for the same week.
Frequently asked questions #
No. The agent has no LinkedIn action of any kind. The drafts land in a pull request, a person reads them, and the author copies the one they want into LinkedIn by hand.
Yes, as a second agent with its own slug, its own CONTENT_AUTHOR and its own pull request title prefix. Give each a different first kind of post, because both read the same context and could otherwise draft the same proof point the same week.
Not by default. The cookbook’s performance-report variation adds LinkedIn’s read-only extractProfilePostActivity action with the author’s profile URL locked. It is a paid action, listed at 0.05 credits per item returned, and needs a LinkedIn connector. It never adds a write action.