Developer Docs Audience Research
Use this skill to understand who developer documentation is for before planning, writing, or reorganizing docs. It helps agents turn vague audiences into concrete users, goals, questions, journeys, and validation work.
This skill is derived from Jared Bhatti, Zachary Sarah Corleissen, Jen Lambourne, David Nunez, and Heidi Waterhouse's Docs for Developers: An Engineer's Field Guide to Technical Writing, especially Chapter 1, "Understanding your audience." It is expanded with paraphrased guidance from Christopher Gales and the Splunk Documentation Team's The Product Is Docs: Writing Technical Documentation in a Product Development Group, especially Chapter 3, "Audience," Chapter 9, "Learning Objectives," and Chapter 25, "Writing SaaS Documentation." Do not copy book prose into user outputs. Source: https://link.springer.com/book/10.1007/978-1-4842-7217-6
Quick Start
- Load
guidelines.md to choose the smallest useful reference set.
- Start from the user's doc artifact or product surface, not from a generic audience label.
- Identify user goals, learning objectives, business goals, user traits, questions, and missing knowledge.
- Use
workflows/map-doc-audience.md when the user needs a full audience brief.
- Mark assumptions and recommend validation through user conversations, support data, analytics, or a friction log.
Default Output
When researching an audience, return:
- Audience snapshot - primary and secondary users, roles, skill level, environment, and constraints.
- Goals - user goals and business goals that the docs must support.
- Learning objective - starting point, destination, and exit criteria when useful.
- User questions - setup, concept, task, API, troubleshooting, and decision questions.
- Research artifacts - audience definition, persona, user story, journey map, or friction log entries when useful.
- Assumptions and gaps - what is inferred versus verified.
- Validation plan - the next interviews, data sources, or product walk-throughs.
Contents
| Need |
Start Here |
| Understand audience concepts |
references/core/knowledge.md |
| Apply research rules |
references/core/knowledge.md |
| See concise examples |
references/core/knowledge.md |
| Produce an audience brief |
workflows/map-doc-audience.md |
| Define learning objectives |
workflows/define-learning-objectives.md |
| Route by task |
guidelines.md |
Core Posture
- Treat "developer" as too broad until narrowed by task, context, skill, and environment.
- Separate what users need from what internal teams want to say.
- Distinguish durable audience definitions from specific personas.
- Prefer evidence over assumptions, but preserve assumptions clearly when evidence is not available yet.
- Let audience findings and learning objectives shape content type, order, depth, examples, and success metrics.
Source: hashgraph-online/awesome-codex-plugins → plugins/LVTD-LLC/skills/skills/developer-docs-audience-research/SKILL.md
1---2name: developer-docs-audience-research3description: Research developer documentation audiences by mapping user goals, learning objectives, business goals, developer traits, user questions, personas, user stories, journey maps, and friction logs. Use when planning docs for APIs, SDKs, platforms, CLIs, developer tools, onboarding guides, SaaS docs, or support-heavy docs before writing or restructuring content.4---5
6
7# Developer Docs Audience Research
8
9Use this skill to understand who developer documentation is for before planning, writing, or reorganizing docs. It helps agents turn vague audiences into concrete users, goals, questions, journeys, and validation work.
10
11This skill is derived from Jared Bhatti, Zachary Sarah Corleissen, Jen Lambourne, David Nunez, and Heidi Waterhouse's *Docs for Developers: An Engineer's Field Guide to Technical Writing*, especially Chapter 1, "Understanding your audience." It is expanded with paraphrased guidance from Christopher Gales and the Splunk Documentation Team's *The Product Is Docs: Writing Technical Documentation in a Product Development Group*, especially Chapter 3, "Audience," Chapter 9, "Learning Objectives," and Chapter 25, "Writing SaaS Documentation." Do not copy book prose into user outputs. Source: https://link.springer.com/book/10.1007/978-1-4842-7217-6
12
13## Quick Start
14
151. Load `guidelines.md` to choose the smallest useful reference set.
162. Start from the user's doc artifact or product surface, not from a generic audience label.
173. Identify user goals, learning objectives, business goals, user traits, questions, and missing knowledge.
184. Use `workflows/map-doc-audience.md` when the user needs a full audience brief.
195. Mark assumptions and recommend validation through user conversations, support data, analytics, or a friction log.
20
21## Default Output
22
23When researching an audience, return:
24
251. **Audience snapshot** - primary and secondary users, roles, skill level, environment, and constraints.
262. **Goals** - user goals and business goals that the docs must support.
273. **Learning objective** - starting point, destination, and exit criteria when useful.
284. **User questions** - setup, concept, task, API, troubleshooting, and decision questions.
295. **Research artifacts** - audience definition, persona, user story, journey map, or friction log entries when useful.
306. **Assumptions and gaps** - what is inferred versus verified.
317. **Validation plan** - the next interviews, data sources, or product walk-throughs.
32
33## Contents
34
35| Need | Start Here |
36|------|------------|
37| Understand audience concepts | `references/core/knowledge.md` |
38| Apply research rules | `references/core/knowledge.md` |
39| See concise examples | `references/core/knowledge.md` |
40| Produce an audience brief | `workflows/map-doc-audience.md` |
41| Define learning objectives | `workflows/define-learning-objectives.md` |
42| Route by task | `guidelines.md` |
43
44## Core Posture
45
46- Treat "developer" as too broad until narrowed by task, context, skill, and environment.
47- Separate what users need from what internal teams want to say.
48- Distinguish durable audience definitions from specific personas.
49- Prefer evidence over assumptions, but preserve assumptions clearly when evidence is not available yet.
50- Let audience findings and learning objectives shape content type, order, depth, examples, and success metrics.
51
52---
53
54**Source:** [`hashgraph-online/awesome-codex-plugins`](https://github.com/hashgraph-online/awesome-codex-plugins) → `plugins/LVTD-LLC/skills/skills/developer-docs-audience-research/SKILL.md`
hashgraph-online