LinkedIn content

The outcome

The proof points, customer stories and lessons the team already wrote down stop sitting in a repo nobody outside GTM reads. Every Monday one agent reads context/ (positioning, proof, clients, insights, objections, alternatives) and the last two weeks of cadence/log/, and drafts three LinkedIn posts for one named author:

1. One on a proof point: a result a customer got, from a proof/ file.
2. One that answers an objection or a misconception buyers bring, without naming a competitor.
3. One from this week: something the team learned, from a dated insight or log entry.

Each draft opens on a hook line, stays under LinkedIn's fold-friendly length, and ends with the files it draws on. A claim with no file behind it is cut. A customer without reference permission is described, never named.

The drafts land as cadence/content/<week>.md in one pull request, [linkedin-content] <week>. A re-run that week finds that pull request by its title, links it and stops; it never opens a second one. To redraft, close the pull request and run it again. The agent has no LinkedIn action at all: publishing is the author's act, done by hand, after review.

Example

Every Monday, draft three LinkedIn posts for our CEO, Dana Ruiz, from what's in context/.

Illustrative output, 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. Nobody noticed
until a quarter's pipeline review. We moved the rules into code with a test
on every field they read, and the leak closed in the first week...

**Sources:** context/proof/fabrikam-routing-leak.md, context/client/fabrikam.md

## 2. Objection: "we already have a CRM admin"

**Hook:** Your CRM admin is not the problem. The spreadsheet next to them is.
...
**Sources:** context/objection/already-have-admin.md, context/insight/2026-10-01-win-loss.md

Three drafts and six cited files landed in the "[linkedin-content] 2026-W41" pull request; nothing was posted anywhere.

Put it in your project

This folder is a worked example: real project resources written for some other company. The job is to end up with the code your company would have written, in your project, and an agent does the adapting. If the cargo-project skill is in your session it carries the long form of this; if not, this is enough.

1. Install it — the CLI does the copy. From inside the project (the folder holding cargo.json), cargo-ai project add cookbook/linkedin-content writes this example to infra/linkedin-content/ and this procedure to .agents/skills/linkedin-content/. No project yet? cargo-ai project init <dir> --cookbook linkedin-content && cd <dir> && npm install does both. If you are reading this from the project's .claude/skills/, the install already happened — start at step 2.
2. Reconcile it with what is already declared. If the project already has a GitHub or Anthropic connector, rewire the imports to the existing one and drop the copy; two resources with one slug is a collision at deploy.
3. Name the author. Set CONTENT_AUTHOR in infra/agents/content-writer.ts to the person the posts are written as. The prompt refuses to run while it reads PLACEHOLDER. references/post.md (installed beside this file) is the draft shape.
4. Adapt. Work the sections below in order: What should not change is what you argue back about (say what breaks, then do it if they still want it); What you can change is what you offer unprompted; What you will be asked is the floor, and you derive before you ask. Record what you changed and why under a ## Decisions section in your copy of this file.
5. Check, then plan. node --import tsx evals/contract.mjs from this skill's folder, then npm run check && cargo-ai project plan from the project root. Show the diff, and deploy only on an explicit yes: cargo-ai project deploy. Never cargo-ai project init --force into a non-empty directory.
6. Verify. Send the agent its trigger text once by hand (cargo-ai ai message create), and walk Done when line by line. Then send it again: it must update the same pull request.

What you will be asked

Derive before you ask. Only the inputs marked asked genuinely live in the operator's head.

Checked before moving on, not after the deploy:

• cargo-ai project check prints agent:linkedin_content_writer bound to <your repo>#<branch> with no trailing infra/
• context/ has at least one file under global/ and one under proof/ or insight/
• node --import tsx evals/contract.mjs passes

What you can change

What should not change

• Nothing on the agent can publish. (infra/agents/content-writer.ts) No LinkedIn action of any kind: no like, comment, connect, follow or message. An agent that can act on LinkedIn can speak as a person in public, and one bad draft becomes a post with the author's name on it. The contract fails if any of those lands on uses.
• Every claim has a file. (infra/agents/content-writer.prompt.ts §3) A number with no source is the fastest way to have a customer correct the author in the comments. Cut it rather than soften it.
• A customer without reference permission is not named. (§2) The client/ file's reference_permission is what the team agreed to. Naming a customer who did not agree is a relationship problem, not a content one.
• One file and one pull request per week. (§1) The re-run check is what keeps a second Monday trigger, or a manual run, from opening a duplicate that a reviewer merges by mistake.
• No context capability, and no writes under context/. (infra/agents/content-writer.ts) The drafts read the knowledge layer; they do not change it. A capability would be a write path that skips the review every other pipeline goes through.

Done when

• node --import tsx evals/contract.mjs passes
• cargo-ai project plan reports the agent, the two connectors and the folder
• the first run opened one pull request, [linkedin-content] <week>, containing only cadence/content/<week>.md in the references/post.md shape
• every draft lists its sources, and every number, customer and quote in it appears in one of them
• no customer whose client/ file lacks reference permission is named
• a second run the same week linked the open pull request, opened no second one and changed nothing
• nothing was posted to LinkedIn or anywhere else

What it costs

No connector action runs: the agent reads files in its checkout and opens a pull request through GitHub. The recurring cost is the harness run itself, once a week, billed as LLM tokens through the Anthropic connector, and it scales with how much of context/ and cadence/ there is to read.

The performance-report variation adds one paid LinkedIn action per run. Before adding it, read its live price: cargo-ai orchestration action list extractProfilePostActivity --kind connector --integration-slug linkedin, and say it out loud.

Composes into

call-capture, win-loss-review and web-capture (they write the proof, insights and objections the drafts are built from), and standup (whose log entries are this week's material).