Devrel Content

DevRel Content

When to Use

Use this skill when you need when the user wants to create technical content for developers including blog posts, tutorials, and documentation. Trigger phrases include "write a blog post," "technical article," "developer content," "tutorial," "devrel content," "dev blog," "technical writing," or "content for...

This skill helps you create technical content that developers actually read: blog posts, tutorials, documentation, and thought leadership pieces that build trust and drive adoption.

Before You Start

Load your audience context first. Read .agents/developer-audience-context.md to understand:

• Who you're writing for (role, seniority, tech stack)
• Their pain points (what problems resonate)
• Verbatim language (how they describe things)
• Voice & tone (how formal/technical to be)

If the context file doesn't exist, run the developer-audience-context skill first.

The DevRel Content Framework

Phase 1: Research & Validation

Before writing anything, validate the topic is worth writing about.

Red flags — Don't write if:

• You're the only one who cares about this topic
• 10 identical articles already exist
• The topic is too broad ("Introduction to JavaScript")
• The topic is too narrow (no search volume, no community interest)

Phase 2: Content Type Selection

Choose the right format for your goal:

Phase 3: Outline Structure

Use this outline template:

# [Title that promises specific value]

## Hook (2-3 sentences)
- State the problem or opportunity
- Establish credibility ("We migrated 10,000 repos...")
- Promise what the reader will learn

## Context (optional)
- Brief background if needed
- Link to prerequisites

## The Meat
### Section 1: [First major concept]
- Explanation
- Code example
- Common pitfall

### Section 2: [Second major concept]
- Explanation
- Code example
- Real-world application

### Section 3: [Third major concept]
- Explanation
- Code example
- Advanced tip

## Putting It Together
- Complete example
- Working code

## What's Next
- Links to deeper content
- Call to action (try the product, join Discord, etc.)

Writing Code Examples

Code is the content. Get it right.

The Copy-Paste Test

Every code example must:

Code Example Structure

First, install the dependencies:

\`\`\`bash
npm install your-library axios
\`\`\`

Now create a file called `fetch-data.js`:

\`\`\`javascript
// fetch-data.js
import { Client } from 'your-library';
import axios from 'axios';

const client = new Client({
  apiKey: process.env.YOUR_API_KEY // Use environment variables
});

async function fetchUserData(userId) {
  try {
    const user = await client.users.get(userId);
    console.log(`Fetched user: ${user.name}`);
    return user;
  } catch (error) {
    console.error(`Failed to fetch user: ${error.message}`);
    throw error;
  }
}

// Example usage
fetchUserData('user_123')
  .then(user => console.log(user))
  .catch(err => process.exit(1));
\`\`\`

Run it:

\`\`\`bash
YOUR_API_KEY=sk_test_xxx node fetch-data.js
\`\`\`

Expected output:

\`\`\`
Fetched user: Jane Developer
{ id: 'user_123', name: 'Jane Developer', email: 'jane@example.dev' }
\`\`\`

Language-Specific Conventions

Technical Accuracy Checklist

Run through before publishing:

SEO for Developer Content

Developers use Google differently than consumers.

Developer Search Patterns

Technical SEO Checklist

Example Optimized Title

Content Quality Signals

What separates great devrel content from mediocre:

Do This

• Show, don't tell — Code over prose
• Address the "why" — Not just how to do it, but when and why
• Acknowledge tradeoffs — Nothing is perfect; developers respect honesty
• Link to sources — Official docs, RFCs, related articles
• Include dates — "Updated March 2024" or version numbers
• Progressive disclosure — Start simple, add complexity
• Real examples — Production scenarios, not just hello world

Don't Do This

• Wall of text — Break up with code, headers, bullets
• Marketing speak — "Best-in-class," "seamless," "revolutionary"
• Assuming knowledge — Define acronyms, link to prerequisites
• Outdated content — Nothing worse than a 2019 tutorial with deprecated APIs
• Buried lede — Put the answer first, explanation second
• No code — Developers came for code, not prose

Content Templates

Blog Post Template

# [Specific, keyword-rich title]

[2-3 sentence hook: problem + promise]

## The Problem

[1 paragraph explaining the pain point]

## The Solution

[Brief explanation of your approach]

### Step 1: [Action]

[Explanation]

\`\`\`language
// Code
\`\`\`

### Step 2: [Action]

[Explanation]

\`\`\`language
// Code
\`\`\`

### Step 3: [Action]

[Explanation]

\`\`\`language
// Code
\`\`\`

## Complete Example

\`\`\`language
// Full working code
\`\`\`

## Troubleshooting

### [Common Error 1]
[Solution]

### [Common Error 2]
[Solution]

## What's Next

- [Link to deeper dive]
- [Link to related tutorial]
- [CTA: Try it yourself]

Comparison Post Template

# [Tool A] vs [Tool B]: [Specific Use Case] ([Year])

[1 paragraph: Who this comparison is for and what you'll learn]

## Quick Comparison

| Feature | Tool A | Tool B |
|---------|--------|--------|
| [Feature 1] | | |
| [Feature 2] | | |
| [Feature 3] | | |

## When to Choose [Tool A]

- [Scenario 1]
- [Scenario 2]
- [Scenario 3]

## When to Choose [Tool B]

- [Scenario 1]
- [Scenario 2]
- [Scenario 3]

## Deep Dive: [Specific Aspect]

### Tool A Approach
[Explanation + code]

### Tool B Approach
[Explanation + code]

## Our Recommendation

[Specific guidance based on use case]

Measuring Content Success

Metrics to Track

Content → Conversion Path

Track the journey:

1. Search/social → Blog post
2. Blog post → Docs / quickstart
3. Docs → Sign up / install
4. Sign up → Activation (first success)

Tools

Related Skills

• developer-audience-context — Foundation for knowing your readers
• technical-tutorials — Deep dive into step-by-step content
• developer-newsletter — Distributing content via email
• developer-seo — Technical SEO optimization
• hacker-news-strategy — Sharing content on HN effectively

Limitations

• Use this skill only when the task clearly matches its upstream source and local project context.
• Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
• Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.