Developer Audience Context
When to Use
Use this skill when you need when the user wants to establish or update their developer audience context. Also use when starting any other developer marketing skill to ensure foundational context is loaded. Trigger phrases include "developer persona," "target developers," "who are our developers," "developer...
This skill helps you create and maintain .agents/developer-audience-context.md — a foundational document that captures everything about your target developers. All other developer marketing skills reference this document first, so you only define your audience once.
Before You Start
Check if .agents/developer-audience-context.md exists:
- If it exists: Read it and offer to update specific sections
- If it doesn't exist: Create the directory and file, then walk through each section
Two Ways to Build Context
Option 1: Auto-Draft from Codebase (Recommended)
Analyze existing materials to draft an initial version:
- README.md — Product description, features, getting started
- Documentation —
/docs, API reference, tutorials
- Landing pages —
index.html, marketing copy
- package.json / pyproject.toml — Dependencies reveal ecosystem
- GitHub Issues — Common questions, frustrations, use cases
- Existing blog posts — Technical content, tutorials
After drafting, walk through each section to validate and fill gaps.
Option 2: Start from Scratch
Ask questions section-by-section. Don't advance until the current section is complete.
The 10 Sections to Capture
1. Product Overview
| Field |
What to capture |
| Product name |
Official name and any aliases |
| One-liner |
"We help [developers] do [X] without [Y]" |
| Category |
API, SDK, CLI, SaaS, open source library, infrastructure |
| Core technology |
Languages, frameworks, platforms supported |
| Pricing model |
Free/open source, freemium, usage-based, seat-based |
2. Developer Persona
Not "developers" generically — get specific:
| Field |
What to capture |
| Primary role |
Backend, frontend, full-stack, DevOps, data, ML, mobile |
| Seniority |
Junior, mid, senior, staff, lead, architect |
| Company size |
Solo, startup, scale-up, enterprise |
| Industry verticals |
Fintech, healthtech, e-commerce, gaming, B2B SaaS |
| Tech stack |
Languages, frameworks, cloud providers they use |
| Decision authority |
Individual contributor, team lead, buyer, influencer |
Ask: "Describe the developer who gets the most value from your product in one paragraph. What's their day-to-day like?"
3. Where They Hang Out
Developers research before they buy. Know where:
| Channel |
Specifics to capture |
| Communities |
Specific subreddits, Discord servers, Slack groups |
| Social |
Twitter/X hashtags, LinkedIn groups |
| Content |
Blogs they read, newsletters they subscribe to, podcasts |
| Events |
Conferences, meetups, hackathons |
| Code |
GitHub topics, Stack Overflow tags |
Pro tip: Use social listening tools to monitor conversations across Hacker News, Reddit, Stack Overflow, GitHub, and Twitter. See where discussions about your problem space happen organically.
4. Problems & Pain Points
Capture the actual problems, not your solution's features:
| Level |
What to capture |
| Functional |
"I can't do X" / "X takes too long" / "X is error-prone" |
| Emotional |
Frustration, anxiety, embarrassment, fear |
| Situational |
When does the pain occur? What triggers the search? |
Ask: "What's the #1 frustration that brings developers to you?"
Research: Search Reddit, Hacker News, and Stack Overflow for complaints about your problem space. Capture verbatim quotes.
5. Current Alternatives
What are developers using today instead of you?
| Alternative type |
Examples |
| Direct competitors |
Tools that solve the same problem |
| DIY / build it yourself |
Custom scripts, internal tools |
| Indirect solutions |
Workarounds, manual processes |
| Do nothing |
Live with the pain |
For each alternative, capture:
- Why developers choose it
- What's frustrating about it
- What would make them switch
6. Key Differentiators
What makes you different — in developer terms:
| Differentiator type |
Example |
| Technical |
"10x faster," "No dependencies," "Type-safe" |
| DX (Developer Experience) |
"5-minute setup," "Great docs," "First-class CLI" |
| Ecosystem |
"Works with X," "Built for Y framework" |
| Philosophy |
"Open source," "Privacy-first," "Local-first" |
Warning: Avoid marketing fluff. Developers see through "best-in-class" and "enterprise-grade." Use specific, provable claims.
7. Verbatim Developer Language
Capture exact phrases developers use — not polished marketing copy:
| Category |
Examples |
| Describing the problem |
"This is such a pain," "I wish I could just..." |
| Describing your product |
How they explain it to others |
| Objections |
"But what about...", "I'm worried that..." |
| Praise |
Testimonials, tweets, GitHub comments |
Sources: GitHub issues, Twitter mentions, Hacker News comments, support tickets, sales calls, community Slack/Discord.
8. Technical Trust Signals
What proof points matter to developers:
| Signal type |
Examples |
| Adoption |
GitHub stars, npm downloads, Docker pulls |
| Quality |
Test coverage, security audits, uptime SLA |
| Community |
Contributors, Discord members, forum activity |
| Credibility |
Backed by X, used by Y, created by Z |
| Transparency |
Open source, public roadmap, changelog |
9. Conversion Actions
What does success look like at each stage?
| Stage |
Primary action |
Secondary actions |
| Awareness |
Star repo, follow on Twitter |
Read blog post, share content |
| Consideration |
Clone repo, read docs |
Watch demo, join Discord |
| Trial |
Sign up, install SDK |
Complete quickstart, make first API call |
| Activation |
Reach "Hello World" moment |
Integrate into real project |
| Conversion |
Upgrade to paid |
Add team members, expand usage |
10. Voice & Tone
How should you sound when talking to these developers?
| Dimension |
Spectrum |
| Formality |
Casual ← → Professional |
| Technicality |
Accessible ← → Deep technical |
| Personality |
Neutral ← → Opinionated |
| Humor |
Serious ← → Playful |
Examples:
- Stripe → Professional, precise, clean
- Vercel → Modern, confident, developer-first
- Supabase → Friendly, accessible, community-driven
- Tailwind → Opinionated, direct, practical
Output Format
Save to .agents/developer-audience-context.md with this structure:
# Developer Audience Context
Last updated: [DATE]
## Product Overview
[Section content]
## Developer Persona
[Section content]
## Where They Hang Out
[Section content]
## Problems & Pain Points
[Section content]
## Current Alternatives
[Section content]
## Key Differentiators
[Section content]
## Verbatim Developer Language
[Section content]
## Technical Trust Signals
[Section content]
## Conversion Actions
[Section content]
## Voice & Tone
[Section content]
Maintenance
Update this document when:
- You learn something new from user research
- You find great verbatim quotes
- Your positioning or differentiation changes
- You expand to new developer segments
Tools
| Tool |
Use case |
| Octolens |
Monitor developer conversations across GitHub, Hacker News, Reddit, Stack Overflow, Twitter. Essential for capturing verbatim language, finding pain points, and understanding where your developers hang out. |
| GitHub Search |
Find how developers describe problems in issues |
| Twitter Advanced Search |
Find discussions about your space |
| Google Alerts |
Track mentions of competitors and problem keywords |
Related Skills
After establishing context, these skills will reference it:
devrel-content — Writing content that resonateshacker-news-strategy — Engaging on HN authenticallydeveloper-onboarding — Optimizing time-to-valuedeveloper-seo — Targeting the right technical queriescompetitor-tracking — Understanding your competitive landscape
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.
1---
2name: developer-audience-context
3description: "When the user wants to establish or update their developer audience context. Also use when starting any other developer marketing skill to ensure foundational context is loaded."
4risk: critical
5source: https://github.com/jonathimer/devmarketing-skills/tree/main/skills/developer-audience-context
6source_repo: jonathimer/devmarketing-skills
7source_type: community
8date_added: 2026-07-01
9license: MIT
10license_source: https://github.com/jonathimer/devmarketing-skills/blob/main/LICENSE
11---
12
13# Developer Audience Context
14## When to Use
15
16Use this skill when you need when the user wants to establish or update their developer audience context. Also use when starting any other developer marketing skill to ensure foundational context is loaded. Trigger phrases include "developer persona," "target developers," "who are our developers," "developer...
17
18
19This skill helps you create and maintain `.agents/developer-audience-context.md` — a foundational document that captures everything about your target developers. All other developer marketing skills reference this document first, so you only define your audience once.
20
21---
22
23## Before You Start
24
25Check if `.agents/developer-audience-context.md` exists:
26
27- **If it exists**: Read it and offer to update specific sections
28- **If it doesn't exist**: Create the directory and file, then walk through each section
29
30---
31
32## Two Ways to Build Context
33
34### Option 1: Auto-Draft from Codebase (Recommended)
35
36Analyze existing materials to draft an initial version:
37
381. **README.md** — Product description, features, getting started
392. **Documentation** — `/docs`, API reference, tutorials
403. **Landing pages** — `index.html`, marketing copy
414. **package.json / pyproject.toml** — Dependencies reveal ecosystem
425. **GitHub Issues** — Common questions, frustrations, use cases
436. **Existing blog posts** — Technical content, tutorials
44
45After drafting, walk through each section to validate and fill gaps.
46
47### Option 2: Start from Scratch
48
49Ask questions section-by-section. Don't advance until the current section is complete.
50
51---
52
53## The 10 Sections to Capture
54
55### 1. Product Overview
56
57| Field | What to capture |
58|-------|-----------------|
59| Product name | Official name and any aliases |
60| One-liner | "We help [developers] do [X] without [Y]" |
61| Category | API, SDK, CLI, SaaS, open source library, infrastructure |
62| Core technology | Languages, frameworks, platforms supported |
63| Pricing model | Free/open source, freemium, usage-based, seat-based |
64
65### 2. Developer Persona
66
67Not "developers" generically — get specific:
68
69| Field | What to capture |
70|-------|-----------------|
71| Primary role | Backend, frontend, full-stack, DevOps, data, ML, mobile |
72| Seniority | Junior, mid, senior, staff, lead, architect |
73| Company size | Solo, startup, scale-up, enterprise |
74| Industry verticals | Fintech, healthtech, e-commerce, gaming, B2B SaaS |
75| Tech stack | Languages, frameworks, cloud providers they use |
76| Decision authority | Individual contributor, team lead, buyer, influencer |
77
78**Ask**: "Describe the developer who gets the most value from your product in one paragraph. What's their day-to-day like?"
79
80### 3. Where They Hang Out
81
82Developers research before they buy. Know where:
83
84| Channel | Specifics to capture |
85|---------|---------------------|
86| Communities | Specific subreddits, Discord servers, Slack groups |
87| Social | Twitter/X hashtags, LinkedIn groups |
88| Content | Blogs they read, newsletters they subscribe to, podcasts |
89| Events | Conferences, meetups, hackathons |
90| Code | GitHub topics, Stack Overflow tags |
91
92**Pro tip**: Use social listening tools to monitor conversations across Hacker News, Reddit, Stack Overflow, GitHub, and Twitter. See where discussions about your problem space happen organically.
93
94### 4. Problems & Pain Points
95
96Capture the actual problems, not your solution's features:
97
98| Level | What to capture |
99|-------|-----------------|
100| Functional | "I can't do X" / "X takes too long" / "X is error-prone" |
101| Emotional | Frustration, anxiety, embarrassment, fear |
102| Situational | When does the pain occur? What triggers the search? |
103
104**Ask**: "What's the #1 frustration that brings developers to you?"
105
106**Research**: Search Reddit, Hacker News, and Stack Overflow for complaints about your problem space. Capture verbatim quotes.
107
108### 5. Current Alternatives
109
110What are developers using today instead of you?
111
112| Alternative type | Examples |
113|-----------------|----------|
114| Direct competitors | Tools that solve the same problem |
115| DIY / build it yourself | Custom scripts, internal tools |
116| Indirect solutions | Workarounds, manual processes |
117| Do nothing | Live with the pain |
118
119For each alternative, capture:
120- Why developers choose it
121- What's frustrating about it
122- What would make them switch
123
124### 6. Key Differentiators
125
126What makes you different — in developer terms:
127
128| Differentiator type | Example |
129|--------------------|---------|
130| Technical | "10x faster," "No dependencies," "Type-safe" |
131| DX (Developer Experience) | "5-minute setup," "Great docs," "First-class CLI" |
132| Ecosystem | "Works with X," "Built for Y framework" |
133| Philosophy | "Open source," "Privacy-first," "Local-first" |
134
135**Warning**: Avoid marketing fluff. Developers see through "best-in-class" and "enterprise-grade." Use specific, provable claims.
136
137### 7. Verbatim Developer Language
138
139Capture exact phrases developers use — not polished marketing copy:
140
141| Category | Examples |
142|----------|----------|
143| Describing the problem | "This is such a pain," "I wish I could just..." |
144| Describing your product | How they explain it to others |
145| Objections | "But what about...", "I'm worried that..." |
146| Praise | Testimonials, tweets, GitHub comments |
147
148**Sources**: GitHub issues, Twitter mentions, Hacker News comments, support tickets, sales calls, community Slack/Discord.
149
150### 8. Technical Trust Signals
151
152What proof points matter to developers:
153
154| Signal type | Examples |
155|-------------|----------|
156| Adoption | GitHub stars, npm downloads, Docker pulls |
157| Quality | Test coverage, security audits, uptime SLA |
158| Community | Contributors, Discord members, forum activity |
159| Credibility | Backed by X, used by Y, created by Z |
160| Transparency | Open source, public roadmap, changelog |
161
162### 9. Conversion Actions
163
164What does success look like at each stage?
165
166| Stage | Primary action | Secondary actions |
167|-------|---------------|-------------------|
168| Awareness | Star repo, follow on Twitter | Read blog post, share content |
169| Consideration | Clone repo, read docs | Watch demo, join Discord |
170| Trial | Sign up, install SDK | Complete quickstart, make first API call |
171| Activation | Reach "Hello World" moment | Integrate into real project |
172| Conversion | Upgrade to paid | Add team members, expand usage |
173
174### 10. Voice & Tone
175
176How should you sound when talking to these developers?
177
178| Dimension | Spectrum |
179|-----------|----------|
180| Formality | Casual ← → Professional |
181| Technicality | Accessible ← → Deep technical |
182| Personality | Neutral ← → Opinionated |
183| Humor | Serious ← → Playful |
184
185**Examples**:
186- Stripe → Professional, precise, clean
187- Vercel → Modern, confident, developer-first
188- Supabase → Friendly, accessible, community-driven
189- Tailwind → Opinionated, direct, practical
190
191---
192
193## Output Format
194
195Save to `.agents/developer-audience-context.md` with this structure:
196
197```markdown
198# Developer Audience Context
199
200Last updated: [DATE]
201
202## Product Overview
203[Section content]
204
205## Developer Persona
206[Section content]
207
208## Where They Hang Out
209[Section content]
210
211## Problems & Pain Points
212[Section content]
213
214## Current Alternatives
215[Section content]
216
217## Key Differentiators
218[Section content]
219
220## Verbatim Developer Language
221[Section content]
222
223## Technical Trust Signals
224[Section content]
225
226## Conversion Actions
227[Section content]
228
229## Voice & Tone
230[Section content]
231```
232
233---
234
235## Maintenance
236
237Update this document when:
238
239- You learn something new from user research
240- You find great verbatim quotes
241- Your positioning or differentiation changes
242- You expand to new developer segments
243
244---
245
246## Tools
247
248| Tool | Use case |
249|------|----------|
250| **[Octolens](https://octolens.com)** | Monitor developer conversations across GitHub, Hacker News, Reddit, Stack Overflow, Twitter. Essential for capturing verbatim language, finding pain points, and understanding where your developers hang out. |
251| **GitHub Search** | Find how developers describe problems in issues |
252| **Twitter Advanced Search** | Find discussions about your space |
253| **Google Alerts** | Track mentions of competitors and problem keywords |
254
255---
256
257## Related Skills
258
259After establishing context, these skills will reference it:
260
261- `devrel-content` — Writing content that resonates
262- `hacker-news-strategy` — Engaging on HN authentically
263- `developer-onboarding` — Optimizing time-to-value
264- `developer-seo` — Targeting the right technical queries
265- `competitor-tracking` — Understanding your competitive landscape
266
267## Limitations
268
269- Use this skill only when the task clearly matches its upstream source and local project context.
270- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
271- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.
jonathimer