agentsclimarketplace

Developer audience context

Skill ranbot-ai/awesome-skills/skills/developer-audience-context

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 includFrom its SKILL.md

Install
npx -y skills add ranbot-ai/awesome-skills --skill developer-audience-context

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 6 stars6 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.4 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it

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:

  1. README.md — Product description, features, getting started
  2. Documentation/docs, API reference, tutorials
  3. Landing pagesindex.html, marketing copy
  4. package.json / pyproject.toml — Dependencies reveal ecosystem
  5. GitHub Issues — Common questions, frustrations, use cases
  6. 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

FieldWhat to capture
Product nameOfficial name and any aliases
One-liner"We help [developers] do [X] without [Y]"
CategoryAPI, SDK, CLI, SaaS, open source library, infrastructure
Core technologyLanguages, frameworks, platforms supported
Pricing modelFree/open source, freemium, usage-based, seat-based

2. Developer Persona

Not "developers" generically — get specific:

FieldWhat to capture
Primary roleBackend, frontend, full-stack, DevOps, data, ML, mobile
SeniorityJunior, mid, senior, staff, lead, architect
Company sizeSolo, startup, scale-up, enterprise
Industry verticalsFintech, healthtech, e-commerce, gaming, B2B SaaS
Tech stackLanguages, frameworks, cloud providers they use
Decision authorityIndividual 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:

ChannelSpecifics to capture
CommunitiesSpecific subreddits, Discord servers, Slack groups
SocialTwitter/X hashtags, LinkedIn groups
ContentBlogs they read, newsletters they subscribe to, podcasts
EventsConferences, meetups, hackathons
CodeGitHub 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:

LevelWhat to capture
Functional"I can't do X" / "X takes too long" / "X is error-prone"
EmotionalFrustration, anxiety, embarrassment, fear
SituationalWhen 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 typeExamples
Direct competitorsTools that solve the same problem
DIY / build it yourselfCustom scripts, internal tools
Indirect solutionsWorkarounds, manual processes
Do nothingLive 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 typeExample
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:

CategoryExamples

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Keep looking

Skills are one crate of 326,059. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.