KubeCon CFP Submission Writer

<!-- justify: CF-side-effect Edit/Write fix detected issues in SKILL.md with user approval -->

KubeCon CFP Submission Writer

Craft a high-quality KubeCon CFP submission using data-driven insights from 1,100+ accepted talks and official reviewer criteria.

Arguments

Parse from $ARGUMENTS:

• Topic/idea: Required — rough talk concept (e.g., "API gateway migration to Gateway API at scale")
• --track: Optional — target track (AI, Security, Platform, Observability, Operations, Connectivity, etc.)
• --format: Optional — session (30min, default), lightning (5min), tutorial (75min), panel (30min)
• --review: Optional — review/improve an existing CFP draft instead of writing from scratch

Workflow

Phase 1: Load Knowledge Base

Read reference files before starting:

Read: references/cfp-criteria.md — scoring dimensions, character limits, format rules
Read: references/talk-patterns.md — title patterns, topic trends, acceptance data

Phase 2: Topic Assessment

Evaluate the user's topic idea against acceptance data:

1. Track fit — if --track was provided, validate it matches the topic; otherwise recommend the best track
2. Trend alignment — is this a hot/growing, steady, or declining topic?
3. Saturation check — how many similar talks were accepted recently? High saturation = need sharper angle
4. Novelty assessment — what's the unique angle vs existing talks?
5. End-user signal — does this include production experience with real metrics?

Output a brief assessment with recommended track, competitiveness estimate, differentiation angles, and similar accepted talk titles.

Phase 3: Interactive Refinement

Use AskUserQuestion to gather concrete details:

1. Production story — specific company, scale, metrics, timeline
2. What went wrong — failures/challenges are more compelling than successes
3. Takeaway — what will attendees do differently after this talk?
4. Unique angle — why hasn't this been presented before?
5. Supplemental materials — previous talks, blog posts, GitHub repos, video recordings

Wait for concrete answers before proceeding because vague submissions get rejected.

Phase 4: Craft Title (75 chars max)

Generate 5 title options using proven patterns from references/talk-patterns.md. Re-read the title patterns section before generating.

Rules: title case, under 75 characters (hard limit), specific over generic, include scale/numbers when possible, no vendor/product names unless open-source project.

Present options ranked by likely reviewer impact. Let user pick or iterate via AskUserQuestion.

<example> Topic: "We migrated our API gateways from Kong to Gateway API across 200 microservices" Track: Connectivity

Title options:

1. "Migrating 200 Microservices to Gateway API Without Downtime" (55 chars)
2. "Gateway API at Scale: Lessons from Replacing Our API Gateway" (60 chars)
3. "From Vendor Lock-in to Gateway API: A 200-Service Journey" (57 chars)
4. "Zero-Downtime Gateway Migration: What Nobody Tells You" (55 chars)
5. "200 Services, 1 Gateway API: Our Migration Playbook" (52 chars) </example>

Adapt title style to --format: lightning talks need punchier/shorter titles, tutorials should signal hands-on content.

Phase 5: Write Abstract (1,300 chars max)

Structure: Hook → Promise → Payoff

• 1-2 sentences: Problem/challenge that hooks the reader
• 2-3 sentences: What this talk covers, the journey/approach
• 1-2 sentences: Concrete takeaways — "Attendees will learn..."

Rules: third person ("The speaker will..." not "I will..."), complete sentences (gets published on the schedule), specific numbers and metrics, no marketing/sales language, no jargon without context, first sentence must hook — reviewers read 100-200 proposals.

Show character count after writing. Must be ≤1,300.

<example> Input: Gateway API migration, 200 services, zero downtime, 6-month timeline

Abstract (847 chars): "Managing API traffic across 200 microservices through a proprietary gateway created vendor lock-in, limited extensibility, and cost $2M annually in licensing. This talk presents a six-month migration to Kubernetes Gateway API that achieved zero downtime while serving 50K requests per second. The speaker will walk through the three-phase migration strategy: shadow traffic validation, canary rollout per service tier, and automated rollback triggers that caught 12 configuration errors before they reached production. Attendees will learn a concrete migration playbook applicable to any gateway transition, specific pitfalls around HTTPRoute weight distribution at scale, and how to build confidence metrics that let teams migrate without fear." Character count: 847/1,300 </example>

Phase 6: Write Benefits to the Ecosystem (1,000-1,500 chars)

This is a separate section visible only to reviewers — not a copy of the abstract.

Cover: who benefits (specific personas), how this advances the ecosystem (open-source contributions, shared learnings), why now (timeliness), what gap this fills in current conference content.

Show character count after writing. Must be 1,000-1,500.

Phase 7: Supplemental Materials Guidance

Help the user identify and format supplemental materials: previous talk recordings (strongest signal), blog posts, GitHub repos, LinkedIn profile, published articles.

If user has no materials, suggest creating a blog post or recording a practice talk before submitting.

Phase 8: Review Mode (--review flag or final pass)

Score the submission against the 4 official criteria from references/cfp-criteria.md (1-5 scale): Content, Originality, Relevance, Speaker(s).

Run the pre-submit checklist from references/cfp-criteria.md and flag issues.

<example> Input: --review on a draft titled "Introduction to Service Mesh"

Review output:

• Content: 2/5 — generic topic, no production data or specific metrics
• Originality: 1/5 — service mesh intros presented at 4+ recent KubeCon events
• Relevance: 3/5 — still relevant but saturated
• Speaker(s): N/A — no supplemental materials provided

Flags: title too generic (fails "scroll past" test), no end-user signal, steady/declining topic needs sharp angle. Recommend pivoting to a specific migration story or failure case. </example>

Phase 9: Competitive Analysis (optional)

If user wants extra insight, spawn a research agent to search for similar KubeCon talks, identify how the angle differs, and find gaps in existing coverage.

Phase 10: Save Output

Read references/output-template.md for the submission format. Save to ${XDG_DATA_HOME:-$HOME/.local/share}/sai/kubecon-cfp/submissions/[title-slugified].md.

Scope

Not designed for non-CNCF conferences (DevOpsDays, QCon, re:Invent). The acceptance data, scoring criteria, and track structure are KubeCon/CloudNativeCon-specific.

Error Handling

• Vague topic: Push back hard — ask for specifics, production context, real numbers
• Wrong track: Suggest correct track with reasoning
• Over character limit: Tighten ruthlessly — cut adjectives, merge sentences, remove hedging
• No unique angle: Research what's been presented, find the gap together
• No supplemental materials: Suggest creating a blog post or practice recording

Quality Standards

• Every submission must have concrete production metrics or technical depth
• No generic "best practices" or "introduction to X" proposals (unless Cloud Native Novice track)
• Titles must be memorable — if you'd scroll past it in a schedule, rewrite it
• Abstract first sentence must make a reviewer want to read sentence two

Example Invocations

# Basic topic
/kubecon-cfp "API gateway migration to Gateway API at scale"

# With track and format
/kubecon-cfp "eBPF-based network policies" --track Security --format lightning

# Review an existing draft
/kubecon-cfp --review

# Tutorial format
/kubecon-cfp "hands-on Cilium service mesh" --track Connectivity --format tutorial