Install
openclaw skills install conference-talk-prepperHelp speakers prepare conference talks end-to-end. Covers CFP and abstract writing, talk format selection, narrative structure, slide design, rehearsal proto...
openclaw skills install conference-talk-prepperHelp speakers prepare conference talks from CFP submission through post-talk distribution. Acts as an experienced speaker coach: blunt about weak structure, ruthless about cutting content, specific about what makes a talk memorable versus forgettable.
Invoke this skill at any point in the talk preparation lifecycle.
Basic invocation:
Help me write a CFP for a talk on database migrations Review my abstract — is it strong enough to get accepted? I have 30 minutes at a conference next month, help me structure the talk My slides are walls of text, redesign them How do I rehearse a 45-min talk?
With context:
I'm a first-time speaker, the audience is senior engineers, topic is incident response I have a 5-min lightning slot at a design conference, what should I do differently? My demo failed last time and I froze — give me a recovery protocol I gave this talk once, how do I turn it into a "signature talk" I reuse?
The agent works on whichever stage you bring: CFP, outline, slides, rehearsal, logistics, or post-talk.
Most talks are rejected at the CFP stage because the abstract is generic. The agent enforces three rules.
Title formula: specific outcome + audience + counterintuitive angle.
WEAK: "Microservices at Scale"
STRONG: "How We Cut Microservice Latency 80% by Deleting Services"
WEAK: "Better Code Reviews"
STRONG: "The Two-Question Code Review: How Senior Engineers Review in 10 Minutes"
WEAK: "Introduction to Kubernetes"
STRONG: "Kubernetes for Skeptics: When Not to Use It (and What We Used Instead)"
Abstract structure (150-200 words):
Bio template (60-80 words):
[Name] is [current role] at [company], where they [one specific
accomplishment with a number]. Previously [past role/credibility
marker]. They've [spoken/written/built] about [topic] at [past venues].
[One human detail — pet, hobby, location — keeps it from sounding
like a LinkedIn summary].
CFP committees skim hundreds of submissions. The agent flags vague verbs ("explore," "discuss," "look at"), buzzword stacking, and any sentence that could appear in any other talk's abstract.
Different formats reward different structures. The agent matches your content to the format.
| Format | Length | Best For | Structure |
|---|---|---|---|
| Lightning | 5 min | One sharp idea, one demo, one strong opinion | 1 hook, 1 point, 1 takeaway. Cut everything else. |
| Keynote | 30 min | A vision, a story arc, a call to action | 3-act narrative; one hero example threaded throughout |
| Deep dive | 45 min | Technical detail, multiple sub-topics, live demo | 4-5 sections with clear transitions; 1 demo |
| Workshop | 90 min+ | Hands-on, attendees do something | 70% activity, 30% framing; checkpoints every 15 min |
Choosing wrong is the #1 reason talks feel off. A 45-minute deep dive crammed into 5 minutes becomes a fire hose. A lightning idea stretched to 30 minutes becomes filler. The agent will push back on format mismatches.
Opening hook (first 60 seconds matter most).
Three openings that work:
Three openings that kill talks:
3-act narrative:
Act 1 — Setup (20% of time): The world as it was. The pain. Why it matters now.
Act 2 — Struggle (60% of time): What you tried, what failed, what you learned.
Act 3 — Resolution (20% of time): What works now, what the audience should do, the bigger lesson.
Callbacks: plant a phrase, image, or character early; return to it 2-3 times. This is what makes a talk feel like a story, not a list.
Demo placement: never in the first 5 minutes (audience not warm yet), never in the last 5 minutes (no recovery time if it fails). Sweet spot: middle third.
Closing memorable line: the last sentence is what people quote on Twitter. Write it first. Examples:
The agent reviews slides against five rules.
1. One idea per slide. If a slide has two ideas, split it.
2. No walls of text. Rule of thumb: if a slide has more than 10 words, the audience will read instead of listen — and read faster than you talk, then tune out.
3. High-resolution images. No clipart. No 320x240 JPGs from a 2008 blog. Source from Unsplash, your own screenshots, or hand-drawn diagrams.
4. Font legibility from the back of the room. Minimum 30pt for body text, 60pt+ for titles. If you wouldn't read it from 50 feet away on a phone screen, the back row can't read it on a projector.
5. Dark mode for code, light mode for everything else. Code is harder to read on white in dim rooms. Use a high-contrast theme like Dracula or Solarized Dark with 24pt+ monospace.
Slide types in a typical talk:
| Type | Purpose | Word Count |
|---|---|---|
| Title slide | Set tone | 5-10 |
| Section divider | Mark act transitions | 3-5 |
| Image slide | Emotion, scale, metaphor | 0-5 |
| Quote slide | Authority, callback | 10-25 |
| Diagram slide | Show structure | 5-15 labels |
| Code slide | One concept, one snippet | 5-15 lines |
| Punchline slide | Big idea, big text | 3-8 |
Pass 1 — Solo read (sitting, full talk through)
Goal: catch logic gaps, redundancies, missing transitions.
Do this 7+ days before the talk. Expect to rewrite 20-30%.
Pass 2 — Solo standing (with slides, out loud, timed)
Goal: hit timing, find tongue-twisters, lock the opening.
Do this 4-5 days before. The opening should be word-perfect.
Pass 3 — Small audience (1-3 trusted people, full run)
Goal: feedback on what landed, what confused, what dragged.
Do this 2-3 days before. Ask: "where did your attention drift?"
Pass 4 — Tech rehearsal in venue (or as close as possible)
Goal: test laptop, dongle, clicker, mic, screen ratio, lighting.
Do this the day-of or evening before. Solves 80% of failure modes.
Skipping Pass 4 is the most common pre-talk mistake. Most disasters are tech disasters and are preventable.
A 30-minute slot is not 30 minutes of content.
Stated slot: 30 min
Intro by host: -2 min
Q&A: -5 min
Buffer for tech: -1 min
Actual content: 22 min
Rules of thumb:
Demos electrify a talk when they work and crater it when they don't. The agent enforces three rules.
1. Always have a backup video. Pre-record the demo. If anything goes wrong live (network, laptop, projector), switch to the video without missing a beat.
2. Failure recovery script. Memorize three lines:
If a command fails: "That's not what I expected — let's see why" (then move on)
If the network dies: "And this is why we have a backup" (cut to video)
If something crashes: "Live coding always entertains. Here's what should have happened." (cut to slides)
3. Reset state between rehearsals. Demo failures often come from state left behind from rehearsal. Use a clean container, fresh terminal, fresh database.
Every question falls into one of four categories.
| Category | Frequency | How to Handle |
|---|---|---|
| Curious | 50% | Answer concisely, redirect to the talk's core point |
| Hostile | 10% | Acknowledge, agree where you can, defend where you must, do not get defensive |
| Unrelated | 25% | Bridge: "That's outside this talk, but the related thing I'd say is..." |
| "More a comment than a question" | 15% | Thank them, find the implicit question, answer that |
Bridging technique: when a question is hostile or unrelated, restate it in your terms before answering. "If I'm hearing the question right, you're asking [reframe in a way you can answer]." This is not dodging — it's clarifying. Don't overuse.
If you don't know: say "I don't know" — fast. Never make up an answer. Audiences forgive ignorance; they crucify bluffing. Offer to follow up: "Find me after, I'll dig into it."
The agent produces a checklist tuned to the venue.
24 hours before:
[ ] Slides finalized, exported as PDF backup
[ ] Demo video recorded and on local disk (not cloud)
[ ] Laptop charged, charger packed
[ ] All dongles packed (HDMI, USB-C, VGA if old venue)
[ ] Clicker tested, fresh batteries
[ ] Outfit chosen (something with a belt or pocket for mic pack)
Morning of:
[ ] Full hydration (start 2 hours before, stop 30 min before)
[ ] Light meal — not a heavy one
[ ] No new caffeine if you don't normally drink it
[ ] Re-read opening 3 times so it's automatic
[ ] Walk for 20 min to burn nervous energy
30 min before:
[ ] At venue, on the actual stage if allowed
[ ] Mic test, screen ratio confirmed (16:9 vs 4:3)
[ ] Clicker paired with laptop, range tested
[ ] Water bottle on stage or podium
[ ] Phone on airplane mode
Nerves protocol:
[ ] 4-7-8 breathing (inhale 4s, hold 7s, exhale 8s) x3
[ ] Power pose for 90 seconds before going on
[ ] Remind yourself: the audience wants you to succeed
[ ] First 60 seconds memorized cold — momentum follows
The talk is 20% of the value. The other 80% is what you do in the week after.
Within 24 hours:
- Slides on Speakerdeck or Notist with a link in your bio/site
- Tweet/post: "Just gave [talk title] at [conf]. Slides: [link]. Key idea: [one sentence]."
- DM the 3-5 people who asked the best questions; offer to chat further
Within 1 week:
- Blog post adapting the talk into an article (different medium, same ideas)
- 60-90 second video clip of your strongest moment for X / LinkedIn / YouTube
- Email any contacts who couldn't attend with the slides + video link
Within 1 month:
- If video is published, embed it on your site and re-share on social
- Pitch the talk to a podcast as an interview topic
- Submit a refined version to the next CFP
The "give one talk and disappear" strategy wastes the work. The signature-talk strategy compounds.
3 talks/year strategy:
The signature talk: one talk you give 10-15 times across 2 years, refining each delivery. After version 5+ it becomes effortless and razor-sharp. This is how speakers like Kelsey Hightower, Camille Fournier, and Sandi Metz become known for specific ideas.
Repurposing across audiences:
Same core talk, different framings:
Engineers -> emphasize the technical mechanism
Managers -> emphasize team and process implications
Designers -> emphasize user impact and craft
Business -> emphasize cost, time-to-market, risk
The slides change ~30% per audience; the spine stays the same.
Each community rewards different behaviors.
| Audience | Rewards | Punishes |
|---|---|---|
| Engineering | Specifics, tradeoffs, real numbers, code, war stories | Hand-waving, marketing language, no code |
| Design | Craft, narrative, emotional resonance, beautiful slides | Ugly slides, code-heavy, jargon |
| Business | ROI, frameworks, decision criteria, brevity | Technical depth without "so what," missing the buyer's perspective |
| Academic | Citations, prior work, methodology, careful claims | Overclaiming, missing references, hand-wavy methods |
The same core insight may need three different talks for three audiences. Don't try to write one talk for all four.
The agent watches for these and flags them aggressively.
1. Too many topics
Symptom: outline has 7 sections for a 30-min talk.
Fix: cut to 1 idea. Everything else is a different talk.
2. Reading slides verbatim
Symptom: slides are full sentences. Speaker's eyes locked on screen.
Fix: slides become headlines/images; full sentences move to speaker notes.
3. Ignoring the time limit
Symptom: rehearsal is 35 min for a 30-min slot.
Fix: cut 5 minutes. Cut a section, not just words.
4. No clear takeaway
Symptom: at the end, audience can't say what to do differently.
Fix: write the closing line first. Reverse-engineer the talk to support it.
5. No strong opening
Symptom: opens with "Hi, I'm [name], I work at..."
Fix: open with story/question/contrarian fact. Bio comes later or skipped.
6. Demo with no backup
Symptom: when WiFi dies, talk dies.
Fix: pre-recorded video on local disk.
7. Q&A monopoly
Symptom: one person asks 4 questions, others get 0.
Fix: after answering, say "let's get someone who hasn't asked yet."
WEAK (197 words, generic):
Title: Improving Database Performance
In this talk, I'll explore various approaches to improving database
performance in modern applications. We'll look at indexing strategies,
query optimization, and caching, and discuss when each is appropriate.
We'll also examine common pitfalls and best practices.
Database performance is a critical concern for any application at scale.
As applications grow, performance issues can become a significant
problem. There are many tools and techniques available to address these
issues, and choosing the right one can be challenging.
This talk will provide attendees with a comprehensive overview of
database performance optimization. We'll discuss different types of
indexes, look at how to interpret query plans, and explore caching
strategies including Redis and in-memory caching. We'll also touch on
configuration tuning and monitoring.
By the end of this talk, attendees will have a better understanding of
database performance and will be equipped with the knowledge to optimize
their own applications. This talk is suitable for developers of all
levels who work with databases.
Why it fails: vague title, "explore/look at/discuss" three times in one paragraph, no insight, no number, could be any talk on the topic, "suitable for all levels" means nobody is a target.
STRONG (181 words, specific):
Title: How We Cut a 12-Second Query to 80ms by Deleting an Index
We thought we needed more indexes. We needed fewer.
Last year our checkout query crossed 12 seconds at peak traffic. The
team's instinct was familiar: add indexes, increase memory, scale the
database. We did all three. None worked. The query stayed slow, and
write performance got worse.
The fix turned out to be counterintuitive. Postgres was choosing the
wrong index because we'd added too many. Removing two redundant indexes
let the planner pick the optimal one — and the query dropped to 80ms.
In this 30-minute talk I'll walk through the exact EXPLAIN ANALYZE
output before and after, the three signals that told us indexes were
the problem (not the cure), and a checklist for auditing your own
indexes for the same pattern.
You'll leave with a one-page audit you can run on your largest table
on Monday morning. Senior engineers and DBAs will get the most out of
this — basic Postgres knowledge assumed.
Why it works: specific number in title, contrarian opening, concrete pain, named tools, named output, named audience, concrete deliverable.
WEAK SLIDE:
+------------------------------------------------------------------+
| Microservices Best Practices |
| |
| When designing a microservices architecture, there are several |
| best practices that should be considered. First, services should |
| be loosely coupled and highly cohesive. Second, each service |
| should own its own data and avoid sharing databases with other |
| services. Third, communication between services should be done |
| through well-defined APIs, ideally using asynchronous messaging |
| where possible. Fourth, services should be independently |
| deployable. Fifth, monitoring and observability should be built |
| in from day one, not added later. |
| |
| (footer: 14pt) Slide 14 of 47 — Conference Name 2026 |
+------------------------------------------------------------------+
Why it fails: 95 words. Audience reads instead of listens. Five separate ideas competing on one slide. No visual anchor. Footer is unreadable.
STRONG REDESIGN (split into 6 slides):
Slide 14a — Section divider:
+-----------------------------+
| |
| 5 Rules | (96pt, centered)
| |
| for Microservices | (48pt)
| That Survive Year 2 |
| |
+-----------------------------+
Slide 14b:
+-----------------------------+
| 1. Own your data | (72pt)
| |
| No shared databases. | (36pt)
+-----------------------------+
Slide 14c:
+-----------------------------+
| 2. Async first | (72pt)
| |
| Sync is the exception. | (36pt)
+-----------------------------+
(slides d, e, f follow the same pattern for rules 3, 4, 5)
Why it works: one idea per slide, big readable text, headline + one supporting sentence, builds rhythm (audience anticipates each rule), speaker now narrates instead of audience reading. Total speaking time is similar; comprehension is far higher. The "5 Rules" framing also gives the audience a structure to remember.
The agent produces, depending on stage:
The agent walks you through CFP -> outline -> slides -> rehearsal in order, with extra emphasis on the opening 60 seconds and the failure-recovery scripts.
Paste the abstract. The agent rewrites it using the title formula and 4-part structure. Most rejections come from generic titles and "explore/discuss" verbs.
Share the deck or describe a slide. The agent applies the 10-word rule, suggests splits, and flags slides that need an image instead of words.
The agent finds the section that doesn't earn its time and proposes a cut, not a trim. Trimming words rarely saves minutes; cutting a whole section does.
The agent prepares 8-10 likely questions across the four categories with draft answers, plus the bridging technique for hostile or unrelated questions.
The agent helps you choose between repurposing for new audiences, refining into a signature talk, or evolving into a workshop.
This skill is tuned for conference talks — a curated audience that chose to attend, a fixed time slot, a CFP-style format. It does not fit:
If your talk is one of the above, the structural advice here will mislead you. Use the right skill for the format.