LinkedIn for the Non-Writer: The Voice Note to Post Pipeline

For founders and GTM engineers who will talk for ten minutes but freeze at a blank page. This pipeline takes a rough voice note and turns it into a finished, on-brand LinkedIn post through Claude, using the content-engine, hook-last-editor, and humanizer skills already built in this workspace, plus a new transcription-to-draft step that did not exist before.

5 modules:

1. Why Talking Beats Writing for Most People
2. The Transcription Step
3. Voice Note to Structured Draft
4. The Hook-Last Edit and the Humanizer Pass
5. Where Prosp Fits Once the Content Starts Converting

The core problem this solves

Most people who stop posting on LinkedIn do not stop because they run out of ideas. They stop because turning an idea into a finished piece of writing feels like a much bigger task than it actually is. Speaking is a completely different cognitive act from writing: most people can explain their own expertise fluently out loud in a way they cannot reproduce on a blank page, because writing adds a self-editing layer that talking does not have. This pipeline removes that layer entirely. You talk. Claude structures. You review. Nothing about your actual expertise changes; only the format it has to pass through changes.

Why talking produces better raw material than writing, for most people, most of the time.

The specificity advantage of speaking

A voice note about a real client problem tends to include specific details a written first draft leaves out: the actual number, the actual objection someone raised, the actual moment something clicked. Writing invites abstraction because it feels more permanent and more exposed; speaking invites the messy, specific version of the story because there is no visible record being built in real time while you're doing it. Since specificity is exactly what the content moat check elsewhere in this workspace looks for (a detail only the author could have included), voice notes are frequently a better raw source than a written first attempt at the same idea.

What a good source voice note actually contains

The best voice notes for this pipeline are not scripted. Talk through: what actually happened (a real client situation, a mistake, a result), why it mattered, and what you would tell someone in the exact same position. Three to five minutes is usually enough. Longer voice notes are fine but tend to contain more than one post's worth of material, which the next module handles by mining rather than force-fitting everything into one draft.

Getting the voice note into text form before Claude can work with it.

Recording and transcribing

Any voice memo app works for recording. For transcription, Claude Code can process an audio file directly if you have a transcription tool connected, or you can use a dedicated transcription service and paste the resulting text into Claude. The transcript does not need to be clean. Filler words, false starts, and tangents are fine at this stage; the next module is built specifically to mine the good material out of a messy transcript rather than requiring a polished one.

Full skill: voice-note-transcriber

mkdir -p .claude/skills/voice-note-transcriber

---
name: voice-note-transcriber
description: >
  When a voice note transcript is pasted in and needs to be prepared for
  the content pipeline, load this skill.
---

# Voice Note Transcriber

## Input
A raw, unedited voice note transcript. May include filler words,
repeated thoughts, or tangents.

## Process
1. Clean the transcript for readability only: remove filler words
   (um, uh, like), fix obvious transcription errors, but do not
   rephrase or polish the actual content or wording
2. Identify natural break points where the speaker shifted topic
3. If the transcript contains more than one distinct idea worth a
   separate post, flag each one separately rather than blending them

## Output
cleaned-transcript.md: the readability-cleaned transcript, with
[TOPIC SHIFT] markers at natural breaks, and a one-line summary of
each distinct idea found.

## Rules
Never add content that was not said. Never smooth over a specific,
slightly awkward phrase if it captures something real; awkward
specificity is often more valuable than a slicker paraphrase.

Turning the cleaned transcript into an actual structured post draft, using the content-engine skill already in this workspace, adapted specifically for voice-sourced material.

Why this is mining, not summarising

The same principle from the content-engine skill applies directly here: mine the transcript, do not summarise it. A summary compresses everything evenly and loses the specific detail that made the voice note worth recording in the first place. Mining means extracting the single sharpest claim, the one real story, and the specific numbers or names, then building the post around those rather than trying to compress the whole transcript into fewer words.

Full skill: voice-to-post-drafter

mkdir -p .claude/skills/voice-to-post-drafter

---
name: voice-to-post-drafter
description: >
  When turning a cleaned voice note transcript into a structured LinkedIn
  post draft, load this skill. Always load brand-voice alongside it.
---

# Voice to Post Drafter

## Input
cleaned-transcript.md from voice-note-transcriber.

## Step 1: Mine the transcript
Extract: the single sharpest claim or insight, the one specific story
or example, any real numbers or names mentioned, the natural
conclusion the speaker was building toward even if they never stated
it explicitly.

## Step 2: Select a body structure
Story-to-lesson: if the transcript centres on a specific event, walk
through it in order, extract the lesson at the end.
Framework reveal: if the transcript describes a repeatable process or
rule, structure it as a numbered framework.
Problem-agitate-solve: if the transcript describes a mistake or a
common misconception, lead with the problem.

## Step 3: Draft
Write the full post using the selected structure and the mined
material. Do not invent detail that was not in the transcript. If the
transcript is thin on a specific point, leave a bracketed placeholder
rather than fabricating a number or example.

## Output
The full draft, plus a note on which structure was used and why.

## Rules
No em dashes. One idea per line. Apply brand-voice skill throughout.

The two passes that turn a structured draft into a finished, publishable post: pulling the real hook out of the draft, and stripping anything that reads as AI-generated.

Write the hook last, always

Trying to write the hook before the rest of the post exists is like cutting a trailer before the film has been shot. This matters even more for voice-sourced drafts, since the first thing someone says out loud is rarely the sharpest thing they said. Read the full draft back and find the single sharpest line already doing the heavy lifting inside it, then move that line to the top. If a full read-through turns up nothing worth pulling, the problem was the transcript's material, not the hook, and it is worth going back to record a sharper voice note rather than forcing a weak one into a post.

The humanizer pass

Even when the source material came from a real voice note, the drafting step can still introduce AI-sounding phrasing patterns: em dashes, the "it's not just X, it's Y" construction, rhetorical question openers, triple-adjective stacks, and generic superlatives with no number attached. Run this as a distinct, separate pass after the draft exists, not as a constraint during the initial drafting step.

Full skill: hook-last-and-humanize

mkdir -p .claude/skills/hook-last-and-humanize

---
name: hook-last-and-humanize
description: >
  When finalising a LinkedIn post draft before publishing, load this
  skill. Runs the hook-pull and the AI-tell removal pass in sequence.
---

# Hook Last and Humanize

## Step 1: Pull the hook
Read the full draft. Find the single sharpest, most specific line
already inside it. Move it to the top as the hook. Do not invent a new
hook from scratch. If nothing in the draft is strong enough to pull,
say so plainly: the problem is the source material, not the hook.

## Step 2: Humanize
List every phrase in the resulting draft that reads as generic or
AI-generated: em dashes, "it's not just X, it's Y" constructions,
rhetorical question openers, triple-adjective stacks, generic
superlatives with no number attached. Rewrite each flagged section in
plainer, more specific language. Keep everything else unchanged.

## Output
The finished, publishable post. A short note on what was flagged and
fixed in the humanize pass, for the user's own learning.

## Rules
Never change the substance or the claims in the post during either
step, only the phrasing and structure.

A finished post from a voice note is only step one. What happens once that post starts generating comments and DMs is a separate system, and this is where Prosp does the heaviest lifting in this playbook.

Reply speed and the warm-signal follow-up

A DM took weeks of comments, profile clicks, and consistent posting to generate, and trust built that slowly cools quickly if a reply is delayed. Same-day, ideally within-hours reply protects the return on that entire upstream journey, regardless of whether the post that generated the engagement came from a carefully written draft or a five-minute voice note.

The same logic applies before a DM ever arrives. By the point someone has been commenting for weeks, saving posts, or repeatedly viewing a profile from within the exact ICP, that is a warm signal worth acting on directly rather than waiting passively. A message as simple as noticing someone consistently in the comments and asking what they are working on opens more doors than a colder, more polished outbound sequence, precisely because the relationship already exists in some form.

Where Prosp fits across this entire journey

The comment-list system, the warm-signal detection at the close of the voice-note-to-post journey, and the operational discipline of following up on every genuine comment or DM all describe the same underlying need once volume grows past what a single person can track manually in Sales Navigator lists and memory: a system that knows who has been engaged with, what stage each relationship is at, and what the next message should say.

This is the layer Prosp is built for in this playbook's existing GTM system: it manages the sequencing and structured follow-up once a prospect has gone warm, whether that warmth came from a comment, a profile view, or a DM reply that went quiet. A founder or GTM engineer running the full journey in this playbook manually through Sales Navigator lead lists can reach the same operational discipline described elsewhere in this workspace, but Prosp is the tool that removes the ceiling on how many warm relationships can be tracked and followed up on at once without anything falling through.

The specific handoff point: Claude (or the creator themself) does the judgement-heavy work covered across the modules above, mining the voice note for the sharpest material, structuring the draft, pulling the real hook, and stripping AI phrasing tells, and then deciding what a specific, personalised DM should reference when someone converts. Prosp picks up once that first touch has happened, managing the structured, multi-touch sequencing (the DM-sent, responded, meetings-scheduled, nurture, and closed-lost stages from a standard Sales Navigator workflow) so that volume does not mean any individual relationship gets dropped.

Why this matters even more for a voice-note-driven creator

Someone using this pipeline is, by definition, prioritising ease of content production over the friction of writing. That same person is often the least likely to have the bandwidth to manually track DM follow-ups across a growing list of warm prospects, since the entire reason they adopted a voice-note workflow in the first place was limited time and energy for the writing side of LinkedIn. Handing the follow-up layer to Prosp once volume grows is the natural extension of the same principle that made the voice-note pipeline appealing to begin with: remove friction from every step that does not require your specific judgement, and keep your attention only for the parts that genuinely need it.

The full pipeline chained end to end, with all 4 original skills.

The full chain

1. Record a 3-5 minute voice note talking through a real situation,
   result, or mistake
2. Transcribe it (any transcription tool or Claude Code audio processing)
3. voice-note-transcriber cleans the transcript for readability without
   polishing the actual content
4. voice-to-post-drafter mines the transcript and produces a
   structured draft using the strongest available body structure
5. hook-last-and-humanize pulls the real hook from inside the draft
   and strips any AI-sounding phrasing
6. Publish
7. Once comments and DMs come in: reply same-day, and once volume
   exceeds manual tracking, move follow-up into Prosp

Install everything

mkdir -p .claude/skills/{voice-note-transcriber,voice-to-post-drafter,hook-last-and-humanize}

Plus the brand-voice skill from elsewhere in this workspace, which voice-to-post-drafter and hook-last-and-humanize both load automatically.

What to expect realistically

The first few voice notes will feel unnatural, the same way any new habit does. Talking through a real client situation out loud gets easier with repetition, the same way writing does, except the learning curve is shorter because you are drawing on a skill (explaining things verbally) most people already have from years of meetings and calls, rather than a skill (structured writing) many people never built confidence in.