samber/developer-relations-skills已通过检查
SKILL DETAIL
conference-cfp-submission
samber/developer-relations-skills/conference-cfp-submission
Turns a talk idea into a submission-ready conference proposal for one specific event, or helps choose which conferences to target and plan a submission calendar across several - track fit, title options, an attendee-facing abstract, verb-first takeaways, the reviewer-only fields, a credibility package, and a self-review against the committee's own criteria. Use whenever the user mentions a CFP, a call for papers, a conference proposal, a talk abstract, a session description, submitting to KubeCon, PyCon or FOSDEM, which conference to submit to, planning a CFP season, or says their proposals keep getting rejected - even if they only ask to shorten an abstract. Covers community-run and vendor-run events. Do NOT use for structuring the accepted talk (samber/developer-relations-skills@tech-talk-outline) or its demo (samber/developer-relations-skills@developer-live-demo-design).
安装量 · 415查看来源
Installation
npx skills add https://github.com/samber/developer-relations-skills --skill conference-cfp-submission
技能文件
SKILL.md
最近同步 · 2026年10月23日
evals/evals.json›
{
"skill_name": "conference-cfp-submission",
"evals": [
{
"id": 1,
"prompt": "I'm a staff SRE at Northwind Freight and I want to submit a talk about how we cut our pager volume from 340 alerts a week to 51. The CFP for ScaleNorth closes in 9 days. Realistically I have about four hours of writing time, and I'm not a speaker - the idea of getting grilled on stage over a position I've staked out genuinely scares me, I'd fold. I do want to milk this one: give it at four or five events, get the recording up, and write it up as a post afterwards. Give me the spiciest angle, the one that'll actually get picked out of the pile.",
"expected_output": "A ranked menu of candidate angles with the orderings stated explicitly, the contrarian thesis deleted on the user's stated constraint, a recommendation, and a pause for the user to choose before any copy gets written.",
"files": [],
"expectations": [
"Presents a ranked set of candidate angles rather than jumping straight to one angle",
"Names the war story, the contrarian thesis and the practical playbook as the candidate angles",
"States the efficiency ordering explicitly as war story > contrarian thesis > practical playbook",
"Reports value on the review grid and value in the room as two separate orderings rather than blending them into a single rank",
"Gives value on the review grid as contrarian thesis > war story > practical playbook",
"Gives value in the room as practical playbook > war story > contrarian thesis",
"Deletes the contrarian thesis from the menu outright instead of listing it as an available option",
"Says the contrarian thesis was deleted because the user cannot rehearse defending a position live",
"Promotes the practical playbook above its position in the efficiency order on the strength of the user's compounding goal of four or five events plus a recording plus a written version",
"Treats compliance cost as its own consideration, naming employer approval, customer anonymisation or a security read as a cost of the war story angle",
"Waits for the user to pick an angle before drafting any title or abstract copy"
]
},
{
"id": 2,
"prompt": "Submitting to NordicCloud Summit. Their CFP page says: \"During the first round of reviews, proposal author information is not displayed to reviewers.\" Title cap is 80 characters, abstract cap is 1,200. I work at Marbleline - we're the payments infra company behind about a third of Nordic card processing, so put Marbleline in the title, it's the strongest credential I've got. Open the abstract with \"At Marbleline, we believe idempotency is a product feature, not an implementation detail.\" Talk is about how we rebuilt our retry layer after a duplicate-charge incident that hit 1,900 customers.",
"expected_output": "A proposal pack whose published fields carry no identifying information, the requested opening replaced, affiliation still disclosed where the form asks, and character counts shown against both caps.",
"files": [],
"expectations": [
"Keeps the employer name out of the title",
"Keeps the employer name out of the abstract",
"Keeps the employer name out of the outline",
"Explains that the first round of review is anonymous, so identifying detail in the published fields breaks the event's own review process",
"Rejects the requested opening line beginning \"At Marbleline, we believe\" rather than using it as written",
"Supplies a replacement opening that names the problem the reader recognises instead of the employer",
"Still discloses the affiliation in whatever form field asks for it rather than concealing it entirely",
"Shows a character count for the title against the 80-character cap",
"Shows a character count for the abstract against the 1,200-character cap",
"Offers five title options, ranked",
"Carries the 1,900-customer figure into the abstract"
]
},
{
"id": 3,
"prompt": "DevConf Atlantic closes Sunday. I've got five decent talk ideas and I want all five in, plus a panel on incident response with two colleagues from my team - Dev, Marcus and me, all three of us here at Cragview Systems. Their CFP fine print says \"if an individual submits more than three proposals, none of their submissions will be reviewed\" and further down \"proposals that are solely or to a large extent written or include AI-generated text by a large-scale language model will be rejected, with no opportunity to resubmit.\" Just generate all five plus the panel and I'll paste them in tonight, I'm out of time.",
"expected_output": "A hard stop on the submission count with the all-or-nothing consequence spelled out, the panel composition problems flagged, the AI policy read back, and the draft framed as copy the user must rewrite.",
"files": [],
"expectations": [
"States that submitting five proposals means none of them is reviewed, not that the first three are kept",
"Tells the user to cut the list to three or fewer before submitting",
"Counts the panel submission against the per-person cap rather than treating it as exempt from it",
"Flags that a panel where all three speakers come from the same company fails the usual requirement that more than one company be represented",
"Flags the rule against a panel of three or more speakers who all identify as men",
"States that every panellist must be named and confirmed at submission time",
"Restates the event's AI policy back to the user explicitly",
"States that the generated copy is a draft the user must rewrite in their own voice with their own specifics before submitting",
"Recommends a humanizer pass on the final copy without naming a specific humanizer skill",
"Treats the per-person cap as a published rule that is not negotiable, distinct from any self-set quality bar",
"Does not hand back five proposals presented as ready to paste into the form"
]
},
{
"id": 4,
"prompt": "I run DevRel at Quillstack, we make a workflow orchestration engine. Submitting to QuillCon, which is our own annual user conference - about 1,200 customers and prospects in the room. The talk is about Harbor Dental Group, a customer running roughly 40,000 workflow executions a day across 90 clinics, and how their ops team restructured around it. I assume I should scrub all the Quillstack product references out so it doesn't come across as a pitch?",
"expected_output": "A correction that the vendor-neutral rule inverts at a vendor's own event, a proposal built on product depth and customer outcome, written for a B2B room, with approval and invention constraints respected.",
"files": [],
"expectations": [
"States that the vendor-neutral prohibition on product framing does not apply at the vendor's own conference",
"States that product depth is the point at a vendor-run event",
"Keeps the product as the subject of the proposal rather than demoting it to background setting",
"Builds the proposal around the customer outcome and the specificity of the implementation",
"Identifies the buying motion as B2B and writes the abstract accordingly",
"Names an organisational cost in the abstract - migration effort, operational burden, or what the team stopped doing",
"Keeps figures inside numbers the company already publishes or the customer has approved",
"States that naming Harbor Dental Group requires that customer's approval, or anonymises them",
"Carries the 40,000 executions per day figure into the abstract",
"Does not invent further customer metrics beyond the figures supplied",
"Writes verb-first takeaways scoped to the slot"
]
},
{
"id": 5,
"prompt": "Two submissions this year, two rejections. Braidwood Systems Conf just sent me a note saying \"strong proposal, but we had no room in the programme this year.\" The other one was a form rejection. What's the acceptance rate at these things, 10% or so? I figure I just keep rewriting this abstract until it's perfect and eventually one lands. Should I?",
"expected_output": "A refusal to quote an acceptance rate, a reframing of the sample size, the waitlist note read as a win, and retargeting recommended over rewriting.",
"files": [],
"expectations": [
"Declines to quote an acceptance-rate figure at the user",
"States that the circulating \"about one in ten\" figure has no primary source",
"States that major event CFP pages do not publish submission or acceptance counts",
"Says two submissions is too small a sample to judge the proposal's quality",
"Names 8-10 submissions as the working sample size before an acceptance rate means anything",
"Labels that sample size as a working number set here rather than a published one",
"Reads the \"strong proposal, no room\" note as evidence the proposal worked",
"Recommends resubmitting that proposal elsewhere unchanged rather than rewriting it",
"Tells the user to request written reviewer feedback after a rejection",
"Explains that large events run a balance pass on topic spread, speaker diversity and first-time speakers, so a strong proposal can lose for reasons the author cannot influence"
]
},
{
"id": 6,
"prompt": "Cap is 1,000 characters, can you just tighten this up? Here's what I've got.\n\nAbstract: \"In this talk I'll walk you through our journey migrating from Jenkins to a new CI system. I'll share what we tried, what failed along the way, and what we eventually got right. We'll look at the architectural choices we made and the lessons we learned as a team. By the end you'll understand the trade-offs involved in this kind of migration.\"\n\nTakeaways: Understand how CI fits into your stack. Learn about the trade-offs of different pipeline designs. Appreciate the importance of build automation. Understand why we chose what we chose.",
"expected_output": "A rubric diagnosis delivered before any rewrite, then a rewrite with action-verb takeaways cut to size, the missing evidence flagged as a question rather than invented, and a character count.",
"files": [],
"expectations": [
"Scores the existing draft before rewriting any of it",
"Scores it on all four axes: Content, Originality, Relevance and Speaker",
"Gives each axis a score on a 1-5 scale",
"Gives a written reason for each axis score",
"Names the speaker-centric framing - \"I'll walk you through our journey\" - as a rejection pattern",
"Replaces every \"Understand\", \"Learn about\" and \"Appreciate\" takeaway with an action the attendee performs afterwards",
"Starts every rewritten takeaway with an action verb",
"Cuts the takeaway list to between two and four items",
"Flags the absence of any specific number, system or scale the speaker can source, and asks the user for one",
"Does not invent a metric to fill that gap",
"Reports the rewritten abstract's character count against the 1,000-character cap"
]
},
{
"id": 7,
"prompt": "I've got one talk - the night our Postgres connection pooler ran out of slots and took down checkout for 71 minutes. First time I'd be speaking anywhere. Four events on my list: GlobalScale Summit (6,000 attendees, deadline 10 Jan, notify 1 Mar, their tracks are AI, Security and Developer Experience), RegionDB Days (about 300 people, deadline 20 Nov, notify 15 Dec, one of their tracks is literally called \"Production War Stories\"), DataPlatform World (deadline 5 Jan, notify 20 Feb), and OpenInfra Nordics (deadline 8 Jan, notify 25 Feb). GlobalScale is the one that'd look best on my LinkedIn so I want to go all-in on that one. Thoughts?",
"expected_output": "A portfolio ranking that puts track fit above name recognition, a single-calendar view of the four events, overlapping-window and sequencing decisions made explicitly, and a first-speaker recommendation.",
"files": [],
"expectations": [
"Ranks the candidate events by how many fit criteria they satisfy rather than by name recognition or attendee count",
"Recommends RegionDB Days ahead of GlobalScale Summit for this talk",
"Cites the \"Production War Stories\" track description as matching the incident material",
"Notes that GlobalScale Summit publishes no track matching this talk",
"States that a strong proposal in the wrong track loses to a weaker one in the right track",
"Notes that a first-time speaker at a flagship event competes against speakers with a recorded track record there",
"Pulls every candidate event's deadline, notification date and event date into one calendar rather than handling the events one at a time",
"Identifies that submitting the same material to events with overlapping review windows requires deciding in advance which acceptance the user would take",
"Sequences the earlier-deadline regional event first so the material gets talked through before the flagship submission",
"Recommends submitting the lower-effort angle first where two deadlines fall close together, so a rejection still leaves preparation time",
"Suggests running the talk at a meetup before the conference submission, given this is a first proposal"
]
},
{
"id": 8,
"prompt": "Going for the 5-minute lightning slot at Ferrolane Devcon. Here's what I want to cover: our queue backlog problem, why we picked Redis Streams, the consumer group bug we hit, the metrics we added, the dashboard, the on-call rota change, cost savings, and what we'd do differently. Lightning talks are way easier to get into than the main track, right? What's the actual acceptance rate difference between the two?",
"expected_output": "A refusal to promise format-based odds, and a proposal cut to lightning scope with a single action-verb takeaway and a minute-budgeted outline.",
"files": [],
"expectations": [
"States that no event publishes per-format acceptance data",
"Declines to give an acceptance rate difference between lightning and main track",
"Notes that the lightning format is widely treated as the easiest entry point while making clear this is not a measured claim",
"Cuts the scope to one idea for the 5-minute slot",
"Produces exactly one takeaway for the lightning format",
"Starts that takeaway with an action verb",
"States that a long list of takeaways signals to a reviewer that none of them will land",
"Offers the longer format as the alternative if the user wants to keep the wider scope",
"Produces an outline with minute estimates that fits inside the lightning slot",
"Does not carry all eight listed items into the proposal"
]
},
{
"id": 9,
"prompt": "I want to submit \"The State of WebAssembly in 2027\" to a big cloud-native conference. I've read basically every blog post and watched all the talks on it for the last two years, so I know the space cold - but I haven't shipped anything with it myself. Write me a killer abstract, throw in some impressive adoption numbers to make it land, and for the speaker section say I've spoken before - I did do a five-minute lightning thing at a local meetup once but nobody recorded it.",
"expected_output": "A plain stop on the missing first-hand material, no invented figures or speaking credits, the gaps left as questions to the user, and a route to a version that could be evidenced.",
"files": [],
"expectations": [
"Stops and says plainly that without first-hand material the proposal becomes a survey talk",
"Names credibility asserted rather than evidenced as a recurring rejection pattern",
"Refuses to invent adoption or performance numbers for the abstract",
"Refuses to inflate or invent the prior-speaking claim",
"Leaves the missing material as an explicit question to the user rather than filler text in the pack",
"Asks what first-hand experience could back a reframed version - a system run, an incident handled, data collected, or a migration led",
"Points out that the title as written commits the speaker to a survey with no position attached",
"Notes that a conference-length recorded practice run, or a written version of the material, gives a reviewer something to check when no talk recording exists",
"Does not hand back a finished, submission-ready abstract built on the current material",
"States plainly what the meetup lightning talk can and cannot be claimed as"
]
},
{
"id": 10,
"prompt": "BuildScale Conf form has exactly these fields: Title (100 chars), Abstract (1,500 chars), Outline, Audience level, Track. That's it - no notes-to-reviewers box, no benefit-to-community box. Tracks on offer: \"The Future of Engineering\", \"Platform & Infrastructure\", \"Culture & Craft\". My talk is how we took our CI queue from a 40-minute median wait down to 6 minutes across 210 repos. \"The Future of Engineering\" sounds like the most prestigious track so put me in that one. For the outline just paste the abstract in again, it's the same content anyway.",
"expected_output": "An outline built as a two-level minute-budgeted running order, the track chosen by description rather than prestige, the missing reviewer field handled by folding one sentence into the payoff, and counts shown.",
"files": [],
"expectations": [
"Refuses to paste the abstract into the outline field",
"Produces the outline as a running order with minute estimates",
"Formats the outline as a two-level bulleted list",
"Rejects \"The Future of Engineering\" as a track picked by name rather than by its description",
"Recommends \"Platform & Infrastructure\" as the track matching the material",
"States that chairs rank proposals within a track, so the track choice changes the competition the proposal faces",
"Notes that this form offers no notes-to-reviewers field",
"Folds the single strongest reviewer-only sentence into the abstract's payoff and drops the rest, rather than inventing a field the form does not have",
"Sets an honest audience level rather than labelling the talk advanced by default",
"Carries both the 40-minute and 6-minute figures into the abstract",
"Shows a character count for the title against 100 and for the abstract against 1,500"
]
},
{
"id": 11,
"prompt": "Great news - the same talk got accepted at two events, both in March. Can you write me the slide deck and sort out the narrative arc, and also figure out how to make the live demo not blow up? Two other things: I actually gave this exact talk at PyData Grenoble last October, is that going to be a problem for either of them? And Hartfield Cloud Days closes in three weeks, I may as well fire the same proposal in there too since it's already written.",
"expected_output": "A handoff for the slides and demo, the recycled-content question routed to each event's own rule, and the two-acceptance scheduling conflict raised before a third submission is encouraged.",
"files": [],
"expectations": [
"Declines to write the slide deck or the narrative arc, stating that this skill's scope ends at submission",
"Hands the talk structure off to samber/developer-relations-skills@tech-talk-outline",
"Hands the live demo off to samber/developer-relations-skills@developer-live-demo-design",
"Writes both handoff targets in owner/repo@skill form rather than as bare skill names",
"Flags that events archiving their talks check whether the same session ran recently, so a previously delivered talk may be ineligible",
"Tells the user to read each target event's own recycled-content rule rather than assuming one event's rule transfers to another",
"Raises the scheduling conflict created by already holding two acceptances for the same talk in the same month",
"States that a proposal is reusable across a season but a post-acceptance scheduling conflict is not",
"Tells the user to decide which event they would actually take before submitting to Hartfield Cloud Days",
"Does not treat the third submission as free simply because the proposal text already exists",
"Reminds the user to keep the promises the published abstract made, because attendees quote it back"
]
}
],
"trigger_queries": [
{ "query": "help me write a CFP submission for KubeCon", "should_trigger": true },
{ "query": "my talk proposals keep getting rejected, what am I doing wrong", "should_trigger": true },
{ "query": "shorten this abstract to 1,300 characters", "should_trigger": true },
{ "query": "call for papers closes Friday and I have nothing written", "should_trigger": true },
{ "query": "which conferences should I send this talk to", "should_trigger": true },
{ "query": "turn this blog post into a conference talk proposal", "should_trigger": true },
{ "query": "write me a session description for the platform engineering track", "should_trigger": true },
{ "query": "I need a speaker bio and an abstract for a submission form", "should_trigger": true },
{ "query": "what do I put in the notes to reviewers field", "should_trigger": true },
{ "query": "is this title strong enough to get picked", "should_trigger": true },
{ "query": "PyCon US closes next week, can you help me get something in", "should_trigger": true },
{ "query": "how many proposals am I allowed to send to one event", "should_trigger": true },
{ "query": "FOSDEM devroom submission help", "should_trigger": true },
{ "query": "draft the takeaways for my 25 minute session", "should_trigger": true },
{ "query": "I want to speak at a conference this year but I don't know where to start", "should_trigger": true },
{ "query": "review this before I hit submit", "should_trigger": true },
{ "query": "the form asks for benefit to the community, what do I write there", "should_trigger": true },
{ "query": "help me pick a track for my observability talk", "should_trigger": true },
{ "query": "my abstract is 1,800 characters and the limit is 1,300", "should_trigger": true },
{ "query": "planning my CFP season for next year", "should_trigger": true },
{ "query": "should I go for a lightning talk or a full session", "should_trigger": true },
{ "query": "write the outline field for my submission", "should_trigger": true },
{ "query": "how do I make this stand out against 400 other submissions", "should_trigger": true },
{ "query": "I got waitlisted, what should I do with it now", "should_trigger": true },
{ "query": "rejected again, should I give up on speaking", "should_trigger": true },
{ "query": "what do programme committees actually score you on", "should_trigger": true },
{ "query": "do I need a recording of a previous talk to get accepted", "should_trigger": true },
{ "query": "can I send the same proposal to two events", "should_trigger": true },
{ "query": "I have an incident story from last year, is it worth proposing", "should_trigger": true },
{ "query": "submitting to our own user conference, how much product can I put in", "should_trigger": true },
{ "query": "the first review round is anonymous, does that change my abstract", "should_trigger": true },
{ "query": "what's all this AI policy language on the CFP page", "should_trigger": true },
{ "query": "prep my workshop submission, they want prerequisites", "should_trigger": true },
{ "query": "I want to propose a panel with three colleagues", "should_trigger": true },
{ "query": "they said my scope was too broad, how do I narrow it down", "should_trigger": true },
{ "query": "give me five title options for this talk idea", "should_trigger": true },
{ "query": "what makes a good hook for a session description", "should_trigger": true },
{ "query": "the form wants prerequisites and audience level, what do I say", "should_trigger": true },
{ "query": "first time speaker, where should I aim", "should_trigger": true },
{ "query": "help me pitch this database migration story to a conference", "should_trigger": true },
{ "query": "should I mention my company in the proposal or not", "should_trigger": true },
{ "query": "score my draft the way a reviewer would", "should_trigger": true },
{ "query": "how long should the abstract actually be", "should_trigger": true },
{ "query": "which of these two angles is more likely to get picked", "should_trigger": true },
{ "query": "deadline is tomorrow, I need a proposal out of this idea", "should_trigger": true },
{ "query": "write me the attendee facing description for my session", "should_trigger": true },
{ "query": "what goes in the reviewer only fields versus the public blurb", "should_trigger": true },
{ "query": "I want to get on stage at a big cloud native event next year", "should_trigger": true },
{ "query": "help me sell this idea to a programme committee", "should_trigger": true },
{ "query": "my employer wants me speaking more, what do I put in", "should_trigger": true },
{ "query": "how do I turn our internal runbook into a talk proposal", "should_trigger": true },
{ "query": "can I propose a talk I already gave at a meetup", "should_trigger": true },
{ "query": "need help getting a session accepted somewhere this season", "should_trigger": true },
{ "query": "my talk got accepted, help me structure the slides", "should_trigger": false },
{ "query": "build a minute by minute outline for my accepted keynote", "should_trigger": false },
{ "query": "the narrative arc of my 30 minute talk isn't working", "should_trigger": false },
{ "query": "how many slides should a 20 minute talk have", "should_trigger": false },
{ "query": "design the live demo for my conference talk so it doesn't break on stage", "should_trigger": false },
{ "query": "what's my fallback if the demo fails in front of the room", "should_trigger": false },
{ "query": "should we sponsor KubeCon and at which tier", "should_trigger": false },
{ "query": "how much does a booth at a developer conference cost", "should_trigger": false },
{ "query": "plan our booth activation for the expo hall", "should_trigger": false },
{ "query": "start a monthly Go meetup in Lisbon", "should_trigger": false },
{ "query": "how do I find speakers for our user group", "should_trigger": false },
{ "query": "write the event description for our next meetup", "should_trigger": false },
{ "query": "I'm going on a podcast next week, prep me", "should_trigger": false },
{ "query": "what sound bites should I have ready for this interview", "should_trigger": false },
{ "query": "write our quarterly devrel content calendar", "should_trigger": false },
{ "query": "turn this talk into an engineering blog post", "should_trigger": false },
{ "query": "write a technical blog post about our monolith migration", "should_trigger": false },
{ "query": "script a screencast walking through the SDK", "should_trigger": false },
{ "query": "pitch this launch to reporters", "should_trigger": false },
{ "query": "we need an embargo plan for the announcement", "should_trigger": false },
{ "query": "write a customer case study about their production deployment", "should_trigger": false },
{ "query": "does conference speaking help me get promoted to staff advocate", "should_trigger": false },
{ "query": "build my portfolio to land a developer advocate job", "should_trigger": false },
{ "query": "write the job posting for a developer advocate", "should_trigger": false },
{ "query": "help me prepare for the presentation round of a job interview", "should_trigger": false },
{ "query": "how do we measure whether devrel is working", "should_trigger": false },
{ "query": "which devrel podcasts and newsletters should I follow", "should_trigger": false },
{ "query": "allocate our devrel budget across events and content", "should_trigger": false },
{ "query": "benchmark our competitor's developer relations motion", "should_trigger": false },
{ "query": "write our code of conduct for the Discord", "should_trigger": false },
{ "query": "design the perks ladder for our ambassador program", "should_trigger": false },
{ "query": "audit our repository README", "should_trigger": false },
{ "query": "write release notes for v3.2", "should_trigger": false },
{ "query": "write the quickstart for our API", "should_trigger": false },
{ "query": "our docs need a structure audit against Diátaxis", "should_trigger": false },
{ "query": "write a migration guide for this breaking change", "should_trigger": false },
{ "query": "should we open source this component", "should_trigger": false },
{ "query": "pick a license for the project", "should_trigger": false },
{ "query": "plan the launch of our open source project", "should_trigger": false },
{ "query": "which open source projects should we sponsor", "should_trigger": false },
{ "query": "set up sponsorship tiers on my open source project", "should_trigger": false },
{ "query": "segment our developer audience into named groups", "should_trigger": false },
{ "query": "price our developer tool", "should_trigger": false },
{ "query": "optimize my GitHub profile README", "should_trigger": false },
{ "query": "write a sales proposal for this enterprise deal", "should_trigger": false },
{ "query": "draft an RFP response for the procurement team", "should_trigger": false },
{ "query": "help me write a grant proposal for research funding", "should_trigger": false },
{ "query": "write the abstract for my journal paper submission", "should_trigger": false },
{ "query": "format my research paper for the ACM submission deadline", "should_trigger": false },
{ "query": "write a project proposal to get headcount approved", "should_trigger": false },
{ "query": "draft a client proposal with pricing and scope", "should_trigger": false },
{ "query": "write the promotional social posts for my upcoming talk", "should_trigger": false },
{ "query": "book travel and accommodation for the conference I'm attending", "should_trigger": false }
]
}
references/event-research-checklist.md›
# Event research checklist
What to extract before writing a single field, where to find it, and what each finding changes in the proposal.
## Hard constraints (from the CFP page and the submission form)
| Finding | Where | What it changes |
| ------------------------------------------------------ | ---------------------------------------------------- | -------------------------------------------------------------- |
| Field list | The form itself, or the CFP page's "what we ask for" | Which sections of the pack you produce |
| Character or word caps per field | Form hints, CFP page | Draft length; count, never estimate |
| Formats and durations offered | CFP page | Scope of the whole talk (see table below) |
| Submissions allowed per person | CFP page, often in the fine print | Whether the user should spread proposals across events instead |
| Speakers allowed per proposal, panel composition rules | CFP page | Whether a co-speaker is possible at all |
| Deadline, notification date, event date | CFP page | Turnaround, and when to move the proposal elsewhere |
| Anonymous or named review | CFP page, "review process" section | Whether the copy may name the speaker or employer |
| Recycled-content rule | CFP page or speaker terms | Whether a previously delivered talk is eligible |
| AI-assistance policy | CFP page or code of conduct | How much rewriting the user must do before submitting |
| Travel, accommodation, ticket, honorarium | Speaker terms page | Whether the user can accept an acceptance |
| Recording and licensing terms | Speaker terms page | Whether the employer must approve |
## Soft signals (from last year's schedule and the track list)
- **Track descriptions.** Copy the wording of the track you target; the proposal should echo its vocabulary, because chairs rank within a track.
- **What already ran.** Five to ten titles from the previous edition show the level, the house title style, and which angles are exhausted.
- **Who spoke.** A programme dominated by vendor talks or by end-user stories tells you which framing the committee rewards.
- **Stated wants.** Many CFPs say what they want more of: first-time speakers, end-user experience, non-tool-specific topics, novel approaches.
- **Mentorship and early-submission programmes.** Several events pair submitters with previous speakers or offer proposal review, and they gate it on submitting well before the deadline. Surface it to the user as soon as you find it.
- **Real proposals with their verdict.** speakerline.io publishes submitted proposals tagged Accepted or Rejected, each with its abstract and its reviewer-only pitch, indexed by speaker, event and tag. Read three accepted entries for the target event - or for the closest comparable event, since coverage skews to Ruby conferences - before drafting. Entries are self-submitted, so read them as house-style evidence, not as a representative sample.
## Format-to-scope mapping
| Format | Typical length | Realistic scope | Notes |
| -------------------- | -------------- | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------ |
| Lightning talk | 5-10 min | One idea, one takeaway | Widely treated as the easiest entry point, though no event publishes per-format acceptance data - say so rather than promising better odds |
| Standard session | 25-30 min | One problem, 2-3 takeaways | The default format, and the one most submissions target |
| Long session | 45-60 min | One extended case study with nuance | Scarce; some events ask how you would cut it to the shorter slot |
| Workshop or tutorial | 75-180 min | Attendees build something | Prerequisites and environment setup must be explicit |
| Panel | 25-45 min | Discussion, no takeaway structure expected | All panellists usually named at submission; diversity rules may apply |
| Poster or demo table | Varies | One artefact, repeated conversations | Rarely competitive; good for work in progress |
## When browsing is unavailable
Ask the user for exactly these, in one message:
1. The CFP page text, pasted.
2. Five accepted talk titles from the previous edition.
3. The track list with descriptions.
4. The submission form's field names and any caps shown next to them.
Anything still missing becomes an explicit assumption, listed at the top of the delivered pack, so the user can correct it before pasting into the form.
references/proposal-pack-template.md›
# Proposal pack template
The deliverable. Produce it as one document the user can paste field by field into the submission form, with every character count shown against the event's cap.
## Table of Contents
- [Shape](#shape)
- [Constraints read from the CFP](#constraints-read-from-the-cfp)
- [Track](#track)
- [Title](#title)
- [Abstract ({N}/{cap} chars)](#abstract-ncap-chars)
- [Takeaways](#takeaways)
- [Outline (reviewer-only)](#outline-reviewer-only)
- [Notes to reviewers ({N}/{cap} chars)](#notes-to-reviewers-ncap-chars)
- [Benefit to the community ({N}/{cap} chars)](#benefit-to-the-community-ncap-chars)
- [Audience level and prerequisites](#audience-level-and-prerequisites)
- [Speaker bio ({N}/{cap} chars)](#speaker-bio-ncap-chars)
- [Supplemental materials](#supplemental-materials)
- [Self-review](#self-review)
- [Before you submit](#before-you-submit)
- [Filled example (abridged)](#filled-example-abridged)
- [Constraints read from the CFP](#constraints-read-from-the-cfp)
- [Track](#track)
- [Title](#title)
- [Abstract (912/1,300 chars)](#abstract-9121300-chars)
- [Takeaways](#takeaways)
- [Outline (reviewer-only)](#outline-reviewer-only)
- [Notes to reviewers](#notes-to-reviewers)
- [Rules for the pack](#rules-for-the-pack)
## Shape
```markdown
# {Event name} - {format}, {duration} - deadline {date}
## Constraints read from the CFP
- Fields: ...
- Caps: title N chars, abstract N chars, ...
- Review: anonymous / named
- Per-person cap: N proposals
- AI policy: ...
- Assumptions (only if something could not be confirmed): ...
## Track
{track name} - {one line on why this track's description matches}
## Title
{chosen title} ({N}/{cap} chars)
Alternatives:
1. ...
2. ...
## Abstract ({N}/{cap} chars)
{published copy, hook → promise → payoff}
## Takeaways
- {verb} ...
- {verb} ...
- {verb} ...
## Outline (reviewer-only)
- 0-4 min - ...
- ...
- 4-14 min - ...
- ...
- 14-26 min - ...
- 26-30 min - ...
## Notes to reviewers ({N}/{cap} chars)
{why this speaker, what exists already, what is new here, demo derisking}
## Benefit to the community ({N}/{cap} chars)
{who gains beyond the room, which gap in this programme it fills, why now}
## Audience level and prerequisites
{level} - {what attendees must already know}
## Speaker bio ({N}/{cap} chars)
{third person, 2-3 sentences, one connecting the speaker to this subject}
## Supplemental materials
- Prior talk recording: ...
- Repo / post / benchmark: ...
## Self-review
Content x/5 - ...
Originality x/5 - ...
Relevance x/5 - ...
Speaker x/5 - ...
## Before you submit
- [ ] Rewritten in your own voice
- [ ] Within the per-person submission cap
- [ ] Employer approval, if the recording terms need it
- [ ] Links open in a private window
```
## Filled example (abridged)
Constructed for illustration - "ExampleConf EU" is not a real event and the numbers are invented. Copy the shape, never the content.
```markdown
# ExampleConf EU - session, 30 min - deadline 12 Feb
## Constraints read from the CFP
- Fields: title (75), abstract (1,300), benefit to community (1,000-1,500), outline, bio (400)
- Review: anonymous first round - no employer name in title, abstract or outline
- Per-person cap: 3 proposals
- AI policy: assistance allowed, low-effort generated text rejected
## Track
Operations - the track description asks for "production experience, including what went wrong".
## Title
Cutting a 90-Minute Deploy to Nine Minutes on the Same Cluster (61/75 chars)
## Abstract (912/1,300 chars)
A deploy that takes 90 minutes stops being a deploy and becomes a scheduled event... {full copy}
## Takeaways
- Measure where deploy time actually goes, with no new tooling
- Decide which stages can run concurrently without weakening the rollback path
- Size the risk of removing a verification stage before removing it
## Outline (reviewer-only)
- 0-3 min - the 90-minute deploy and what it cost the team
- 3-12 min - measuring the pipeline: three stages held 70% of the time
- image build cache misses
- serialized integration suite
- manual approval gate
- 12-24 min - the four changes, in the order they shipped, with the one that regressed
- 24-30 min - what we would not do again, and questions
## Notes to reviewers
I own this pipeline and the numbers come from our build records... {full copy}
```
## Rules for the pack
- Show every character count next to its field; a reviewer never sees an over-cap field, the form simply refuses it.
- Never invent an employer, a customer name, a metric, an award or a prior talk. Where the user has not supplied one, write the placeholder as a question to the user, not as filler text in the pack.
- List assumptions at the top when the CFP could not be read, so the user corrects them before submitting.
- Keep the reviewer-only sections textually distinct from the abstract; overlap wastes the argument.
references/reviewer-rubric.md›
# Reviewer rubric and pre-submit checklist
Score the pack as a reviewer would: cold, fast, next to dozens of rivals, with no knowledge of the speaker beyond the form.
## Scoring anchors
### Content - is it coherent, structured and deliverable?
| Score | Anchor |
| ----- | ------------------------------------------------------------------------------------ |
| 1 | A topic, not a talk. No structure, no evidence the material exists |
| 2 | A structure implied but not shown; scope larger than the slot |
| 3 | Clear shape, outline present, but generic sections ("background", "lessons learned") |
| 4 | Outline with minutes, each section carrying one point, scope matched to the slot |
| 5 | The above, plus the hardest part of the talk is visibly already solved |
### Originality - is the idea, angle or data new?
| Score | Anchor |
| ----- | ------------------------------------------------------------------ |
| 1 | A version of this ran at this event recently, unchanged |
| 2 | Common topic, common angle, no data of the speaker's own |
| 3 | Common topic with a specific context that has not been shown here |
| 4 | A lens the programme lacks: new data, a failure, a contrarian read |
| 5 | Something only this speaker could submit |
### Relevance - right event, right track, right moment?
| Score | Anchor |
| ----- | ---------------------------------------------------------------------- |
| 1 | Wrong audience entirely, or a sales pitch |
| 2 | Adjacent to the event's subject; track chosen by name, not description |
| 3 | Fits the track, timing neutral |
| 4 | Matches the track description's own wording and the level of the room |
| 5 | Answers a question this community is actively arguing about |
### Speaker - right person, evidenced?
| Score | Anchor |
| ----- | ----------------------------------------------------------------------- |
| 1 | Enthusiasm and seniority claims only |
| 2 | Relevant job title, nothing tying the speaker to this specific material |
| 3 | Clear first-hand involvement, no external evidence |
| 4 | First-hand involvement plus checkable artefacts (repo, post, data) |
| 5 | The above plus a recording of a previous talk |
A proposal scoring 3 across the board is a proposal that will be beaten. Push Content and Originality to 4 before submitting. That priority is this skill's own call, not a published weighting - no committee publishes per-axis weights - but it is where the documented rejection patterns cluster: undeliverable scope and no angle on a well-worn topic.
## Pre-submit checklist
Copy: rules
- [ ] Title within cap, specific, no unexplained pun, no question mark, no product name at a vendor-neutral event
- [ ] Abstract within cap, complete sentences, opens on the problem
- [ ] Voice matches the house style visible on last year's schedule
- [ ] At least one number, system or scale the speaker can source
- [ ] Takeaways verb-first, scoped to the slot
- [ ] No claim the speaker cannot defend from a stage
Fields
- [ ] Reviewer-only text says something the abstract does not
- [ ] Outline has minute estimates and two levels
- [ ] Track matches the track description
- [ ] Audience level honest
- [ ] Prerequisites stated for a workshop
- [ ] Supplemental links open and are public
Rules
- [ ] Inside the per-person submission cap for this event
- [ ] Content not previously delivered where the event forbids it
- [ ] Panel or co-speaker composition rules satisfied, everyone confirmed
- [ ] Event's AI policy read, and the copy rewritten in the speaker's own voice
- [ ] Anonymity respected if the first round is blind
- [ ] Affiliation disclosed where the form asks
- [ ] Speaker terms acceptable: travel, ticket, recording licence, employer approval
Logistics
- [ ] Deadline and notification date recorded, with the event date checked against the calendar
- [ ] Proposal saved outside the submission platform for reuse
- [ ] Submitted early enough to qualify for mentorship or feedback where the event offers it
## Reviewing someone else's draft
When the user brings an existing proposal instead of an idea, run the rubric first and report scores with reasons before rewriting anything. A rewrite that arrives before the diagnosis teaches the user nothing, and they will need the diagnosis for the next CFP - the proposal is one submission, the pattern is a season.
references/title-and-abstract-examples.md›
# Title, abstract and takeaway examples
Two kinds of example live here. The first section quotes real proposals with their published verdict; everything after it is constructed for contrast, written to isolate one rejection pattern at a time. Use the real ones as the standard and the constructed ones as diagnosis aids.
## Real accepted proposals
Both are published on speakerline.io, which shows each proposal's submitted text and whether it was accepted.
**"Adopting Sorbet at Scale" - Ufuk Kayserilioglu, RubyConf 2019, accepted.** The abstract's first line is nothing but production scale:
> Shopify is a platform used by 800K merchants generating 12B$ revenue per year, serving 80K requests per second. Our core monolith is a 21K file Ruby on Rails application modified by 800 PRs per day.
Four numbers before the subject is even named. The reviewer-only pitch then carries what the abstract never claims: the speaker led the adoption and wrote the tooling the talk describes. That split - scale in the abstract, standing in the pitch - is the pattern to copy.
**"Access Denied: the missing guide to authorization in Rails" - Vladimir Dementyev, RailsConf 2018, accepted.** No metrics anywhere. It wins on a named gap in the ecosystem (the framework ships no authorization layer) and on enumerating the decisions the talk resolves: where authorization belongs, activity-based versus role-based, what existing libraries do and do not cover.
The pair matters: a numbers-first opening is the strongest default, not a rule. A proposal with no metrics still lands when it names a gap the audience recognises and commits to resolving specific decisions.
## Constructed weak/strong pairs
Weak and strong versions of the same material. The weak column is not a straw man - each one is a real rejection pattern, but the text itself was written for this skill, not taken from a submitted proposal.
### Titles
| Weak | Strong | Why |
| --------------------------------------- | --------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- |
| Building Better APIs | Three API Changes That Broke 40 Downstream Teams | Names the stake and the scale |
| Our Kubernetes Journey | Cutting a 90-Minute Deploy to Nine Minutes on the Same Cluster | Before and after, both measured |
| Is Your Observability Strategy Working? | We Paid for 12 TB of Logs and Used 400 GB | Declarative beats interrogative, and the gap between the two figures is the whole talk |
| Developer Experience: A Deep Dive | The Onboarding Step That Cost Us Half Our New Hires' First Week | The colon version front-loads a vague category |
| Scaling with Acme Cloud Run | Running 400 Batch Jobs an Hour Without a Scheduler | Vendor-neutral rooms reject the product framing |
| Rollback to the Future | Rollback to the Future: Undoing a GitOps Deploy the Cluster Kept Reapplying | A pun is fine when the rest of the title still says what the talk is |
### Abstracts
The same 30-minute talk, both versions inside a 1,000-character budget.
**Weak - speaker-centric, vague, no evidence**
> In this talk I'll walk you through our migration journey from a monolith to microservices. I'll share what we tried, what failed along the way, and what we eventually got right. We'll look at some of the architectural choices we made and the lessons we learned as a team. By the end, you'll have a good sense of how we approached the problem and you'll understand the trade-offs involved in this kind of migration.
Failures:
- Every sentence describes the speaker's activity.
- No number.
- "You'll understand" is not a takeaway.
- Nothing distinguishes it from fifty other migration talks.
**Strong - attendee-centric, specific, structured**
> Splitting a monolith usually fails in the same place: the database. Three services later, our team was running distributed transactions by hand and losing orders during deploys. This session walks through the two months that followed - the boundary we drew wrong, the outbox pattern that fixed writes but not reads, and the three-week freeze we could have avoided by moving the data before the code. Attendees leave able to sequence a decomposition around data ownership rather than service boundaries, spot the two failure signatures that mean the split came too early, and price the freeze honestly before proposing one.
Why it works: the hook is a recognisable failure, the middle names a concrete sequence, the payoff is three actions, and the whole thing reads as something only this team could have written.
### Takeaways
| Weak | Strong |
| -------------------------------------------------------- | --------------------------------------------------------------------------- |
| Understand how observability fits into your architecture | Choose which three signals to instrument first on a service you already run |
| Learn about the trade-offs of event-driven systems | Price the operational cost of a broker before proposing one |
| Gain insight into database migrations | Sequence a zero-downtime column rename in a table with active writes |
| Appreciate the importance of documentation | Run a docs cold-start test with a colleague in under an hour |
### Reviewer-only text
The notes field is where the sentences that would sound arrogant in published copy belong.
**Weak (copy-pasted abstract)**
> This talk covers our migration from a monolith to microservices and the lessons we learned.
**Strong (argues the case)**
> I led this migration and still own the services. The numbers in the abstract come from our incident record, and I can share the anonymised timeline. Last year's programme had two talks on decomposition strategy, both from the design side - this one is the operational aftermath, including the freeze we mishandled. No product is discussed; the tooling is open source and linked.
### Opening lines to cut on sight
- "At Acme, we believe…" - the employer's name in the first four words.
- "Have you ever wondered why microservices are hard?" - a question the talk never answers.
- "My journey into platform engineering started in 2019…" - the speaker's biography instead of the attendee's problem.
- "Kubernetes is a container orchestration system…" - defining a term the audience knows.
- "In today's fast-paced cloud-native landscape…" - a sentence carrying no information.
SKILL.md›
---
name: conference-cfp-submission
description: Turns a talk idea into a submission-ready conference proposal for one specific event, or helps choose which conferences to target and plan a submission calendar across several - track fit, title options, an attendee-facing abstract, verb-first takeaways, the reviewer-only fields, a credibility package, and a self-review against the committee's own criteria. Use whenever the user mentions a CFP, a call for papers, a conference proposal, a talk abstract, a session description, submitting to KubeCon, PyCon or FOSDEM, which conference to submit to, planning a CFP season, or says their proposals keep getting rejected - even if they only ask to shorten an abstract. Covers community-run and vendor-run events. Do NOT use for structuring the accepted talk (samber/developer-relations-skills@tech-talk-outline) or its demo (samber/developer-relations-skills@developer-live-demo-design).
license: MIT
metadata:
author: Samuel Berthe
version: "1.0.1"
---
# Conference CFP
You are a proposal editor who has sat on programme committees. The user has a talk idea and a target event; produce every field of that event's submission form, written so a tired reviewer scoring their fortieth proposal picks this one.
The proposal is judged alone. Reviewers cannot see the user's reputation, the demo they would give, or the conversation that produced the idea - only the form. Everything that has to land must be inside the fields.
Scope ends at submit. If the user wants slides or a narrative arc, hand off rather than drifting.
- Structuring the accepted talk: samber/developer-relations-skills@tech-talk-outline.
- The demo: samber/developer-relations-skills@developer-live-demo-design.
- Buying a sponsor slot: samber/developer-relations-skills@developer-event-sponsorship.
- Running your own event: samber/developer-relations-skills@developer-meetup-program.
Typical invocations:
- "help me submit this to the platform track"
- "write a CFP for my incident post-mortem"
- "my last three proposals were rejected, what am I doing wrong"
- "shorten this abstract to 1,300 characters"
- "turn this blog post into a talk proposal"
Each one starts at the Interview below and ends with the pack in [./references/proposal-pack-template.md](./references/proposal-pack-template.md), field by field, ready to paste into the form.
Expected output, every time: one markdown document with the event's constraints at the top, followed by:
- Track
- Title plus alternates
- Abstract
- Takeaways
- Outline
- Each reviewer-only field
- Bio
- Supplemental links
- The self-review scores
- A pre-submit checklist
Show a character count next to every capped field. Never hand back prose paragraphs of advice instead of the filled pack.
## Interview
Ask one question at a time, multiple-choice where possible, and skip anything already answered. Questions 1-5 gate everything: do not draft a title before they are answered.
**Memory: Store a few info about the current task or project context. When memory lives in a file, use `devrel-context.md`; if a different memory system is in use, rely on that instead. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.**
1. Which event, and where is the CFP page? Paste it if you can. If the user has not chosen an event yet, work through [Step 0](#step-0---choosing-which-conferences-to-target) first, then return here.
2. Which format and slot length are you targeting - lightning, standard session, long session, workshop, panel?
3. What is the talk about, in the words you would use to a colleague?
4. What first-hand experience backs it: a system you ran, an incident you handled, data you collected, a migration you led? Give one number.
5. Who is the attendee - job, situation, what they are trying to do that day? "Developers" is not an answer.
6. What are you representing: an employer's product, your own open-source project, or only yourself?
7. Have you given this talk, or a close version of it, anywhere else? Where, and when?
8. Have you spoken before, and is there a recording?
9. What is the deadline, how many other proposals are you sending to this event, and is there a date the talk itself has to land by - a launch, a hiring push, a funding milestone?
10. Is this a one-off win (get into this event, this year) or a compounding asset - a talk you give five times, that becomes a recording, a post and a reference?
11. What is your effort ceiling before the deadline: writing hours, whether you can rehearse defending a position live, and whether you can build material you do not already have?
12. Does the buying motion around your subject look B2B (a team adopts, someone else signs) or self-serve individual adoption? Both is a valid answer.
Answers 9 to 11 re-rank the angles in Step 2, so ask them before offering any.
- A tight deadline promotes the war story, whose material already exists.
- A compounding answer promotes the practical playbook, the only angle that survives being reused across five events and a written version.
- An effort ceiling that excludes rehearsing a live defence deletes the contrarian thesis.
If the user cannot answer 4, stop and say so plainly. Without first-hand material the proposal becomes a survey talk, and "credibility asserted, not evidenced" is one of the recurring rejection patterns behind § Failure modes.
## Step 0 - Choosing which conferences to target
Skip this step when the user already has a target event; start at the Interview.
When they don't, treat it as a portfolio decision, not a single yes/no on one event's name recognition:
| Criterion | What to check | Why it matters |
| ---------------------------- | -------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Track/topic fit | Does the event publish a track description matching the talk, or has it run this subject before | A strong proposal in the wrong track loses to a weaker one in the right track (Step 6) |
| Audience fit | Does the event's typical attendee match who the talk is written for (Interview Q5) | A practitioner talk dies at a business-track event, and the reverse is just as true |
| Vendor-neutral vs vendor-run | See § Event type and audience | Changes what the proposal is even allowed to say before a track is picked |
| Track record | Has the user submitted to this event before, and what happened | A first submission to a flagship event competes against speakers with a recorded track record there; a regional or community event is the lower-risk way to build one |
| Compliance lead time | Does the topic need employer approval, customer sign-off, or a security read (Step 2's compliance-cost column) | Determines how much lead time the submission needs before the deadline, not just how much writing time |
| Travel and format fit | Timezone, travel budget, and whether the event even offers the target format (Step 1's format-to-scope table) | Rules out an otherwise-good match early rather than after acceptance |
Rank candidate events by how many of these they satisfy, not by name recognition alone. A regional or community event with strong track fit is a better first target than a flagship event with weak fit - acceptance is judged over a season, not a single submission (see § Measurement).
### Planning a submission season
CFP deadlines differ by months across events covering the same topic, so treat several candidate events as one calendar rather than one at a time:
- Pull each candidate event's deadline, notification date and event date into one file as soon as a CFP page is found, not only after submitting - the events likeliest to fit one talk often cluster on overlapping windows rather than spacing out evenly.
- Never submit the same material to two events whose review windows overlap without first deciding which the user would actually take if both accept; a proposal is reusable across a season, but a scheduling conflict after two acceptances is not.
- Sequence a first-time or lower-confidence angle at a regional or community event with an earlier deadline, and hold the flagship-event submission for once the material has been talked through once, on a stage or at a meetup.
- Where two target events have close deadlines, submit the lower-effort angle first (Step 2's efficiency order), so a rejection still leaves time to prepare the higher-effort angle for the next deadline.
Track the calendar in the same file recommended in § Measurement.
## Step 1 - Read the event before writing a word
The same idea wins at one event and loses at its neighbour. Establish the event's rules first; they constrain every later step.
1. If you can browse the web, read the CFP page, the code of conduct or speaker terms, the track list, and last year's schedule. If you cannot, ask the user to paste the CFP page and five accepted talk titles from the previous edition.
2. Extract the hard constraints: field list, character or word caps, formats and durations, per-person submission cap, deadline, whether review is anonymous, whether travel is covered.
3. Extract the soft signals: which track descriptions match the idea, what the last edition already covered, what the event says it wants more of, whether the room is vendor-neutral.
4. State the constraints back to the user in a short block before writing. A cap discovered after drafting forces a rewrite that loses the sharpest sentences.
Read real proposals too, not only rules. speakerline.io publishes full submitted texts tagged Accepted or Rejected, with the reviewer-only "pitch" alongside the abstract.
Three accepted entries for the target event tell you more about its house style than any advice page. Coverage skews to Ruby conferences, so treat a missing event as normal and fall back to last year's published schedule.
Anonymous first-round review changes the copy. PyCon US states that "during the first round of reviews, proposal author information is not displayed to reviewers", so the title, description and outline must not name the speaker or their employer.
Other events, Write the Docs among them, review with names visible on purpose, to balance perspectives. Never guess which model applies - the CFP page says.
If your environment has persistent memory, store the event profile and the user's proposal under the event's name. Events repeat annually, CFPs are reused for the next city, and the second submission should start from the first one's file.
See [./references/event-research-checklist.md](./references/event-research-checklist.md) for the full extraction list and the format-to-scope table.
## Step 2 - Find the angle, and get it approved
A topic is not a proposal. Reviewers see fifteen versions of every popular topic, and the one they pick has a position attached.
Ask the user the question that produces one: _what do you believe about this that most of the room does not?_ Then present the candidate angles in the ranked order below, say the ranking out loud, recommend the top survivor, and wait for the user to choose. Effort here is what the angle costs before submission: material the user must already possess, hours of writing, and the preparation the angle commits them to for the stage.
| Angle | Effort before submitting | What it buys on the review grid | What it buys in the room | Fails when |
| ------------------ | --------------------------------------------------------------------------- | -------------------------------------------------------------------------- | --------------------------------------------------------------------------- | ------------------------------------------------------------------ |
| War story | an hour, when the failure and its numbers are already the user's | credibility a reviewer can check, and the originality nobody else can copy | attention, and the trust that carries the rest of the talk | the user has no failure they own and may publish |
| Contrarian thesis | a week, most of it assembling the evidence and rehearsing the defence | the highest standout score on a grid of forty look-alike proposals | memorability, and the invitations that follow it | the position collapses in Q&A, in front of the room |
| Practical playbook | a week, generalising one case into steps that work for someone else's stack | the least, on originality - this is the shape reviewers see most | the highest attendee ratings, and the only angle people implement on Monday | the title is vague, and it dies on the grid before anyone reads it |
- efficiency: war story > contrarian thesis > practical playbook
- value on the review grid: contrarian thesis > war story > practical playbook
- value in the room: practical playbook > war story > contrarian thesis
- effort: practical playbook > contrarian thesis > war story
- compliance cost: war story > contrarian thesis > practical playbook
The two value lines are the honest shape of this choice, not a hedge: what gets a proposal accepted and what makes the talk worth giving are different things. Blending them into one rank hides the case the user most needs to see.
Compliance cost, per angle:
- War story about an incident at an employer: needs that employer's approval, customer anonymisation and often a security read before a single sentence is public, and it cannot be withdrawn once the schedule publishes.
- Contrarian thesis that names competitors: carries a lighter version of the same exposure, at a vendor-neutral event.
- Playbook built from public material: carries none.
That efficiency order starves the practical playbook. It is first on value in the room and first on effort, so a ratio defeats it every round: a speaker who only ever computes efficiency ends up with a shelf of war stories and no talk anyone implements.
Promote the practical playbook:
- When the track description explicitly asks for practitioner or how-to content.
- When the goal is attendee ratings and a repeat invitation from this event.
- When the interview returned a compounding answer - a playbook is the angle that survives five events, a recording and a written version.
- When the steps already exist as an internal runbook: its effort collapses to an hour and it moves to the top outright.
Delete an angle the user's constraints rule out rather than offering it and letting them pick it: no failure they own and may publish means no war story, and no capacity to rehearse a defence means no contrarian thesis. Say which you deleted and why.
The order is a default, not a law: it shifts with the event and with who is speaking. Re-rank it against what you know about this user.
- A speaker with an existing recording and public standing can carry a contrarian thesis a first-time speaker cannot.
- A published incident write-up makes the war story near-zero effort.
- An event whose last edition ran three war stories in the same track inverts the top two.
Present the ranked angles, let the user choose, and do not write copy until they have. An angle changed after the abstract is written means starting over.
Pressure-test the chosen angle against the last edition's schedule. If the event ran a near-identical talk last year, the proposal needs a new lens - new data, a different scale, the failure case, or the contrarian read - before it is worth the user's submission slot.
## Step 3 - Title
Offer five options, ranked, spanning specific-and-plain to punchy. The title's only job is to make a reviewer read the abstract and an attendee open the session page.
Patterns worth using:
- The problem at scale ("Cutting Cross-Region Egress in a 400-Service Estate").
- The journey ("From Cron to Workflows Without a Freeze").
- The contrarian claim.
- The real number.
- The promised failure ("The Migration That Passed Every Test and Still Lost Data").
Rules:
- Respect the character cap; count the characters out loud.
- Prefer specific over vague.
- Drop question marks, which are almost always weaker than the declarative version.
- Drop puns that need explaining.
- Drop product names at vendor-neutral events.
- Avoid a colon whose left half is a vague category ("Developer Experience: A Deep Dive").
## Step 4 - Abstract
This text is published on the schedule, so write it for the attendee choosing between five rooms, not for the committee.
Shape it in three parts: hook, promise, payoff.
1. Hook - one or two sentences naming a problem the reader recognises immediately.
2. Promise - two or three sentences on what happens in the session: the case, the approach, the structure.
3. Payoff - one or two sentences of concrete takeaways.
Voice: third person where the event publishes abstracts verbatim, otherwise match the house style visible in last year's schedule. Complete sentences, no headings, no bullets unless the form allows them. Include the real numbers from Interview question 4; a specific figure is the cheapest credibility available.
Ban these openings; each loses the reader in the first line:
- The employer's name.
- A rhetorical question the talk never answers.
- The speaker's personal journey.
- A definition of a term the audience already knows.
Report the character count against the cap after every revision. Cut adjectives, hedges and stacked qualifiers first; they carry no information for a reviewer.
See [./references/title-and-abstract-examples.md](./references/title-and-abstract-examples.md) for two real accepted proposals and weak/strong pairs on the same talk.
## Step 5 - Takeaways
Two to four, verb-first, each an action the attendee performs afterwards: diagnose, instrument, audit, size, migrate, choose, measure. "Understand X" and "appreciate the importance of Y" read as an admission that the talk has no structure yet.
Scope them to the slot:
- Lightning talk: one idea, one takeaway.
- Standard session: one problem, two or three takeaways.
Eight takeaways in twenty-five minutes tells a reviewer none of them will land.
## Step 6 - Reviewer-only fields
Most forms have fields the attendee never sees: notes to reviewers, benefits to the ecosystem or community, the outline, prerequisites, audience level. Repeating the abstract into them wastes the one place where the user can argue their case.
| Field | Write this |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Outline | The running order with minute estimates, two levels deep - PyCon US asks for "an enumeration of what you intend to say, along with time estimates" and says "a two-level bulleted list format works best". It is the proof the talk exists |
| Notes to reviewers | Why this speaker, what is already built, how the demo is derisked, what makes the angle new here |
| Benefit to the ecosystem | Who gains beyond the room, what gap in this year's programme it fills, why now |
| Prerequisites | What attendees must already know or have installed |
| Audience level | The honest one - a mislabelled advanced talk empties the room |
| Track | The track whose description matches, since chairs rank inside a track and a great proposal in the wrong one loses to a weaker rival |
Where the form offers no notes field, fold the strongest reviewer-only sentence into the abstract's payoff and drop the rest.
## Step 7 - Credibility package
Reviewers are asked whether the speaker can deliver this specific talk. Specificity is the evidence; enthusiasm is not.
- A recording of a previous talk is the single strongest signal. If none exists, a conference-length recorded practice run or a written version of the same material gives a reviewer something to check.
- Link repos, posts, benchmarks and incident write-ups that show the work behind the talk.
- Write the bio in third person, two or three sentences, and make one of them connect the speaker to _this_ subject rather than listing seniority.
- Add a co-speaker only when they bring a distinct perspective - the customer, the other side of the migration. Check the form's speaker cap and any panel composition rules before promising anyone a slot.
## Step 8 - Submission rules and the AI-policy check
Run these before submitting; each one can void an otherwise winning proposal. The named rules below were read from the PyCon US and KubeCon + CloudNativeCon North America (Linux Foundation) CFP pages; treat them as examples of what to look for.
Read the target event's current page rather than assuming they transfer, since caps and policies change between editions.
- **Per-person cap.** Several large events cap proposals per speaker and remove _all_ submissions from anyone over the line. PyCon US caps them at three: "if an individual submits more than three proposals, none of their submissions will be reviewed". KubeCon uses the same cap and also limits a speaker to one panel plus one non-panel session per event.
- **Recycled content.** Events that archive their talks check whether the same session ran under their banner recently.
- **No sales pitch.** At vendor-neutral events a product-shaped proposal is "almost always rejected" - the Linux Foundation CFP's own words. The product can be the example the lessons came from; it cannot be the subject.
- **Panel composition.** Where the format allows a panel, expect published rules: all panellists named at submission, more than one company represented, and no panel of three or more speakers who all identify as men. Confirm every panellist before naming them.
- **AI policy.** Read it and tell the user what it says. PyCon US rejects proposals "solely or to a large extent written or include AI-generated text by a large-scale language model", with no second chance to submit. CNCF allows assistance but rejects "low-quality or clearly AI-generated 'slop'" and bars repeat offenders from future CFPs.
- **Humanizer pass.** Run the final copy through your preferred humanizer skill. Model-flavoured prose is exactly what reviewers now pattern-match on, and it costs the proposal its credibility before its idea is read.
- **Disclosure.** State the employer or project affiliation where the form asks. Reviewers find out anyway, and a hidden affiliation reads worse than a declared one.
Whatever the policy, everything produced here is a draft the user must rewrite in their own voice with their own specifics - say that out loud rather than assuming they know.
## Step 9 - Self-review against the committee's criteria
Score the finished pack on the four axes committees converge on, 1-5, with a written reason per score. Do it in the reviewer's voice, not the author's.
| Axis | The question | 1 looks like | 5 looks like |
| ----------- | ---------------------------------- | --------------------------------- | ------------------------------------------------------ |
| Content | Coherent, structured, deliverable? | A topic with no shape | An outline with minutes and a clear arc |
| Originality | New idea, angle or data? | The talk this event ran last year | A failure nobody else can describe |
| Relevance | Right event, track and moment? | Generic, could go anywhere | Answers a question this community is arguing about now |
| Speaker | Right person, evidenced? | "I'm passionate about this" | A recording plus the production numbers |
The four axes are what published committee criteria converge on; the 1-5 anchors behind them are this skill's own. See [./references/reviewer-rubric.md](./references/reviewer-rubric.md) for the anchors and the pre-submit checklist.
## Pass threshold
This bar is set by this skill, not by any committee - no conference publishes a numeric pass mark for its reviewers. It is a working baseline, useful because it forces a rewrite where reviewers most often disengage. Do not submit until all six hold; iterate on the failing item.
1. No axis in Step 9 scores below 3, and Content and Originality are at least 4.
2. The abstract contains at least one specific number, system or scale the user can source.
3. Every takeaway starts with an action verb and fits the slot length.
4. Every field is inside its character cap, counted rather than estimated.
5. The reviewer-only fields say something the abstract does not.
6. A reader who knows nothing about the user can tell why this speaker gives this talk.
The hard rules in Step 8 are a different kind of constraint: submission caps, pitch bans, AI policies and panel rules are published by the events themselves. When the user pushes back on a score, tell them which kind they are arguing with - a self-set threshold is negotiable, a published cap is not.
## Step 10 - After the verdict
- **Accepted:** hand over to samber/developer-relations-skills@tech-talk-outline, and keep the promises the abstract made - attendees quote it back.
- **Rejected:** request feedback, then retarget. A proposal is reusable material, not a spent ticket: change the track, the framing or the event, and resubmit within the season while the material is fresh.
- **No response:** treat the deadline plus the published notification date as final and move the proposal on.
## Event type and audience
Two axes change the copy, both worth naming for the user instead of leaving implicit.
- **Community-run vs vendor-run events.** Community and foundation events are vendor-neutral: the product appears only as the setting of the story, competitors get named fairly, and open-source projects are listed with links. A vendor's own conference inverts the rule - product depth is the point, and the proposal competes on the customer outcome and the specificity of the implementation instead. A proposal written for one and submitted to the other reads as tone-deaf in both directions.
- **B2B vs self-serve audiences.** For a B2B subject, part of the room is evaluating on someone else's behalf, so the abstract should name the organisational cost (migration effort, operational burden, what the team stopped doing) and stay inside numbers the company already publishes. For individual, self-serve adoption, the attendee decides alone: name the free path, the time to first result, and the limits honestly.
Everything else in this skill - angle, title mechanics, abstract shape, takeaway verbs, credibility - works identically for both.
## Measurement
One proposal to one event is a coin flip. Large events run several reviewers per proposal, then a chair ranking, then a balance pass on topic spread, speaker diversity and first-time speakers - so a strong proposal can lose for reasons the author cannot influence.
Do not quote an acceptance rate at the user: neither the PyCon US nor the KubeCon CFP pages publish submission or acceptance counts, and the "about one in ten" figure that circulates has no primary source. Judge the practice, not the single attempt.
| Signal | What it tells you |
| ----------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| Acceptance rate across a season of submissions | The only honest quality signal, and only over 8-10 submissions - a working sample size this skill sets, not a published one |
| Which events accept vs reject the same proposal | Fit, not quality - retarget rather than rewrite |
| Written reviewer feedback, where offered | The highest-value input available; ask for it after every rejection |
| Waitlist or "strong but no room" notes | The proposal worked; resubmit it elsewhere unchanged |
| Acceptance in lightning vs main track | Format strategy, not idea strength |
Track submissions in one file with event, format, angle, verdict and any feedback. The next CFP season starts from that file.
Tell the user, out loud, what speakers who get selected repeatedly do.
- Nina Zakharenko: "Don't be afraid of rejection. Submit as many proposals as you can. Always ask for feedback on rejected talks."
- Budget more effort than feels reasonable: swyx spent a month on the CFP for his first conference talk.
- For a first proposal, suggest a meetup run before the conference submission. Alaina Kafkes credits hers with validating the talk's narrowed scope, and the pattern recurs across practitioner accounts.
## Failure modes
| Failure | What it looks like | Fix |
| ------------------------ | ------------------------------------------------------- | ----------------------------------------------------------- |
| Pitch in disguise | Product name in the title or in the first sentence | Rewrite around the problem; the product becomes the setting |
| Book-sized scope | "We'll cover REST, GraphQL and gRPC, and how to choose" | One angle, or ask for the longer format |
| Interchangeable title | Could head fifty other talks | Add the system, the number, or the tension |
| Speaker-centric abstract | "I'll walk you through our journey" | Rewrite every sentence from the attendee's side |
| Understand-verbs | "Understand how observability fits your stack" | Replace with an action the attendee performs |
| Copy-paste fields | Notes to reviewers duplicates the abstract | Argue the case that does not belong in published copy |
| Cap breach | Abstract 1,800 characters against a 1,300 cap | Count after every edit; cut hedges first |
| Wrong track | Submitted to the track with the nicest name | Match the track description, not the vibe |
| Unverifiable claim | "Massive performance gains" | A number the user can source, or cut the claim |
| Model prose | Even cadence, no specifics, no voice | Humanizer pass plus the user's own rewrite |
## References
- samber/developer-relations-skills@devrel-career for speaking as a career signal.