Podcast Show Notes That Sound Like You

You paste a transcript into an AI model and get back show notes that are accurate, tidy, and could belong to any podcast on any topic. Every fact is right. None of it sounds like you.

The reason is simple. Without other instructions, a language model writes the version that fits the widest range of shows, because that is the safest guess. Your show is not the widest range. It has a rhythm, a way of introducing guests, jokes that recur, and words you would never say. The model has no way of knowing any of that unless you show it.

This post explains how to build a voice guide, a short document that gives the model evidence of how your show actually sounds. It includes a script that measures your style from your own transcripts, a template, a before and after example, and a six-question test for checking whether the output passes as yours.

What generic sounds like

Generic AI copy has recognizable habits. Wikipedia's editors maintain a field guide to them, Signs of AI writing. The ones that show up most often in show notes:

If you spot several of these in one paragraph, you are reading the model's default. A voice guide exists to replace the default with yours.

Why adjectives do not work

The first instinct is to write a voice guide made of adjectives: warm, curious, conversational, plain spoken. That describes half the podcasts in existence, and a model can satisfy it while still writing generic copy. Adjectives are a description of a feeling. What the model needs is evidence: your actual sentence lengths, your openings, your recurring phrases, and examples of your writing it can imitate.

The five steps below collect that evidence.

Step 1: Collect samples of your voice

Gather transcripts from three to five episodes you consider representative, and a few pieces of your own writing, such as a newsletter or a post you liked. Two rules keep the sample honest.

• Use host speech only. If your transcripts are labeled by speaker, filter out the guest. A guide built from a guest's speech will describe the guest.
• Choose episodes you would happily reuse. A guide built from your weak episodes teaches the model your weak habits.

Save the host-only text as .txt files in one folder.

Step 2: Measure, do not guess

Most people describe their own style badly. Measuring it is quick. This script reads a folder of host-only transcripts and reports your average sentence length, the most common ways your sentences begin, and the words you lean on.

#!/usr/bin/env python3
"""Measure how a host talks: sentence length, sentence openers, favorite words."""
import re
import sys
from collections import Counter
from pathlib import Path

SKIP = set(
    "the and but for with that this you your they them was are not have has had "
    "does did just like really very from what when then than there here into "
    "about would could should been were will can its our out all one get got".split()
)


def main(folder):
    text = " ".join(p.read_text(errors="ignore") for p in Path(folder).glob("*.txt"))
    sentences = [s.strip() for s in re.split(r"(?<=[.!?])\s+", text) if s.strip()]
    lengths = [len(s.split()) for s in sentences]
    openers = Counter(" ".join(s.split()[:2]).lower() for s in sentences if len(s.split()) > 2)
    words = re.findall(r"[a-z']+", text.lower())
    favorites = Counter(w for w in words if w not in SKIP and len(w) > 3)
    print(f"sentences: {len(sentences)}, average length: {sum(lengths) / len(lengths):.1f} words")
    print("top openers:", openers.most_common(8))
    print("top words:", favorites.most_common(15))


if __name__ == "__main__":
    if len(sys.argv) != 2:
        sys.exit("usage: voice_stats.py <folder-of-host-only-txt-files>")
    main(sys.argv[1])

Run it with python3 voice_stats.py host-transcripts. Spoken transcripts split on pauses and false starts, so treat the sentence length as a rough guide and compare it against your written work rather than a fixed target. The openers and top words are the useful parts. If half your sentences begin with "So" or "Okay," that belongs in the guide. If a common word from a generic show-notes template appears nowhere in your list, that belongs in the guide too.

Then read three or four transcript pages yourself and note what the numbers miss: how you introduce a guest, what you say when you disagree, where the jokes come from, how you close.

Step 3: Write the guide

Keep it to one page. A long guide gets ignored, by the model and by you. Use this template:

# Voice guide: [show name]

## Sound
- Average sentence: [N] words. Short sentences for emphasis, longer ones to explain.
- I open with [a claim / a story / a question], never with the topic announcement.
- I address the listener as [you / no one in particular].
- Humor: [dry, self-deprecating, none]. Never puns.

## Always
- Name the guest and what they do in the first two sentences.
- Use concrete numbers and names from the episode.
- [Any recurring phrase or structure that belongs to the show.]

## Never
- "In this episode," "dive deep," "delve," "unpack," "game-changer"
- "Whether you're a beginner or a pro"
- Closing lines that sell the episode.
- [Add every miss you catch.]

## Show notes structure
1. Two to three sentence hook in my voice.
2. Five timestamped highlights, each one sentence.
3. Links mentioned, exactly as spoken.

## Examples of the real thing
[Paste two show-notes entries you wrote by hand and were happy with.]

The examples section matters most. A rule such as "sound conversational" is ambiguous. Two real paragraphs in your voice are not.

Step 4: Give the model the guide, and check the output

Put the guide in whatever context your setup reads first. In Claude Code that is a file such as voice-guide.md referenced from CLAUDE.md. In a chat interface it can be the first message, or a project instruction if your tool has one. The starter CLAUDE.md in our Claude and ChatGPT workflow post shows one way to wire it in.

Ask for show notes for an episode you already wrote by hand, so you can compare.

Step 5: Test it blind

Generate two versions of the same show notes: one with the voice guide and one without. Give them to a co-host, a friend who listens, or yourself a few days later, and ask which one sounds like you. If the guided version does not win clearly, the guide needs more examples, not more adjectives.

For any single output, run these six checks:

1. Would I say this out loud?
2. Does it open the way I open?
3. Does it contain a word or phrase from my Never list?
4. Does it claim anything that is not in the episode?
5. Is the length close to my usual?
6. Could this paragraph appear on another show unchanged?

A yes on question 3, 4, or 6 is a fail. Fix the output, and add whatever caused the miss to the guide.

A before and after

Here is an invented example. The excerpt is made up for this post: a host of a solo show about selling online courses, speaking in short, plain sentences.

Transcript excerpt:

Okay, so here's the thing about pricing. Most people guess. I guessed for two years. Then I asked ten customers what they'd paid the year before. It was more than I charged. So I raised the price by 30 percent and nobody left.

Show notes without a voice guide:

In this episode, we delve into the crucial topic of course pricing, exploring how creators can navigate the complex landscape of value-based pricing. Whether you're a beginner or a seasoned pro, you'll walk away with actionable insights to elevate your business.

Show notes with a voice guide:

Most course creators guess at their price. I guessed for two years, until I asked ten customers what they'd paid the year before. It was more than I charged. I raised the price by 30 percent and nobody left.

The second version adds nothing that is not in the transcript. It is also shorter, which is a common result: much of what makes the first version sound generic is filler.

Keep the guide alive

Your voice drifts, and a guide written once goes stale. Two habits keep it useful.

• Every time you edit AI output, note why. If you keep deleting the same phrase, it belongs on the Never list. If you keep restoring the same kind of sentence, it belongs in Always.
• Refresh the examples every few months with your best recent work.

This is the same idea that Dan Vega describes for his Claude Code skills, where he keeps a log of pitfalls and refines after each one. The guide is a document you tend, not one you finish.

What a voice guide cannot do

A guide narrows the output. It does not give the model your opinions, your memory of the recording, or your sense of what mattered. It also cannot verify facts, so a fabricated detail can still slip through in your voice, which makes it harder to spot. One read-through by you before anything is published is still the step that turns a draft into your show notes.

Checklist

• Three to five host-only transcripts saved
• voice_stats.py run and the numbers noted
• One-page guide written from the template
• Two hand-written show notes pasted in as examples
• Blind test done against a version with no guide
• Never list updated after every miss