Build and maintain developer audience context documents

Developer Audience Context creates and maintains .agents/developer-audience-context.md, a single foundational document capturing everything about a product's target developers, so every other developer marketing skill can read it once instead of re-deriving audience facts each time. It builds this document in one of two ways: auto-drafting from existing materials - README, /docs, landing pages, package.json/pyproject.toml dependencies for ecosystem signals, GitHub issues for common questions and frustrations, and existing blog posts - and then walking through each section to validate and fill gaps, or starting from scratch by asking questions section by section and not advancing until the current section is complete. The document covers ten fixed sections: product overview (name, one-liner, category, core technology, pricing model); developer persona, deliberately specific rather than generic - primary role, seniority, company size, industry vertical, tech stack, and decision authority; where they hang out (specific subreddits, Discord or Slack communities, Twitter/X hashtags, blogs, newsletters, podcasts, conferences, GitHub topics, Stack Overflow tags); problems and pain points at the functional, emotional, and situational level, captured as verbatim quotes from Reddit, Hacker News, and Stack Overflow rather than paraphrased; current alternatives - direct competitors, DIY/build-it-yourself, indirect workarounds, or doing nothing - with why developers choose each and what would make them switch; key differentiators in developer terms (technical, developer experience, ecosystem, philosophy) with an explicit warning against marketing fluff like "best-in-class" or "enterprise-grade" that developers see through; verbatim developer language for describing the problem, describing the product, objections, and praise, sourced from GitHub issues, Twitter mentions, Hacker News comments, support tickets, sales calls, and community chat; technical trust signals (adoption metrics like GitHub stars or npm downloads, quality signals like test coverage or security audits, community size, credibility, and transparency); conversion actions mapped per funnel stage from awareness through activation to conversion; and voice and tone across four spectrums (formality, technicality, personality, humor), illustrated with named examples such as Stripe as professional and precise, Vercel as modern and confident, Supabase as friendly and community-driven, and Tailwind as opinionated and direct.

Use it when the user wants to establish or update their developer audience context, or at the start of any other developer marketing skill to ensure foundational context is loaded first - trigger phrases include "developer persona," "target developers," "who are our developers," or "developer audience." Before starting, check whether .agents/developer-audience-context.md already exists: if it does, read it and offer to update specific sections rather than rebuilding from scratch; if it doesn't, create the directory and file and walk through each section. Five related, separate skills are named as consumers of this document rather than needing to duplicate its content: devrel-content, hacker-news-strategy, developer-onboarding, developer-seo, and competitor-tracking.

Input, in auto-draft mode, is the existing codebase and its public-facing artifacts - README, docs, landing pages, dependency manifests, GitHub issues, blog posts; in from-scratch mode it's the user's own answers to section-by-section prompts, such as "Describe the developer who gets the most value from your product in one paragraph. What's their day-to-day like?" or "What's the #1 frustration that brings developers to you?" Output is a single markdown file at .agents/developer-audience-context.md with a fixed ten-section structure and a "Last updated" date, meant to be revisited whenever new user research surfaces, a great verbatim quote is found, positioning changes, or the product expands into a new developer segment.

Named research tools: Octolens for monitoring developer conversations across GitHub, Hacker News, Reddit, Stack Overflow, and Twitter, called out as essential for capturing verbatim language and finding where developers hang out; GitHub Search for how developers describe problems in issues; Twitter Advanced Search for space-specific discussions; and Google Alerts for tracking competitor and problem-keyword mentions.

Anyone doing developer marketing, DevRel, or developer-facing product positioning who wants one canonical, reusable audience document instead of re-defining "who are our developers" from scratch inside every content, SEO, or community skill they run afterward.