Menu
Turn a CFP submission into a structured talk outline with section timings, theory/practical balance, demo risk assessments, fallback plans, and Patrick Winston opening/close principles applied throughout.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when you have a single piece of content (blog post, talk, case study, docs PR) and want to extract multiple content angles from it โ abstraction ladders, audience pivots, controversy checks, and hidden assumptions that could each become their own piece.
Use when you want to discover content series across your existing work โ finds clusters by theme rather than topic, identifies repeated points from different angles, flags incomplete arcs, and suggests series framing that makes relationships explicit.
Use when you've delivered a talk and want to convert it into blog posts, social content, newsletter sections, and republishing pitches โ or when you have presentation materials (slides, transcript, speaker notes) that could reach wider audiences. Produces multiple content pieces from a single talk.
Use when you've solved a user problem, answered a support question, or helped someone with a technical issue and want to turn it into shareable content. Produces both short-form "TIL" and long-form fully-contextualized pieces, plus recommends the right format (docs, blog, talk).
Generate a speaker or author bio through a short Q&A. Controls for length, person (first or third), and a slider for how much to centre the current employer vs. broader career and personal brand.
Generate a complete conference proposal through a structured brainstorming Q&A. Produces abstract, extended abstract, title variants, and learning outcomes โ calibrated to the session format and grounded in your DevRel context.
| name | build-talk-outline |
| description | Turn a CFP submission into a structured talk outline with section timings, theory/practical balance, demo risk assessments, fallback plans, and Patrick Winston opening/close principles applied throughout. |
Before doing anything else:
~/.devadvokit.md exists.Read reference/winston-talk-principles.md silently before starting. Apply these principles throughout โ they are not optional polish, they are structural requirements.
Ask these questions one at a time. Wait for each answer before moving on.
Paste your CFP abstract or talk description. If you don't have one yet, describe the talk in a few sentences โ the problem it addresses, the angle you're taking, and what you want the audience to leave with.
What's the session format and length? (e.g. talk / 30 min, workshop / 90 min โ include whether Q&A is expected and if so, how long it typically runs at this event)
Any specifics about this particular audience beyond your general context? (e.g. expected seniority mix, whether this is a specialist or general-track event, anything you know about what they've already seen at this conference)
Where does this talk sit on the theory-to-practical spectrum?
Are you planning any live demos? If yes: describe each one โ what you're showing, what it depends on (network, auth, third-party services, local tooling), and roughly how long you'd expect each to take.
Are there any audience interaction moments planned? (e.g. polls, show-of-hands questions, short exercises, pair discussions) If so, describe them.
Is there anything that absolutely cannot be cut if you run short on time โ a specific point, demo, or moment that the talk doesn't work without?
How do you want to end? (e.g. clear call to action, open question for the audience, resources slide, straight into Q&A)
Use the CFP material, the Q&A answers, and the speaker context from ~/.devadvokit.md to construct the outline. Before generating, consult reference/outline-structure-patterns.md to select the most appropriate structural pattern for the talk type and format.
Present the outline as a structured sequence. For each section:
[START TIMEโEND TIME] Section title
Content notes: what happens in this section, key points covered
Type: [concept / demo / interaction / transition / close]
Use cumulative timestamps from 0:00. Be precise โ "5:00โ9:00" not "about 5 minutes in".
Read reference/winston-talk-principles.md and apply the following before finalising the outline. These are structural checks, not suggestions.
The opening section must contain an empowerment promise โ a specific statement of what the audience will be able to do by the end that they can't do now. Write it out in the content notes for the opening section. It must be specific enough that a person in the audience could evaluate at the end whether the promise was kept.
Flag and remove any of the following if the user's described opening contains them:
Before writing the outline, identify where the following land. Include them as content notes in the relevant sections:
If the talk is persuasive (making a case, recommending a change, arguing a position):
The close section must end with a contributions slide โ what the audience now has that they didn't have when they walked in. Write out what that slide should contain in the content notes for the close.
The close must mirror the opening promise. Check that the empowerment promise made at the start is directly answered by the contributions at the end.
Flag if the user described ending with "Questions?" or "Thank you" as the final slide.
Based on the number of sections and the content in each, estimate whether the slide count is likely to exceed the Winston threshold (20 slides for a 30-min talk is the warning level). Flag it if so and note which sections are most likely to produce dense slides.
For each live demo identified in the Q&A, produce a risk block immediately after the section it appears in. Consult reference/demo-risk-patterns.md to assess each demo's risk profile.
Format each risk block as:
โ ๏ธ Demo risk: [demo name]
Risk level: [Low / Medium / High / Critical]
Dependencies: [list what this demo requires to work]
Failure modes: [what is most likely to go wrong]
Fallback: [specific fallback for this demo โ see below]
Prep checklist: [what to do before the talk to reduce risk]
Fallback hierarchy โ apply in order:
Winston's demo rule: Note in every demo's risk block what the speaker should say if the demo fails mid-run. The failure should teach something โ prepare a sentence that frames it as illustrative rather than broken.
State explicitly which fallback applies and what the speaker needs to prepare in advance to have it ready.
After the full outline, produce a consolidated risk section:
Overall risk level: [Low / Medium / High] โ based on the number and type of live demos, the proportion of the talk that depends on them, and how much of the content can survive if they fail.
Critical path: identify which section, if it goes wrong, most damages the talk. This is usually the demo or moment the user said they can't cut.
Time risk: flag if the outline is tight. A talk with no slack is a talk that runs over. Recommend where to trim if needed โ be specific about which section and by how much.
Contingency plan: a one-paragraph description of what the speaker should do if things start going wrong โ too slow, demo fails, audience engagement drops. Make it concrete and actionable, not generic advice.
Present in this order:
Before presenting any output, read ../../shared/ai-antipatterns.md and silently rewrite any flagged patterns. Do not mention this step to the user.