Content From Conversation

Module 3: Content From Conversation

The content creation problem is mostly a framing problem.

People talk about “creating content” as if it’s a separate activity — something you do after the real work, with a blank page and a brief and a deadline. Under that framing, content is a tax on doing things. No wonder most people don’t post consistently.

The frame that actually works: you’re not creating anything. You’re extracting. The content already exists — in the sessions where you solved a problem, the builds where something clicked, the experiments that produced an interesting result. Your job is to make it visible.

That’s a much lower-effort task. And it’s one Claude Code can do most of the work on.

The Pattern

Do something interesting
    ↓
Run the social-media agent
    ↓
Claude reads context / you describe what happened
    ↓
Claude drafts per-platform posts
    ↓
You review and approve
    ↓
Posts queue to Buffer

The key moment is step three. Claude can read files, bash output, git logs — whatever is in your current session. If you just solved a bug, the fix is right there. If you deployed a new feature, the deployment output is right there. You don’t have to summarise anything from scratch.

You might add one sentence of context: “The interesting bit was that the issue was in the timezone handling, not the date parsing I assumed.” Claude takes it from there.

What Claude Looks For

When you invoke the social-media agent after a session, it looks for shareable angles — things that are either useful to others or honest about the process.

Useful angles:

• “Here’s the thing I learned that I wish I’d known”
• “Here’s a pattern I use for X”
• “Here’s a tool/command/approach worth knowing about”

Process-honest angles:

• “I assumed X, the problem was actually Y”
• “This took three hours because I misread the docs — here’s what the docs actually say”
• “Built a small thing to solve this annoying problem”

Both work. Both are what people actually want to read. Neither requires pretending the work was smooth or the insight was obvious.

Batching vs. In-Moment

You can run the extraction either way.

In-moment — Right after something interesting happens, while you’re still in the session. The context is warm. Claude has access to what you just did. This produces the most accurate posts because the detail is right there.

Batched — At the end of the week, you describe a few things that happened. This is less precise but lower friction for people who don’t want to stop mid-session. The posts are a bit more general but still useful.

Most people end up doing both — in-moment for things that felt genuinely useful, batched for anything that slipped by.

The Approval Step

You always review before anything queues. This is non-negotiable — not because Claude gets it wrong (it usually doesn’t), but because you’re the one signing your name to it.

The review typically takes about ninety seconds. You read the three drafts. You approve the ones that sound like you, edit the ones that are close but not quite right, and skip the ones that don’t work. The social-media agent waits for explicit approval before calling post-to-buffer.

Common edits at this stage:

• Trimming jargon Claude didn’t know to avoid
• Adjusting the tone (sometimes Claude is slightly more earnest than you’d be)
• Adding a specific detail Claude didn’t have
• Removing a claim that’s technically true but would read as bragging

The Tone Problem

One recurring issue: Claude sometimes writes in a slightly more polished voice than the post warrants. Social posts that read as marketing copy don’t perform well — they signal that the author is optimising for impressions rather than sharing something real.

If you find drafts consistently landing on the wrong side of that line, adjust the agent instructions. Add something like: “Write as if explaining to a colleague, not presenting at a conference. Use plain language. Don’t over-polish.” It changes the output significantly.

What You’re Not Doing

You’re not running a content calendar. You’re not planning “one LinkedIn post per week” or “three Threads posts per day.” You’re not hiring a ghostwriter or using templates.

You’re doing the work. When the work produces something worth sharing, you extract it. The schedule emerges from what you’re actually doing, not from an editorial plan.

This sounds less productive than a content calendar. In practice it’s more productive, because the posts are real and people can tell the difference.

---

The final module covers the Threads API directly — posting without Buffer when you want more control.