Purpose
Turn a technical topic and a rough set of talking points into a fully structured internal talk outline — with a narrative arc that holds attention, timed sections that fit the slot, demo hooks with fallbacks, and pre-drafted answers to the questions the room will actually ask. Solves the "I know the material but I don't know how to sequence it" problem that makes engineer-led talks ramble or run over.
When to Use
Invoke this skill when the user asks to:
- Prepare a brown bag, lunch-and-learn, or internal tech talk
- Outline or structure a knowledge-sharing session for their team
- Plan an architecture walkthrough, post-mortem readout, or design decision talk
- Figure out how to sequence and pace technical material for an internal audience
- Anticipate the questions a room of engineers will ask and prepare answers
- Convert a pile of notes or a doc into a presentable talk structure
Inputs Required
Before starting, collect:
- Topic: The technical subject and the one thing you want people to walk away understanding
- Duration: Total slot length (e.g., 20 min, 30 min, 45 min) and whether Q&A is inside or outside that
- Audience: Who's in the room — same-team, cross-team, mixed seniority, junior-heavy, staff+, non-engineers present
- Familiarity level: How much the audience already knows about this topic (none / general awareness / deep)
- Key points: 3–8 things you know you want to cover (bullet dump is fine)
- Demo intent: Is there a live demo, code walkthrough, or diagram-driven segment? (yes/no + what)
- Goal: What action or belief change you want afterward — adoption, awareness, feedback, buy-in, or pure education
If familiarity level or goal is missing, assume a mixed-seniority same-org audience and an education-plus-awareness goal, and note the assumption.
Instructions
Step 1: Set the Spine (One-Sentence Thesis + Takeaway)
Before structuring, lock two things:
- Thesis: The single claim the talk defends, stated in one sentence ("Our current retry logic is the root cause of the incident pattern, and a token-bucket approach fixes it").
- The one takeaway: If the audience forgets everything else, what should survive? Everything in the outline must serve this.
Reject scope that doesn't serve the takeaway. If the key points imply two talks, flag it and recommend which one to give.
Step 2: Build the Narrative Arc
Map the material onto a proven arc — pick the one that fits the goal:
- Problem → Investigation → Solution (best for post-mortems, migrations, "why we changed X")
- Status Quo → Tension → Resolution (best for advocacy: "why we should adopt Y")
- Concept → Mechanism → Application (best for pure education: "how Z works")
- Before → After → How (best for wins and case studies)
State which arc was chosen and why. Then place each of the user's key points into a beat of that arc. Any point that doesn't fit a beat is a candidate for cutting or moving to an appendix slide.
Step 3: Design the Hook (First 90 Seconds)
Draft an opening that earns attention in a room of skeptical engineers. Provide one concrete option from these patterns:
- A surprising number or graph ("This query ran 40M times last week")
- A relatable pain ("Raise your hand if you've been paged for this")
- A provocative claim the talk will defend
- A 20-second failure story
Avoid the anti-patterns: agenda slides read aloud, "a bit about me," and apologizing for the material.
Step 4: Timed Section Breakdown
Allocate the duration across the arc beats with explicit minute budgets. Rules:
- Opening/hook: ~10% of total
- Reserve Q&A time explicitly (default 20% if inside the slot)
- No single teaching section over ~8 minutes without a demo, diagram, or interaction break
- Leave a 2-minute buffer for overrun
Present as a table: Section | Minutes | Purpose | Key visual/artifact.
Step 5: Demo & Interaction Hooks
For each demo, code walkthrough, or diagram segment:
- Setup line: What you say right before to frame what to watch for
- The payoff moment: The exact thing the audience should notice
- Fallback plan: What to show if the live demo breaks (recorded GIF, screenshot, "here's what would happen")
- Time-box: Max minutes before you must move on
If there's no demo, insert at least one interaction hook (poll, hand-raise, "what would you do here?") to break passive listening.
Step 6: Anticipate Q&A
Generate 6–8 questions the room will realistically ask, each labeled by type:
- Skeptic ("Did you consider [alternative]?")
- Scope ("Does this handle [edge case]?")
- Adoption ("What does this mean for my team?")
- Trap (the question you hope no one asks — surface it and prepare an honest answer)
For each: a 2–3 sentence prepared answer, and a note on whether to pre-empt it in the talk instead. Flag any question that reveals a real weakness worth addressing in the content itself.
Step 7: Slide-by-Slide Skeleton
Produce a slide list mapping to the timed sections. For each slide: a title, a one-line content note, and the intended visual (diagram / code / bullet / chart / none). Keep it to roughly one slide per 1.5–2 minutes of talk. End with a single-slide summary that restates the one takeaway and the next action.
Step 8: Closing & Call to Action
Draft a closing that lands the takeaway and states one concrete next step tied to the goal (try it, review the doc, give feedback in the thread, opt into the pilot). No "thanks, any questions?" as the final beat — the CTA comes first, then Q&A.
Output Format
- Structure: Ordered sections matching the steps, with the timed breakdown and slide skeleton as tables
- Length: 800–1,200 words
- Format: Structured document — prose for arc/hook/closing, tables for timing and slides, labeled lists for Q&A
- Sections: Thesis & Takeaway → Narrative Arc → Hook → Timed Breakdown (table) → Demo/Interaction Hooks → Anticipated Q&A → Slide Skeleton (table) → Closing & CTA
- Tone: Practical staff-engineer coaching — direct, opinionated about cuts, allergic to filler
Quality Checklist
Before delivering output, verify:
- [ ] The thesis and one-takeaway are each a single concrete sentence — not a topic label
- [ ] Every key point provided by the user is placed in an arc beat or explicitly flagged for cutting
- [ ] Section minute budgets sum to the stated duration including Q&A and a 2-minute buffer
- [ ] Every demo segment has a stated fallback plan
- [ ] 6–8 anticipated questions are present, each with a type label and a prepared answer
- [ ] The slide count is proportional to the duration (~1 slide per 1.5–2 minutes)
- [ ] The closing states one concrete next action tied to the stated goal
Notes
- The most common failure in engineer talks is front-loading context and running out of time before the payoff — the arc and timing steps exist specifically to prevent this; when in doubt, cut background and start closer to the tension.
- For advocacy talks, the "trap" question in Step 6 is usually the real crux — address it head-on in the content rather than defending it live.
- If the material genuinely exceeds the slot, recommend splitting into a talk plus a follow-up doc rather than compressing everything into unreadable slides.
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills