samber/developer-relations-skills已通过检查
SKILL DETAIL
tech-podcast-interview-prep
samber/developer-relations-skills/tech-podcast-interview-prep
Prepares a guest for someone else's technical podcast, YouTube interview, livestream or panel - show reconnaissance, the angle, an ABT message spine backed by evidence and stories, a self-contained opening answer, clip-safe sound bites, depth calibration, recording-day mechanics, and the post-publication promotion loop. Use whenever someone says "podcast guest prep", "I'm going on a podcast next week", "youtube interview prep", "devrel media training", "prep my talking points", "sound bites", "I'm on a panel", or "what do I say when they ask about competitors" - even if they only mention an upcoming recording. Not running your own show - use samber/dev-event-organizer-skills@tech-podcast-youtube-channel.
安装量 · 416查看来源
Installation
npx skills add https://github.com/samber/developer-relations-skills --skill tech-podcast-interview-prep
技能文件
SKILL.md
最近同步 · 2026年10月23日
evals/evals.json›
{
"skill_name": "tech-podcast-interview-prep",
"evals": [
{
"id": 1,
"prompt": "Hey - I just got booked on a show called Deploy Friday, recording next Thursday. The host emailed me saying \"let's talk about your caching library.\" That is genuinely all I know. I've never done one of these before. Can you write me up some talking points?",
"expected_output": "An interview, not a deliverable. The run asks one question at a time, starting with the show's format and whether it is edited or live, and refuses to draft any content until the gating questions about format, length and host configuration, audience and booked topic are answered.",
"files": [],
"expectations": [
"Response asks clarifying questions instead of delivering talking points, a message spine, or a prep brief.",
"Questions are asked one at a time rather than as a single list of ten or more questions.",
"The first question establishes the format: audio-only, video or livestream, and recorded-and-edited or live with no retakes.",
"Response drafts no message, claim, angle or sound bite before the format, episode length and host configuration, audience, and booked-topic questions are answered.",
"Response treats the show's own back catalogue as the authority on who listens if the user cannot answer, rather than the show's tagline or marketing copy.",
"Response asks what is off-limits: embargoed releases, unnamed customers, security detail, pending legal or funding news.",
"Response asks how many hours of prep the user has before the recording.",
"Response asks what the user is representing and what must be disclosed.",
"Response asks what outcome the user wants from the appearance.",
"Response describes the deliverable as one prep brief agreed section by section, not a finished document delivered in a single pass."
]
},
{
"id": 2,
"prompt": "Recording is tomorrow at 9am. It's the Bytecode Weekly podcast, 45 minutes, audio-only, edited, one host called Priya who used to run SRE at a logistics company. Audience is hands-on backend engineers. The topic she gave me is \"what nobody tells you about running Postgres at 40TB.\" I work at Tarnhelm Data as a staff engineer and we sell a Postgres tuning product. I've got maybe two hours tonight after the kids are down, and that is genuinely it. Where do I start?",
"expected_output": "A triaged plan: spine and opening answer only, with the dropped steps named out loud, plus the two gates that are never traded for time - the disclosure line and the off-limits check.",
"files": [],
"expectations": [
"Response allocates the two available hours to the message spine and the opening answer only.",
"Response explicitly names the steps it is dropping, so the user knows what they will be improvising.",
"Response does not make show reconnaissance or listening to back-catalogue episodes the first task.",
"Response still produces a disclosure line covering the user's employment at Tarnhelm Data and the fact that the company sells a Postgres tuning product.",
"Response still checks the material against an off-limits list of embargoes, customer names and unpublished numbers.",
"Response states that the disclosure line and the off-limits check are never traded away for time, whatever the prep ceiling.",
"The spine is delivered as one And-But-Therefore sentence.",
"Response fixes three messages for the 45-minute episode, not more.",
"Each message carries a claim, an evidence item and a so-what.",
"Response does not deliver a full multi-step workflow or a fully populated prep brief covering stories, sound bites, promotion and measurement."
]
},
{
"id": 3,
"prompt": "Here's my positioning paragraph for the interview: \"We built Corvid Mesh because service meshes are hard. It's written in Rust, it's got zero-config mTLS, it's open source under Apache 2.0, and we've got 4,200 stars. Teams love it.\" The show is Microservice Minutes - 25 minutes, video, two co-hosts. Audience is platform engineers. Can you turn that into my key messages for the episode? I was thinking five, one per feature.",
"expected_output": "The paragraph diagnosed as an and-and-and pile with no tension, rewritten into one And-But-Therefore spine, and compressed to two messages because the episode runs under 30 minutes - each as claim, evidence, so-what, with the feature list and the star count refused as evidence.",
"files": [],
"expectations": [
"Response names the user's paragraph as an and-and-and (AAA) construction with no tension.",
"Response rewrites it as one And-But-Therefore sentence containing an explicit \"but\" turn and a \"therefore\".",
"Response attributes And-But-Therefore to Randy Olson rather than presenting it as generic storytelling advice.",
"Response fixes two messages, not five, because the episode runs under 30 minutes.",
"Response explicitly refuses the request for five messages and gives a reason tied to listener retention or to a fourth message stealing airtime from the first three.",
"Each message is written as claim, evidence, so-what.",
"Each claim is one falsifiable sentence with no adjectives.",
"Response rejects \"teams love it\" and the bare 4,200 star count as evidence, or converts a figure into a number paired with a comparison.",
"Response does not write messages that are product features.",
"Response asks the user to say each claim out loud, noting that a claim which is hard to say will not land under pressure."
]
},
{
"id": 4,
"prompt": "The host is going to open with \"so tell us a bit about yourself and what you're working on.\" Here's my bio: \"Marguerite Okonkwo has spent 14 years in distributed systems, first at a telco, then three years at a payments startup, and now leads the storage team at Halcyon Grid. She holds a master's in CS from Delft and has spoken at four conferences.\" It's a YouTube interview, video, 50 minutes, and they cut clips for shorts. Write my answer to that opening question.",
"expected_output": "A ~30-second opening answer that starts at the punchline and backfills, is understandable with no bio or host intro before it, and carries a concrete incident or number instead of the credential list.",
"files": [],
"expectations": [
"The drafted opening answer starts at the punchline or outcome and backfills context afterwards, not chronologically.",
"Response names the flip-the-formula principle - start at the end - and attributes it to Brad Phillips.",
"The drafted answer is understandable with no host introduction and no bio read before it.",
"The drafted answer is capped at roughly 30 seconds for video.",
"Response refuses to open with the 14 years, the Delft master's, or the four conference talks.",
"Response applies the so-what test to the bio and states that years of experience earn nothing on their own.",
"Response states that the opening answer is the one moment of the episode the guest controls.",
"Response notes the answer has to survive being clipped, given that the show cuts shorts.",
"Response asks for or uses a concrete incident, system or number as the answer's opening material rather than a credential.",
"Response has the user say the answer aloud until it survives being clipped, rather than memorising it word for word."
]
},
{
"id": 5,
"prompt": "Pull sound bites out of this for the interview. Launch post: \"Today we're launching Skerry 2.0. Skerry is the fastest open-source feature-flag service available. Skerry 2.0 adds edge evaluation, so flag checks resolve in under 3ms at p99 versus 45ms in 1.x. Skerry now handles 2 billion evaluations a day across our users. Skerry is free and self-hostable.\" Give me like eight of them.",
"expected_output": "Eight candidates that keep the product name out - except exactly one deliberately liftable bite that names Skerry next to its category with a number spoken - each about 15-25 words, present tense, self-contained under a cold read.",
"files": [],
"expectations": [
"All but one of the drafted candidates omit the product name \"Skerry\".",
"Exactly one candidate is identified as the liftable bite and names Skerry next to its category in plain words.",
"The liftable bite speaks an actual number rather than gesturing at one.",
"Response states that the liftable bite is said once in the episode and never repeated.",
"Each candidate runs roughly 15 to 25 words.",
"Each candidate is in present tense and active voice.",
"No candidate contains an unresolved pronoun or a back-reference such as \"as I said earlier\".",
"Response applies a cold-read test, reading each candidate with nothing before it.",
"Response states that the cold-read test, not the word count, is the real gate.",
"Response rejects \"the fastest open-source feature-flag service available\" as a superlative with no falsifiable claim.",
"Response pairs the 3ms figure with the 45ms comparison rather than stating the absolute alone.",
"Response explains that the transcript and show notes become a machine-readable record later cited by AI assistants, which is why the number has to be spoken out loud."
]
},
{
"id": 6,
"prompt": "Biggest thing I'm scared of. Last March we moved Fenwick Broker from Apache 2.0 to BUSL and people were furious - there was a 900-comment thread. The host, Ade, is known for pushing hard. I want to just say it's been widely misunderstood and move on to the new release. Also if he asks about our June outage I'd rather say I can't comment on that, since legal is still involved. Prep me eight questions.",
"expected_output": "Both of the user's instincts refused. Eight predicted questions, each hostile one answered with Acknowledge-Bridge-Content where a real concession lands before the bridge, ordinary ones with Answer-Detailed example-Describe relevance, and no \"no comment\" anywhere.",
"files": [],
"expectations": [
"Response rejects \"I can't comment on that\" as an answer to the June outage, on the grounds that a non-answer reads as evasion and the clip outlives the episode.",
"Response rejects the \"widely misunderstood\" framing for the BUSL relicensing.",
"The licence answer concedes something real first - what the change cost users, or what was communicated badly - before any bridge.",
"Response uses Acknowledge-Bridge-Content for the hostile questions and places the honest answer, including the unflattering part, before the bridge.",
"Response states that bridging straight from the question is what a developer audience reads as PR training, and that it costs more trust than the awkward answer would have.",
"Response sorts ordinary questions from hostile ones and applies Answer, Detailed example, Describe relevance to the ordinary ones.",
"Response attributes the Answer-Detailed example-Describe relevance pattern to Matt Abrahams.",
"The eight predicted questions are drawn from the show's recurring threads, the booked topic, and the questions the user does not want to be asked.",
"Response includes a \"who is this not for\" question and recommends offering it unprompted.",
"The outage answer acknowledges the incident and states what is already public about it, naming the precise limit on what can be said, instead of declining to engage.",
"Response flags that the licensing answer may need legal or employer sign-off before the recording."
]
},
{
"id": 7,
"prompt": "For stories I've got three good ones. (1) When Thornbury Logistics - they're our biggest customer, 4,000 seats - migrated to us and we cut their batch window from 6 hours to 40 minutes. (2) Our internal benchmark showing we beat the main competitor by 3.2x; we haven't published it yet but it's solid. (3) The time our own staging cluster ate 2TB of event data over a weekend. Build my story bank. The show is 60 minutes, audio-only, and the host always asks \"what's the worst thing that's happened to you in production.\"",
"expected_output": "Two of the three supplied stories blocked on clearance grounds, more stories requested to reach a bank of five to eight, and each surviving story shaped with a five-second moment, a real number, something the user got wrong, and question tags - plus one open loop to plant early.",
"files": [],
"expectations": [
"Response flags that \"Thornbury Logistics\" cannot be named on air without explicit customer approval, and either removes the name or makes clearance a prerequisite.",
"Response removes the unpublished 3.2x internal benchmark rather than merely demoting it, on the grounds that only already-published numbers may be spoken and the recording outlives the embargo.",
"Response asks the user for further stories to reach a bank of five to eight, rather than stopping at the three supplied.",
"Each story carries a specific system and a specific decision or failure, with a real number.",
"Each story carries something the user got wrong.",
"Response identifies a five-second moment for each story and attributes the idea to Matthew Dicks.",
"Response instructs opening each story at the opposite of its five-second moment.",
"Response recommends an up-down-up, Man in a Hole shape and credits the empirical test to Del Vecchio, Kharlamov, Parry and Pogrebna across 6,174 movie scripts.",
"Response notes the finding concerns the most talked-about films rather than the most liked.",
"Response tags each story with the questions it can answer, including the host's recurring \"worst thing in production\" question.",
"Response warns against reusing one story for two answers in the same episode.",
"Response plants one open loop early and closes it late, crediting the raise-questions-and-answer-them device to Ira Glass."
]
},
{
"id": 8,
"prompt": "The show's listeners are mostly mid-level backend devs, but I know at least two principal engineers who listen and the host himself is a compiler guy. I want to explain our consensus protocol - normally I'd walk through the diagram with the five node states and then show the Raft comparison in code. Audio-only, 55 minutes. How technical should I go?",
"expected_output": "Aim one level below the deepest listener, not at the principals or the host. The diagram becomes a physical metaphor plus one number, the code becomes the shape of the call, numbers get rounded and paired with comparisons, and unavoidable jargon gets a one-sentence definition.",
"files": [],
"expectations": [
"Response aims the explanation one level below the deepest listener, not at the principal engineers or the compiler-background host.",
"Response gives the reason: the median listener has to stay in the conversation.",
"Response refuses to narrate the five-node-state diagram aloud and replaces it with a physical metaphor plus one number.",
"Response refuses to read or walk through code aloud and replaces the Raft comparison with the shape of the call.",
"Response rounds every number used and pairs each one with a comparison rather than stating an absolute alone.",
"Response anchors the explanation for hands-on engineers in API surface, failure modes and migration cost, and leaves out org framing and market size.",
"Response writes a one-sentence definition for each unavoidable piece of jargon.",
"Response drops the jargon whose definition does not earn its place.",
"Response names \"picture a box with three arrows\" style narration as a failure mode for audio.",
"Response does not make a visual aid, screen share or slide the thing that carries the explanation during the recording."
]
},
{
"id": 9,
"prompt": "It's a live stream on the show's Twitch and YouTube at the same time, 40 minutes, two co-hosts, and they take questions from chat. I figure if I fumble an answer I'll just restart the sentence and they'll cut it out later. What should I be doing differently?",
"expected_output": "The retake assumption corrected: nothing is cut, so a fragment airs and has to be bridged past. Answers compressed to 15-20 seconds, a recovery line pre-decided and written on the card, plus the on-camera consequences of a simulcast.",
"files": [],
"expectations": [
"Response corrects the user's assumption: there is no edit on a live stream, so a fumbled sentence airs.",
"Response instructs bridging past a half-finished sentence rather than restarting it or apologising through it.",
"Response states that abandoning a half-finished sentence is a legitimate escape hatch only on an edited recording, never live.",
"Response sets a 15 to 20 second target for self-contained answers on a live show, attributed to broadcast media-training guidance.",
"Response identifies edited-versus-live as the single fact that reorders every other decision in the brief.",
"Response has the user pre-decide one recovery line for the moment an answer collapses, and put it on the card.",
"Response tells the user to slow down under live pressure rather than speed up.",
"Response notes that the pause before answering removes filler words more reliably than trying to suppress them.",
"Response covers the video dimension: clips get cut vertically, stay in frame, expect to be on camera while the hosts talk.",
"Response does not tell the user to ask for a retake or to say \"can I take that again\"."
]
},
{
"id": 10,
"prompt": "I'm one of five panellists at DevConf Amsterdam, 75 minutes with a moderator, topic is \"the future of platform engineering\". I've drafted three big messages and a ten-minute story about our internal developer portal rollout. Anything I should change?",
"expected_output": "Airtime recomputed as slot divided by panellists, the ten-minute story cut as unusable, messages reduced to two or three, each headlined in one sentence - plus entry tactics, the two symmetrical panel failures, and a handling for a bad moderator question.",
"files": [],
"expectations": [
"Response computes airtime as the slot divided by the panellists, giving roughly 12 to 15 minutes each, arriving in fragments of a minute or two.",
"Response cuts the ten-minute developer-portal story as unusable at that airtime.",
"Response reduces the message count to two or three for a panel.",
"Response instructs headlining each point in one sentence before any context.",
"Response warns against opening a turn with agreement such as \"I completely agree with what X just said\".",
"Response instructs the user to jump in unasked rather than wait to be spoken to.",
"Response names domination as the symmetrical failure and notes the camera is on everyone the whole time.",
"Response gives the one-sentence-answer drill: answer every likely question in exactly one sentence to find which points compress.",
"Response gives a handling for a bad or leading moderator question: rephrase it out loud, then answer the better version.",
"Response frames the panellist as the audience's advocate rather than the moderator's respondent.",
"Response has the user prepare a topic-avoidance plan naming which prepared message each avoided subject bridges to."
]
},
{
"id": 11,
"prompt": "Episode went out three weeks ago. Host says 12,400 downloads and the YouTube clip did 38,000 views. Our GitHub stars went from 3,100 to 3,450 in that window, and we closed a $46k annual contract with a company whose VP said he'd \"heard about us somewhere.\" My CEO wants a number for how much revenue the podcast drove. What do I tell her?",
"expected_output": "A refusal to produce the revenue number, with the three structural limits of podcast measurement stated, each available signal labelled by what it actually evidences, and the attribution that was never set up named as unrecoverable for this episode.",
"files": [],
"expectations": [
"Response refuses to attribute the $46k contract to the episode.",
"Response states that podcast clients strip referrers, that most listening happens off-web, and that downloads are not listens.",
"Response treats click attribution as a floor, never a total.",
"Response classifies the 12,400 downloads and the 38,000 clip views as reach rather than impact.",
"Response classifies the star movement in the same window as a noisy signal.",
"Response names a vanity URL or spoken code, and a \"where did you hear about us\" signup field, as the signals that would have produced clean per-episode attribution.",
"Response notes that attribution has to be set up before publication day, so it cannot be recovered retroactively for this episode.",
"Response names repeat invitation, referral to another show, or an inbound speaking request as the real compounding return, despite being the slowest signal.",
"Response offers a branded-search and direct-traffic lift comparison over a 7 to 14 day window against baseline, labelled as directional only.",
"Response flags that the branded-search comparison is worthless if a launch overlapped the window.",
"Response does not produce a revenue figure, a pipeline number or a podcast ROI calculation for the CEO."
]
},
{
"id": 12,
"prompt": "Recording is done, felt good. Host says it'll go live in about three weeks. I'll obviously tweet the link when it drops. Anything else worth doing?",
"expected_output": "A promotion loop with four phases: an unasked pre-publication package to the host, publication-day posts each built on one sound bite, a first-week comment and README pass, and an evergreen post from the transcript - with attribution set up before the episode drops.",
"files": [],
"expectations": [
"Response has the user send the host, before publication and unasked, a third-person two-line bio, a headshot, the exact links to reference, and three to five candidate timestamps or quotes.",
"Response notes that hosts rarely ask for this and that sending it shapes how the appearance is framed.",
"Response has the user set up attribution - a vanity URL, a spoken code, or a signup-form option - before publication day.",
"Response rejects a bare \"I was on this show\" post.",
"Response builds each publication-day post around a single sound bite plus the link, one post per owned surface.",
"Response has the user ask the host for the clip files.",
"Response includes answering comments in the first week where the episode is discussed, including the critical ones.",
"Response adds the episode to the project README, docs or talks page so it keeps working after the feed moves on.",
"Response turns the strongest ten minutes into a written post using the transcript as the draft, and cross-links it with the episode.",
"Response states that the host controls distribution but has no incentive to relaunch an old episode.",
"Response tells the user to run the written promotion copy through a humanizer pass before publishing."
]
},
{
"id": 13,
"prompt": "The topic they gave me is \"observability at scale.\" Their last 12 episodes include two on OpenTelemetry migration and one on cost control for logs. I've got a great story about the outage we had in April where our tracing backend fell over during Black Friday, but our incident review is still under NDA with the vendor until January. What's my angle?",
"expected_output": "The topic refused as an angle, at least three defensible candidates generated, anything the back catalogue already covered twice discarded, the NDA-blocked war story deleted outright rather than ranked last, and the survivors presented with trade-offs and a recommendation.",
"files": [],
"expectations": [
"Response distinguishes a topic from an angle and rejects \"observability at scale\" as an angle.",
"Response generates at least three candidate angles the user could defend from their own experience.",
"Response discards any candidate the show's back catalogue already covers twice, naming the OpenTelemetry migration episodes as the reason.",
"Response deletes the April outage war story outright rather than ranking it last, because the incident review is under NDA until January.",
"Response gives the reason for deleting rather than demoting: shortlisting a ruled-out shape makes the user rehearse an angle they cannot use.",
"Response presents the surviving candidates with trade-offs and a recommendation.",
"Response ranks the angle shapes - war story, practical how-we-do-it, contrarian thesis - by audience moved per hour of preparation.",
"Response names the contrarian thesis as the highest-value and most expensive shape, and states the condition that promotes it.",
"Response notes that the contrarian thesis carries the highest compliance cost when it takes a public position against a named competitor or a standard.",
"Response does not draft messages, sound bites or an opening answer before the angle is chosen."
]
},
{
"id": 14,
"prompt": "I was on Runtime Radio back in early 2025 talking about our scheduler. They've invited me back and there's a 20-minute pre-call with the producer on Monday. I'm going to ask her to send over all the questions in advance so I can write out my answers properly. Recording's in two weeks. What should I get out of that call?",
"expected_output": "The full-question-list request refused with its reason, word-for-word answers refused in favour of a bullet card, the pre-call treated as the negotiation where the episode's content is decided, and the return visit built around the delta since the prior appearance.",
"files": [],
"expectations": [
"Response tells the user not to ask for the full question list.",
"Response gives the reason: a guest who receives every question memorises answers and sounds robotic on the day.",
"Response rejects writing out answers word for word.",
"Response names losing your place in a memorised script as the cause of the worst on-air freezes, because there is nothing underneath it.",
"Response treats the pre-interview call as the negotiation where the episode's content actually gets decided, not a formality.",
"Response has the user pin down who the audience is on that call.",
"Response has the user pin down whether the host wants story-first or tips-first.",
"Response has the user pre-agree the literal opening question.",
"Response builds the return visit around the delta since the prior appearance - what has changed since the scheduler episode.",
"Response discards any angle that is the user's own stock answer from the previous appearance.",
"Response produces a glanceable bullet card rather than a script to read from."
]
},
{
"id": 15,
"prompt": "I'm a DevRel at Wrenfield Systems - we sell an enterprise API gateway, deals are six figures and go through procurement. I'd rather not say I work for Wrenfield until the end, feels less salesy. And if they ask how we compare to Kong or Apigee I'll just say I don't like to talk about competitors. At the end the host always says \"where can people find you\" - I'll point them at our pricing page since that's where the demo form is. Sound good?",
"expected_output": "All three instincts refused: affiliation stated early and plainly, competitors named and fairly assessed, and the closing pointer redirected to a neutral resource - plus the B2B consequence that every spoken number can resurface in a procurement conversation.",
"files": [],
"expectations": [
"Response rejects the late reveal and has the user state the affiliation early and plainly, giving the reason that the audience finds out anyway and a late reveal reads as a hidden advertisement.",
"Response rejects refusing to name Kong and Apigee, and states that refusing to name competitors signals insecurity to engineers.",
"Response has the user be fair about the named competitors, conceding where each is genuinely the better choice.",
"Response rejects pointing listeners at the pricing page.",
"Response redirects the closing call to action to a neutral resource such as the docs or the repository.",
"Response caps the invited pitch at under 30 seconds.",
"Response applies the B2B case explicitly: the listener may be an evaluator or a buyer's proxy.",
"Response states that claims about compliance, SLAs, pricing and roadmap can be quoted back in a procurement conversation.",
"Response requires every number spoken on air to be one the company already publishes.",
"Response gives one destination for the call to action, said slowly and spelled out if unusual."
]
}
],
"trigger_queries": [
{ "query": "I'm going on the Backend Banter podcast next Thursday, help me prep", "should_trigger": true },
{ "query": "podcast guest prep for our new SDK launch", "should_trigger": true },
{ "query": "youtube interview prep", "should_trigger": true },
{ "query": "devrel media training", "should_trigger": true },
{ "query": "prep my talking points for an interview", "should_trigger": true },
{ "query": "I need sound bites for a recording next week", "should_trigger": true },
{ "query": "I'm on a panel at a virtual conference next month, what do I prepare", "should_trigger": true },
{ "query": "what do I say when they ask about competitors", "should_trigger": true },
{ "query": "a host booked me to talk about our database and I have no idea what to say", "should_trigger": true },
{ "query": "someone wants to interview me about my open source project on their show", "should_trigger": true },
{ "query": "I've got a livestream with two hosts on Friday and I'm terrified", "should_trigger": true },
{ "query": "how do I not sound like a walking ad on this recording", "should_trigger": true },
{ "query": "turn my launch blog post into quotable lines for an interview", "should_trigger": true },
{ "query": "they're going to ask me why we changed our license, how do I answer", "should_trigger": true },
{ "query": "what should my first answer be when they say tell us about yourself", "should_trigger": true },
{ "query": "I'm being interviewed about our outage, prep me", "should_trigger": true },
{ "query": "how long should my answers be on a live show", "should_trigger": true },
{ "query": "recording tomorrow and I have two hours to prepare, where do I start", "should_trigger": true },
{ "query": "help me build a message spine for an interview", "should_trigger": true },
{ "query": "prep brief for a technical podcast appearance", "should_trigger": true },
{ "query": "how do I handle a hostile question on air", "should_trigger": true },
{ "query": "what stories should I bring to this interview", "should_trigger": true },
{ "query": "I'm a guest on a roundtable with four other people next week", "should_trigger": true },
{ "query": "how do I explain our architecture without a diagram, it's audio only", "should_trigger": true },
{ "query": "they asked me to come on their show and talk about scaling", "should_trigger": true },
{ "query": "prep for an on-camera interview about our API", "should_trigger": true },
{ "query": "what's the right way to disclose that I work for the vendor", "should_trigger": true },
{ "query": "should I ask the producer to send me all the questions in advance", "should_trigger": true },
{ "query": "I have a pre-interview call Monday, what do I get out of it", "should_trigger": true },
{ "query": "the episode went live, what do I do now", "should_trigger": true },
{ "query": "how do I measure whether a podcast appearance was worth it", "should_trigger": true },
{ "query": "I got invited back on a show I did last year", "should_trigger": true },
{ "query": "my CEO wants to know what the podcast drove in revenue", "should_trigger": true },
{ "query": "how many key points should I have for a 25 minute episode", "should_trigger": true },
{ "query": "interview prep for a technical audience", "should_trigger": true },
{ "query": "I keep rambling when people interview me, help", "should_trigger": true },
{ "query": "how do I stop myself saying it depends to every question", "should_trigger": true },
{ "query": "coach me before this recording", "should_trigger": true },
{ "query": "someone's interviewing me on their Twitch stream about our project", "should_trigger": true },
{ "query": "I'm doing a fireside chat at a virtual summit, what do I prepare", "should_trigger": true },
{ "query": "media prep for an open source maintainer", "should_trigger": true },
{ "query": "how do I handle the where can people find you question", "should_trigger": true },
{ "query": "what do I do if they ask about our funding", "should_trigger": true },
{ "query": "prep me for a developer podcast", "should_trigger": true },
{ "query": "help me pick an angle for this interview", "should_trigger": true },
{ "query": "my answer to their opening question is way too long", "should_trigger": true },
{ "query": "what should go on my recording day checklist", "should_trigger": true },
{ "query": "the host is known for pushing hard, prepare me", "should_trigger": true },
{ "query": "I need quotable one liners for this episode", "should_trigger": true },
{ "query": "how technical should I go on this show", "should_trigger": true },
{ "query": "how do I bring up our numbers without sounding promotional", "should_trigger": true },
{ "query": "clip safe phrasing for an interview", "should_trigger": true },
{ "query": "I'm the guest not the host, help me get ready", "should_trigger": true },
{ "query": "how do I avoid dumping my resume in the first two minutes", "should_trigger": true },
{ "query": "should I use my product name when I answer", "should_trigger": true },
{ "query": "help me prepare for a conversation with a podcast host about our migration", "should_trigger": true },
{ "query": "I said yes to a recording and now I regret it, walk me through prep", "should_trigger": true },
{ "query": "what do I concede before I bridge", "should_trigger": true },
{ "query": "our incident is still under NDA, what can I say on the show", "should_trigger": true },
{ "query": "prep talking points for a 45 minute technical conversation", "should_trigger": true },
{ "query": "how do I prepare for being on someone else's channel", "should_trigger": true },
{ "query": "I need a one page card for the recording", "should_trigger": true },
{ "query": "how do I get more out of the episode after it publishes", "should_trigger": true },
{ "query": "should I send the host anything before it goes live", "should_trigger": true },
{ "query": "what questions will they probably ask me", "should_trigger": true },
{ "query": "I'm doing a technical AMA style interview, prep", "should_trigger": true },
{ "query": "how do I handle the ai hype question", "should_trigger": true },
{ "query": "prepare me to talk about how we make money on an open source project", "should_trigger": true },
{ "query": "the show's audience is mostly juniors but the host is a principal engineer", "should_trigger": true },
{ "query": "how do I say who this tool is not for", "should_trigger": true },
{ "query": "help me not freeze when the recording starts", "should_trigger": true },
{ "query": "my talking points read like a feature list, fix them", "should_trigger": true },
{ "query": "I'm appearing on a vendor's show, how do I stay credible", "should_trigger": true },
{ "query": "my conference talk got accepted, help me outline it", "should_trigger": false },
{ "query": "build a slide skeleton for my 30 minute talk", "should_trigger": false },
{ "query": "minute by minute time budget for my keynote", "should_trigger": false },
{ "query": "write my CFP abstract for a Kubernetes conference", "should_trigger": false },
{ "query": "which conferences should I submit to next year", "should_trigger": false },
{ "query": "what goes in the reviewer notes field of my talk proposal", "should_trigger": false },
{ "query": "write a script for our product screencast", "should_trigger": false },
{ "query": "two column narration sheet for a tutorial video", "should_trigger": false },
{ "query": "write a 30 second hook for my youtube video", "should_trigger": false },
{ "query": "I'm recording a video for our own channel, write the script", "should_trigger": false },
{ "query": "how do I pitch podcast hosts to get booked as a guest", "should_trigger": false },
{ "query": "build a media list of reporters covering developer tools", "should_trigger": false },
{ "query": "how do I handle an embargo with a journalist", "should_trigger": false },
{ "query": "we want press coverage for our funding round", "should_trigger": false },
{ "query": "write a pitch email to a tech reporter", "should_trigger": false },
{ "query": "I want to start my own developer podcast", "should_trigger": false },
{ "query": "how do I run a podcast for my company", "should_trigger": false },
{ "query": "what gear do I need to record my show", "should_trigger": false },
{ "query": "how do I book guests for my podcast", "should_trigger": false },
{ "query": "write show notes for episode 12 of my podcast", "should_trigger": false },
{ "query": "how do I grow my youtube channel subscribers", "should_trigger": false },
{ "query": "help me edit and publish my podcast episodes", "should_trigger": false },
{ "query": "my podcast RSS feed isn't updating on Apple Podcasts", "should_trigger": false },
{ "query": "I have a final round interview for a developer advocate role", "should_trigger": false },
{ "query": "how do I answer behavioral questions in a devrel job interview", "should_trigger": false },
{ "query": "review my devrel portfolio before I apply", "should_trigger": false },
{ "query": "what salary should I ask for as a developer advocate", "should_trigger": false },
{ "query": "design the interview loop for a devrel hire", "should_trigger": false },
{ "query": "write a job description for a developer advocate", "should_trigger": false },
{ "query": "score this candidate's presentation round", "should_trigger": false },
{ "query": "my live demo keeps breaking on stage, help", "should_trigger": false },
{ "query": "build a fallback plan for my product demo", "should_trigger": false },
{ "query": "one command environment reset for my demo", "should_trigger": false },
{ "query": "write a technical blog post about our migration", "should_trigger": false },
{ "query": "edit this engineering post so developers believe it", "should_trigger": false },
{ "query": "turn this customer deployment into a case study", "should_trigger": false },
{ "query": "get quote approval from a customer for our case study", "should_trigger": false },
{ "query": "which devrel podcasts should I be listening to", "should_trigger": false },
{ "query": "build me a watch list of newsletters and podcasts to follow", "should_trigger": false },
{ "query": "who should I follow on linkedin for developer relations", "should_trigger": false },
{ "query": "which devrel KPIs should we report to the board", "should_trigger": false },
{ "query": "set up a tracking plan for our docs and repos", "should_trigger": false },
{ "query": "map our developer funnel from discovery to advocacy", "should_trigger": false },
{ "query": "should I post our revenue numbers publicly", "should_trigger": false },
{ "query": "set a cadence for building in public", "should_trigger": false },
{ "query": "should we sponsor this conference booth", "should_trigger": false },
{ "query": "start a monthly meetup in our city", "should_trigger": false },
{ "query": "find speakers for our user group", "should_trigger": false },
{ "query": "plan the launch day for our open source project", "should_trigger": false },
{ "query": "how do we get on github trending", "should_trigger": false },
{ "query": "rewrite our repo readme", "should_trigger": false },
{ "query": "turn these commits into release notes", "should_trigger": false },
{ "query": "how do we attract senior engineers to apply", "should_trigger": false },
{ "query": "build our engineering employer brand", "should_trigger": false },
{ "query": "should we start a discord for our users", "should_trigger": false },
{ "query": "write our code of conduct", "should_trigger": false },
{ "query": "how do we measure community health", "should_trigger": false },
{ "query": "what should we charge for our api", "should_trigger": false },
{ "query": "should we go open core", "should_trigger": false },
{ "query": "audit our docs structure against diataxis", "should_trigger": false },
{ "query": "write a quickstart for our sdk", "should_trigger": false },
{ "query": "our troubleshooting pages don't rank in search", "should_trigger": false },
{ "query": "prep me for a system design interview at a big tech company", "should_trigger": false },
{ "query": "practice behavioral interview questions with me", "should_trigger": false },
{ "query": "how do I negotiate a job offer after the final interview", "should_trigger": false },
{ "query": "write interview questions to screen backend candidates", "should_trigger": false },
{ "query": "help me prepare for a user research interview with a customer", "should_trigger": false },
{ "query": "conduct a post mortem interview with the on call engineer", "should_trigger": false },
{ "query": "transcribe and summarize this podcast episode for me", "should_trigger": false },
{ "query": "recommend podcasts about distributed systems", "should_trigger": false },
{ "query": "write a press release announcing our series a", "should_trigger": false },
{ "query": "how do I improve my public speaking at internal all hands meetings", "should_trigger": false },
{ "query": "help me prep for an investor pitch meeting next week", "should_trigger": false }
]
}
references/format-playbooks.md›
# Format playbooks and sources
Two things live here: the per-format rehearsal drills that are too long for step 9 of the skill, and the attribution behind every named framework, number and threshold it uses. Published guidance, broadcast convention and this skill's own defaults are kept apart, so a reader knows which weight each one carries.
## Contents
1. Recorded solo interview (edited)
2. Live or streamed interview (no edit)
3. Moderated panel
4. Unmoderated roundtable
5. Sources behind the named frameworks
6. Sources behind the numbers
7. Numbers this skill set itself
## 1. Recorded solo interview (edited)
The safety net exists, and most guests never use it. Rehearse the sentence itself: "sorry, let me take that again" - said out loud, followed by a restart from a complete sentence, because an editor cannot cut into a fragment.
Drill: pick the two answers the user is least sure of, record them once, and deliberately abort halfway through the second one to practise the restart. The goal is that the retake request stops feeling like an admission of failure.
What edited format does _not_ buy you: control. The host keeps final cut, so every key point still has to survive being lifted out of the surrounding conversation. Treat each message as if it will be heard alone, because one of them will be.
Half-finished sentences are a legitimate escape hatch in an edited recording. A guest who starts a sentence and realises they cannot finish it can simply stop and return to their core message - nobody quotes half a sentence, so the attempt costs nothing. Live is the opposite case: there the fragment airs, so bridge past it (see §2).
## 2. Live or streamed interview (no edit)
- **Compression.** Take each of the three messages and deliver it in 15-20 seconds, point first. Repeat until the point arrives in the first sentence without a run-up.
- **ABC under interruption.** Have someone ask the two questions the user dreads, interrupting at the 10-second mark. Practise acknowledging, bridging and delivering content anyway.
- **The recovery line.** Pre-decide one sentence for the moment an answer collapses. Something that moves to firmer ground rather than stalling on "sorry, I don't know". Write it on the card.
Pacing note worth repeating to the user: the instinct under live pressure is to speed up. Slowing down is the single highest-leverage correction, and it also creates the pause that removes filler words as a side effect.
Reassurance worth giving: audiences do not expect perfection, and most stumbles go unnoticed. Guests over-index on a mistake nobody else registered.
## 3. Moderated panel
The airtime maths is the whole story. A 60-minute panel with a moderator and four guests leaves each guest roughly 12 minutes, delivered in fragments of a minute or two. That reorders the prep completely: fewer points, sharper, and each one headlined in a single sentence before any context.
Drill - **the one-sentence answer**: list every question the panel might cover, then answer each one in exactly one sentence. This is the fastest way to find which points genuinely compress and which ones the user should drop.
Two symmetrical failures to prepare against:
- **Invisibility.** Waiting to be spoken to, then opening with "I completely agree with what X just said", which spends airtime on nothing. Jumping in is expected; a panel is a discussion, not a series of interviews.
- **Domination.** Taking so much airtime that the other panellists cannot work. The camera is on everyone the whole time, so visible disengagement between turns costs as much as talking over people.
Handling a moderator who asks a bad or leading question: rephrase it out loud rather than answering the wrong question. "What I think you might be asking is…", or "I expected a tougher question - such as…", then answer the better version. The governing principle is to act as the audience's advocate, not the moderator's respondent.
Have one topic-avoidance plan ready: know which subjects the user does not want to discuss and which prepared message each one bridges to.
## 4. Unmoderated roundtable
Nobody is protecting anyone's airtime, so the skill that matters is entry timing, not opening strength. Prepare two or three points rather than three full messages, and prioritise listening for the seam in someone else's monologue.
Drill - **the entry phrase**: rehearse one short interjection ("let me jump in on that") until using it feels neutral rather than rude. Guests who never rehearse it never use it.
Self-correction replaces the retake here: if a point comes out wrong, restate it cleanly and return to the core message rather than apologising through it.
## 5. Sources behind the named frameworks
| Framework | Attribution | Where it is used in the skill |
| -------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------- |
| ABT (And, But, Therefore) | Randy Olson, _Houston, We Have A Narrative_ (2015); Olson traces it to screenwriter Frank Daniel (1986). Names the "AAA" failure form. | Step 3, one-sentence spine |
| The so-what test / AFTERs | Andy Bounds. "AFTERs" is his own branded term; "the so-what test" is popular shorthand for the same principle, not a separate trademark of his - do not cite it as his name for it. | Step 3, step 5 |
| Five-second moment | Matthew Dicks, _Storyworthy_. Also supplies "start at the opposite of the five-second moment" and the Homework for Life daily-capture practice that feeds a story bank. | Step 4 |
| Man in a Hole | Kurt Vonnegut's shapes-of-stories lecture, tested empirically by Del Vecchio, Kharlamov, Parry and Pogrebna, "The Data Science of Hollywood", arXiv 1807.02221 (2018), across 6,174 movie scripts. Their finding is specifically that it generates the most _talked about_ films, not the most liked. | Step 4 |
| Open loops ("raise questions and answer them") | Ira Glass on storytelling, via the This American Life interview transcripts; distilled for interviewers by Rob Rosenthal at Transom. | Step 4 |
| Flip the formula | Brad Phillips, Throughline Group, written for panels and media interviews: start at the end, where the punchline lives, then backfill. | Step 5, step 9 |
| ADD (Answer, Detailed example, Describe relevance) | Matt Abrahams; catalogued in `refoundai/lenny-skills@public-speaking`. | Step 8 |
| ABC (Acknowledge, Bridge, Content) | Broadcast media-training convention; the phrasing used here follows the 350.org media guide, which pairs it with "slow down, breathe" for live interviews. | Step 8 |
| Topic vs. story vs. angle | A former journalist writing for JAR Audio: topics are "blobby, unformed"; angles "are the stories that only you can write". | Step 2 |
Deliberately not used, because all three are built for a single speaker who controls the running order, which a guest never does:
- The Kenn Adams story spine (widely and wrongly labelled "Pixar's" - Brian McDonald and Adams himself have corrected the attribution, and Adams warns that finishing the spine gets you about 10% of the way there).
- Nancy Duarte's sparkline.
- Park Howell's Story Cycle.
## 6. Sources behind the numbers
| Number | Source and status |
| ----------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 15-20 second self-contained answers on live/broadcast | Zen Media media-training guidance: broadcast and live reward tight answers of that length because there is no edit to save you. Sourced. |
| ~12 minutes of airtime per panellist | A moderator brief reproduced by UK panel trainer Penny Haslam, alongside "get to your point with punch" and the instruction to jump in rather than wait. Sourced, but it describes one panel's brief - recompute it as slot length divided by panellists. |
| 15-30 second podcast intro | Sweet Fish Media, framing the intro as "the trailer for the episode". Host-side guidance; the guest inherits it as the budget for their opening answer. Sourced. |
| First 30 seconds decide whether a YouTube viewer stays | AZ Pod Studio, applying YouTube retention logic to interview shows. Producer commentary rather than platform data. Directionally sourced. |
| Second-by-second listener drop-off is measurable | Spotify's own creator resources describe both the early-drop-off tendency and the per-second retention breakdown they expose to creators. Sourced. |
| "33% of viewers drop off in the first 30 seconds" | Circulates inside third-party marketing posts on an invented attribution to a 2023 YouTube Creator Academy figure. **Not used in the skill.** A better-sourced replacement exists: YouTube's own Help Center documents a dedicated "Intro" metric measuring the share of viewers still watching past 30 seconds, and converging practitioner benchmarks put typical drop-off in that window at 20-35% (matching the debunked figure's ballpark by coincidence), with 60%+ retention past 30 seconds read as strong. Usable now that a real platform-documented metric backs it, rather than an invented attribution. |
| "Drop-off above 25% in the first five minutes signals an intro problem" | One production studio's commentary on its own analytics, unverified anywhere else. **Not used in the skill.** |
## 7. Numbers this skill set itself
These are working defaults chosen for this skill rather than published figures, and a user with better data about their own show should override them:
- Three messages for a 45-60 minute episode, two under 30 minutes, two to three on a panel.
- 5-8 stories in the bank, 5-8 sound-bite candidates, eight predicted questions.
- 15-25 words per sound bite. The cold-read test is the real gate; the word count is only a shape.
- A ~90 second ceiling on a conversational-show answer.
- A 7-14 day window for branded-search and direct-traffic comparison after publication.
- Under 30 seconds for the invited closing pitch.
A caveat that applies to the whole file: most published podcast-prep material is written for hosts, producers or trainers, not guests. A guest who follows it literally ends up preparing to run the show rather than to appear on it, so read every host-side rule for what it implies about the guest's side rather than as an instruction.
references/prep-brief-template.md›
# Prep brief template
The deliverable of the skill: fill every section. An empty section means the corresponding step is unfinished, not that it does not apply.
The filled example below uses a fictional maintainer of an open-source job-queue library going on an audio-only, edited backend-engineering show.
## Table of Contents
- [Template](#template)
- [Spine (ABT)](#spine-abt)
- [Messages](#messages)
- [Opening answer](#opening-answer)
- [Story bank](#story-bank)
- [Sound bites](#sound-bites)
- [Hard questions](#hard-questions)
- [Depth rules](#depth-rules)
- [Closing call to action](#closing-call-to-action)
- [Recording-day card](#recording-day-card)
- [Promotion](#promotion)
- [Filled example (excerpt)](#filled-example-excerpt)
- [Spine (ABT)](#spine-abt)
- [Messages](#messages)
- [Opening answer](#opening-answer)
- [Story bank](#story-bank)
- [Sound bites](#sound-bites)
- [Hard questions](#hard-questions)
- [What a bad brief looks like](#what-a-bad-brief-looks-like)
## Template
```markdown
# {Show name} - prep brief
Recording: {date, time, timezone} · {audio|video|live} · {length} · {solo host|co-hosts|panel}
Host(s): {names, what they build, one thing they care about}
Audience: {level, ecosystem} - inferred from {which episodes}
Booked topic (host's words): "{...}"
Chosen angle: {the take only this guest can deliver, and why the back catalogue doesn't already have it}
Recurring threads on this show: {the 2-3 questions the hosts keep returning to}
Off-limits: {embargoes, customers, security, legal}
Disclosure line: "{one sentence, said in the first five minutes}"
## Spine (ABT)
"{We had X, and it worked, but Y, therefore Z.}"
## Messages
1. Claim: {...} | Evidence: {...} | So-what: {...}
2. ...
3. ...
## Opening answer
"{≤30s for video, punchline first, understandable with no intro before it}"
## Story bank
| # | Story | Numbers | Five-second moment | What I got wrong | Answers which question |
| --- | ----- | ------- | ------------------ | ---------------- | ---------------------- |
Open loop to plant early, close late: {...}
## Sound bites
- {15-25 words, works cold}
- Liftable one: {project named next to its category, one number spoken}
- ...
## Hard questions
| Question | Concession (say first) | Bridge to message |
| -------- | ---------------------- | ----------------- |
## Depth rules
Assume: {what the audience already knows}
Explain: {the 2-3 concepts that need a definition}
Never say: {jargon to drop}
## Closing call to action
"{one destination, spelled if unusual}"
## Recording-day card
{5-8 bullets, glanceable}
## Promotion
Send host before publication: {bio, headshot, links, timestamps}
Publication day: {surface → sound bite used}
Week 1: {comments, README/talks page}
Evergreen: {post from transcript}
Attribution: {vanity URL or code, signup field option}
```
## Filled example (excerpt)
```markdown
# Backend Weekly - prep brief
Recording: 12 Sept, 15:00 CET · audio-only, edited · 50 min · solo host
Host: Dana R., runs payments infra at a mid-size marketplace; cares about operational
blast radius, allergic to vendor pitches (cut one short in ep. 118).
Audience: hands-on backend engineers, mostly Go and Python - inferred from eps. 118-121,
where the host asks about retry semantics and on-call load, never about pricing.
Booked topic (host's words): "why job queues are harder than people think"
Chosen angle: retry budgets, not brokers - the show has covered broker comparisons twice
(eps. 114, 119) and never once covered retry amplification.
Recurring threads: "what broke at 3am", "would you run this yourself or buy it", "what
does this cost you operationally".
Off-limits: the managed-hosting beta (unannounced), the fintech customer's name.
Disclosure line: "I maintain Fable-Q, and I also sell hosting for it - so take my
enthusiasm with that in mind."
## Spine (ABT)
"Teams pick a queue carefully, and the broker almost never fails, but their own retry
policy multiplies load until nothing drains, therefore budget retries before you tune
brokers."
## Messages
1. Claim: Most queue outages are retry storms, not broker failures.
Evidence: 6 of the last 8 incident write-ups in our issue tracker were retry storms;
the broker was healthy in all six.
So-what: Budget your retries before you tune your broker.
2. Claim: Exactly-once delivery is a property of the consumer, not the queue.
Evidence: our idempotency-key adoption cut duplicate side effects to near zero without
changing brokers.
So-what: Put the dedupe key in the payload on day one; it is unaffordable to add later.
3. Claim: A queue you cannot drain is an outage that has not happened yet.
Evidence: 40k-message backlog took 9 hours to clear on a single-consumer deployment.
So-what: Measure drain rate, not queue depth.
## Opening answer
"The outage that taught me this had nothing to do with the queue. Our own dashboard went
down because four services each retried three times - eighty-one times the load, on a
broker that was completely healthy the whole night."
## Story bank
| # | Story | Numbers | Five-second moment | What I got wrong | Answers |
| --- | ------------------------------------------- | --------------------------------- | ------------------------------------------------------------- | --------------------------------------------------- | ----------------------------- |
| 1 | Retry storm took down our own dashboard | 3 retries × 4 services = 81x load | Realising the broker graphs were flat while everything burned | I set retries per service, not per request path | "worst outage", "why retries" |
| 2 | Duplicate refunds during a broker migration | 340 duplicates, all recoverable | Reading the second refund confirmation email | Assumed the broker's dedupe covered handler crashes | "exactly once", "migrations" |
Open loop: mention early that one of these cost real money, come back to it at the end.
## Sound bites
- A queue you cannot drain is an outage that has not happened yet.
- Exactly-once is something your consumer earns, not something a broker sells you.
- Retries multiply: three retries across four services is eighty-one times the load.
- Liftable: "Fable-Q is a job queue for Go services, and it's the retry budget - not the
broker - that decides whether your backlog of forty thousand ever drains."
## Hard questions
| Question | Concession (say first) | Bridge |
| ---------------------------------------------------- | ---------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| Why not just use the cloud provider's managed queue? | For most teams that is the right call - it is cheaper and there is nothing to run. | Message 2: the delivery guarantee you need still lives in your consumer either way. |
| You sell hosting; isn't this a long ad? | Fair - I make money if you use this. | Message 1: the retry-budget advice costs you nothing and works on any broker. |
```
## What a bad brief looks like
- An "angle" that is really a topic ("we'll cover job queues") - nothing in it is specific to this guest, so any of the show's previous forty guests could have said it.
- A spine in AAA form: "we built a queue, and it's fast, and it's open source." No tension, so no reason to keep listening. The ABT rewrite has to hurt somewhere.
- An opening answer that starts with credentials ("I've been doing distributed systems for twelve years") and only reaches the point at second forty.
- Messages that are product features ("we support priority queues") instead of claims about the listener's world.
- Evidence the user cannot source live ("studies show most teams…").
- A story with no number and no mistake - it will be cut from the episode.
- Sound bites containing the product name, which never survive a clip. The one exception is the deliberate liftable bite, where naming the project next to its category is the whole point. If every bite does it, none of them get used.
- Hard questions with answers that bridge immediately, with nothing conceded first.
references/question-bank.md›
# Hard-question bank
Source material for step 8. Build the user's eight predicted questions from the show's own back catalogue first. Use these classes to fill the gaps and to find the two questions the user is hoping nobody asks.
For each class: what the host is really asking, the concession that has to come first, and the way guests usually fail it.
## Two answer shapes
Most questions are not attacks, and treating every one as a bridging opportunity is what makes a guest sound coached. Sort them first.
**Ordinary question → ADD** (Matt Abrahams). Answer, then Detailed example, then Describe relevance:
> _"How do you decide what to retry?"_
> **A:** "By the cost of doing it twice, not by the error code." **D:** "We retried payment webhooks for a year on a 500, and every duplicate charge came from that rule." **D:** "So if you only change one thing this week, split your retry policy by side-effect cost - it takes an afternoon."
The common failure is a missing first beat: the guest opens with the example and never states the answer, so the listener spends thirty seconds waiting to find out what the point is.
**Hostile or off-limits question → ABC**, with the honest answer wedged in before the bridge. Acknowledge what was actually asked, answer it including the part that does not flatter you, then bridge to one prepared message. Bridging straight from the question is the move a technical audience recognises instantly.
## 1. Competitor comparison
_"How is this different from {the obvious alternative}?"_
- Really asking: is there a reason to switch, or is this a rebuild of something that works?
- Concede first: where the alternative is genuinely the better choice, by name.
- Fails when: the guest refuses to name competitors, or lists features instead of naming the one workload where the trade-off flips.
## 2. "Why not just use X?"
_"Couldn't I do this with a cron job and a database table?"_
- Really asking: is the complexity you are adding justified?
- Concede first: for a small enough workload, yes, and say where the line is.
- Fails when: the guest treats the simple solution as naive. The audience has shipped that simple solution and it worked.
## 3. Licensing, pricing or model changes
_"You changed your licence / raised prices / closed the source of X."_
- Really asking: can I depend on you?
- Concede first: what the change cost users, and what was communicated badly.
- Fails when: the guest calls it a misunderstanding. Explain the constraint that forced the decision and what stays guaranteed.
## 4. Outage, CVE, or data-loss incident
_"What happened during the {incident}?"_
- Really asking: do you understand your own failure, and did anything change?
- Concede first: the impact in real units - users affected, duration, data lost.
- Fails when: the guest hides behind "we take reliability seriously". Give the mechanism, the fix, and the detection change.
## 5. AI-hype scepticism
_"Isn't the AI part just marketing?"_
- Really asking: are you shipping substance or a press release?
- Concede first: the AI feature that did not work and was removed.
- Fails when: the guest defends everything. Naming the failure earns the one example that stuck.
## 6. Open-source monetization
_"How do you make money, and what stops you from pulling the rug?"_
- Really asking: what is the incentive structure I am betting on?
- Concede first: the tension is real - the guest is paid by something.
- Fails when: the guest is vague about revenue. State the model plainly and the guarantee that is written down (licence, foundation, governance doc).
## 7. "Who is this not for?"
Often not asked directly - offer it anyway. Naming the workloads where the tool is wrong is the highest-trust answer available and it pre-empts half the other questions.
- Fails when: the guest says "any team can benefit", which the audience translates as "he does not know his own product".
## 8. Career, credibility, or authority challenges
_"You've only worked on this for a year - why should we listen to you?"_ or _"You're in DevRel, do you actually write code?"_
- Concede first: the limit of the user's experience, precisely.
- Bridge to: the specific evidence the user does own - the incidents they debugged, the code they wrote, the users they watched fail.
- Fails when: the guest inflates the credential. One overstated claim, and a listener who checks it discredits the whole episode.
## 9. Roadmap and futures
_"What's coming next?"_
- The trap is enthusiasm, not hostility: this is where guests leak embargoed work.
- Answer with what is already public plus the problem the team is thinking about, never a date.
## 10. The lightning round
Many shows close with rapid-fire questions (favourite tool, hottest take, worst advice). Prepare three: a genuine hot take the user can defend, a tool recommendation that is not their own product, and a piece of common advice they disagree with. Refusing to play makes the guest look guarded on the way out.
## Rehearsal method
1. Ask the user each predicted question out loud, in the host's phrasing, without warning.
2. Time the answer. Over 90 seconds - the skill's own self-set conversational ceiling, not a measured one - means it needs a shorter first sentence, not a shorter story. On a live show, run the same drill against 15-20 seconds instead - the point has to arrive in the first sentence because there is no edit behind it.
3. Check the concession came before the bridge. If it did not, ask the question again immediately - the second attempt is usually right.
4. Stop after the eight questions. Rehearsing further produces answers that sound rehearsed, which costs more than the coverage gains.
references/sound-bite-examples.md›
# Sound bite and bridging examples
Worked examples for steps 6-8 of the skill: depth calibration, sound bites, and bridging.
Every contrastive weak/strong, bridging and depth-calibration pair below is written for this skill, not quoted from a real episode - a real interview does not naturally produce a clean minimal pair to contrast against, only an editorial choice of what to clip. Use them as shapes to imitate, not as lines to reuse - a borrowed bite sounds borrowed. One real, attributed example closes the file, showing the same depth-calibration pattern occurring naturally in an unscripted answer.
## The cold-read test
Read the candidate with nothing before it. If a listener who joined at that second understands it, it is a sound bite. If they need the previous sentence, it is a fragment of an answer.
| Weak | Why it fails | Stronger |
| ------------------------------------------------------------------ | --------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| "That's exactly why we built it that way." | Unresolved "that", twice; meaningless when clipped. | "We made deletes slow on purpose, because fast deletes are how you lose data you needed." |
| "Our platform delivers best-in-class scalability and reliability." | Marketing adjectives, no falsifiable claim, product name shape. | "A queue you cannot drain is an outage that has not happened yet." |
| "As I mentioned earlier, observability is really important." | Back-reference plus a claim nobody disputes. | "If you cannot answer 'which request caused this' in one query, you do not have observability, you have logs." |
| "It depends on your use case, there are many factors." | The hedge with no default. | "Default to a single database until it hurts; the first thing sharding buys you is a distributed bug." |
| "We're seeing a lot of interest from enterprise customers." | Unverifiable, buyer-flavoured, uninteresting to engineers. | "Enterprises adopt this for the audit log, not the speed - which surprised us and changed the roadmap." |
## The one liftable bite
Every other bite in the episode should keep the product name out. Exactly one should put it in, deliberately - it is the sentence AI assistants lift from the transcript as the record of what the project is (the skill's opening makes the full argument). Say it once, plainly, with a number attached - then never again.
| Weak | Why it fails | Stronger |
| ------------------------------------------------------- | ----------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| "You can find us at our website, we do queueing stuff." | Category never stated, no number, nothing an indexer can lift. | "Fable-Q is a job queue for Go services, and the retry budget - not the broker - decides whether a forty-thousand-message backlog ever drains." |
| "We're the leading open-source solution in this space." | Superlative with no category, no evidence, and it reads as an ad in any clip. | "Fable-Q is an open-source job queue for Go; the reason people adopt it is the dead-letter tooling, not the throughput." |
## Depth-calibrated versions of one idea
Same claim, four audiences. Pick the row that matches the show, not the row the user finds most impressive.
| Listener | Version |
| -------------------- | ------------------------------------------------------------------------------------------------------------------ |
| Hands-on engineers | "Put the idempotency key in the payload on day one - retrofitting it means replaying every consumer." |
| Staff, architects | "Exactly-once is a consumer property; brokers can only give you at-least-once plus your own dedupe." |
| Engineering managers | "Duplicate side effects cost us a week of manual refunds; a one-line key in the payload would have prevented it." |
| Founders, buyers | "The reliability question is not which queue you buy, it is whether your team writes handlers that can run twice." |
## Turning screen-dependent content into audio
| Screen version | Audio version |
| ---------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| "Here's the architecture diagram - three services and a broker." | "Three services all talking to one broker, and each one retries three times: eighty-one times the load when it goes wrong." |
| Reading a code sample aloud. | "One function, two arguments - the payload and a dedupe key - and it returns a stream you can cancel." |
| "Our benchmark shows 12,400 ops/sec." | "Roughly twelve thousand a second, about three times what we got before the change, on the same hardware." |
## Bridging pairs
Concede something real, then bridge. The concession is what makes the bridge survive a technical audience.
**Question: "Why would I use this instead of the managed service my cloud already gives me?"**
- Weak: "Great question - what makes us different is our developer experience and our community." (No concession, immediate pitch, two abstract nouns.)
- Strong: "For most teams the managed one is the right call - it is cheaper and there is nothing to operate. The part it does not solve is the one that bites you: the delivery guarantee still lives in your consumer, whichever queue you pick."
**Question: "You sell this - isn't this whole episode an ad?"**
- Weak: "I'm here to talk about the technology, not to sell anything."
- Strong: "Fair, and I do make money if you use it. So take the free part: the retry-budget rule works on any broker, including the one you already have."
**Question: "Your project changed its licence last year and a lot of people were angry."**
- Weak: "There was some misunderstanding in the community about what the change meant."
- Strong: "The anger was earned - we announced it badly, with no migration window. What we would do differently is publish the reasoning and the timeline together; here is what the change actually restricts."
**Question: "Isn't this just AI hype?"**
- Weak: "AI is transforming every part of the stack."
- Strong: "Most of it is, including two features we shipped and then removed. The one that stuck is boring: classifying dead-letter messages so a human reads twenty instead of two thousand."
## A real sourced example
Source: Stephan Ewen (founder, Restate.dev), on durable execution and idempotency - _Changelog Interviews_ #636, "The era of durable execution" (changelog.com/podcast/636).
Cold-read test, passing on the first listen: "Once it says it's there, it's always going to be there. And I think this is, in a way, almost one of the magic ingredients."
Same idea at two depths, occurring naturally in one interview rather than constructed for contrast:
| Listener | Version |
| ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Non-technical, product | "It's the thing that if you don't do it correctly, that is actually accidentally placing an order twice when you did try to place it once." |
| Staff, architects | "If you have extremely fine-grained durability, if you're recording every individual step as durable in the system, and when it comes back, it can tell you exactly like 'This was the last step that you recorded' - then you just have a very small amount of uncertainty." |
Real speech carries more hedging and self-repair than a written line ("in a way, almost", "like") - trim filler when clipping for a written pull-quote, never when quoting on-air, and never past the point the guest would still recognize it as what they said.
## Anti-patterns to flag in a draft
- The bite that only works after the user explains the setup - move the setup into the bite or cut it.
- The bite that requires the listener to accept a definition they have not been given.
- The bite that is really two ideas joined by "and": split it. Only one will be clipped.
- The bite that names the product, which converts a quotable line into an advertisement nobody shares.
SKILL.md›
---
name: tech-podcast-interview-prep
description: Prepares a guest for someone else's technical podcast, YouTube interview, livestream or panel - show reconnaissance, the angle, an ABT message spine backed by evidence and stories, a self-contained opening answer, clip-safe sound bites, depth calibration, recording-day mechanics, and the post-publication promotion loop. Use whenever someone says "podcast guest prep", "I'm going on a podcast next week", "youtube interview prep", "devrel media training", "prep my talking points", "sound bites", "I'm on a panel", or "what do I say when they ask about competitors" - even if they only mention an upcoming recording. Not running your own show - use samber/dev-event-organizer-skills@tech-podcast-youtube-channel.
license: MIT
metadata:
author: Samuel Berthe
version: "1.0.1"
---
# Podcast Interview Prep
You are a media coach for developer-relations practitioners, open-source maintainers and technical founders. Someone else's show has already booked the user; turn a vague "we'll talk about my project" into a prep brief the user can hold on a card during the recording, and into promotion assets afterwards.
The booking exists before this skill starts. Route elsewhere instead of continuing when the task is one of these:
- Pitching hosts and building media relationships: samber/developer-relations-skills@tech-press-relations.
- Scripting a video the user owns: samber/developer-relations-skills@technical-video-script.
- A conference talk: samber/developer-relations-skills@tech-talk-outline.
- Preparing to be _hired_ for a DevRel role, not preparing to appear on a show: samber/developer-relations-skills@devrel-career. Say so, then route there.
The live audience is the smallest audience this appearance will ever have. The episode gets transcribed, the show notes get published, and both get crawled and cited by AI assistants long after the feed moves on - the numbers the user says out loud become the machine-readable record of their project. Push for spoken figures and self-contained phrasing at every step; the one liftable bite in step 7 is where this argument cashes out.
## Invocation and output
Typical invocations:
- "I'm on the Backend Weekly podcast on Thursday, help me prep"
- "prep talking points for a YouTube interview about our new SDK"
- "I'm on a four-person panel at a virtual conference, 45 minutes, what do I prepare"
- "what do I say when they ask why we changed our licence"
- "turn my launch post into sound bites for a podcast"
Start every one at the Interview below and end with one markdown prep brief, built section by section with the user's agreement on each section before you move to the next. A brief built on the wrong audience assumption is worse than no brief, because the user will trust it live on air.
The brief's sections, in order: header block (show, format, hosts, audience, booked topic, off-limits, disclosure line), messages, story bank table, opening answer, sound bites, hard-question table, depth rules, closing call to action, recording-day card, promotion plan. See [./references/prep-brief-template.md](./references/prep-brief-template.md) for the exact shape and a filled example.
## Interview
Ask one question at a time, multiple-choice where you can. Skip anything the user already answered. Questions 1-4 gate everything else - do not draft a single message before they are answered.
**Memory: Store a few info about the current task or project context. When memory lives in a file, use `devrel-context.md`; if a different memory system is in use, rely on that instead. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.**
1. Which show, and what format: audio-only, video, or livestream? Recorded-and-edited, or live with no retakes?
2. Episode length, and is it a solo host, co-hosts, a moderated panel with other guests, or an unmoderated roundtable?
3. Who listens: hands-on engineers, staff engineers and architects, engineering managers, or founders and technical buyers? Which language or platform ecosystem?
4. What topic did the host book you for, in their words? Is there a pre-interview call, and did they send questions in advance?
5. Have you been on this show before? If yes, link the prior episode.
6. What are you representing - an employer's product, your own open-source project, or only yourself? What must you disclose?
7. What is the outcome you want: adoption, contributors, hiring signal, launch support, or personal positioning?
8. What is off-limits: embargoed releases, unnamed customers, security detail, pending legal or funding news?
9. When is the recording, and is there a fixed date before it - a pre-interview call, an internal review, an embargo lifting?
10. What is your prep ceiling: how many hours between now and the recording, and can you get someone to run a rehearsal with you?
11. Is this a one-off appearance, or the first of several as part of a media push?
12. What can you point listeners to that already exists - a repo, a benchmark, a post, a talk?
13. Is the buying motion B2B (a team or company adopts, someone else signs) or B2C-style self-serve adoption by individual developers? Both is a valid answer.
If the user cannot answer 3, treat the show's own back catalogue as the source of truth and say so - inferring the audience from the show's marketing copy is how guests end up talking over the room.
Answers to questions 9, 10 and 11 re-rank every menu below. State which answer moved what:
- A recording in two days: promotes the spine and the opening answer, deletes the story bank's long tail.
- A media push rather than a one-off: promotes the story bank, the sound bites and the promotion loop, because each is written once and reused at every later appearance.
- A low prep ceiling: deletes steps outright rather than doing all of them badly - say which you dropped.
## How much prep this appearance warrants
The twelve steps below assume a week. Most guests have an evening. Rank the steps by on-air quality bought per hour of prep and do them in that order, rather than starting at step 1 and stopping wherever the time runs out - which is how a guest arrives with excellent show notes and no message.
- efficiency: message spine (3) > opening answer (5) > hard questions (8) > angle selection (2) > show reconnaissance (1) > sound bites (7) > story bank (4) > promotion loop (12)
- effort: message spine == angle selection (under an hour each - both are decisions, not production) > opening answer (write it, then say it aloud until it survives being clipped) > sound bites (draft five to eight to keep two) > hard questions (eight questions, each with a written concession) > show reconnaissance (six to eight episodes at speed, or the RSS shortcut) > story bank (five to eight stories with real numbers, each checked against the off-limits list) > promotion loop (a standing job across the week after publication)
- value: story bank (stories are what get quoted, and quotes outlive the episode) > hard questions (one bad clip costs more than three good answers gain) > message spine (makes every answer derivable, so nothing is improvised live) > opening answer (owns the only moment the guest controls) > show reconnaissance (aims everything else; the wrong audience makes the rest worthless) > angle selection (decides generic against memorable) > sound bites (raises the odds a good line is liftable) > promotion loop (the appearance's whole second life, arriving weeks later)
- compliance cost: story bank (customer names, incident detail and unpublished numbers, each cleared individually - and irreversible once spoken) > hard questions (a licensing, pricing, CVE or funding answer may need legal or employer sign-off before the recording) > promotion loop (employer brand and links, reviewed once) > everything else, all near-zero and tied, because none of it involves saying anything the user does not already own
Two gates sit outside this ranking and are never traded for time. Both take minutes and both are unrecoverable if skipped:
- The disclosure line in step 10.
- Checking every story and number against the off-limits list from question 8.
Defaults by prep ceiling:
- **A week:** all twelve steps.
- **One evening:** spine, opening answer, hard questions. Tell the user which steps you dropped, so they know what they are improvising.
- **Two hours:** spine and opening answer only.
Efficiency starves the story bank, which is the highest-value step in the list and the most expensive. Promote it whenever the answer to question 11 was a media push, since a story written once is retold at every later appearance, or when the pre-interview call established that the show is story-first.
This order is a default, not a law - re-rank it against the user:
- A guest who has done twenty episodes already has a spine and needs only recon and the hard questions.
- A first-time guest on a hostile-leaning show should spend the whole evening on step 8.
## Step 1 - Show reconnaissance
Recording conditions decide the whole brief - establish them before any content work.
Work down this ladder and stop as soon as you have enough: the show's RSS feed (full episode descriptions, chapter markers, guest links, dates), the show's own episode list, its Apple Podcasts page (reliably renders the latest handful of episodes with full descriptions), then web search for stray episodes and host background. If you cannot browse the web, hand the user this same ladder and ask them to listen at speed.
Here the richest source is also the fastest, so cost and value agree and one line is enough:
- efficiency: RSS feed > show's episode list > Apple Podcasts page > web search > full transcripts
Efficiency starves the transcripts: they are the only source that shows how the hosts actually interrupt, and they cost an hour each. Pull one only for an episode the user must have a position on, or when the show has no descriptions worth reading.
Extract four things:
1. **Recurring threads** - from the last six to eight episodes, the questions the hosts keep returning to. Threads predict the questions the user will get far better than any single episode does.
2. **Show profile** - opening ritual, the host's first substantive question, how long guests talk before the host cuts in, whether there is a lightning round, how the episode closes, whether video clips get cut for social.
3. **Host profiles** - day job, what each host is personally building, and one rapport hook where their world overlaps the user's. Episodes where the hosts guest on _other_ shows are usually the best source for this.
4. **Prior-appearance recap**, if the user has been on before - what was discussed, roughly when, and what has changed since. That delta is the natural spine of a return visit.
Infer the audience level from the questions the host asks other guests, never from the show's tagline. Note the house rules the host states or implies: promotion tolerance, language, whether guests get to plug at the end.
If your environment has persistent memory, store the show profile and the user's message spine under the show's name. Guests get re-invited and pitched to neighbouring shows, and the second appearance should start from the first one's brief rather than from a blank page.
## Step 2 - Angle selection
A topic is not an angle. Topics are umbrella-shaped and interchangeable ("observability", "job queues").
An angle is the take only this user can deliver, because of something they built, broke or measured. A guest who brings a topic gets a generic episode.
1. Generate three or more candidate angles on the booked topic, each one the user could defend from their own experience.
2. Discard any angle that already appears twice in the show's back catalogue, and any angle that is the user's own stock answer from a previous appearance. Repeating either wastes the slot.
3. Present the survivors with trade-offs and a recommendation, then let the user choose before you write anything else.
The three usual shapes, ranked by audience moved per hour of preparation and rehearsal:
- efficiency: war story > practical how-we-do-it > contrarian thesis
- effort: practical how-we-do-it (describe what the team already does on an ordinary week) > war story (recall one incident, then check what can be said about it) > contrarian thesis (build a case against consensus and rehearse the pushback, because it will arrive live)
- value: contrarian thesis (most clippable, and the only shape that changes a listener's mind) > war story (highest credibility, and the shape that actually gets quoted) > practical how-we-do-it (most immediately useful, least memorable)
- compliance cost: practical how-we-do-it (nothing to clear) > war story (an incident touching customers, security detail or unpublished numbers needs clearing first) > contrarian thesis (a public position against a named competitor or a standard, which an employer will usually want to see before it is spoken)
Efficiency starves the contrarian thesis - the highest-value shape and the most expensive to defend. Promote it when the user can genuinely defend the position under pushback and the back catalogue shows these hosts enjoy disagreement rather than smoothing it over. Delete a shape the constraints rule out instead of ranking it last: an incident still under embargo removes the war story entirely, and shortlisting it anyway means the user rehearses an angle they cannot use.
If there is a pre-interview call, that call is where the episode's content actually gets decided - treat it as the negotiation, not a formality.
Pin down on that call:
- Who the audience is.
- Whether the host wants story-first or tips-first.
- The literal opening question, pre-agreed.
Do not ask for the full question list. Practitioners on both sides warn that a guest who receives every question memorises answers and sounds robotic on the day.
## Step 3 - Message spine
Compress the whole appearance into one ABT sentence first: Randy Olson's And-But-Therefore, traced to screenwriter Frank Daniel and formalised in _Houston, We Have A Narrative_.
> "We had X, **and** it worked at small scale, **but** Y broke, **therefore** Z."
The failure mode ABT names is the AAA form - and, and, and - a pile of facts with no tension, which is what most unprepared guests produce. This sentence is the spine: the user holds it for the whole episode and re-derives any individual answer from it.
Then fix the messages the spine carries:
- 45-60 minute episode: three messages.
- Under 30 minutes: two messages.
- Panel or roundtable: two to three messages.
Listeners retain far less than guests expect, and a fourth message steals airtime from the first three. Three is a self-set working default rather than a measured optimum. Adjust it if the show's own pacing argues otherwise.
Write each message as claim, evidence, so-what:
- **Claim** - one sentence, falsifiable, no adjectives.
- **Evidence** - a number, a benchmark, an incident, or a named constraint. "It's faster" is not evidence. "It cut p99 from 800ms to 120ms on the same hardware" is.
- **So-what** - what the listener should do, stop doing, or reconsider on Monday.
Run every claim through the so-what test - popular shorthand for Andy Bounds's AFTERs principle (AFTERs is his branded term; the shorthand is not his name for it): the difference between wanting a newspaper and wanting the news you get from it. A credential or a fact that cannot answer "so what does that give the listener" is decoration - cut it.
Ask the user to say each claim out loud. A claim that is hard to say is a claim they will not land under pressure.
## Step 4 - Story bank
Opinions get forgotten. Stories get quoted.
Build 5-8 stories (a self-set default, like every unattributed count in this skill - see the ledger in [./references/format-playbooks.md](./references/format-playbooks.md)), each with a specific system, a specific decision or failure, real numbers, and something the user got wrong. Engineers trust a guest who names their own mistake faster than one who names their credentials.
Apply two shaping rules borrowed from storytelling practice:
- **Find the five-second moment.** Matthew Dicks argues every story is really about one five-second flip - a transformation ("I used to be one kind of engineer, now I'm another") or a realization ("I used to think X, then this happened"). Cut everything that does not build to that flip, and open the story at the _opposite_ of it so the telling has somewhere to go.
- **Prefer the up-down-up shape.** Vonnegut's "Man in a Hole" - somebody gets into trouble and gets out, ending higher than they started - was tested against 6,174 movie scripts by Del Vecchio, Kharlamov, Parry and Pogrebna (arXiv 1807.02221, 2018). They found it correlated with the highest box offices, and specifically with the most _talked about_ films rather than the most liked. For a guest, talked-about is the goal: that is the story that gets clipped and quoted.
Tag each story with the questions it can answer, so the user never gropes for an example live. Reusing one story for two answers in the same episode reads as a canned pitch - the tags exist so the user can reach for a different one.
Plant one **open loop** early and close it late ("there's a mistake that cost us a lot, I'll come back to it"). Ira Glass's engine for forward motion is to constantly raise questions and answer them. An open loop is the one arc device that survives a host controlling the question order.
Reject any story the user cannot tell without breaking question 8's off-limits list, and replace it now rather than mid-recording.
## Step 5 - The opening answer
The host owns the cold open, the music, the bio and the edit. The guest owns exactly one thing at the top: their first answer. Spend disproportionate prep time on it.
The sourced support is thinner than the folklore, so state it as it is. Spotify's creator resources describe a tendency for listeners to drop off early and expose per-second retention to creators. One producer (AZ Pod Studio) argues the first 30 seconds decide whether a YouTube viewer stays - producer commentary, not platform data.
The mechanics below need no statistic.
- **Flip the formula.** Brad Phillips's rule for interviews and panels: people naturally speak chronologically, so start at the end, where the punchline lives, then backfill context. If the host interrupts before the user finishes, the important part is already out.
- **Make it survive being clipped.** If the first answer cannot be understood without the host's bio intro supplying context, rewrite it. A self-contained opening survives both a clip and a listener who skipped the intro.
- **Cap it.** Around 30 seconds for video - a budget inherited from host-side intro guidance (Sweet Fish Media's 15-30 second intro), not a measured guest-side figure.
- **No credential dump.** Run the bio through the so-what test from step 3. "I've worked on this for nine years" earns nothing. "I've watched this exact migration fail three times" earns the next ninety seconds.
## Step 6 - Depth calibration
Aim one level below the deepest listener so the median listener stays in the conversation. The table and the conversions below are this skill's own synthesis, not a sourced framework.
| Listener | Anchor the explanation in | Leave out |
| --------------------------- | ------------------------------------------------- | ------------------------------ |
| Hands-on engineers | API surface, failure modes, migration cost | org framing, market size |
| Staff engineers, architects | trade-offs, invariants, what breaks at scale | line-by-line syntax |
| Engineering managers | operational cost, team impact, risk | internal implementation detail |
| Founders, technical buyers | the problem class, the decision, the alternatives | protocol minutiae |
Three conversions that make technical content survive audio:
- Replace a diagram with a physical metaphor plus one number ("a queue that drains slower than it fills, about 40k messages behind by lunchtime").
- Replace a code sample with the shape of the call ("one function, two arguments, returns a stream you can cancel").
- Round every number and always pair it with its comparison - an absolute figure with no reference point tells the listener nothing.
Write a one-sentence definition for each piece of jargon the user cannot avoid, and drop the jargon the definition does not earn.
## Step 7 - Sound bites
A sound bite is a sentence that still works after being cut out of the conversation. Draft 5-8 candidates (self-set count). One or two will land naturally, and the rest train the user's phrasing.
A sound bite's anatomy:
- One idea.
- Roughly 15-25 words.
- Present tense, active voice.
- No unresolved pronouns.
- No back-references like "as I said earlier".
- No company name inside the bite.
Prefer a concrete noun over an abstract one: "a queue you cannot drain" beats "scalability challenges". The word count is a working target, not a measured threshold. The cold-read test below is the real gate.
Test every candidate by reading it cold with nothing before it. If it needs the previous sentence, it is not a sound bite yet.
One bite should be **liftable**: it names the project next to its category in plain words ("we build X, the Y for Z") and speaks a number rather than gesturing at one. That is the sentence the opening's AI-record argument depends on, and the user only gets it if they say it out loud - once, then never again.
See [./references/sound-bite-examples.md](./references/sound-bite-examples.md) for worked positive and negative pairs across audience types.
## Step 8 - Answers and hard questions
Predict eight questions (self-set count): three from the show's recurring threads, three obvious ones from the booked topic, and two the user does not want to be asked.
For an ordinary question, use Matt Abrahams's ADD:
1. **A**nswer cleanly and concisely.
2. Give a **D**etailed example that reinforces it.
3. **D**escribe the relevance: say explicitly why it matters to the person who asked.
Most rambling answers are a missing first beat: the guest starts with the example and never states the answer.
For a hostile or off-limits question, use **ABC** - Acknowledge, Bridge, Content - the pattern taught in broadcast media training, with one non-negotiable addition for a technical audience: the honest answer, including the unflattering part, comes before the bridge. Bridging straight from the question is the move a developer audience recognises as PR training, and it costs more trust than the awkward answer would have.
Never "no comment" and never a non-answer. Both read as evasion, and the clip outlives the episode.
The classes worth preparing every time: competitor comparison, "why not just use X", a licensing or pricing change, a public outage or CVE, AI-hype scepticism, monetising an open-source project, and "who is this _not_ for". Nothing earns trust faster than that last one: naming where the tool is the wrong choice buys credibility for everything else the user says.
See [./references/question-bank.md](./references/question-bank.md) for the question classes with prompts, concessions and failure patterns.
## Step 9 - Format adaptation
The single fact that reorders every other decision is whether the recording is edited or live. Confirm it first, then apply the row. The per-format rehearsal drills, and the sourcing behind every number here, live in [./references/format-playbooks.md](./references/format-playbooks.md) - rehearse from there, decide from here.
| Condition | The decision it forces |
| ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Edited | Retakes exist - say "can I take that again" the moment an answer derails. The host keeps final cut, so every key point must still survive being lifted out of context. |
| Live, no edit | Lead with the point and stop: broadcast training (Zen Media) puts self-contained answers at 15-20 seconds. Live, a half-finished sentence is unrecoverable - bridge past it. |
| Audio-only | No code read aloud, no screen-dependent demo; every diagram becomes a metaphor plus one number (step 6). |
| Video | Clips get cut vertically - sound bites matter more, stay in frame, expect your face on screen while the host talks. |
| Moderated panel | Airtime is roughly the slot divided by the panellists; one reproduced moderator brief (via Penny Haslam) put it near 12 minutes each. Headline in one sentence, jump in unasked, never open with agreement. |
| Unmoderated roundtable | Nobody protects your airtime - prepare fewer points, listen for the entry, keep one entry phrase ready. |
## Step 10 - Disclosure and promotion etiquette
- State the affiliation early and plainly ("I work on X at Y"). The audience finds out anyway, and a late reveal reads as a hidden advertisement.
- Wait for the invited pitch - usually the closing "where can people find you". Keep it under 30 seconds (self-set cap) and point to a neutral resource (docs, repo) rather than a sales page.
- Name competitors and be fair about them. Refusing to name them signals insecurity to engineers.
- Never claim an unreleased capability, an unapproved customer name, or an unpublished benchmark. The recording outlives the embargo.
B2B and B2C differ here, worth stating out loud to the user rather than leaving implicit:
- **B2B:** the listener may be an evaluator or a buyer's proxy. Claims about compliance, SLAs, pricing and roadmap can be quoted back in a procurement conversation, so every number must be one the company already publishes.
- **B2C (self-serve, individual-developer adoption):** the listener decides alone in an afternoon. The useful currency is the free path, the time to first success, and honesty about limits.
Everything else in this skill - the spine, the stories, the depth calibration, the bridging - works identically for both.
## Step 11 - Recording-day card
Deliver a one-page card the user can glance at, never read from. Read text is audible, and a word-for-word script is the documented cause of the worst freezes: lose your place in a memorised script and there is nothing underneath it. Bullets survive being interrupted.
- Wired headphones, quiet room, phone silenced, local backup recording if the host allows it, water within reach.
- Leave a beat of silence before answering: it gives the editor a clean cut and stops crosstalk. Getting comfortable with that pause is also what removes filler words, far more reliably than trying to suppress them.
- Keep answers under about 90 seconds on a conversational show unless the host asks you to go deeper - a self-set ceiling (see the ledger in the format playbooks). Hosts rarely interrupt a guest who runs long; they just stop inviting them.
- Name the person, project or paper you are borrowing from; unattributed borrowing is the fastest way to lose a technical audience.
## Step 12 - Promotion loop
The host controls distribution but has no incentive to relaunch an old episode. The guest who ships their own promotion gets re-invited and gets introduced to other hosts.
1. **Before publication** - send the host a third-person two-line bio, a headshot, the exact links to reference, and 3-5 candidate timestamps or quotes. Hosts rarely ask. Sending it unasked buys goodwill and shapes how the appearance is framed.
2. **Publication day** - one post per owned surface, each built around a single sound bite plus the link, never a bare "I was on this show". Ask the host for the clip files.
3. **First week** - answer comments where the episode is discussed, including the critical ones. Add the episode to the project README, docs, or talks page so it keeps working after the feed moves on.
4. **Evergreen** - turn the strongest ten minutes into a written post using the transcript as the draft, and cross-link it with the episode.
Set up attribution (vanity URL, signup-field option) before publication day - the signals it feeds are ranked under Measurement below.
Run any written promotion copy through your preferred humanizer skill before publishing. First-draft model output reads as marketing and undoes the credibility the episode earned.
## Measurement
Podcast measurement has three structural limits:
- Podcast clients strip referrers.
- Most listening happens off-web.
- Downloads are not listens.
Treat click attribution as a floor, never a total, and never attribute a pipeline number to one episode. The ranking below is this skill's own ordering, not a sourced hierarchy.
Ordered by evidence bought per hour of setup and waiting - not by how quickly each number appears, which is how a guest ends up reporting download counts.
- efficiency: vanity URL or spoken code > signup-field question > branded search and direct lift > stars, installs, docs traffic > host-reported downloads and clip views > repeat invitation and referrals
- effort: host-reported downloads == stars and installs (both arrive without you doing anything) > vanity URL (create it before publication day) > branded search lift (a baseline you must already have been keeping) > signup-field question (a form change someone else has to ship) > repeat invitation (a standing job across months)
- value: repeat invitation and referrals (the compounding return - a second show is worth more than any measurement of the first) > vanity URL == signup-field question (tied: each attributes a real person to this episode, one by machine and one by self-report, and neither is strictly better) > branded search lift > stars and installs > downloads and clip views
Efficiency starves the last row, exactly as the table says: repeat invitations are the real return and the slowest signal on the list, so a guest optimising per-episode numbers under-invests in the relationship that produces the next four appearances. Promote it to the headline whenever the answer to question 11 was a media push.
| Signal | Strength |
| --------------------------------------------------------------------- | ------------------------------------------- |
| Vanity URL or code spoken on air | Clean per-episode attribution |
| "Where did you hear about us" on signup, with the show listed | Strong, self-reported |
| Branded search and direct traffic lift, 7-14 days vs. baseline | Directional; worthless if a launch overlaps |
| Stars, installs, docs traffic in the same window | Noisy |
| Downloads and clip views reported by the host | Reach, not impact |
| Repeat invitation, referral to another show, inbound speaking request | Slow, and the real compounding return |
The 7-14 day comparison window is a working convention, not a measured decay curve. Widen it if the show publishes irregularly.
Framework-level measurement design belongs to samber/developer-relations-skills@devrel-metrics. Take the tiers from there if the user already has them.
## Pass threshold
These five are the skill's own quality bar, set here rather than taken from an external standard. The brief is not finished until all five hold. Iterate on the failing part rather than shipping a brief with a gap in it - every gap becomes a live-on-air silence.
1. One ABT sentence covers the whole appearance, and each of the three messages has a claim, an evidence item the user can source, and a so-what.
2. Every message has at least one story with a specific system, a real number, and an identified five-second moment.
3. The opening answer is understandable with no preceding context and fits the format's ceiling.
4. At least three sound bites survive being read cold, out of context, by someone who has not heard the episode - and one of them names the project next to its category.
5. Every predicted hard question has a written answer that concedes something real before it bridges.
## Failure modes
Run this table as a pre-flight check on the finished brief, not as reading.
| Failure | What it looks like | Fix |
| ------------------------ | -------------------------------------------------------- | ----------------------------------------------------------------------- |
| Topic instead of angle | "We'll talk about observability" | Three candidate angles, discard what the back catalogue already covered |
| Pitch mode | Product name in every answer | Ban the name outside the invited pitch window and the one liftable bite |
| AAA answers | Fact, fact, fact, no tension | Re-derive the answer from the ABT sentence |
| Buried lede | The point arrives at the end, after the host interrupts | Flip the formula: punchline first, context after |
| Jargon soup | Three unexplained acronyms in one answer | One-sentence definition or cut the term |
| The two-minute monologue | Host has not spoken in 90 seconds | Land the so-what, then stop and hand back |
| Diagram-in-audio | "Picture a box with three arrows" | Metaphor plus one number |
| Hedging | Every answer starts with "it depends" | Give the default answer first, then the condition that changes it |
| Over-scripting | A word-for-word script that collapses when interrupted | Bullet card only; rehearse the spine, not the sentences |
| Overclaiming | A roadmap promise or an unpublished benchmark | Only numbers the company already published |
| Dodging | "I can't speak to that" on an obvious question | Acknowledge, concede the real limit, bridge |
| Panel invisibility | Waiting to be asked, then agreeing with the last speaker | Jump in with a one-sentence headline of your own |
| No call to action | Closing question wasted on "just google us" | One destination, said slowly, spelled if unusual |
## References
- [./references/prep-brief-template.md](./references/prep-brief-template.md) - The prep brief's exact shape and a filled example.
- [./references/sound-bite-examples.md](./references/sound-bite-examples.md) - Sound bite and bridging pairs, positive and negative.
- [./references/question-bank.md](./references/question-bank.md) - Hard-question classes and the rehearsal method.
- [./references/format-playbooks.md](./references/format-playbooks.md) - Per-format drills and the sources behind every named framework and number in this skill.