TL;DR: A show notes generator is only reliable when it is extracting from something. Feed it the episode transcript and it compresses what was actually said; feed it a title and it invents an episode. Every prompt below takes the transcript as input, and every proper noun still gets checked against the audio.
Why does a show notes generator invent an episode that never happened?
There are two completely different things sold under the same name, and the difference decides whether the output is usable.
The first takes your transcript and compresses it. Summarising, extracting, reformatting, choosing. Language models are genuinely good at that, and the failure modes are mild: a summary that emphasises the wrong half of the conversation, a chapter title duller than the segment deserved.
The second takes your episode title, maybe a guest name, and writes show notes anyway. Headers, timestamps, a bio, a resources list, all of it fabricated, because there was nothing there to extract from. The model does what it always does with a gap: fills it with the most plausible-sounding thing. This is ordinary hallucination, and it is worse here than in most contexts because the output format is so convincing. Nobody looks at a neat timestamp and asks whether it corresponds to anything.
So there is one rule underneath this entire page, and it is not a caveat at the end. Every prompt here takes the transcript as input. If you have no transcript, the honest answer is that you do not yet have show notes, and the next step is transcription, not prompting.
What is in a set of show notes, and what breaks in each piece?
Show notes are not one artefact. They are a bundle of about ten, which is why a single do-everything prompt gives you ten mediocre pieces. Each has a different reader, a different length and a different way of going wrong.
| Piece | Its job | How it fails |
|---|---|---|
| Short summary | Earn the click from a listing or preview card | Truncated from the long one, so it stops mid-sentence |
| Long summary | Tell someone who already clicked what they are getting | Reads like a press release, promises "insights" |
| Timestamped chapters | Let people skip to the part they came for | Timestamps are guessed and drift further as the episode goes on |
| Guest bio | Establish why this person is worth an hour | Job title, company or credential quietly wrong |
| Links and resources | Send people to the thing that was mentioned | Invented URLs, or a real URL for the wrong company |
| Pull quotes | Give the episode a shareable line | Paraphrased, then presented in quotation marks |
| SEO title and description | Get found by someone who was not already looking | Generic, keyword-stuffed, identical every week |
| Social clip list | Feed the clips workflow without re-watching | Clip boundaries that cut mid-sentence |
| Newsletter blurb | Sell one episode inside a wider email | Duplicates the long summary word for word |
| YouTube description | Serve a different platform with different rules | Chapter format wrong, so chapters do not appear |
Read down the failure column and a pattern shows up. Roughly half break because the model invented something; the rest break because someone reused an artefact built for a different job. Both are fixable in the prompt.
Does the transcript need cleaning before anything else?
Usually yes, and it is the cheapest twenty minutes in the workflow. Raw speech-to-text output carries filler words, false starts, missing speaker labels and a scattering of confidently wrong proper nouns, and everything downstream inherits those errors.
The constraint on a cleanup prompt is that it must not rewrite. You want disfluencies removed and punctuation fixed, not sentences improved. The moment the model starts improving sentences, your pull quotes stop being quotes.
Prompt 1: clean the transcript without changing what was said
Clean this podcast transcript for readability. Do not rewrite it.
TRANSCRIPT:
<paste>
Rules:
- Remove filler words (um, uh, you know, like as filler) and false
starts, but keep the speaker's actual word choice everywhere else.
- Fix punctuation and sentence breaks. Do not change vocabulary.
- Do not merge, reorder, condense or summarise anything.
- Keep every timestamp exactly as it appears. Do not add new ones.
- Keep speaker labels. If a label is missing, write SPEAKER UNKNOWN
rather than guessing which speaker it was.
- Output the full cleaned transcript, not a summary.
Prompt 2: flag likely mis-transcriptions before they spread
You are auditing a speech-to-text transcript for likely errors.
TRANSCRIPT:
<paste>
List every proper noun: people, companies, products, books, papers,
places, and every spoken URL, figure or date. For each, output a row:
TERM | TIMESTAMP (or NOT AVAILABLE) | CONFIDENCE (high/medium/low) |
WHY IT MIGHT BE WRONG
Mark CONFIDENCE low for anything that could plausibly be a mishearing
of a more common word or name. Do not correct anything. Do not
substitute a name you think was meant. Your job is to produce a
checking list, not a fix.
Prompt 3: repair speaker labels using context only
This transcript has unreliable speaker labels.
KNOWN SPEAKERS: <host name>, <guest name>
TRANSCRIPT:
<paste>
Reassign speaker labels using conversational context: who asks
questions, who answers, who refers to "my company", who thanks whom.
Where the context does not decide it, write SPEAKER UNCLEAR and move
on. Output the transcript with corrected labels and a short list at
the end of every timestamp where you were unsure.
Where does the transcript go, and what if the episode is long?
One wrapper does most of the work. It carries the episode metadata the model cannot infer, states the no-invention rule once, and defines the tag vocabulary every other prompt reuses. Save it as your house block and put it at the top of everything below.
Prompt 4: the house wrapper
You are producing show notes from a podcast transcript. You may only
use what is in the transcript below. You may not use outside knowledge
about any person, company or product mentioned, even if you recognise
them.
SHOW: <show name>
EPISODE: <number and title>
HOST: <host name>
GUEST: <guest name, role, company — as the host introduced them>
RUNTIME: <hh:mm:ss>
AUDIENCE: <who listens, in one line>
TRANSCRIPT:
<paste>
Rules for every output:
- If something is not in the transcript, write NOT STATED. Never fill
a gap with something plausible.
- Never invent a name, company, job title, book, URL, statistic or
date. If a spoken URL is unclear, write URL UNCLEAR: <as heard>.
- Anything you infer rather than read gets tagged [INFERRED] with a
one-clause reason.
- Quote verbatim when you quote. Never paraphrase inside quote marks.
- Use the show's own vocabulary for recurring segments and in-jokes.
Prompt 5: long episodes, in passes
This transcript is too long to handle in one pass. Work in segments.
TRANSCRIPT SEGMENT <n> OF <total>, covering <start>-<end>:
<paste>
For this segment only, output:
1. TOPICS: every distinct topic, with its first timestamp.
2. QUOTABLE: up to three verbatim quotes with timestamps.
3. MENTIONS: names, companies, books, URLs, figures, with timestamps.
4. OPEN THREADS: anything started here that was not resolved here.
Do not summarise the episode. Do not speculate about other segments.
I will paste the next segment next. After the final segment I will ask
you to merge, and at that point you may only use the segment outputs
above, not new material.
Two-hour interview shows hit context limits, and the symptom is not an error message. It is a model that gets vaguer about the middle of the episode while staying confident about the first fifteen minutes. Segmenting fixes that, and the segment outputs then feed chapters, quotes and links, so nothing gets extracted twice.
How do you write the episode summary, short and long?
Write both, separately. The short one is a hook that has to survive being displayed next to forty other episodes. The long one is for someone who has already looked closer and wants to know whether it earns an hour. Truncating the long one gives you a first line written to be a third paragraph.
Prompt 6: the one-sentence hook
<house wrapper>
Write six one-sentence descriptions of this episode, each under 20
words. Each must name something specific that was actually discussed,
not a category. Rank them by how likely someone scrolling a podcast app
would be to stop. After each, name the specific detail it uses.
Ban: "dives into", "explores", "unpacks", "fascinating", "insights",
"journey".
Prompt 7: the short directory summary
<house wrapper>
Write a 50-70 word episode summary for a podcast directory listing.
Requirements: name the guest and their actual role as stated in the
transcript; name two or three concrete things covered; end on the most
surprising or contested point. No rhetorical questions. No "in this
episode". Do not promise anything the transcript does not deliver.
Prompt 8: the long summary
<house wrapper>
Write a 200-300 word episode summary in three paragraphs.
Paragraph 1: the question this episode is actually about, and why now.
Paragraph 2: what the guest argues, including the strongest specific
example or number they gave, quoted or cited with its timestamp.
Paragraph 3: where the conversation goes somewhere unexpected, and who
this episode is genuinely for.
Use the guest's own framing where they had one. Do not add context from
outside the transcript.
Prompt 9: who should skip this one
<house wrapper>
In under 60 words, and honestly: who is this episode NOT for? Base it
only on what was covered — assumed knowledge, scope, how technical it
gets, which debates it does not touch. Do not soften it into a
recommendation.
That last one looks like a strange thing to publish, and some shows will not want to. Run it anyway, even if it stays in your notes. If the model cannot name anyone the episode is wrong for, your summary is promising everything to everyone.
How do you get timestamped chapters that are actually right?
This is the second big failure mode, after invented facts, and it has a mechanical cause. A model cannot recover timing from plain text. If your transcript carries no timestamps, there is nothing in the input that encodes when anything happened, so a model asked for chapters will produce numbers that look right and are not. They will be evenly spaced, plausibly formatted, and wrong, usually drifting further out as the episode goes on.
The workflow that works is simple: export a transcript that already carries timestamps, which most transcription tools and editing suites will give you as SRT, VTT or timestamped text. Give the model that file and chapters become extraction again.
Then there is the question of format, which depends entirely on where the chapters are going, and the two destinations most shows care about publish different rules.
YouTube reads chapters out of the video description as plain timestamped lines. Its own help page states three requirements: "Make sure that the first timestamp you list starts with 00:00", "Your video should have at least three timestamps listed in ascending order", and "The minimum length for video chapters is 10 seconds" (support.google.com/youtube/answer/9884579, accessed 27 August 2026).
Podcast apps that implement the Podcasting 2.0 namespace read a separate chapters file linked from the RSS feed. The podcast:chapters tag takes a required url and a required type, with JSON preferred as application/json+chapters. The JSON Chapters Format, version 1.2, requires a version string and a chapters array; each chapter object requires only startTime, "expressed in seconds with float precision for fractions of a second", with title, img, url and endTime all optional, and chapter order assumed to follow ascending startTime (Podcastindex-org/podcast-namespace, docs/tags/chapters.md and docs/examples/chapters/jsonChapters.md, accessed 27 August 2026). Whether your host will publish that file, or generate chapters its own way, is a question for your host's documentation rather than something to assume.
Prompt 10: chapters from a timestamped transcript
<house wrapper>
The transcript above carries timestamps. Produce chapters as plain
timestamped lines, one per line, in this format:
MM:SS Chapter title
Rules:
- The first line must be 00:00.
- Use only timestamps that appear in the transcript. Never round to a
neat number that is not there. Never interpolate.
- At least <n> chapters, in ascending order, none shorter than 10
seconds.
- Titles under 50 characters, naming the specific thing discussed, not
the category. "Why they killed the mobile app" beats "Product".
- No chapter for the intro music or the sponsor read unless the
transcript shows one.
- After the list, note any place where you were unsure which timestamp
a topic started at.
Prompt 11: the same chapters as a JSON chapters file
<house wrapper>
Convert the chapter list below into a JSON chapters object.
CHAPTERS:
<paste your verified chapter lines>
Output valid JSON only, no commentary, with a top-level "version"
string and a "chapters" array. Each chapter object has "startTime" in
seconds as a number (convert MM:SS exactly, do not round) and "title".
Keep the array in ascending startTime order. Do not add fields I have
not given you values for. Do not invent image or link fields.
Prompt 12: chapter boundaries when you have no timestamps
<house wrapper>
This transcript has NO timestamps, so do not produce any. Instead,
identify <n> points where the conversation clearly changes subject.
For each, output:
BOUNDARY <n> | verbatim first sentence of the new topic (exact words,
copied from the transcript) | proposed chapter title
I will search for each sentence in my editor to find the real time.
Do not estimate a time. Do not write anything that looks like a
timestamp.
Prompt 13: make the chapter titles worth scanning
Rewrite these chapter titles. Keep every timestamp exactly as it is.
CHAPTERS:
<paste>
Each title: under 50 characters, concrete, using the specific noun from
the conversation rather than a category word. Preserve any term the
show uses as its own jargon. Do not add a title for a chapter that is
not in the list, and do not merge chapters.
Why are names, companies and book titles the most dangerous part?
Because two error sources stack, and the second one hides the first.
Speech-to-text mishears proper nouns more than anything else. They are rare words, often non-English, often said quickly by someone who says them every day. Your transcript will contain a scattering of names that are close to right and not right. Then the model reads that transcript and does something reasonable and catastrophic: it normalises. A slightly odd name becomes the nearest common name. An unfamiliar company becomes a company it recognises. A book title drifts one word toward the title it has seen more often. The output is now clean, confident, and wrong about the guest's own employer.
This is the same underlying behaviour covered in why ChatGPT makes things up, except that here it is aimed at exactly the details a guest will notice.
Prompt 14: the verification worksheet
<house wrapper>
Build me a verification worksheet before writing anything else. List
every item I will need to check against the audio:
PERSON | COMPANY | ROLE/TITLE | BOOK OR PAPER | URL | NUMBER | DATE
For each, one row: ITEM | TYPE | TIMESTAMP (or NOT AVAILABLE) |
EXACTLY AS IT APPEARS IN THE TRANSCRIPT | RISK (high/medium/low)
Mark RISK high for anything that is unusual, non-English, said once, or
could be a mishearing. Do not correct anything and do not fill in what
you think the right version is.
Prompt 15: the short guest bio
<house wrapper>
Write a 40-word guest bio using ONLY what the transcript states about
this guest — how the host introduced them, and anything they said about
their own work.
Do not use anything you know about this person from outside the
transcript, even if you are confident. Do not add a credential, a
company history, a book, or a previous role that is not in the
transcript. Write NOT STATED for any field the transcript does not
cover, and list those fields under the bio.
Prompt 16: the long guest bio
<house wrapper>
Write a 90-110 word guest bio in two sentences of background and one of
why they were the right person for this specific conversation.
Same constraint: transcript only, no outside knowledge, NOT STATED for
gaps. After the bio, list every factual claim it makes as a numbered
line with the timestamp it came from, so I can check each one against
the audio.
Prompt 17: the spoken intro read
<house wrapper>
Write a 25-second spoken intro for the host to read, introducing this
guest and this episode. Conversational, first person, no adjectives
doing work a fact could do. It must contain one specific thing from
this episode that would make someone stay. Transcript only. Give me two
versions with different opening lines.
How do you collect the links and resources mentioned?
Spoken links are the worst input a model gets here. People say "it's on our site", or read out a URL the transcription tool renders as three words. So the correct output is not a tidy list of links. It is a list of mentions, tagged by how resolvable they are, so you know which ones you have to go and find.
Prompt 18: mentions, not links
<house wrapper>
Extract everything mentioned that a listener might want to look up:
tools, books, papers, companies, people, events, articles, products.
One row each:
MENTION | TYPE | TIMESTAMP | CONTEXT (the sentence it appeared in,
verbatim) | STATUS
STATUS is one of:
- URL SPOKEN: <as heard, exactly>
- NAMED ONLY (no URL given)
- VAGUE (referred to but not clearly named)
Never construct a URL. Never guess a domain from a company name. If no
URL was said, STATUS is NAMED ONLY, and that is the correct answer.
Prompt 19: search queries for the ones you have to find
Here are mentions from a podcast episode that have no URL.
MENTIONS:
<paste the NAMED ONLY and VAGUE rows>
For each, write the search query I should run to find the right thing,
using the context sentence to disambiguate. Do not tell me the URL.
Do not tell me what you think the thing is. Just the query, plus one
line on what would confirm I found the right one.
Prompt 20: format the verified links
Format these verified links as a show notes resources block.
VERIFIED LINKS:
<paste, one per line: label | url>
Format: "- Label — one clause on why it came up in the episode"
followed by the URL on the same line. Order them by where they appeared
in the episode. Do not add any link that is not in my list. Do not
change any URL, including trailing slashes.
That last rule exists because models tidy URLs. They normalise a tracking parameter away, drop a trailing path segment, helpfully swap http for https. Sometimes that is fine. Sometimes it breaks a working affiliate link and nobody notices for six months.
Which pull quotes are worth lifting?
A pull quote has one job: it is the line someone screenshots. So it has to be verbatim, because a paraphrase inside quotation marks is an attributed sentence the guest never said, and guests notice. Spoken sentences are messy, and the fix is an explicit elision policy rather than silent tidying.
Prompt 21: verbatim pull quotes with timestamps
<house wrapper>
Find the 8 most quotable lines in this episode.
For each: the quote VERBATIM, the speaker, the timestamp, and one line
on why it lands.
Rules:
- Verbatim means verbatim. You may remove filler words (um, uh) and
you may mark a cut with [...] — nothing else.
- Do not join two sentences from different parts of the episode.
- Do not improve grammar. If the sentence is ungrammatical and still
good, keep it ungrammatical.
- Prefer lines that stand alone without the question that prompted
them. If a quote needs its setup, include the setup as a separate
labelled line, outside the quote marks.
Prompt 22: choose the quote cards
From these quotes, pick the 3 best for graphic quote cards.
QUOTES:
<paste>
For each: the quote as it should appear on the card (under 18 words,
still verbatim, [...] allowed), the attribution line, and one sentence
on who it is aimed at. If a quote cannot be cut to 18 words without
changing its meaning, say so and do not cut it.
What should the SEO title and description say?
Two constraints matter here and they pull in different directions. The title has to make sense to someone who has never heard of your show, and it has to fit the field it is going into. Those fields differ by platform, and podcast hosts differ from each other, so the honest instruction is to parameterise the limit rather than bake a number into the prompt.
Where the platform does publish a number, use it. YouTube's own help page states that "Video titles have a character limit of 100 characters" and "Video descriptions have a character limit of 5,000 characters" (support.google.com/youtube/answer/57407, accessed 27 August 2026). For podcast feeds, Apple's RSS feed requirements page sets technical requirements for the feed itself without publishing a per-field character cap, so the limit you actually hit is your host's. Check your host's documentation, put that number in the prompt, and do not trust a number you saw in a blog post, including this one.
Prompt 23: episode title options
<house wrapper>
Write 10 episode titles, each under <n> characters.
Split them: 4 that lead with the guest's name and their single most
credible identifier; 4 that lead with the most specific claim made in
the episode; 2 that lead with the question the episode answers.
Every title must be understandable to someone who has never heard of
this show or this guest. No colons-plus-vague-subtitle. No "Part 1"
unless the transcript says so. Rank all 10 and explain the top choice
in one line.
Prompt 24: the description field
<house wrapper>
Write the episode description for <platform>, maximum <n> characters,
counted including spaces. Tell me the exact character count.
Structure: hook sentence, then 2-3 sentences of specifics, then a plain
line naming who it is for. Front-load the guest's name and the topic in
the first 100 characters, because that is what shows in a truncated
preview. Plain text only — assume links may not be clickable and no
formatting survives. Do not exceed the limit and then apologise; write
to fit.
Which moments make good social clips?
Clip selection is the piece most likely to be redone by hand: the model cannot hear pacing and cannot see the video. What it does reliably is narrow two hours to eight candidates with timestamps, which turns a re-watch into a spot check.
Prompt 25: clip candidates with in and out points
<house wrapper>
Identify 8 clip candidates of 30-90 seconds each.
For each: IN timestamp, OUT timestamp, the verbatim first and last
sentences, a one-line description of the moment, and the hook in the
first three seconds.
Rules:
- IN and OUT must be timestamps that appear in the transcript.
- A clip must start at the beginning of a sentence and end at the end
of one. Never cut mid-sentence.
- A clip must make sense without the question that prompted it, or the
question must be inside the clip.
- Flag any clip that depends on visual context I would need to check.
Prompt 26: captions and on-screen text
For each clip below, write the platform caption and the on-screen hook.
CLIPS:
<paste your chosen clips with their verbatim opening lines>
Caption: under 125 characters, states what the clip is about, no
"watch till the end". On-screen hook: under 8 words, must be a phrase
that actually appears in the clip. Do not write a hook using words the
speaker does not say.
Clips, the newsletter and the description field are the same conversation aimed at three audiences, which is the general pattern covered in content repurposing. If you also publish the episode to video, the scripting side of that workflow overlaps heavily with YouTube script prompts.
What changes for the newsletter and the YouTube description?
Both are the same source material in a different container, and both fail the same way: someone pastes the long summary in and calls it done. A newsletter blurb competes with three other items in the same email, so it needs a reason to stop now, not a description. A YouTube description has to carry the chapters block, which the feed version does not.
Prompt 27: the newsletter blurb
<house wrapper>
Write a newsletter blurb: 70-90 words, second person, sitting inside an
email with three other items.
Lead with the specific claim or moment most likely to make someone stop
scrolling. One verbatim quote, under 20 words, with attribution. End
with a plain link line, no "click here". Do not restate the episode
description. Do not use the word "episode" more than once.
Prompt 28: the assembled YouTube description
Assemble a YouTube description from these verified components.
SUMMARY: <paste your long summary>
CHAPTERS: <paste your verified chapter lines>
LINKS: <paste your verified links block>
GUEST BIO: <paste short bio>
Order: 2-3 sentence hook, guest line, chapters block, links, bio,
subscribe line. Reproduce the chapters block EXACTLY as given, one per
line, first line 00:00, nothing between the lines. Keep the whole thing
under <n> characters and tell me the count. Do not add anything that is
not in the components above.
Prompt 29: the whole bundle, once you trust the pieces
<house wrapper>
Produce the full show notes bundle in one document, in this order:
1. One-sentence hook
2. Short summary (50-70 words)
3. Long summary (200-300 words)
4. Guest bio (40 words)
5. Chapters (plain timestamped lines, first line 00:00)
6. Links and resources (mentions with STATUS tags)
7. Three pull quotes, verbatim with timestamps
Apply every rule in the wrapper. At the end, output a section called
NEEDS VERIFICATION listing every proper noun, URL, figure and date in
the bundle, each with its timestamp, so I can check it against the
audio before publishing.
Run Prompt 29 only once the individual prompts have taught you what your show's output looks like when it is right. It is a time-saver for episode forty, not a starting point for episode one, and the NEEDS VERIFICATION block is what makes it safe to use at all.
Stop rewriting prompts. Start shipping.
Works with ChatGPT, Claude, Gemini, Grok, Midjourney, Ideogram, Veo3 & Kling. 5.0★ on the Chrome Web Store.
Create An AccountWhat should you check before you publish?
Five checks, and none of them are optional the first ten times.
Did every proper noun get heard, not read? Names, companies, job titles, book and paper titles, spoken URLs, every figure said out loud. Against the audio, at the timestamp, not against the transcript that produced the error.
Do the chapter timestamps land where they claim? Click three at random, including one near the end, where drift shows up first. If your source transcript had no timestamps, this check is the whole ball game.
Is every quote actually a quote? Search the exact string in the transcript. If it is not there character for character, fix it or drop the quote marks.
Does every link resolve, and to the thing that was mentioned rather than a company with a similar name?
Does anything that said NOT STATED in one artefact appear as a fact in another? That is the tell for a later pass filling a gap the first pass was honest about.
None of this is work a generator removes, and it is worth being blunt about what a prompt tool does. Prompt Architects generates and improves the prompt. It is not a transcription tool, it never touches your audio, and it does not write the show notes: the model you paste into does that, with your transcript. What it helps with is the part that decays. The wrapper in Prompt 4 is long, and its no-invention rules are exactly the lines people trim when they are publishing at 11pm. A saved prompt template keeps the full version, so episode forty gets the same discipline as episode one. The free plan covers 5 prompt enhancements per day, per the FAQ page, and saving prompts to a library starts on Pro.
If the chapters JSON in Prompt 11 is the piece you want to get right first, the format-enforcement techniques in the JSON prompt generator go deeper on getting structured output that validates on the first try. And the rest of the free generator prompts we have published are collected in one index.
One last thing worth saying plainly, because the pages that sell these tools rarely do: nothing on this page will get you more downloads. Show notes that are accurate, skimmable and honest are good practice and good manners toward the people who already listen. Whether they move any number on your dashboard is not something this post can tell you, and anyone who claims otherwise is selling you a spreadsheet, not a workflow.