Build and maintain developer audience context documents

Developer Audience Context creates and maintains .agents/developer-audience-context.md as a shared foundation for developer marketing work. It records who a product serves, what those developers are trying to accomplish, and how they describe their problems. The shared context informs marketing content, onboarding material, search strategy, or competitive analysis. The result is a persistent brief that can be reviewed and updated as evidence changes.

The workflow starts by checking whether the context document already exists. If it does, the instruction is to read it and offer specific updates. For a new document, the recommended approach drafts an initial version from repository material: the README, product documentation, API references, tutorials, landing copy, package manifests, issues, and existing articles. The user then validates each section and fills gaps. An alternative interview mode builds the brief section by section and waits until each is complete before advancing.

Use this skill when developer marketing repeatedly starts from an incomplete understanding of the audience, or when several downstream activities need the same product and persona assumptions. It is also useful when new community research, customer language, positioning, or audience segments should update an existing brief.

Do not treat an automatically drafted persona as established customer research. Use specific evidence and real complaints rather than converting product features into presumed pains. Technical and commercial claims need validation. The skill does not replace testing, security review, or approval for destructive or costly actions.

The document has ten substantive sections. Product Overview captures the name, category, technology, and pricing model. Developer Persona identifies roles, seniority, company context, stack, decision authority, and daily work. Where They Hang Out maps communities, social channels, publications, events, GitHub topics, and relevant question tags. Pain Points separates functional frustrations, emotional concerns, and situations that trigger a search for help.

Alternatives covers direct competitors, do-it-yourself approaches, indirect workarounds, and doing nothing, including reasons to choose or leave them. Differentiators records specific, provable advantages in technology, developer experience, ecosystem, or philosophy. Verbatim Language preserves actual problem descriptions, objections, and praise. Trust Signals collects adoption, quality, community, credibility, and transparency evidence. Conversion Journey maps awareness through consideration, trial, activation, and expansion. Voice & Tone sets formality, technical depth, personality, and humor.

The output is a Markdown file with a last-updated date and these sections. Research should retain actual quotations from issues, support, sales, and community discussions rather than invented customer language.

Suggested research tools include Octolens, GitHub Search, Twitter Advanced Search, and Google Alerts. Downstream uses include developer content, Hacker News strategy, onboarding, SEO, and competitor tracking. These references describe research and handoff options; they do not establish that credentials or external services are configured.

This is for teams preparing developer-facing marketing and onboarding who need a concrete, reviewable account of their audience before choosing messages or channels.