Conference Talks skill for Claude Code
Proposals that get accepted, talks that land. Claude develops talks from a single takeaway sentence outward. It writes CFP titles, abstracts, reviewer notes, and bios tailored to the conference, builds a timed narrative arc for the slot, drafts speaker notes before slides, keeps code and charts readable from the back row, plans demos with recorded fallbacks, and runs a rehearsal loop that cuts sections instead of rushing.
- name
conference-talks - size174 lines · ≈1,850 tokens
- files1
- licenseMIT
- updated
What Claude sees before loading it
This description is the only part of the skill that sits in context all the time. Claude reads it to decide when to load the full playbook below.
description: Develops technical conference talks from idea to delivery - picking one takeaway, writing CFP proposals with titles, abstracts, and reviewer-facing details that get accepted, outlining the narrative arc, building slides that support speech rather than replace it, live demo risk management, speaker notes, timing to the slot, and rehearsal with feedback. Use when submitting to a call for papers, writing a talk abstract or bio, turning a blog post or project into a talk, structuring a meetup or keynote presentation, or preparing to rehearse and deliver.Try asking
- Write a CFP proposal for a talk about our Postgres to ClickHouse migration
- Turn this blog post into a 25-minute talk outline with speaker notes
- My talk runs 40 minutes in rehearsal and the slot is 30. Help me cut it
Use it when
- Submitting a proposal to a call for papers
- Turning a project, incident, or post into a talk
- Structuring slides and speaker notes for a meetup or conference
- Preparing demos and rehearsing to a time slot
Skip it when
- You need the slide file built or edited — use pptx-decks
- You are writing the written article version — use dev-blog-posts
How to check the result
A colleague who watches one rehearsal can state the takeaway in one sentence, and three timed runs all finish inside the slot with Q&A time left.
The common mistake it prevents
Building slides first and discovering the talk has no single takeaway, so it becomes a tour of everything the speaker knows.
A talk works when the audience can state its one takeaway afterward, the proposal told reviewers exactly what attendees will learn and why this speaker can teach it, and the delivered talk lands within the time slot with a demo that cannot sink it. Slides are the last thing to make, not the first.
Ground rules
- One takeaway per talk, written as a sentence before anything else. Everything that does not serve it is cut, however interesting.
- The audience is the customer: name who they are and what they already know.
- Specific beats general: real numbers, real failures, real code from a real system.
- Never submit a talk you have not outlined; reviewers can tell, and you will have to build it anyway.
- Respect the slot: a 30-minute talk is ~25 minutes of content plus questions.
Workflow
- [ ] 1. Choose the takeaway and the audience
- [ ] 2. Write the proposal (title, abstract, details for reviewers, bio)
- [ ] 3. Outline the narrative arc and time budget
- [ ] 4. Draft speaker notes per section
- [ ] 5. Build slides from the notes
- [ ] 6. Plan demos with fallbacks
- [ ] 7. Rehearse, time, get feedback, cut
- [ ] 8. Delivery-day checklist and follow-up1. Takeaway and audience
Fill in:
After this talk, <audience> will be able to <do/decide/understand X>
because I will show them <evidence or method> from <my experience>.If the sentence needs “and” twice, there are two talks. Strong talk types: war story (incident, migration, scale problem), how-we-built, lessons from N years of X, deep dive into a mechanism, practical how-to with a reusable method.
2. Proposal
Reviewers read hundreds of proposals quickly. Make theirs an easy yes.
Title: specific and honest, 4-10 words. Promise an outcome or a tension.
| Weak | Strong |
|---|---|
| Kubernetes Best Practices | We Cut Our Kubernetes Bill 60% Without Touching the Apps |
| Intro to Observability | Debugging a 2% Error Rate Nobody Could Reproduce |
| Rust at Scale | What Broke When We Rewrote the Billing Engine in Rust |
Abstract (public, 100-200 words; check the CFP’s limit):
- Hook: the problem or surprising result in one or two sentences.
- What the talk covers: 3 concrete things, not a table of contents of buzzwords.
- What attendees leave with: the takeaway, phrased for them.
Details for reviewers (private field, if offered): outline with minutes per section, audience level and prerequisites, why you (you built it, ran it, broke it), whether it has been given before and how it changed, demo plan, and links to prior talks or posts.
Bio (50-80 words, third person): role, the experience that qualifies you for this specific talk, one human detail. No list of every technology you have touched.
Before submitting, check: matches the conference audience and tracks, within word limits, no vendor pitch (unless it is a sponsor slot), and the title still makes sense without the abstract.
3. Narrative arc and time budget
Default structure for a 30-minute slot:
| Section | Time | Job |
|---|---|---|
| Opening | 2-3 min | The problem, the stakes, why this audience should care; no “about me” slide first |
| Context | 3-4 min | Just enough background for the audience level you chose |
| Core, part 1-3 | 15-17 min | Three main ideas, each with evidence: data, code, story |
| The turn | 2-3 min | What failed, what surprised you, what you would do differently |
| Close | 2 min | Restate the takeaway; one action attendees can take Monday |
| Q&A | 5 min | Buffer |
Rules of thumb: about one main idea per 7-10 minutes; signpost transitions (“That fixed the cost. It did not fix latency.”); return to the opening problem at the end.
4. Speaker notes
Write notes as bullet prompts, not a script you will read. Per section: the point, the evidence, the transition line. Write the first 60 seconds and the last 60 seconds out fully; those are the parts nerves damage most.
5. Slides
| Rule | Detail |
|---|---|
| One idea per slide | The slide headline states the point as a sentence |
| Text the audience can read in 5 seconds | Under ~20 words of body text; no paragraphs |
| Code | Under ~12 lines, 28pt+ monospace, highlight the lines you talk about; build up in steps |
| Charts | One message each; label the takeaway on the chart; remove gridlines and legends where possible |
| Contrast and size | Readable from the back row and on a washed-out projector; dark text on light or light on dark, never mid-grey |
| Accessibility | Do not rely on color alone; describe visuals aloud for people who cannot see them |
| Diagrams | Reveal in steps rather than one dense image |
Make a slide only where it helps the audience see something: code, a diagram, a number,
a picture. Use pptx-decks or your slide tool of choice for the file itself.
6. Demos
Live demos fail on conference Wi-Fi, projectors, and nerves. Decide per demo:
| Option | When |
|---|---|
| Recorded video with live narration | Default for anything networked or slow |
| Live, local-only, scripted | Short, deterministic, no network, rehearsed many times |
| Screenshots with build-up | When the steps matter more than the motion |
For live demos: offline environment, large terminal font, pre-typed commands in a script or shell history, reset script between rehearsals, and a recorded backup on the laptop ready to switch to without apology.
7. Rehearse
- Rehearse aloud at least three full times; the first run is always 30-50% long.
- Time each section against the budget; cut whole sections rather than speaking faster.
- One rehearsal in front of a colleague or recorded on video. Ask them: what was the takeaway? Where were you lost? Where were you bored?
- Practice the transitions and the opening until they are automatic.
- Prepare answers for the three most likely questions and the one you dread.
8. Delivery day and after
Checklist:
- Slides as PDF on laptop and USB/cloud; presenter view tested
- Video adapters (HDMI, USB-C), clicker, charger
- Notifications off, separate presentation user or focus mode
- Demo environment reset and offline backup video ready
- Water; arrive at the room 15 minutes early; check mic and resolution
- Final slide: takeaway, contact, link to slides and resources (short URL or QR)
After: publish slides and a resources page the same day, answer follow-up questions,
and turn the talk into a post (see dev-blog-posts). Ask organizers for feedback scores
and note what to change next time.
Gotchas
- Opening with an agenda and bio wastes the minutes when attention is highest.
- Reading slides aloud makes slides and speaker redundant; the slide shows, you tell.
- “Everything we learned” talks have no takeaway; pick the three lessons that matter.
- Reusing the same proposal across conferences without tailoring to each audience is a common rejection reason.
- Company approval for sharing internal numbers, architecture, or incidents takes time; get it before submitting.
Output contract
**Takeaway:** <one sentence> | **Audience:** <who, level>
**Title:** <title>
**Abstract:** <100-200 words>
**Reviewer notes:** outline with minutes, why me, demo plan
**Bio:** <50-80 words>
**Outline:** <sections with minutes>, demos <recorded/live + fallback>
**Rehearsal log:** run 1 <mm:ss>, run 2 <mm:ss>, feedback applied <items>About this skill
Written and maintained by the Claude Skills editors to the same editorial standard as every skill in the directory: a selective trigger, a real workflow, known pitfalls and a verification step. First published , last updated . MIT licensed.