Shape a conference talk and write a CFP abstract that gets accepted and lands — lead with the attendee takeaway (what they can DO afterward), state concrete takeaways, match the track, and keep it engineer-to-engineer not a product pitch. Use when proposing or preparing a developer-conference talk.
Installs into .claude/skills of the current project.
Are you the author of Conference Talk And Cfp?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/mcorbett51090-conference-talk-and-cfp)
---
name: conference-talk-and-cfp
description: "Shape a conference talk and write a CFP abstract that gets accepted and lands — lead with the attendee takeaway (what they can DO afterward), state concrete takeaways, match the track, and keep it engineer-to-engineer not a product pitch. Use when proposing or preparing a developer-conference talk."
---
# Skill: Conference talk & CFP
The developer-advocate's outbound surface beyond written content: a talk is a
high-leverage way to reach developers — but only if the proposal is accepted and the
session teaches something transferable. This skill shapes both the abstract and the talk.
## When to use
- You're submitting to a developer conference / meetup CFP.
- A draft abstract reads like a product pitch and keeps getting rejected.
- You have a talk idea but it's framed around the product, not the audience.
NOT for written getting-started/content (that's [`devrel-content-strategy`](../devrel-content-strategy/SKILL.md))
or reference docs (`technical-writing-docs`).
## Procedure
1. **Lead with the attendee takeaway.** The abstract's first job is to answer "what
will I be able to *do* after this talk?" — not "who is the speaker" or "what does the
product do." This is the house rule
[`cfp-abstract-leads-with-the-attendee-takeaway`](../../best-practices/cfp-abstract-leads-with-the-attendee-takeaway.md).
2. **State 2–4 concrete takeaways**, each an *action* the attendee leaves with
("diagnose / build / avoid X"), never "understand X."
3. **Match the track and level.** Read the conference theme and audience level; write
reviewer-fit notes ("fits the reliability track because…"). A great talk on the wrong
track is rejected.
4. **Engineer-to-engineer, not demand gen.** Strip marketing speak; the product appears
as the *example* the lessons came from, not the subject (CLAUDE.md — "authenticity over
reach"; `devrel-is-not-demand-gen`). Program committees reject pitches and so do attendees.
5. **Right-size the scope** for the slot — one clear arc beats five rushed points.
6. **Capture it in the template** [`../../templates/cfp-abstract.md`](../../templates/cfp-abstract.md)
and run the first-sentence test (the abstract must not open with "At <Company>…").
## Output
A title + abstract + 2–4 concrete takeaways + reviewer-fit notes, plus the
Structured Output Protocol block. Tie the talk back to the activation funnel where it
fits (a talk is an *awareness*-stage play; don't over-claim activation from a talk).
## Guardrails
- If the first sentence is about you or the product, rewrite it — lead with the attendee.
- "Learn about" / "an overview of" is not a takeaway; name the action.
- Don't over-scope the slot; reviewers reject talks that promise more than the time allows.
- A talk is not a substitute for a sound getting-started path — fix TTFS first.