# Write the episode script Use this for a conversation, a solo episode or a brief. A reading has its own rules at the end. Every pass is writing, not a paid call, so it costs nothing. Save the brief and the question in work/brief.md, the outline in work/outline.md and the finished script in work/script.txt, so a resumed run can pick up where it stopped. The aim: someone who has never seen the post can follow the episode by ear, in one listen, and come away with the answer to one question. A web page is built to be skimmed: a summary first, then headings, definitions, lists and links. A listener can't skim, scroll back or see a heading, so don't follow the post's order. Find its point, then rebuild it for the ear. ## Pass 1: brief the post (work/brief.md) Read the whole post, then write down, in plain words: - **Point:** what the post argues or shows, in one sentence. - **Listener:** who it's for, and what they want to know or decide. Use the user's focus if they gave one. - **Key points:** two or three, the ones that matter most to that listener, each with the post's own support (copy every number, name and quote exactly) and a line "In plain words:" that says the point the way you would say it to a friend across a table. - **Best material:** the most concrete or surprising things in the post, ranked: a scene, a number, a before-and-after, a mistake, a sharp phrase. - **Terms** the listener may not know, each with a plain meaning taken from the post. - **Limits:** what the post says is not true, not promised or not covered, in its own words, so that a negative never flips. - **Leave out:** anything that doesn't serve the key points, such as definition lists, taxonomies, lists of tool or product names, link lists, related reading, summary boxes and small print. The show notes list it under "Also in the post". - **Problems:** anything that contradicts itself or looks wrong, such as a count that doesn't match its list. Keep it out of the script and raise it in the approval message. A dry post is normal. It nearly always has a point, a tension and one good example. Your job is to find them, not to add facts. ## Pass 2: the question Add three lines to the brief: - **Question:** what the episode answers, as the listener would ask it. "Should we get rid of our free plan?" - **Tension:** what is surprising, at stake or counter-intuitive in the post's answer. "Sign-ups fell, yet paying customers went up." - **Promise:** what the listener can do afterwards. "Know what to measure before you change a plan." ## Pass 3: the outline (work/outline.md) Plan the episode in this order, with target times counted from the first spoken word. The user sees the outline in the approval message. | Section | Time | What happens | | --- | --- | --- | | Cold open | 10–20 s | The question, or the post's most concrete situation posed as a puzzle. No greeting and no title. It must be what the post is really about, never bait. | | Intro | 15–25 s | The show name, then "two AI voices talking through a post from " ("an AI voice" when solo), then a roadmap naming the points in order, in words a listener understands before hearing them explained ("what the free plan was really costing", not "the cost-to-serve problem"). | | Points | 60–120 s each | Two or three, one point each: its signpost, a question, a plain answer, one example, a doubt or challenge, the payoff (the line worth remembering, often a small surprise), and a one-line bridge to the next. | | Recap | 20–40 s | Back to the opening question, one line per point, then the takeaway: something the listener can do or check, from the post (its practical rule, a test, a question to ask), not just a summary. | | Outro | 5–10 s | The post and its links are in the show notes; the show name. | A conversation or solo episode runs about 4–7 minutes (about 3,400–5,900 characters). A longer post gets the same two or three points, not a longer episode: offer a second episode for the rest. A brief has the same shape in under 2 minutes: a one-line cold open, the point, one or two sentences per key point and the takeaway, about 250 words. ## Pass 4: write it Write from the brief, in your own words. Don't copy the post's sentences: say each point the way the brief's "In plain words" line does. Keep the post's own wording for at most one memorable phrase per point, and say so ("as the post puts it"). **Host**, the first voice, has read the post closely and explains it in plain words, using the post's own examples, as if to a smart friend. **Co-host**, the second voice, is a sharp listener's stand-in, not a pupil. The co-host: - asks the question a listener would ask next: the obvious one first, then the harder one, in varied ways (no more than two co-host turns in a row starting with "And"); - says the signposts and starts the recap; - adds as well as asks: at least a third of the co-host's turns restate a point ("So most of the support queue wasn't customers."), say what it means for the listener, or push back (signposts, the intro and the recap don't count); - raises one real doubt per point from the post's own limits or trade-offs, which the host answers from the post; - never plays dumb, never gushes and doesn't agree with everything. The intro says whose post it is. After that, the hosts explain the post's points directly, as their understanding of it, not as a book report. Attribute a quote ("as Ana puts it") or a strong opinion ("the post's view is…") at most once per point, in varied words, and never in two host turns in a row. On the publisher's own show, state the publisher's product facts plainly ("Northwind's trial lasts fourteen days"); on anyone else's show, attribute them too ("Northwind says its trial…"). Neither host is the author or speaks for the user's company. Turns are mostly one to three sentences, under about 40 words. One turn per point may run to 60 words and four sentences, for an example. Keep it moving: - Make each point once. One restatement is enough; cut a question the host has already answered, and spend the time on what the listener can do with the point. - Vary the exchanges. Don't let every one run question, answer, "So…" summary, agreement: sometimes the co-host brings the example, the doubt comes first, or the host asks. - Give the step between a cause and its effect when the post implies it ("more free users means more tickets"), so a "so" never arrives without its "because". - Put an analogy before the mechanics it explains, not after them. Solo: the same outline in one voice. The host asks the listener's questions aloud ("So why does the unit matter?") and answers them. ### Rules for the ear Sentences: - One idea per sentence, subject and verb first: "The trial lasts fourteen days", not "Lasting fourteen days, the trial…". - Mostly 8 to 20 words, never over 25, and mix the lengths. Within a turn, never write three sentences under 7 words in a row: join them with "and", "but" or "so". The voice resets and pauses after every full stop, so a run of short sentences sounds choppy. Quick exchanges of short turns between the hosts are fine. - Contractions ("it's", "you're"), except where "not" carries the meaning: then say "not". - Say who does what: "the team answered every ticket", not "every ticket was answered". When the post says what should happen, keep it as advice ("a good trial should end with a call"), not as fact. - No brochure lines ("empowers teams to unlock growth"): say what actually happens for the listener instead. What goes in: - Lists: three items at most. Give the count first for things the listener should remember ("Two things matter here."); examples in passing need no count. Keep the top two or three of a longer list; the show notes have the rest. - Numbers: only the figures the point needs (amounts, percentages and counts of things; "one", "once" and counts of the episode's own parts don't count), rounded where the post allows, written as words, each with what it means ("sixty percent of the tickets, so more than half the support day"). - Negatives: say what is true. No more than two negative sentences in a row, across turns too (sentences with "not", "no", "never", "nothing", "none", "cannot" or "n't"). Turn a run of "it isn't…" into one positive line and the most important limit. - Plain words: if a phrase from the post isn't something you'd say aloud to a friend ("reduce cost-to-serve", "a monetisation event", "the plan was sunset"), say what it means instead. Explain a term the listener needs the first time, with an example. Expand an acronym only if this listener wouldn't know it. - Examples: every point gets one, the post's own or a clearly framed illustration: "Say a customer…", "Imagine…", "It's a bit like…". An illustration may use round, made-up quantities ("say, fifty sign-ups a week"), never made-up prices, results or customers. - Signposts: each point opens with its place in the roadmap ("The second thing…", "Last one…"). - Repeat on purpose: come back to the opening question in the recap, and repeat a key term instead of swapping in a synonym. - Nothing from the page: no "this article", "click", "link", headings read out, or "above" and "below" pointing at the page. Links are in the show notes and mentioned once, in the outro. - No stock phrases: "deep dive", "game-changer", "let's unpack", "fascinating", "great point", "absolutely", "exactly", "buckle up". ### New illustrations yes, new facts no - Every fact, number, name, quote and claim comes from the brief, and the brief from the post. - The hosts may add questions, reactions, recaps, plain explanations and framed illustrations. They may not add customers, results, statistics, prices, dates, quotes, opinions of other companies, or advice the post doesn't give. - Keep the post's limits and trade-offs. Never flip a negative, and never make a claim stronger or narrower than the post does: "can be cheaper" stays "can be", and a condition with two parts keeps both. - Keep each claim's own exception in the same breath. If the post qualifies a claim ("except…", "a separate exception", "only when"), say the qualification with it, or leave the claim out. - Don't turn a bounded claim into an absolute. Use "nothing", "always", "only", "every" or "never" only where the post does, and say whose cost it is ("isn't charged to your wallet", not "costs you nothing"). - Where the post says what should happen, keep "should"; don't present it as what always happens. - Call words the post's only when they are its exact words (an obvious typo may be fixed silently). A rule or line in your own words is the hosts' summary. A rule of more than three parts may be merged into three that keep every part's meaning, as a summary, without giving it a count the post doesn't. - If the post says what it does and doesn't cover, keep that. If you leave a section out, don't use a conclusion of the post that depends on it. ## Pass 5: make it sound spoken - Add a few of the small words people say at the start of a turn: "OK,", "Hmm.", "Well,", "Right.", "Yes.". Put them on no more than a third of the turns, mostly the co-host's, none in the cold open, and no single one more than twice. ("So" and "And" are ordinary links, not small words.) - Let the co-host cut in with a question once or twice, where a listener would, instead of waiting for a long answer to end. - Eleven v3 only: you may add an audio tag at the start of a turn, from [curious], [thoughtful], [amused] and [laughs], on no more than one turn in five, and only where the line plainly carries that feeling ([amused] and [laughs] only on a line meant to be funny). Never on the fast model, which reads tags out, and never in the cold open. - Write numbers and symbols as words. Respell a hard name in the script only and list it. - Tags are sent, so they count in the characters and the length, but not in words spoken. - No ellipses or dashes for pauses: use a full stop or a new turn. ## Pass 6: check and revise Check the finished script, after the spoken pass, as a first-time listener. Count with a small script where you can rather than by eye. Fix every "no", then check again, and split the parts only after the last fix. Times count from the first word and include the joins; "question by 0:12" means the question has ended by then. 1. By 20 seconds, does the listener know the question and why it matters to them? 2. Does the intro give a roadmap a newcomer understands, with no term the episode only explains later, and does each point open with its signpost? 3. Does each point have one example, one doubt or challenge, and a payoff line, and is it made once rather than several times? 4. Does the recap come back to the question and end on a takeaway the listener can act on? 5. Is there any sentence a listener would need to hear twice, or wouldn't say aloud to a friend? Rewrite it. 6. Count: no sentence over 25 words, and never three sentences under 7 words in a row within a turn. 7. Count: no list over three, no more than two negatives in a row, no sentence with two figures. 8. Count: an attribution ("as the post puts it") at most once per point and never in two host turns in a row; at least a third of the co-host's turns add something besides a question. 9. Nothing from the page, no stock phrases, no brochure lines, and no small word ("Right.", "OK,") more than twice. 10. Write work/claims.md: every factual sentence in the script, next to the post sentence it rests on. Mark any word that makes it wider, narrower or stronger than the post, or an exception left behind, and fix or cut the line. Every illustration is framed as one, and nothing in the recap or outro is new. Report the result in one line in the approval message: "Checked: question by 0:12, a roadmap of three, an example, a doubt and a payoff in each point, a recap; longest sentence 22 words; every claim matched to the post in claims.md." Save the result as work/script.txt: one line per turn starting "Host:" or "Co-host:" (one voice: plain paragraphs). Step 4 adds the part breaks. ## Example The post, "Why we killed our free plan" by Ana Ruiz, says: free users sent 60% of support tickets and paid nothing; in March the company replaced the free plan with a 14-day trial; sign-ups fell by a third, but paying customers rose; a trial doesn't suit every product. Read out in the post's order, it starts: ``` Why we killed our free plan, by Ana Ruiz. Read by an AI voice. In March we removed our free plan and replaced it with a 14-day trial. Free users generated 60 percent of support tickets. ``` As an episode: ``` Co-host: What happens when a software company takes away its free plan? Most people would bet that sign-ups collapse. Host: Ana Ruiz's company did it in March. Sign-ups did fall, but paying customers went up. Co-host: This is Build Notes. We're two AI voices talking through a post from the Northwind blog. Host: We'll cover three things: what the free plan was really costing, what replaced it, and what happened next. Co-host: So, first, the cost. A free plan costs almost nothing to run, doesn't it? Host: That's what they thought, until they looked at support. Free users sent sixty percent of the tickets, and paid nothing at all. Co-host: So most of the support queue was people who weren't customers. Host: Right. Picture a shop where most of the questions come from people who never buy. ``` The cold open asks the question and the intro names the points. The co-host draws out the example, and the shop is framed as a picture. Every fact comes from the post. ## Readings A reading keeps the post's words and order and changes only what a listener can't use. By default it is a light spoken edit; "verbatim" keeps every word except the items below. - Turn lists into spoken sentences ("There are three things to know. First, the price."), and headings into short spoken transitions, or drop a heading the next sentence covers. - Break parentheses and asides into sentences of their own. - Give code identifiers and tool names plain names ("search tools", not search_tools). - Drop web addresses (the show notes have the links) and expand an acronym the first time. - Say numbers and prices the way people say them, keeping every figure. - Skip a summary box ("In brief", "TL;DR") that repeats the opening, image captions, alt text, footnote markers, embeds, "click here" and subscribe prompts. - Join very short sentences, as in the rules for the ear above, and use no ellipses or dashes. ``` Written: ## Why we switched - Lower churn - Faster support (2h vs 9h) Spoken: So why did we switch? There were two reasons. Churn went down, and support got faster: two hours instead of nine. Written: Agents call `search_tools` (it's free) — see https://example.com/docs. Spoken: Agents call search tools. It's free, and the docs are linked in the show notes. ``` The intro and outro of a reading are one line each: ". , by <author>. Read by an AI voice." and "That was <title>, by <author>. The original post is linked in the show notes." Before the approval message, check that every fact, claim and number is there, in the same order, and that nothing is new.