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