samber/developer-relations-skillsチェック済み
SKILL DETAIL
tech-talk-outline
samber/developer-relations-skills/tech-talk-outline
Turns an accepted conference talk abstract into a rehearsable outline - the one-sentence takeaway, a narrative arc, a minute-by-minute time budget, demo placement, and a slide skeleton with cut checkpoints. Use whenever someone says "talk outline", "technical talk structure", "slide skeleton", "my talk got accepted, now what", "how do I structure this conference talk", "my talk runs over time", "what do I cut from my talk", or "where should the demo go" - even if they only say they are preparing a conference session. Structures what the talk says. Not the CFP abstract - use samber/developer-relations-skills@conference-cfp-submission. Not slide files, not stage-delivery coaching.
インストール · 417出典を見る
Installation
npx skills add https://github.com/samber/developer-relations-skills --skill tech-talk-outline
スキルファイル
SKILL.md
最終同期 · 2026/10/23
evals/evals.json›
{
"skill_name": "tech-talk-outline",
"evals": [
{
"id": 1,
"prompt": "Just got the acceptance email. 'Postgres Wire Protocol Without the Driver' is in at ScaleConf Lisbon, 25 minute slot with 5 minutes of Q&A after it, platform track. Here is the abstract I submitted: 'Every language reimplements the Postgres wire protocol badly. We ripped out our ORM's driver and spoke the protocol directly, cutting p99 from 340ms to 61ms. You will leave able to decide whether raw protocol access is worth it for your service, and how to measure it.' I'm a staff engineer at Klaxis and I also maintain the open-source client we built out of this work. I have the benchmark harness, before and after flame graphs, and the migration diff. Talk is in seven weeks and I can rehearse most evenings. Can you put the outline together?",
"expected_output": "An interview started one question at a time, not a finished outline; then a gated-and-ranked arc menu presented for the speaker to choose from, an arrow, evidenced pillars, a buffered time budget, and an affiliation disclosure in the first minute.",
"files": [],
"expectations": [
"Asks clarifying questions before producing any outline, one question per message rather than a single batched questionnaire",
"Does not deliver a finished talk outline in the first response",
"Presents 2-3 candidate narrative arcs and waits for the speaker to choose before continuing, rather than selecting one silently",
"States that arcs the available material, the audience's starting belief, or the slot length make infeasible are deleted from the menu entirely, not ranked last",
"Ranks the surviving arcs by belief moved per hour of preparation and names a recommended leader",
"Names what that ranking starves - a high-value, high-effort arc that loses on ratio - and the condition that would promote it anyway",
"Produces a single-sentence arrow and states that it is reused verbatim as the closing line",
"Carries the accepted abstract's own promise (deciding whether raw protocol access is worth it, and how to measure it) into the outline instead of substituting a different takeaway",
"Proposes 2-3 pillars and names a concrete piece of evidence for each one, drawn from the benchmark harness, the flame graphs, or the migration diff",
"Places a moment of realization at a named minute and ties it to a specific belief that flips",
"Reserves 10-15% of the 25-minute slot as unused buffer and states the buffer amount explicitly",
"Instructs the speaker to state in the first minute that they maintain the client being presented, and to name where it is the wrong choice",
"Sets no target slide count and prescribes no slides-per-minute ratio"
]
},
{
"id": 2,
"prompt": "30 minute slot at IndexConf, Q&A is inside it. My outline right now is: 0-5 live demo of Trailhead's query planner rewriting a bad join, 5-12 how the planner works, 12-22 three customer case studies, 22-28 the architecture, 28-30 wrap. I want to lead with the demo because that is the thing that makes people go whoa and I need them awake early. And I want to close on a second, bigger demo so people leave impressed. The opening demo takes about 3 minutes when I run it at my desk. Does this hold up?",
"expected_output": "A rejection of both the opening demo and the closing demo, with the demo relocated behind the pillar it proves, a 2x time budget, a watch-this line, and the arrow moved into the closing position.",
"files": [],
"expectations": [
"Rejects opening the talk with the demo, on the grounds that the audience does not yet believe the problem at minute zero",
"States that the same demo shown before the problem lands reads as a product tour, and only reads as proof once the problem has landed",
"Moves the demo to sit after the pillar whose claim it proves",
"Rejects ending the talk on a demo",
"Requires at least two minutes of speaking inside the slot after the demo ends",
"Gives the reason that an overrun must not be able to eat the conclusion, so the arrow stays the last thing heard",
"Budgets the demo at roughly twice its rehearsed desk length - about 6 minutes for a 3-minute desk run, not 3",
"Requires the speaker to state what to watch before starting the demo, and gives a concrete example of such a line",
"Labels the two-minute floor and the 2x demo budget as this skill's own defaults rather than measured or published thresholds",
"Reserves 3 to 4.5 minutes of the 30-minute slot as unused buffer",
"Flags that no single mode should run longer than about seven minutes without a change of mode",
"Returns a revised minute-by-minute budget in which the closing position holds the arrow restated in the same words as the hook, not a demo"
]
},
{
"id": 3,
"prompt": "Talk is Thursday and it is Monday night. 20 minute slot at a regional cloud conference. I have maybe two hours total between now and then, including tonight. The plan was to live-code a Kubernetes admission controller from an empty file against our staging cluster - build the whole thing on stage, about 12 minutes of typing. Everyone loves watching someone build something from nothing. My laptop, their wifi. What is the best way to structure it?",
"expected_output": "Unscripted live typing and progressive construction removed from the options outright because of the two-hour ceiling, a narrated screencast recommended instead, with the fidelity-tier orderings stated and the deadline named as what re-ranked the arcs.",
"files": [],
"expectations": [
"Removes unscripted live typing from the options entirely rather than offering it with caveats, because the two-hour rehearsal ceiling cannot cover it",
"Removes the progressive-construction arc for the same reason instead of ranking it last",
"States the principle that an option the speaker has no hours to rehearse is not presented at all",
"Recommends a narrated screencast, or an equivalent pre-recorded demo, as the fidelity tier for this case",
"States the efficiency ordering of demo fidelity tiers: narrated screencast > scripted live demo against a prepared environment > unscripted live typing",
"States that the value ordering runs the opposite way, because unscripted live typing is the only tier an audience cannot suspect and a screencast asks the room to take the recording on trust",
"Names the condition that would promote unscripted live typing anyway: when liveness itself is the claim being made",
"States that every retake of a narrated screencast is free, which is what makes that tier cheap on effort",
"Flags the compliance cost of demoing against a live staging cluster in a room that may be recorded",
"Recommends an arc built from material the speaker has already lived rather than one that must be constructed and verified, because of the three-day deadline",
"Says explicitly which answer moved which option - the rehearsal ceiling deleting the tiers, the deadline re-ranking the arcs",
"Surfaces the speaking.io position that the only way to win a live demo in front of hundreds of strangers is not to do one"
]
},
{
"id": 4,
"prompt": "I built this talk for a 45-minute slot at our internal engineering summit and it clocks 41 minutes. It has now been accepted at DataCouncil but the slot is 25 minutes with Q&A inside. Three pillars: (1) why our ingest pipeline fell over at 400k events per second, (2) the backpressure model we replaced it with, (3) a cost teardown showing 18k dollars a month saved. Plus a 4-minute demo of the new dashboards. Tell me exactly what to cut and in what order.",
"expected_output": "A refusal to rank the cut list from the outline text, replaced by the accordion procedure that produces the cut order as a measurement, plus whole-pillar cutting, never-cut slides, and clock-time cut checkpoints.",
"files": [],
"expectations": [
"Declines to produce a ranked cut list from the outline text alone",
"Gives the reason: the cut order is what the accordion measures, and a ranking computed from the outline would be false precision substituted for a real measurement",
"Prescribes the accordion - deliver the talk to a 3-minute timer, then 2, then 1, then 30 seconds",
"Requires the speaker to stay in character and end strong on every rep rather than skimming",
"Requires expanding back up through 1, 2 and 3 minutes, adding material deliberately",
"States that what survives the 30-second rep is the arrow and the pillars",
"States that whatever only reappears on the way back up is the cut list, in cut order",
"Distinguishes what is ranked before rehearsal - the arc and the demo - from what rehearsal itself ranks, which is the cuts",
"Prescribes dropping a whole pillar rather than thinning all three to fit",
"Requires deriving the single-sentence arrow and re-reading the accepted abstract's promise before cutting, since both are what the cut list is judged against",
"Sets the gate at two consecutive timed runs landing inside 25 minutes minus the buffer",
"Writes cut checkpoints into the speaker notes as a clock time plus what gets dropped, for example 'past 0:14 at slide 12, drop pillar 3'",
"Names the slides that must never be cut, including the hook, the moment of realization and the arrow"
]
},
{
"id": 5,
"prompt": "We are running the same talk at four events this year. First is a 10-minute lightning slot at a local Go meetup, then 30 minutes at a European Go conference, then two 40-minute internal sessions at customer sites. The talk is 'Zero-allocation JSON decoding in Go' and the 30-minute version has three sections plus a benchmark demo. How do I get the 10-minute version out of the 30-minute one?",
"expected_output": "The lightning version re-derived from the arrow as a single movement rather than three compressed sections, with a forced choice between the point and the demo, and the four-event re-give named as the reason to promote a more expensive arc and a recorded demo.",
"files": [],
"expectations": [
"Refuses to produce the lightning version by proportionally compressing the three existing sections",
"Re-derives the 10-minute version from the arrow rather than from the 30-minute outline",
"States that a lightning slot holds one movement, not a compressed three",
"States that a 5-10 minute slot carries one point or one demo, never both",
"Forces an explicit choice between the single surviving point and the benchmark demo for the lightning slot",
"Notes that the lightning slot rules out the sparkline arc",
"Notes that the lightning slot rules out the progressive-construction arc",
"Treats the four-event re-give as a reason to promote a more expensive arc, because the preparation amortizes across every later slot instead of being paid once",
"Recommends recording the benchmark demo once, on the grounds that a recorded demo amortizes across the four slots the same way",
"Says explicitly that the re-give answer is what moved those rankings",
"Recommends storing the arrow, the chosen arc, the pillars and the cut list so the later slots are re-derived from the same decisions instead of re-invented into a different talk"
]
},
{
"id": 6,
"prompt": "Can you just generate the deck? 22-minute slot so I want 22 slides, one a minute, that is what our comms team says. Talk is 'How we cut cold starts by 80 percent on our serverless platform' at Velocity Berlin. Give me the actual slides, title and bullets for each, and export something I can drop straight into Google Slides. Audience is mixed, backend engineers plus a few engineering managers.",
"expected_output": "A refusal to emit slide files and to accept the 22-slide target, replaced by an ordered list of what each slide must accomplish, presented section by section with approval gates, and handed over as a document.",
"files": [],
"expectations": [
"Refuses to output slide files or a deck export, and states that slide files come later from a deck tool",
"Rejects the 22-slides-for-22-minutes rule and states that slide count is an outcome, never a target",
"Gives the range slide counts legitimately take as a counter-example - a story-led talk on a handful of slides, a dense technical talk running around a hundred in thirty minutes",
"Produces instead an ordered list of what each slide must accomplish",
"Requires each slide title to be written as the takeaway sentence rather than a topic label, and shows a worked contrast between the two",
"Requires one idea per slide, and splitting any slide that carries more than one",
"Requires that nothing appear on screen the speaker is not about to say, with the reason that the audience reads faster than the speaker talks",
"Gives every section a marker slide so a listener who drifted has a visible way back into the talk",
"Places the repository, docs and handle on a slide that appears twice - once where it becomes useful, once at the end",
"Marks the slides that must never be cut under time pressure",
"Presents the skeleton one section at a time and asks for approval before moving to the next, rather than dumping the whole thing at once",
"Hands the outline over as a document or file rather than leaving it in the chat log, where the environment allows writing one",
"Describes a job per slide rather than a title-and-bullets design, for example 'cold-start latency histogram with the warm-pool cutover marked; hold it silently for a beat'"
]
},
{
"id": 7,
"prompt": "I freeze on stage. Last time I blanked at minute four and just stood there. So this time I want the whole talk written out word for word so I can memorize it and never be lost. 35-minute slot. Also, I have written about 4,200 words of it so far, how many minutes is that? And I read somewhere that 185 to 254 words per minute is the range that keeps people engaged, should I be pacing to that? English is not my first language.",
"expected_output": "A refusal to write spoken prose, replaced by note cues with timing checkpoints, plus a refusal to convert 4,200 words using a generic rate and a correction of the 185-254 wpm band's provenance.",
"files": [],
"expectations": [
"Refuses to write the talk out as prose to be read aloud, despite the speaker explicitly asking for it",
"States that the memorized word-for-word script is what causes the freeze, because talking points survive losing your place on stage while memorized prose does not",
"Surfaces the speaking.io position that an outline is a point to channel thoughts, not the verbatim bible of the talk",
"Offers speaker-note cues instead: per section, a timing checkpoint plus what gets dropped if the clock is behind",
"Refuses to convert 4,200 words into minutes using a table value or a generic words-per-minute figure",
"Instructs the speaker to measure their own rate by reading 200 of their own words aloud, timing it, and dividing",
"States that the 185-254 wpm band is the fastest quintile of the study's corpus, not a target the paper sets",
"States that the study's authors treat speaking rate as a surface feature that tracks enthusiasm, and advise against forcing faster delivery",
"Notes that a rate measured on the speaker's second language differs from one measured on their first",
"Does not advise the speaker to speed up in order to reach the quoted band",
"Attributes the rate-versus-engagement finding to a study of edX instructional-video sessions rather than to conference-stage measurement"
]
},
{
"id": 8,
"prompt": "I do DevRel at Corvid, an observability startup. 30-minute session at ObservabilityDays, Q&A after the slot. The product shipped seven things this quarter: adaptive sampling, a trace-diff view, OTel-native ingest, per-service budgets, a query language, anomaly alerts, and a Terraform provider. Marketing wants all seven in the talk. Room is roughly 60 percent hands-on SREs, 30 percent staff engineers, 10 percent engineering managers. I have been on this product for two years and know it cold. Draft the structure.",
"expected_output": "A refusal to structure the talk as a feature walkthrough, with problems promoted to pillars and features demoted to evidence, depth calibrated below the deepest listener, and affiliation disclosed in the first minute.",
"files": [],
"expectations": [
"Refuses a feature-by-feature structure and names it as the feature-tour anti-pattern",
"States that the only legitimate feature tour is a release keynote, where the audience explicitly came for the list",
"Makes the problems the pillars and demotes each feature to evidence under the problem it solves",
"States that a feature with no problem to sit under is cut from the talk",
"Reduces the seven features to at most three pillars",
"Calibrates depth one level below the deepest listener in the room so the median attendee stays in, rather than targeting the average or the most senior",
"Names the curse of knowledge and states that the speaker's own depth estimate errs toward too deep, never too shallow",
"Cites the tapper and listener figures as 50 percent predicted against 2.5 percent actually named",
"Attributes those figures to Heath and Heath's retelling in Made to Stick rather than directly to the 1990 Stanford study",
"Names, per pillar, the single term the speaker will define out loud, instead of simplifying the whole talk",
"Recommends having someone outside the team read the outline and mark where they got lost",
"Requires the speaker to say in the first minute that they work on the product, name competing approaches fairly, and state where Corvid is the wrong choice",
"Gives the reason that an engineering audience discovers the affiliation anyway, and a late reveal retroactively turns the whole talk into an advertisement"
]
},
{
"id": 9,
"prompt": "Talk went out three weeks ago and the recording has been up for two. Our VP wants a number: she is asking what percentage retention counts as a good conference talk, and whether we should be shortening future talks to six minutes since that is apparently where people drop off. We have 1,400 views, a spike around minute 14, a dip from minute 6 to minute 9, and 212 clicks through to the repo. Session feedback score was 4.3 out of 5. Is the talk working, and what do I fix for the next one?",
"expected_output": "A refusal to set a retention target or to shorten future talks, with the dip used to locate a failing section, the spike treated as ambiguous, and the repo clicks reported as directional only.",
"files": [],
"expectations": [
"Refuses to set a target retention percentage, and states that the curve is used to locate a failing minute rather than to score the talk",
"Reads the minute 6 to 9 dip as locating a section that stopped paying, and points the fix at that section of the outline",
"Treats the minute 14 spike as ambiguous, since a spike can mean rewatched because it was good or because it was unclear",
"Names the share still watching after the first 30 seconds as the measure that indicts the hook and the promise",
"Rejects shortening future talks to six minutes",
"States that the six-minute median engagement figure comes from instructional video where viewers can skip, and a seated conference room cannot",
"Concludes that the finding constrains the published recording, not the talk that was accepted",
"Recommends chapter markers and short extracted clips as the response to partial viewing",
"States that attribution from the talk to the 212 repo clicks is weak, and treats the figure as directional only",
"Refuses to let a link-click count decide whether the talk was good",
"Reports the signals as movement against the speaker's own previous talk rather than against an absolute benchmark",
"Recommends rewatching the dipped segment before rewriting it, because a retention curve locates a failure without explaining it"
]
}
],
"trigger_queries": [
{ "query": "my talk got accepted, now what", "should_trigger": true },
{ "query": "how do I structure this conference talk", "should_trigger": true },
{ "query": "talk outline for a 25 minute session", "should_trigger": true },
{ "query": "I need a slide skeleton for my KubeCon talk", "should_trigger": true },
{ "query": "where should the demo go in my talk", "should_trigger": true },
{ "query": "my talk runs 12 minutes over the slot, what do I cut", "should_trigger": true },
{ "query": "help me plan a technical talk", "should_trigger": true },
{ "query": "I have 40 minutes of material and a 25 minute slot", "should_trigger": true },
{ "query": "how do I turn this accepted abstract into an actual talk", "should_trigger": true },
{ "query": "what narrative arc works for a talk about our outage", "should_trigger": true },
{ "query": "structure a lightning talk", "should_trigger": true },
{ "query": "I'm giving a keynote next month and don't know how to open it", "should_trigger": true },
{ "query": "what's the one thing people should remember from my talk", "should_trigger": true },
{ "query": "budget the minutes for a 45 minute session", "should_trigger": true },
{ "query": "should the live demo be at the start or the end of my session", "should_trigger": true },
{ "query": "I got accepted at SREcon and I've never given a talk before", "should_trigger": true },
{ "query": "help me outline a conference session about our migration", "should_trigger": true },
{ "query": "how many slides for a 30 minute talk", "should_trigger": true },
{ "query": "my last talk lost the room at minute five", "should_trigger": true },
{ "query": "I'm on at 2pm Thursday and have no idea what order to put things in", "should_trigger": true },
{ "query": "turn my accepted abstract into something I can rehearse", "should_trigger": true },
{ "query": "what goes in the first three minutes of a technical talk", "should_trigger": true },
{ "query": "I think I need to cut a whole pillar from my talk", "should_trigger": true },
{ "query": "how do I rehearse a conference talk", "should_trigger": true },
{ "query": "run the accordion method on my talk", "should_trigger": true },
{ "query": "I'm speaking on the platform engineering track and have no structure yet", "should_trigger": true },
{ "query": "my session is 20 minutes plus Q&A, how do I split it up", "should_trigger": true },
{ "query": "talk structure help", "should_trigger": true },
{ "query": "what should the closing slide of my talk say", "should_trigger": true },
{ "query": "I need the same talk in a 10 minute version", "should_trigger": true },
{ "query": "outline a technical presentation about our new architecture", "should_trigger": true },
{ "query": "how do I stop my session from feeling like a product demo", "should_trigger": true },
{ "query": "our talk is basically a feature list right now, how do I fix that", "should_trigger": true },
{ "query": "how do I make sure people repeat one sentence back after my session", "should_trigger": true },
{ "query": "I'm on stage in three weeks with nothing written", "should_trigger": true },
{ "query": "my session for DevOpsDays got accepted, how do I build it out", "should_trigger": true },
{ "query": "how much buffer should I leave inside a conference slot", "should_trigger": true },
{ "query": "where does a live coding segment belong in a 30 minute session", "should_trigger": true },
{ "query": "write cut checkpoints into my speaker notes", "should_trigger": true },
{ "query": "I need to know what to drop on the fly if I'm running behind on stage", "should_trigger": true },
{ "query": "help me find the takeaway sentence for my talk", "should_trigger": true },
{ "query": "which story shape works for presenting a postmortem on stage", "should_trigger": true },
{ "query": "I'm re-giving the same talk at four events with different slot lengths", "should_trigger": true },
{ "query": "our session was accepted, can you help me actually build the thing", "should_trigger": true },
{ "query": "how do I open so people don't open their laptops instead", "should_trigger": true },
{ "query": "plan the minute by minute for my conference session", "should_trigger": true },
{ "query": "I always go over time when I speak at conferences", "should_trigger": true },
{ "query": "should I write my conference talk out word for word or just use bullets", "should_trigger": true },
{ "query": "how do I calibrate depth for a mixed room of SREs and managers in my talk", "should_trigger": true },
{ "query": "our CFP got in, need to actually build the thing now", "should_trigger": true },
{ "query": "what's the spine of a good engineering talk", "should_trigger": true },
{ "query": "I'm presenting our benchmark results at a conference, how should I lay them out", "should_trigger": true },
{ "query": "write my CFP abstract for KubeCon", "should_trigger": false },
{ "query": "which conferences should I submit to this year", "should_trigger": false },
{ "query": "my proposal keeps getting rejected, review it", "should_trigger": false },
{ "query": "what should the takeaways field say on this CFP form", "should_trigger": false },
{ "query": "build me a submission calendar for next year's conferences", "should_trigger": false },
{ "query": "how long should the speaker bio be in a conference proposal", "should_trigger": false },
{ "query": "give me title options for a talk proposal", "should_trigger": false },
{ "query": "what do reviewers look for in the private notes field of a CFP", "should_trigger": false },
{ "query": "our talk got rejected from three conferences, should we change the topic", "should_trigger": false },
{ "query": "my live demo broke on stage last time, how do I make it reliable", "should_trigger": false },
{ "query": "I need a one-command reset for my demo environment", "should_trigger": false },
{ "query": "build a demo runbook with independently enterable checkpoints", "should_trigger": false },
{ "query": "what's my fallback if the demo dies mid-talk", "should_trigger": false },
{ "query": "how do I make a demo work offline at a conference venue", "should_trigger": false },
{ "query": "pre-flight checklist for a live demo", "should_trigger": false },
{ "query": "rehearsed recovery lines for when the demo throws an error", "should_trigger": false },
{ "query": "write a script for a 10 minute screencast", "should_trigger": false },
{ "query": "beat sheet for a product walkthrough video", "should_trigger": false },
{ "query": "how do I pace code on screen in a tutorial video", "should_trigger": false },
{ "query": "add chapter markers to our YouTube demo video", "should_trigger": false },
{ "query": "recut my recorded talk into vertical shorts for social", "should_trigger": false },
{ "query": "I'm a guest on a podcast next week, prep me", "should_trigger": false },
{ "query": "clip-safe sound bites for a livestream interview", "should_trigger": false },
{ "query": "research a podcast host before I record with them", "should_trigger": false },
{ "query": "write up our outage as a blog post", "should_trigger": false },
{ "query": "turn this benchmark into an engineering blog article", "should_trigger": false },
{ "query": "write a workshop handout for a three hour hands-on lab", "should_trigger": false },
{ "query": "audit our quickstart for time to first success", "should_trigger": false },
{ "query": "write a build-along tutorial for our SDK", "should_trigger": false },
{ "query": "plan a quarter of devrel content with owners and reviewers", "should_trigger": false },
{ "query": "when should we publish the blog post around our conference talk", "should_trigger": false },
{ "query": "should we sponsor that conference at gold tier", "should_trigger": false },
{ "query": "what does a booth cost at a developer conference", "should_trigger": false },
{ "query": "design the booth activation for the event we're sponsoring", "should_trigger": false },
{ "query": "start a monthly Go meetup in Lisbon", "should_trigger": false },
{ "query": "find speakers for our user group", "should_trigger": false },
{ "query": "generate slides with Marp from this markdown file", "should_trigger": false },
{ "query": "build an HTML slide deck with Slidev", "should_trigger": false },
{ "query": "make me a reveal.js presentation", "should_trigger": false },
{ "query": "convert my notes into a Google Slides file", "should_trigger": false },
{ "query": "design a reusable template for our company slide deck", "should_trigger": false },
{ "query": "fix the typography and spacing on these slides", "should_trigger": false },
{ "query": "coach me on stage presence and hand gestures", "should_trigger": false },
{ "query": "how do I stop shaking and losing my voice when I present", "should_trigger": false },
{ "query": "help me with my seed round investor pitch deck", "should_trigger": false },
{ "query": "data storytelling for a quarterly business review", "should_trigger": false },
{ "query": "write speaker notes for my manager's all-hands presentation", "should_trigger": false },
{ "query": "write the LinkedIn post announcing that I'm speaking at the conference", "should_trigger": false },
{ "query": "which DevRel podcasts and newsletters should I be following", "should_trigger": false },
{ "query": "measure whether our whole conference program was worth the budget", "should_trigger": false },
{ "query": "write a case study about how Acme deployed our SDK in production", "should_trigger": false },
{ "query": "our README needs a rewrite before the talk drives traffic to it", "should_trigger": false }
]
}
references/narrative-arcs.md›
# Narrative arcs for technical talks
Six arcs that hold a technical audience, plus the one to avoid. Pick with the speaker, do not assign silently - the arc decides which material survives.
## Contents
- Choosing an arc
- 1. Problem → dead ends → insight → proof
- 2. Incident
- 3. Migration (before/after)
- 4. Progressive construction
- 5. Contrarian
- 6. Sparkline (what is / what could be)
- Anti-pattern: the feature tour
- Named methods worth citing
## Choosing an arc
First, the gate: three questions decide which arcs are even available. Delete the ones that fail - do not present an arc the speaker cannot deliver and then rank it last, because a shortlisted impossibility comes back as a week of wasted drafting.
1. **What raw material exists?** An incident, a benchmark, a migration and a from-scratch implementation each already imply an arc. No outage, no incident arc. Do not invent a narrative the speaker cannot source.
2. **What does the audience already believe?** If they agree the problem exists, skip to the insight (arcs 3, 4). If they do not, the talk must earn the problem first (arcs 1, 2). If they believe the opposite, the talk is contrarian (arc 5) - and an audience that already agrees rules that arc out entirely.
3. **What is the slot?** Lightning slots hold one movement only, which removes both the sparkline and progressive construction. Keynotes tolerate the sparkline, but a 25-minute technical session usually does not.
Then rank what survived by belief moved per hour of preparation, not by which is easiest to draft - that is how a speaker ends up with a migration talk that convinces nobody:
- efficiency: incident > migration > problem → dead ends → insight > contrarian > sparkline > progressive construction
- effort: incident == migration (both are recall: the speaker lived it, and the work is selection and ordering rather than invention) > problem → insight (the dead ends have to be reconstructed and each one verified) > sparkline (an alternating structure that has to be written and rehearsed as a single piece) > contrarian (demands stronger evidence than any other arc, because every claim will be attacked) > progressive construction (every step must work live, and it eats most of the deck)
- value: progressive construction (the audience can rebuild the thing afterwards - the deepest transfer available) > contrarian (changes a belief the room walked in with) > incident (credibility no other arc buys: the speaker was there and admits what they got wrong) > problem → insight (transfers a technique) > migration (maps onto the audience's actual week) > sparkline (moves belief without handing over anything executable)
No compliance-cost axis applies to the choice of arc. It reappears in the material: an incident arc needs externally-visible detail cleared with whoever owns it before the slot, and that is a gate on the evidence, not a cost of the structure.
Efficiency starves progressive construction - the highest-value arc on the list and the most expensive to rehearse, so it loses every round and speakers default to safer shapes. Promote it when these hold together: a long slot, weeks of rehearsal time, and a subject that genuinely assembles in steps. A workshop-adjacent session is exactly its case.
This order is a default, not a law, and it shifts with who is giving the talk. Re-rank against what you know about this speaker:
- Someone who teaches for a living pays far less for progressive construction than the ranking assumes.
- Someone re-giving the talk at four events amortizes any expensive arc across all of them.
- A speaker whose only real asset is one spectacular outage has an incident arc that outranks everything regardless of ratio.
## 1. Problem → dead ends → insight → proof
The default for a technical argument.
Shape: the problem, made concrete with a number → the obvious fixes and exactly why each one fails → the insight that unlocks it → evidence it works → the arrow restated.
Why it holds: walking the audience through the dead ends is what earns the insight. Skip them and the insight sounds obvious, so the audience concludes they already knew it.
Trap: spending so long on dead ends that the insight arrives with four minutes left. Cap the dead ends at one third of the body.
## 2. Incident
Shape: the system as it was believed to work → the timeline of the failure → the moment the belief broke → what actually changed afterwards (code, process, architecture) → what generalizes.
Why it holds: incidents carry built-in tension and the speaker is unambiguously credible about their own outage. Engineers trust a talk that admits what its authors got wrong more than one that shows a system working.
Trap: turning the timeline into the whole talk. The timeline is a pillar, not the arc - the generalizable lesson is what the audience is there for. Also, clear externally-visible incident detail with whoever owns it before the slot.
## 3. Migration (before/after)
Shape: the old system and the constraint that made it untenable → the forcing function → the options considered → the new system → the real cost, including what got worse.
Why it holds: an audience mostly maintains existing systems. A migration story maps onto their week better than a greenfield design.
Trap: omitting what got worse. Every migration trades something away, and a talk that reports only gains reads as marketing and gets attacked in Q&A.
## 4. Progressive construction
Shape: build the thing from nothing on stage - a parser, a scheduler, a protocol client - adding exactly one concept per step, each step working.
Why it holds: the audience derives the design instead of being shown it, so they can rebuild it later.
Trap: the pace. Each step needs a visible working state, and three concepts introduced in one step lose the room permanently. This arc also consumes slide budget fast - reserve most of the deck for it.
## 5. Contrarian
Shape: state the received wisdom fairly, in its strongest form → the evidence against it → the boundary where it does hold → the replacement rule.
Why it holds: it earns attention immediately, and steelmanning the received wisdom is what stops the room from becoming defensive.
Trap: a weak version of the opposing view. If the audience recognizes a strawman, the talk is over - and this arc requires stronger evidence than any other, since the audience starts out disagreeing.
## 6. Sparkline (what is / what could be)
Nancy Duarte's structure from _Resonate_: open in the ordinary world ("what is"), alternate repeatedly between what is and what could be, and end on the new normal rather than a summary. The gap between the two states is what creates momentum.
Use it for keynotes, ecosystem talks and vision slots - anywhere the goal is a change in belief rather than a transferable technique.
Trap: it needs a real gap. Applied to a 25-minute how-to talk it inflates a modest technique into a manifesto, which a technical audience reads as a pitch.
## Anti-pattern: the feature tour
"Here is our product, here are its features, in menu order." It has no tension, no arrow, and nothing to remember. The only legitimate version is a release keynote, where the audience explicitly came for the list.
The fix is mechanical: make the problems the pillars and demote each feature to evidence under the problem it solves. If a feature has no problem to sit under, it does not belong in the talk.
## Named methods worth citing
- **Bow and Arrow** (Tristan de Montebello): the arrow is the one sentence the audience remembers, and the bow is the two or three stories, numbers and illustrations that give it force. Applies to the whole talk and to each slide - including the trick of writing the slide title as its takeaway.
- **The 5-Second Moment** (Matthew Dicks): every story turns on a single moment of transformation or, more often, realization - "I used to think X, now I think Y". In a technical talk this is the benchmark that contradicted the team, or the outage that killed the architecture.
- **The Accordion Method** (Tristan de Montebello): compress the talk to 3, 2, 1 and 0.5 minutes, then expand back up. What survives the shortest rep is the talk, and what reappears on the way up is the cut list, in cut order.
- **Inside outlining** (Zach Holman, speaking.io): write the main sections first and resist fleshing them out, then add one or two supporting points per section, then at most a third tier. Three sections is his default, and he treats the outline as "a point to channel my thoughts, _not_ as the verbatim bible of my talk".
references/slide-and-demo-craft.md›
# Slide and demo craft for a technical talk
Craft rules for the artifacts the outline produces: the slide skeleton, the code slides, and what the audience sees on screen during the demo. Reliability engineering for the demo itself is a different job - this file only covers what is legible and what is remembered.
## Contents
- Slide count is an outcome, never a target
- Writing a slide's job into the skeleton
- Code on slides
- Room legibility
- Accessibility
- Demo legibility on stage
- The deck's second life
- Skeleton checklist
## Slide count is an outcome, never a target
There is no slides-per-minute rule, and skills that invent one optimize the wrong variable. A story-led talk can run on three slides. A dense technical talk can run a hundred in thirty minutes with two words on each, flipping ten in twenty seconds through a joke and then holding one for five minutes.
Emit an ordered list of what each slide must accomplish, and let the count fall out of it. If the speaker asks for a number anyway, tell them the count they end up with after the first timed run is the correct one.
## Writing a slide's job into the skeleton
Each entry in the skeleton names a job, not a design. "Request-rate graph with the dependency recovery marked; hold it silently for a beat" is a job. "Nice chart" is not.
- Give every section a marker slide. A listener who drifted for ninety seconds needs a visible door back into the talk, and a three-pillar talk has exactly three of them.
- Mark the slides that must never be cut - usually the hook, the moment of realization, and the arrow. Everything else is negotiable under time pressure.
- Attach the timing checkpoint to the slide it belongs to, so the speaker notes and the deck stay in sync when a slide moves.
- Put a slide's evidence next to the claim it supports. A number two slides away from the assertion it proves reads as decoration.
## Code on slides
- Show the smallest fragment that carries the point, never a full file. Cut imports, elide bodies with ellipses - a conference audience forgives both and thanks you for them.
- Highlight the changed lines instead of asking the room to mentally diff two dense slides.
- Never read code aloud line by line. Say what it does, then point at the one line that matters.
- One code slide should teach one thing. If it needs two sentences of setup and two of payoff, it is two slides.
- Prefer a diagram over code when the point is structure, and code over a diagram when the point is a specific API call or an exact failure.
## Room legibility
- Terminal text at 24pt or larger, editor text at 20pt or larger - practitioner convention repeated across speaking guides, not a measured threshold. The back row and the recording crop are what it protects.
- Use a high-contrast theme. A dark theme that looks sharp on a laptop is often unreadable on a washed-out projector, and daytime slots are usually the bright rooms.
- Assume a 16:9 screen with the bottom sixth blocked by heads or a lower-third banner. Nothing load-bearing lives there.
- Check the room's throw distance if the schedule allows - a talk designed for a 300-seat hall wastes its detail in a 40-seat side room, and vice versa.
## Accessibility
- Never convey meaning by color alone. Red/green diffs lose color-blind attendees and bad projectors alike - add a `+`/`-`, a label, or a shape.
- Say out loud what a graph shows before discussing it. Attendees at the back, in a live-caption feed, or listening to the recording on headphones all depend on the narration.
- Keep animation minimal and purposeful - per-word builds slow the talk and break screen readers of the published deck.
- Write image alt text into the published version of the deck, not just the on-stage one.
## Demo legibility on stage
- Zoom the terminal and editor before walking on, not during. Adjusting font size live burns 30 seconds and signals unpreparedness.
- Hide the noise: notifications off, tabs closed, secrets purged, shell prompt shortened, browser bookmarks bar cleared.
- Say what to watch before starting ("watch the p99 line, not the log output"). An unnarrated demo reads as filler even when it works.
- Narrate the waiting. A silent 20-second build feels like a failure to the room, so say what is happening and why it takes that long.
- Keep one slide of "what you just saw" immediately after the demo, so the point survives even if the demo half-worked.
## The deck's second life
Most conference talks are recorded and published, and the slides usually get uploaded separately. Consequences for the skeleton:
- Every slide must survive being screenshotted out of context. No "as I said earlier" references, and no critical information delivered only verbally over a visually empty slide.
- Put the repository link, docs link and speaker handle on a slide that appears twice: once at the point it becomes useful, once at the end where it gets paused and photographed. A link that appears only in the final five seconds is a link nobody captures.
- Export a PDF fallback before travelling. Presentation software failing on someone else's machine is routine, not exotic.
## Skeleton checklist
Before handing the skeleton over, verify:
- Every slide has one idea, and its title is the takeaway sentence rather than a topic label.
- Nothing is on screen that the speaker is not about to say.
- The speaker's line is never the slide's own words read aloud - it comments on what the slide already shows.
- Each section has a marker slide, and the never-cut slides are marked.
- Every code fragment passes the font-size and highlight-the-diff rules.
- No meaning depends on color alone.
- The link slide appears twice, and the final slide stays up through Q&A.
references/sources-and-defaults.md›
# Sources and defaults
Where every number, threshold and named method in this skill comes from, and which ones are this skill's own convention. Read it before quoting a figure to a speaker, an organizer or a report - a house default presented as research is a credibility risk for whoever repeats it.
## Contents
- How to read the status column
- Measured findings
- Named methods and their authors
- Practitioner conventions
- House defaults (this skill's own)
## How to read the status column
| Status | Meaning |
| ------------- | ---------------------------------------------------------------------------------------------- |
| Measured | Comes from a study or a platform's own instrumentation, with a sample size |
| Named method | A published framework with a named author; the method is real, its effect size is not measured |
| Convention | Repeated by experienced practitioners, never measured; treat as a strong prior |
| House default | Set by this skill because the task needs a number; argue with it freely |
## Measured findings
| Figure | Value | Source |
| ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Engagement vs. video length | The paper's own statement: median engagement time is at most 6 minutes regardless of total video length, and viewers often make it less than halfway through videos longer than 9 minutes. Brame's summary renders this as ~100% watched under 6 min, ~50% at 9-12 min, ~20% at 12-40 min | Guo et al., 6.9M edX viewing sessions; summarized in Brame, "Effective Educational Videos", _CBE Life Sciences Education_, 2016 |
| Narration rate and engagement | Engagement usually rose with speaking rate - up to 2x within a length range - across a corpus spanning 48-254 wpm (mean 156). The "185-254 wpm band" quoted in secondary summaries is the corpus's fastest quintile, not a target the paper sets; the authors call rate a surface feature of enthusiasm and advise against forcing faster delivery | Same study |
| Intro retention window | Percentage still watching **after the first 30 seconds** is a named metric in the platform's own retention report, alongside dips, spikes and top moments | YouTube audience-retention documentation |
| Intro length tolerance | An introduction longer than roughly 5 seconds already reads as long - the counter runs on ceremony, not on substance | Nielsen Norman Group video usability findings |
| Curse of knowledge | Tappers of a well-known song predicted listeners would name it 50% of the time; listeners scored 2.5% | Newton, Stanford, 1990, as reported in Heath & Heath, _Made to Stick_ - cite it as their retelling |
Two cautions apply before reusing these figures:
- The video figures come from instructional video and platform analytics, not from conference rooms - a seated conference audience cannot skip, so the length cliff constrains the talk's **recording**, not the talk itself.
- A retention curve locates a failure without explaining it - rewatch the segment before rewriting it.
## Named methods and their authors
| Method | Author | Used in this skill for |
| ---------------------------------- | ----------------------------------- | --------------------------------------------------------------- |
| Bow and Arrow | Tristan de Montebello | The arrow (one remembered sentence) and its pillars |
| The Accordion Method | Tristan de Montebello | Rehearsal, and deriving the cut list in cut order |
| The 5-Second Moment | Matthew Dicks | Locating the moment of realization |
| Inside outlining | Zach Holman, speaking.io | Writing sections first, resisting detail, three-section default |
| Sparkline | Nancy Duarte, _Resonate_ | The what-is / what-could-be keynote arc |
| SUCCESs and the curse of knowledge | Chip and Dan Heath, _Made to Stick_ | Depth calibration, and choosing which evidence a pillar carries |
Names and attributions for the Bow and Arrow, the Accordion and the 5-Second Moment are reliable. The wording used here is paraphrase, so credit the method without quoting it as the author's own sentence.
## Practitioner conventions
Widely repeated, never measured:
- Terminal text at 24pt or larger, editor text at 20pt or larger (speaking.io, and repeated across developer-advocacy speaking guidance).
- Slide count is not a rule - Holman runs ~100 slides in 30 minutes and also holds one for five minutes.
- 10-3-1 for a demo: rehearse 10 times, hold 3 checkpoints, keep 1 recorded backup.
- Holman on live demos, verbatim: _"Live demos are like Global Thermonuclear War: the only way to win is to not do a live demo in front of hundreds of strangers in the first place."_
- Holman on outlines, verbatim: _"I just use an outline as a point to channel my thoughts, not as the verbatim bible of my talk."_
- Slot archetypes (lightning 5-10 min, session 25-45, keynote 45-60) come from conference-programme convention, not from a standard.
## House defaults (this skill's own)
None of these is a published threshold. Each exists because the outline needs a decision, and each is meant to be argued with once the speaker has one timed run:
| Default | Value | Why this value |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- |
| Unused buffer | 10-15% of the slot | Absorbs laughter, A/V handover and one long question - the three overruns rehearsal never shows |
| Mode change | At least every 7 minutes | Long enough to land a pillar, short enough that a drifting listener gets a new entry point |
| Demo budget | 2x its rehearsed length | Stage typing, narration and audience reaction all stretch it |
| Speaking after the demo | At least 2 minutes | Keeps an overrun from eating the conclusion |
| Pillars | 2-3 | Three sections is the inherited default; a fourth pillar reliably steals the buffer |
| Dead ends in arc 1 | At most a third of the body | Beyond that the insight arrives with no room for proof |
| Quality gate | Two consecutive timed runs inside slot-minus-buffer, one-idea and title-as-takeaway per slide, evidence per pillar, demo ending 2 minutes early, a colleague restating the arrow unprompted | Assembled from the accordion method and the per-slide test, and set by this skill rather than by any standard |
Post-talk signals (feedback score, hallway and social repetition of the arrow, retention on the published recording, repo traffic in the following 48 hours) are **directional only**. Report them as movement against the speaker's own previous talk, and refuse to set a target number for them.
references/talk-outline-example.md›
# Worked example: a 30-minute talk outline
The output shape this skill produces, then the same talk structured badly.
## Contents
- Input
- Good outline
- Bad outline, and what each flaw costs
## Input
**Accepted abstract** (25-minute session + 5 minutes Q&A, platform-engineering track, mixed audience of hands-on engineers and staff engineers):
> _Our retry logic took down the payments API._ Retries are the first thing every service adds and the last thing anyone reviews. We rebuilt ours after a 40-minute outage that our own client library caused. You will leave knowing how to tell a safe retry policy from a dangerous one, and how to test the difference before production does it for you.
**Speaker**: platform engineer at the company that ran the outage. Independent of any vendor. Material available: the incident timeline, a load-test harness, before/after latency graphs.
## Good outline
**Arrow** - "A retry policy without a budget is a load amplifier you installed on purpose."
**Arc** - Incident. The audience already retries, but they do not yet believe it is dangerous, and the speaker owns a real outage that proves it.
**Pillars and their evidence**
1. Retries amplify, they do not absorb - the incident's request-rate graph, 3x amplification in 90 seconds.
2. Every safe policy has a budget - the four knobs (cap, jitter, budget, circuit) with the config diff that shipped.
3. You can test this before production does - the load-test harness, run live.
**Moment of realization** - minute 8: the dashboard showing traffic climbing _after_ the dependency recovered. That is when the room stops thinking retries are neutral.
**Time budget**
```
0:00-0:02 hook: the 40-minute outage, in one sentence, with the customer impact
0:02-0:04 promise: how to tell a safe policy from a dangerous one, and who this is not for
0:04-0:10 pillar 1: amplification (timeline + request-rate graph) → realization at 0:08
0:10-0:15 pillar 2: the four knobs, with the config diff
0:15-0:20 pillar 3: testing it (setup + framing)
0:20-0:23 demo: harness reproducing the amplification, then the fixed policy
0:23-0:25 arrow restated, one link slide
0:25-0:30 Q&A
```
Buffer: 3 minutes inside the 25, absorbed by the pillars.
**Slide skeleton** (24 slides; the count is an outcome, not a target)
| # | Slide must accomplish | Notes |
| ----- | ------------------------------------------------ | ------------------------------------------------ |
| 1 | Title + handle | |
| 2 | "Our retry logic took down payments" | The hook, no explanation |
| 3 | Customer impact in one number | 40 min, N failed payments |
| 4 | What you'll be able to tell apart afterwards | The promise |
| 5 | Not for you if: you don't own a client library | Scope, out loud |
| 6 | Section marker: retries amplify | |
| 7-10 | Timeline, four beats, one per slide | Each title = what broke |
| 11 | Request-rate graph, dependency recovery marked | The realization; hold it, say nothing for a beat |
| 12 | "Retries amplify, they don't absorb" | Pillar 1 landed |
| 13 | Section marker: every safe policy has a budget | |
| 14-17 | One knob per slide: cap, jitter, budget, circuit | |
| 18 | The config diff that shipped | Highlight changed lines only |
| 19 | Section marker: test it before production does | |
| 20 | What the harness does, in three lines | |
| 21 | DEMO - what to watch: the request-rate line | Checkpoint: past 0:22, skip the second run |
| 22 | Before/after latency graphs | Insurance if the demo dies |
| 23 | The arrow, verbatim from slide 2's promise | |
| 24 | Repo + docs + handle | Repeats slide 4's link; stays up through Q&A |
**Cut checkpoints for the speaker notes**
- Past 0:11 at slide 12 → compress pillar 2 to cap + budget, drop jitter and circuit slides.
- Past 0:20 at slide 19 → skip the live demo, show slide 22 instead, keep the arrow.
- Never cut: slides 2, 11, 23.
## Bad outline, and what each flaw costs
```
0:00-0:04 About me, about my company, our stack
0:04-0:07 What is a retry? What is exponential backoff?
0:07-0:12 Live demo of our new retry library
0:12-0:20 Feature tour: cap, jitter, budget, circuit, metrics, tracing, config
0:20-0:26 The outage story
0:26-0:30 Q&A
```
- **Four minutes on the speaker.** Credibility comes from the outage, not the bio. Costs the hook window entirely.
- **Defining exponential backoff to a platform-engineering track.** Below the room's floor - the audience opens laptops.
- **Demo at minute seven.** Nobody believes the problem yet, so it is a product tour of a library they have no reason to want.
- **Features as pillars.** Seven features in eight minutes means none is remembered, and there is no arrow to restate.
- **The outage at minute 20.** The one piece of material the audience cannot get anywhere else arrives when they have stopped listening, and there is no room left for the lesson.
- **Ends on Q&A.** The last thing heard is somebody else's question, not the takeaway.
SKILL.md›
---
name: tech-talk-outline
description: Turns an accepted conference talk abstract into a rehearsable outline - the one-sentence takeaway, a narrative arc, a minute-by-minute time budget, demo placement, and a slide skeleton with cut checkpoints. Use whenever someone says "talk outline", "technical talk structure", "slide skeleton", "my talk got accepted, now what", "how do I structure this conference talk", "my talk runs over time", "what do I cut from my talk", or "where should the demo go" - even if they only say they are preparing a conference session. Structures what the talk says. Not the CFP abstract - use samber/developer-relations-skills@conference-cfp-submission. Not slide files, not stage-delivery coaching.
license: MIT
metadata:
author: Samuel Berthe
version: "1.0.2"
---
# Conference Talk Outline
You are a technical talk architect. You turn an accepted abstract into an outline a speaker can rehearse, time, and cut live on stage.
Produce a structured document - not slides, not a script. Slide files come later, from a deck tool.
A word-for-word script is actively harmful: talking points survive losing your place on stage, but memorized prose does not. Hold Zach Holman's stance from speaking.io instead - "I just use an outline as a point to channel my thoughts, not as the verbatim bible of my talk."
Most numbers in this skill are its own defaults, not research. [`references/sources-and-defaults.md`](./references/sources-and-defaults.md) says which is which. Consult it before repeating a figure to the speaker as if it were a standard, and tell them which kind they are getting whenever they ask "why that number".
## Interview
Ask these one at a time, multiple-choice where possible. Stop as soon as you can build the outline - a talk needs context, not an intake form.
**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. Paste the accepted title and abstract, plus the outline you submitted in the CFP if there was one.
2. How long is the slot, and is Q&A inside it or after it?
3. Who is in the room - hands-on engineers, staff/architects, engineering managers, or a mixed track audience? Which conference track?
4. Is there a live demo? Required by the abstract, optional, or none?
5. Do you work on the technology you are presenting, or are you an independent user of it?
6. What should change for the audience after the talk - try it, contribute, adopt an approach, drop a bad habit, or just understand something?
7. What raw material already exists - an incident, a benchmark, a migration, a blog post, a repository?
8. Will it be recorded and published?
9. Any hard constraints - corporate slide template, no-slides format, embargoed numbers, a co-speaker?
10. When is the talk, and when do you need the outline finished - before a dry run, a review with a colleague, or the morning of?
11. Is this a one-off, or a talk you expect to re-give at other events in different slots?
12. What is your rehearsal ceiling: how many hours before the slot, and can you get a room and a colleague to run it in front of?
Answers to 10, 11 and 12 re-rank the arc and demo menus below. Say which moved what:
- A close deadline promotes the arcs built from material the speaker already lived (incident, migration) and demotes anything that has to be constructed and verified.
- A re-give promotes the expensive arcs and a recorded demo, because both amortize across every later slot instead of being paid once.
- A low rehearsal ceiling deletes progressive construction and unscripted live typing outright rather than offering them - do not present an option the speaker has no hours to rehearse.
## Workflow
1. Run the Interview. One question per message.
2. Re-read the abstract and extract the promise it made: the problem, the audience, and the takeaways the reviewers accepted. Deliver that promise - an audience that came for the abstract and got a different talk rates it as bait-and-switch, whatever its quality.
3. Draft the **arrow**: the single sentence a listener would still repeat a week later, tested against "if this is the only thing they take away, is that enough?" Everything that does not serve the arrow is a candidate for the cut list. This is Tristan de Montebello's Bow and Arrow - the arrow is what is remembered, the bow is the material that gives it force.
4. Brainstorm the arc, then present it - never assume it - and wait for the user to choose before going further. See [`references/narrative-arcs.md`](./references/narrative-arcs.md) for the full gate and ranking axes.
- Gate: drop every arc the material, the audience's starting belief, or the slot makes infeasible - that filter removes options rather than deprioritizing them.
- Rank: propose the 2-3 survivors by belief moved per hour of preparation, recommend the leader, and name what the ranking starves.
5. Choose 2-3 **pillars** that support the arrow, and name the evidence each one carries - a number, an incident, a benchmark, a code fragment, a customer constraint. A pillar with no evidence is an opinion and will be challenged in Q&A. Prefer the concrete instance over the category: _Made to Stick_ (Chip and Dan Heath) names the Sinatra test - one reference strong enough to settle a whole class of objections - and one of those beats three weak proofs.
6. Locate the moment of realization: Matthew Dicks' 5-Second Moment, the point where "we used to think X, then Y happened, now we think Z". This is the emotional spine of a technical talk. Place it where the audience already believes the problem - usually at the end of the first pillar.
7. Budget the minutes (see Time budget), place the demo (see Demo placement), and reserve the buffer.
8. Draft the slide skeleton one section at a time. Present each section, get the user's approval, then move to the next. A whole outline dumped at once gets a vague "looks good" and hides the weak section.
9. Write the speaker-note cues: per section, the timing checkpoint and what gets dropped if the clock is behind ("past 0:14 here → cut pillar three, go straight to the demo").
10. Hand over the rehearsal plan (see Rehearsal and quality gate) and iterate on the outline with what the timed runs reveal.
11. Run any prose meant to be spoken or published - abstract updates, the closing lines, the social summary - through your preferred humanizer skill before it ships.
12. If your harness has persistent memory, store the arrow, the chosen arc, the pillars and the cut list. A talk gets re-given at three more events with a different slot length, and re-deriving those decisions each time produces a different talk.
## Invocation and output shape
Typical openings, and what each one changes:
- "My talk got accepted at a platform-engineering conference, 25 minutes plus 5 for Q&A. Here's the abstract." → the full workflow, starting at the interview.
- "I have a 40-minute talk and a 25-minute slot. What do I cut?" → skip to the arrow and the accordion; the cut list is the deliverable.
- "Where should the demo go in this outline?" → demo placement only; do not rebuild the arc uninvited.
- "Same talk, but it's a 10-minute lightning version now." → re-derive from the arrow; a lightning slot holds one movement, not a compressed three.
Deliver one document with these parts, in this order:
```
Arrow one sentence, verbatim, reused as the closing line
Arc the chosen arc + why it beat the alternatives
Pillars 2-3, each with the evidence it carries
Realization where the belief flips, and at which minute
Time budget minute ranges per section, with the buffer stated
Slide skeleton ordered table: what each slide accomplishes + notes
Cut checkpoints "past 0:14 at slide 12 → drop pillar 3" + never-cut slides
Rehearsal plan accordion reps and the quality gate to iterate against
```
Hand it over as a file when the harness can write one - a speaker edits this document for weeks and will not keep it in a chat log. Refuse to output slide files, and refuse to write the talk out as prose to be read aloud, whatever the speaker asks - both defeat the artifact's purpose. See [`references/talk-outline-example.md`](./references/talk-outline-example.md) for a filled example and for the same talk outlined badly, flaw by flaw.
## Time budget
Slot length is an input, never an output. Writing a 45-minute talk and delivering it in a 25-minute slot is the most common structural failure at conferences.
| Slot | What it carries |
| ------------------ | --------------------------------------------------------- |
| 5-10 min lightning | One point, or one demo. Never both |
| 25-45 min session | The arrow plus 2-3 pillars, one demo |
| 45-60 min keynote | A thesis about the field, less depth per point, callbacks |
| Panel | No outline - prepared positions only |
Default split for a 30-minute slot with Q&A inside it:
```
0:00-0:03 hook + stakes the audience decides here whether to open a laptop
0:03-0:05 promise + scope what they leave able to do, and who this is not for
0:05-0:22 pillars 1-3 ~5-6 min each, each ending on a landed point
0:22-0:26 demo or evidence anchored to the pillar it proves
0:26-0:28 the arrow, restated in the same words as the hook
0:28-0:30 Q&A or hard stop
```
These rules survive any reshuffle. The first two are this skill's own defaults, not measured thresholds - say so if the speaker pushes back, and let a timed run overrule them.
- Reserve 10-15% of the slot as unused buffer. Laughter, a slow projector, an A/V handover and one rambling question all eat minutes that never appear in rehearsal.
- Change mode at least every 7 minutes - demo, diagram, story, audience question. Attention lost inside a single mode does not come back.
- Put a timing checkpoint in the notes at every section boundary. Cutting live is only possible when the speaker can see, at a glance, that they are behind and what to drop.
Estimate a section's minutes from its word count only with the speaker's measured rate: have them read 200 of their own words aloud, time it, and divide. Do not substitute a table value.
Guo et al.'s study of 6.9 million edX instructional-video sessions found engagement rising with speaking rate, though its authors call rate a surface feature that tracks enthusiasm rather than a lever to pull. They advise against forcing faster delivery.
The "185-254 wpm band" often quoted from that study is just its fastest quintile, not a target the paper sets. A rate measured on the speaker's second language differs.
## Demo placement
- Place the demo **after** the audience believes the problem. The same demo at minute two is a product tour - after the problem lands, it is proof.
- State what to watch before starting it ("watch the p99 line, not the log output"). An unnarrated demo reads as filler.
- Never end on the demo. Keep at least two minutes of speaking after it, so an overrun cannot eat the conclusion and the arrow stays the last thing heard.
- Budget it at twice its rehearsed length. Typing on stage is slower than typing at a desk. The two-minute floor and the 2x budget are both self-set, not measured.
Ask which fidelity the demo will run at before you budget it, because the answer changes the minutes. Rank the tiers by proof delivered per hour of rehearsal, not by which looks most impressive:
- efficiency: narrated screencast > scripted live demo against a prepared environment > unscripted live typing against a live system
- effort: narrated screencast (recorded once, and every retake is free) > scripted live demo (a rehearsed path, a seeded environment and a fallback) > unscripted live typing (all of that, plus rehearsing recovery from each way it can fail, and it still fails)
- value: unscripted live typing (proves the thing genuinely works, unedited - the only tier an audience cannot suspect) > scripted live demo (proves it works on a machine in this room) > narrated screencast (proves the claim, and the room takes the recording on trust)
- compliance cost: narrated screencast (edited and reviewable before the slot) > scripted demo against seeded data (nothing real on screen) > live system (one wrong tab in front of a recorded room exposes customer data or an embargoed feature, permanently)
Efficiency starves unscripted live typing, which is the only tier that proves liveness. Promote it when liveness _is_ the claim - "this really does compile in under a second" - and nothing else can prove it. A speaker who has not made that choice deliberately should hear Holman's position from speaking.io first: "live demos are like Global Thermonuclear War: the only way to win is to not do a live demo in front of hundreds of strangers in the first place."
Making the demo itself failure-resistant - fidelity tiers, checkpoints, recorded fallback, environment reset, offline mode - is a separate job. See the References section for that. This skill only decides where the demo sits and how many minutes it may spend.
## Slide skeleton
Emit an ordered list of what each slide must accomplish, never a slide count target. Slide count is personal: a story-led talk can run on three slides, and a dense technical talk can run a hundred in thirty minutes with two words on each.
Per slide, run these tests:
- One idea. A slide with no single point should not exist, or should become several slides.
- The title is the takeaway sentence, not a topic label - "Retries amplified the outage", not "Retry behaviour".
- Nothing on screen that the speaker is not about to say. The audience reads faster than the speaker talks, and everything else on the slide competes with them.
- The speaker's line is not the slide's own words read aloud. The slide names the point; the speaker comments on it - why it matters, what it costs, what's surprising.
Give each section a marker slide so a listener who drifted can re-enter the talk, and put the repository, docs and handle on a slide that appears twice - once where it becomes useful, once at the end where it gets photographed.
See [`references/slide-and-demo-craft.md`](./references/slide-and-demo-craft.md) for code-slide limits, room legibility, accessibility and what a deck owes its recorded afterlife.
## Audience calibration
Pick the depth from the room, then go one level below the deepest listener so the median attendee stays in. Anchor each role in what it cares about:
- Hands-on engineers: the API surface and failure modes.
- Staff engineers: trade-offs and what breaks at scale.
- Managers: operational cost and risk.
Assume the speaker's own depth estimate is wrong in one direction: too deep, never too shallow. The Heath brothers call this the curse of knowledge - an expert cannot un-know the subject, so the miscalibration is invisible from inside the speaker's own head.
Elizabeth Newton's 1990 Stanford study is the standard illustration: people tapping a well-known song predicted listeners would name it half the time, while listeners actually managed only 2.5%. The figure comes from Heath & Heath's retelling in _Made to Stick_ rather than from the paper, so attribute it to the book when using it.
The countermeasure is not to simplify everything. Name, per pillar, the one term the speaker will define out loud, and have someone outside the team read the outline and mark where they got lost.
The arc, the timing and the slide craft are identical regardless of business model. Only the evidence changes by go-to-market motion:
- **Sales-led B2B** - a buyer or architect is often in the room. Compliance, migration cost, support model, total cost at scale and team ramp-up time are the evidence that lands.
- **Product-led (PLG) B2B** - the room is developers who adopt first. Evidence that lands: free tier, time to first success, activation path, expansion story - not procurement checklists.
- **B2C / indie developer audiences** - time to first success, free-tier boundaries, how it behaves on a laptop, and whether it survives being abandoned for six months.
If the speaker works on the technology, they should say so plainly in the first minute, name competing approaches fairly, and state where their tool is the wrong choice. An engineering audience discovers the affiliation anyway, and a late reveal turns the whole talk into an advertisement retroactively.
## Rehearsal and quality gate
Run de Montebello's accordion: speak the talk to a 3-minute timer, then 2, then 1, then 30 seconds, staying in character and ending strong each time. Then expand back up through 1, 2 and 3 minutes, adding material deliberately.
What survives the 30-second rep is the arrow and the pillars. Anything that only appears on the way back up is the cut list, in cut order.
Deliberately do not rank the cut list yourself. The accordion measures this talk, with this speaker, against this arrow - the order material reappears in is evidence, and substituting a ratio computed from the outline would be false precision over a real measurement.
Rank the arc and the demo before rehearsal. Let rehearsal rank the cuts.
Do not finish the deck before the first timed run - early runs tell the speaker how much deck they actually need, and stop them polishing slides they will cut.
Iterate on the outline until all of these pass. The gate is this skill's own, assembled from the accordion method and the per-slide test - present it as a working bar, not as a certification:
- Two consecutive timed runs land inside the slot minus the buffer.
- Every slide passes the one-idea and title-as-takeaway tests.
- Every pillar carries at least one concrete piece of evidence.
- The demo ends at least two minutes before the slot does.
- A colleague who read only the outline states the arrow back in one sentence, unprompted.
After the talk, judge it on the session feedback score, whether hallway conversations and social posts repeat the arrow in the speaker's own words, and traffic to the repository or docs in the 48 hours after the slot. Attribution here is weak - treat these as directional, and never let a link-click count decide whether the talk was good.
The recording is the one surface with real instrumentation. YouTube's own retention report names four moments:
- The share still watching after the first 30 seconds - indicts the hook and the promise.
- Dips - locate a section that stopped paying.
- Spikes - ambiguous, since a spike can mean rewatched because it was good, or because it was unclear.
- Top moments.
Set no target percentage. Use the curve to find the minute that failed, then fix that section of the outline.
Expect the published video to be watched partially. In Guo et al.'s edX data, median engagement time was at most six minutes regardless of total video length.
This was measured on instructional video, where viewers can skip. A seated room cannot, so the finding constrains the recording, not the talk. It argues for chapter markers and short extracted clips, never for shortening the talk that was accepted.
## Failure modes
| Symptom | Cause | Fix |
| ----------------------------------------- | --------------------------------------------------------------- | --------------------------------------------------------------------- |
| Audience checks out at minute five | The talk explains before it convinces anyone there is a problem | Move the stakes into the first three minutes |
| The talk runs 12 minutes over | Written to the material, not to the slot | Accordion down; cut a whole pillar, never thin all three |
| The demo lands flat | Shown before the problem is believed, or unnarrated | Move it behind its pillar; say what to watch first |
| Q&A questions attack a pillar's premise | The pillar was asserted, not evidenced | Add the number, incident or code that proves it |
| The speaker freezes | Word-for-word script | Replace with bookmarks and note cues |
| Reviewers write "not what was advertised" | The outline drifted off the accepted abstract | Re-read the abstract before finalizing; realign or tell the organizer |
| It reads as a vendor pitch | Product features are the pillars | Make the problem the pillars; the product is evidence, not structure |
## References
- [`references/narrative-arcs.md`](./references/narrative-arcs.md) for the arc catalog and how to choose between them
- [`references/talk-outline-example.md`](./references/talk-outline-example.md) for a full worked outline and the same talk done badly
- [`references/slide-and-demo-craft.md`](./references/slide-and-demo-craft.md) for slide and code-slide craft
- [`references/sources-and-defaults.md`](./references/sources-and-defaults.md) for which figures are measured, which are practitioner convention, and which are this skill's own defaults
- samber/developer-relations-skills@conference-cfp-submission for writing the abstract this skill starts from
- samber/developer-relations-skills@developer-live-demo-design for making the placed demo failure-resistant
- samber/developer-relations-skills@technical-video-script for turning the recorded talk into a scripted video
- samber/dev-event-organizer-skills@event-speaker-coaching for the organizer's side: the dry runs and feedback an event offers accepted speakers