When this skill is activated, always start your first response with the 🧢 emoji.

Developer Advocacy

Developer advocacy is the practice of representing developers inside a company and representing the company's technology to the developer community. It sits at the intersection of engineering, marketing, and education - requiring the ability to write working code, explain it clearly, and build authentic relationships with technical audiences. This skill covers the five core pillars: conference talks, live demos, technical blog posts, SDK examples, and community engagement.

When to use this skill

Trigger this skill when the user:

• Needs to write or review a conference talk proposal (CFP submission)
• Wants to plan or script a live coding demo
• Asks about writing a technical blog post or tutorial for developers
• Needs to create SDK quickstart examples or code samples
• Wants to build a community engagement strategy (forums, Discord, GitHub)
• Asks about developer experience (DX) improvements for an API or SDK
• Needs to plan a hackathon, workshop, or developer event
• Wants to measure DevRel impact with metrics and KPIs

Do NOT trigger this skill for:

• Pure marketing copy aimed at non-technical buyers - use a marketing or copywriting skill
• Internal engineering documentation with no external audience - use a technical writing skill

Key principles

1. Code is the message - Every piece of developer advocacy content must contain working, copy-pasteable code. Developers trust what they can run. A blog post without a working example is a press release.

2. Empathy over evangelism - Advocate for the developer's needs, not just the product's features. Acknowledge pain points honestly. Developers detect sales pitches instantly and disengage.

3. Show, don't tell - A 90-second demo that works is worth more than a 30-minute slide deck. Prioritize live, interactive formats. When slides are necessary, use them to frame a problem - then solve it with code.

4. Meet developers where they are - Use the platforms, languages, and tools your audience already uses. Don't ask a Python shop to read TypeScript examples. Don't post docs if your community lives on Discord.

5. Compound over campaign - A single blog post fades; a series builds authority. A one-off talk is forgotten; a consistent conference presence builds reputation. Invest in content that compounds: evergreen tutorials, maintained SDKs, active community channels.

Core concepts

The DevRel flywheel

Developer advocacy works as a feedback loop: Build (SDKs, examples, tools) -> Educate (talks, blogs, tutorials) -> Engage (community, support, events) -> Listen (feedback, pain points, feature requests) -> feed learnings back into Build. Breaking any link in this chain reduces the entire function's effectiveness.

Content formats by funnel stage

Measuring DevRel impact

DevRel metrics fall into three tiers. Track all three but report the tier that matches your stakeholder's concern.

• Activity metrics (leading): talks given, posts published, PRs to SDK repos
• Reach metrics (middle): unique visitors, video views, GitHub stars, community members
• Business metrics (lagging): API signups from DevRel-attributed sources, SDK adoption rate, time-to-first-API-call

Common tasks

1. Write a conference talk proposal (CFP)

A strong CFP answers three questions: what will the audience learn, why should they care, and why are you the right person to teach it.

CFP template:

Title: [Action verb] + [specific outcome] + [constraint/context]
  Example: "Ship production WebSockets in 15 minutes with Durable Objects"

Abstract (max 200 words):
  Paragraph 1 - The problem (what pain does the audience feel?)
  Paragraph 2 - The approach (what will you show/build?)
  Paragraph 3 - The takeaway (what do they leave with?)

Outline:
  - [0:00-3:00]  Problem framing - why this matters now
  - [3:00-15:00] Live demo / core content (biggest block)
  - [15:00-22:00] Deep dive on the non-obvious part
  - [22:00-25:00] Recap + next steps + resources

Target audience: [Beginner | Intermediate | Advanced]
Prerequisites: [What should attendees already know?]
Format: [Talk | Workshop | Lightning talk]

Avoid vague titles like "Introduction to X" or "X in 2026". Reviewers see hundreds of those. Lead with the outcome the audience gets.

2. Script a live coding demo

Live demos fail when they are too ambitious. Scope ruthlessly.

The 3-act demo structure:

1. Setup (30 seconds) - Show the starting state. "Here's an empty project / a broken feature / a slow endpoint."
2. Build (3-5 minutes) - Write the code live. Narrate what you type and why. Never type silently for more than 10 seconds.
3. Payoff (30 seconds) - Run it. Show the working result. Celebrate briefly.

Demo safety checklist:

• Pre-install all dependencies; never run npm install live
• Have a git branch with the finished state as a fallback
• Use large font (24pt minimum in terminal, 20pt in editor)
• Disable notifications, Slack, email, system popups
• Test on the exact hardware/display you will present on
• Record a backup video of the demo running successfully
• Use environment variables, never paste API keys on screen

3. Write a technical blog post

Structure for developer blog posts:

1. Hook (2-3 sentences)      - State the problem. Make it personal.
2. Context (1 paragraph)     - Why this problem exists / why now
3. Solution overview          - One sentence: what you will build
4. Step-by-step walkthrough  - Numbered steps with code blocks
5. Complete example           - Full working code (copy-pasteable)
6. What's next               - Links to docs, repo, community

Writing rules:

• Lead with the problem, not the product
• Every code block must be runnable in isolation or clearly marked as a snippet
• Use second person ("you") not first person ("we")
• Keep paragraphs to 3-4 sentences maximum
• Include a "Prerequisites" section if the reader needs accounts, keys, or tools
• Add a TL;DR at the top for scanners

4. Create SDK quickstart examples

Quickstarts must get a developer from zero to a working API call in under 5 minutes. Anything longer and they leave.

Quickstart structure:

## Prerequisites
- Language runtime version (e.g., Node.js >= 18)
- API key (link to signup/dashboard)

## Install
<single install command>

## Authenticate
<2-3 lines showing how to set the API key>

## Make your first call
<5-15 lines of code that do something visible>

## Next steps
- [Link to full API reference]
- [Link to more examples]
- [Link to community/support]

Rules for code samples:

• Use the most common language for your audience first (JavaScript/Python)
• Show the import, setup, and call - never skip the import
• Use realistic values, not foo/bar - e.g., "acme-corp", "order_12345"
• Handle errors in examples; don't just show the happy path
• Pin SDK versions in install commands

5. Build a community engagement strategy

Channel selection framework: