Use this skill when creating conference talks, live coding demos, technical blog posts, SDK quickstart examples, or community engagement strategies. Triggers on developer relations, DevRel, developer experience, tech evangelism, talk proposals, CFP submissions, demo scripts, tutorial writing, hackathon planning, community building, and any task involving advocating a product or API to a developer audience.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Use this skill when creating conference talks, live coding demos, technical blog posts, SDK quickstart examples, or community engagement strategies. Triggers on developer relations, DevRel, developer experience, tech evangelism, talk proposals, CFP submissions, demo scripts, tutorial writing, hackathon planning, community building, and any task involving advocating a product or API to a developer audience.
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
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.
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.
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.
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.
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
Stage
Goal
Formats
Awareness
Developers learn you exist
Conference talks, social posts, podcasts
Evaluation
Developers try your tool
Quickstarts, blog tutorials, sandbox environments
Adoption
Developers ship with your tool
SDK examples, API guides, Stack Overflow answers
Retention
Developers stay and grow
Community channels, changelog updates, migration guides
Advocacy
Developers recommend you
Champion programs, guest blog invitations, co-speaking
Measuring DevRel impact
DevRel metrics fall into three tiers. Track all three but report the tier that
matches your stakeholder's concern.
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:
Setup (30 seconds) - Show the starting state. "Here's an empty project /
a broken feature / a slow endpoint."
Build (3-5 minutes) - Write the code live. Narrate what you type and why.
Never type silently for more than 10 seconds.
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:
Channel
Best for
Effort
Response time
GitHub Discussions
Long-form Q&A, RFCs
Medium
24 hours
Discord / Slack
Real-time help, casual chat
High
< 1 hour
Stack Overflow
SEO-visible answers
Low
48 hours
Twitter/X
Announcements, threads
Medium
Same day
Dev.to / Hashnode
Cross-posting blog content
Low
N/A
YouTube
Tutorials, demos, livestreams
High
N/A
Engagement rules:
Respond to every first-time poster within 24 hours
Never answer with just a docs link; include the relevant snippet inline
Celebrate community contributions publicly (PRs, blog posts, talks)
Create "good first issue" labels on your SDK repos
Run a monthly community call or AMA
Track community health: response time, unanswered questions, active contributors
6. Plan a developer workshop or hackathon
Workshop structure (90-120 minutes):
[0:00-0:10] Introduction + environment check (everyone has X installed)
[0:10-0:25] Concept overview (slides, max 10 slides)
[0:25-0:70] Guided hands-on (step-by-step, instructor-led)
[0:70-0:85] Free exploration (attendees extend the project)
[0:85-0:90] Wrap-up + resources + feedback form
Hackathon planning checklist:
Define clear judging criteria before the event (not after)
Provide starter templates / boilerplate repos
Have mentors available during the entire hacking period
Set a realistic scope - 24-hour hackathons need APIs that work in < 5 minutes
Collect project submissions via GitHub repos, not slide decks
7. Measure and report DevRel impact
Monthly report template:
## DevRel Monthly Report - [Month Year]
### Content produced
- Talks: [N] delivered, [N] accepted/upcoming
- Blog posts: [N] published, [total views], [avg time on page]
- SDK updates: [versions released], [breaking changes]
### Community health
- New members: [N] ([platform])
- Questions answered: [N] / [N] total (response rate: [X]%)
- Median first-response time: [N] hours
- Community contributions: [N] PRs merged from external contributors
### Business impact
- API signups from DevRel-attributed sources: [N]
- Time-to-first-API-call (median): [N] minutes
- SDK downloads: [N] (month-over-month: [+/- X]%)
### Learnings
- Top 3 developer pain points heard this month
- Feature requests relayed to product team
Anti-patterns / common mistakes
Mistake
Why it's wrong
What to do instead
Demo that requires live internet
Wi-Fi fails at every conference
Pre-cache responses or use a local mock server
Blog post with outdated SDK version
Broken code destroys trust instantly
Pin versions and set a calendar reminder to update quarterly
Measuring only vanity metrics (stars, likes)
Leadership needs business impact
Always pair reach metrics with at least one business metric
Talking at developers instead of with them
One-way broadcast kills community
Ask questions, run polls, respond to comments, co-create content
Skipping error handling in examples
Developers copy-paste and hit errors immediately
Always show try/catch or error callbacks in code samples
Over-polished demos that hide complexity
Developers feel tricked when real usage is harder
Show a real rough edge, then show how to handle it
Gotchas
Demo Wi-Fi always fails - cache everything - Conference venue networks are unreliable. Any demo that makes a live HTTP call during the talk risks dying on stage. Pre-record a backup video of the demo working, use localhost or a local mock server, and cache all API responses before walking on stage.
SDK code samples without pinned versions break silently - npm install acme-sdk installs the latest version, which may have different method signatures than your tutorial shows. Always pin with exact versions (acme-sdk@2.3.1) and set a quarterly calendar reminder to update samples.
A/B testing advocacy content with vanity metrics gives false signal - GitHub stars and YouTube views are activity metrics, not impact metrics. A post can get 10,000 views but generate zero API signups. Always instrument content with UTM parameters that tie to your business conversion event.
Community channels without SLA commitments lose trust fast - Opening a Discord or forum and then taking 72+ hours to respond to first-time posters damages the community more than having no channel. Only open channels you can staff with a sub-24-hour first-response commitment.
Live-coding demos typed too fast lose the audience - Narrating your keystrokes is not optional - silence while typing causes the audience to disengage within 10 seconds. Practice narrating every step aloud: "I'm setting the API key as an environment variable because we never hard-code credentials."
References
For detailed guidance on specific sub-domains, read the relevant file from the
references/ folder:
references/talk-frameworks.md - Deep dive on talk structures, storytelling
techniques, and slide design principles for technical audiences
references/content-strategy.md - Editorial calendars, SEO for developer
content, cross-posting workflows, and content repurposing strategies
Only load a references file if the current task requires it - they are long and
will consume context.
Companion check
On first activation of this skill in a conversation: check which companion skills are installed by running ls ~/.claude/skills/ ~/.agent/skills/ ~/.agents/skills/ .claude/skills/ .agent/skills/ .agents/skills/ 2>/dev/null. Compare the results against the recommended_skills field in this file's frontmatter. For any that are missing, mention them once and offer to install:
