USP
Provides specialized, developer-centric marketing knowledge for AI agents, ensuring content and strategies resonate with technical audiences by avoiding generic marketing speak and focusing on transparency and technical accuracy.
Use cases
- 01Crafting a compelling Show HN post for a new CLI tool.
- 02Writing a quickstart guide for a Python SDK.
- 03Identifying developer frustrations with competitors on Reddit and Hacker News.
- 04Optimizing a developer signup flow to reduce friction.
- 05Developing a strategy for marketing an open-source project.
Detected files (8)
skills/developer-ads/SKILL.mdskillShow content (11750 bytes)
--- name: developer-ads description: | Paid advertising strategies for developer audiences on Carbon Ads, BuySellAds, Reddit, and developer newsletters. Covers which platforms work for developers, creating ad creative that doesn't feel like ads, targeting by technology stack, and measuring ad spend ROI. Use when asked about: - Developer advertising - Paid ads for developer tools - Carbon Ads strategy - Reddit advertising for developers - Newsletter sponsorships - Developer ad creative - Targeting developers with ads metadata: version: 1.0.0 --- # Developer Ads ## Overview Most advertising doesn't work for developers. They use ad blockers, distrust marketing, and share bad experiences widely. But targeted advertising on developer-specific platforms—done thoughtfully—can drive qualified awareness and traffic. This skill covers the platforms that actually reach developers, how to create ads that don't trigger immediate dismissal, and how to measure whether your spend is working. ## Why Most Ads Don't Reach Developers ### The Ad Blocker Problem Estimates suggest 50-70% of developers use ad blockers. This makes most display advertising ineffective: - Google Display Network: Heavily blocked - Facebook/Instagram: Limited developer targeting - General programmatic: Low reach, wrong audience ### Developer Ad Resistance Even when ads reach developers, they face skepticism: - Banner blindness is extreme - Marketing language triggers instant dismissal - Developers share bad ads as cautionary tales - Trust is hard to build, easy to lose ### What Does Work Advertising that reaches developers successfully: - **Contextual placement**: Ads on sites developers already trust - **Value-first messaging**: Leading with what you do, not superlatives - **Technical credibility**: Ads that show you understand the audience - **Native formats**: Newsletter mentions, sponsored content ## Platform-by-Platform Guide ### Carbon Ads **What it is:** Native advertising network for developer and design websites **Where ads appear:** - Developer documentation sites - Tech blogs - Developer tools - Open source project sites **Why it works:** - Non-intrusive design - Respected by developers - Often not blocked - Highly contextual placement **Costs:** - CPM-based pricing - Typically $2-5 CPM - Minimum budgets vary - Direct buys for premium sites **Best practices:** - Simple, text-focused creative - Clear value proposition - Relevant to site context - No hype language **Limitations:** - Limited targeting options - Cannot always choose specific sites - Creative restrictions - Availability varies ### BuySellAds **What it is:** Marketplace for buying ads directly on websites **Key developer placements:** - Development-focused websites - Programming blogs - Tech news sites - Developer tool sites **Why it works:** - Direct relationship with publishers - Choose exact sites - Various ad formats - Predictable placement **Costs:** - Per-site pricing - Wide range ($50 to $5000+ per month per site) - Often monthly commitments - Negotiable for volume **Best practices:** - Research site audience before buying - Start with smaller buys to test - Match creative to site tone - Track referrals per site **Limitations:** - Manual process - Variable quality - Need to manage multiple relationships - Some sites have waiting lists ### Reddit Advertising **What it is:** Native advertising on Reddit's developer-focused subreddits **Relevant subreddits:** - r/programming - r/webdev - r/javascript, r/python, etc. - r/devops - r/sysadmin - Technology-specific subreddits **Why it works:** - Precise subreddit targeting - Developers actively use Reddit - Native format in feeds - Comment engagement possible **Costs:** - Auction-based CPM or CPC - Typical CPM: $2-8 for developer subreddits - Minimum daily spend: $5 - Self-serve platform **Best practices:** - Tailor ads to specific subreddit culture - Use Reddit's native language (not corporate speak) - Consider promoted posts over display ads - Monitor and engage with comments **Limitations:** - Developers are hostile to obvious ads - Creative must match Reddit culture exactly - Easy to waste money on wrong targeting - Comments can go negative quickly **Reddit-specific cautions:** - Never astroturf (fake organic posts) - Be prepared for critical comments - Corporate-feeling ads get mocked - Transparency about being an ad helps ### Developer Newsletter Sponsorships **What it is:** Sponsored mentions in newsletters developers subscribe to **Notable newsletters:** - TLDR (various topics) - JavaScript Weekly, Node Weekly, etc. - Pointer - Bytes - Console - Hacker Newsletter - Programming Digest **Why it works:** - Developers opted in to receive - Curator endorsement implied - Not blocked by ad blockers - Higher trust environment **Costs:** - Per-send pricing - Range: $200-5000+ per issue - Depends on list size and engagement - Often booked weeks in advance **Best practices:** - Match newsletter's audience precisely - Provide value in the ad itself - Work with curator on copy - Test multiple newsletters - Track with unique URLs **Limitations:** - High cost per impression - Limited frequency - Availability constraints - Variable quality ### Podcast Sponsorships **What it is:** Sponsor mentions on developer podcasts **Notable shows:** - Syntax - ShopTalk Show - Changelog - Software Engineering Daily - Developer Tea **Why it works:** - Host endorsement carries weight - Engaged, loyal audiences - Hard to skip/block - Builds familiarity over time **Costs:** - Per-episode or per-download pricing - Range: $500-5000+ per episode - Often require multi-episode commitments - Host-read vs produced ads priced differently **Best practices:** - Choose shows your audience actually listens to - Commit to multiple episodes for recognition - Give hosts freedom to personalize - Provide clear, simple value propositions ## Creating Ads That Don't Feel Like Ads ### Messaging Principles **Lead with what you do:** - Bad: "The revolutionary platform transforming development" - Good: "Automated code review for Python teams" **Be specific:** - Bad: "Save time and money" - Good: "Find bugs before PR review" **Acknowledge the audience:** - Bad: Generic benefits anyone could claim - Good: Reference specific technologies, workflows, pain points **Skip the superlatives:** - Avoid: "best," "leading," "revolutionary," "game-changing" - Use: Concrete descriptions of functionality ### Creative Formats **For display ads:** - Simple, clean design - Clear logo - Short, specific headline - One clear CTA **For text ads:** - First sentence explains what you are - Second sentence explains key benefit - No exclamation marks - No ALL CAPS **For sponsored content:** - Genuinely useful content - Product mention natural, not forced - Teach something, don't just pitch - Clear but not overwhelming branding ### Examples **Bad ad copy:** > "Ready to 10X your productivity? Join thousands of developers who've transformed their workflow with our revolutionary platform!" **Better ad copy:** > "Database GUI for PostgreSQL. Query builder, ERD visualization, team sharing. Free for individual use." **Bad newsletter sponsor:** > "Tired of slow deployments? Our AMAZING platform makes deployment a breeze! Sign up now for a FREE trial!" **Better newsletter sponsor:** > "Deploy to any cloud from a git push. We handle SSL, scaling, and rollbacks. See how it works [link]." ## Targeting by Technology Stack ### Technology-Based Targeting **Newsletter targeting:** - Python developers: Python Weekly, PyCoder's Weekly - JavaScript developers: JavaScript Weekly, Bytes - DevOps: DevOps Weekly, SRE Weekly - Choose newsletters matching your technology **Reddit targeting:** - Target specific language/framework subreddits - r/node vs r/programming for different reach - Consider subreddit overlap **Contextual (Carbon/BuySellAds):** - Ads on docs for relevant technologies - Framework-specific blogs - Technology news sites ### Avoiding Wasted Spend **Negative targeting:** - Exclude unrelated technologies - Avoid broad developer targeting when specific works - Filter out student/beginner if targeting professionals **Testing approach:** - Start narrow, expand what works - Different creative for different stacks - Track conversion by source ## Measuring Developer Ad Spend ### Attribution Challenges Developer ad measurement is hard because: - Long consideration periods - Multiple touchpoints before conversion - Ad blockers break tracking - Dark social sharing (Slack, DMs) ### What You Can Measure **Direct metrics:** - Clicks (with skepticism about quality) - Landing page visits - Signups with UTM attribution - First-touch attribution **Proxy metrics:** - Brand search volume changes - Direct traffic trends - Social mentions - Community growth during campaigns ### Setting Up Tracking **UTM discipline:** - Consistent parameter naming - Unique UTMs per placement - Track to conversion, not just click **Landing page strategy:** - Consider campaign-specific landing pages - Ensure tracking survives ad blockers where possible - Ask "how did you hear about us" as backup ### Calculating ROI **Cost per acquisition:** ``` Total Spend / Attributed Signups = CPA ``` **With realistic attribution:** - First-touch attribution undersells ads (assists aren't counted) - Last-touch attribution overcounts (ignores earlier touchpoints) - Self-reported attribution helps fill gaps **Acceptable CPAs:** - Depends entirely on customer lifetime value - Developer tools often have high LTV - Factor in viral/referral potential of developers ## Budget Allocation ### Small Budget ($500-2000/month) **Recommended allocation:** - 1-2 newsletter sponsorships per month - Test Carbon Ads on specific sites - Save some for testing new placements **Focus:** - Find one channel that works - Perfect messaging before scaling - Build measurement foundation ### Medium Budget ($2000-10,000/month) **Recommended allocation:** - Regular newsletter sponsorships (40%) - Carbon/BuySellAds display (30%) - Reddit testing (15%) - Experimental channels (15%) **Focus:** - Scale what's working - Continue testing new placements - Develop creative variations ### Large Budget ($10,000+/month) **Recommended allocation:** - Major newsletter presence (30%) - Broad developer display (25%) - Podcast sponsorships (20%) - Reddit/community ads (15%) - Experimental (10%) **Focus:** - Brand building alongside direct response - Multi-touch attribution - Creative optimization ## Tools - **Google Analytics**: Track campaigns with proper UTM setup - **Platform dashboards**: Native analytics for each platform - **Spreadsheet tracking**: Campaign performance over time - **Survey tools**: "How did you hear about us" collection - **Octolens**: Monitor developer discussions to identify which problems developers talk about most, informing ad messaging and placement decisions ## Common Mistakes 1. **Generic targeting**: Broad "developer" targeting wastes money 2. **Marketing language**: Copy that sounds like consumer advertising 3. **Ignoring blockers**: Assuming impressions = reach 4. **Short tests**: Not giving campaigns time to work 5. **No tracking**: Spending without attribution setup 6. **Wrong platforms**: Using Facebook/Google when developer-specific works better 7. **Over-optimizing for clicks**: Clickbait that doesn't convert ## Related Skills - **developer-lead-gen**: Ads driving to free tools/resources - **developer-seo**: Organic alongside paid - **developer-content-strategy**: Content for landing pages - **developer-newsletter**: Building your own newsletter vs sponsoring othersskills/alternatives-pages/SKILL.mdskillShow content (10684 bytes)
--- name: alternatives-pages description: | Create "[Competitor] alternative" and comparison pages for developer tools. Build honest, high-converting comparison content that ranks for competitive search terms. Trigger phrases: "alternatives page", "comparison page", "vs page", "[competitor] alternative", "competitor comparison", "competitive content", "comparison table", "migration guide", "switch from [competitor]", "compare to [competitor]", "alternative to" metadata: version: 1.0.0 --- # Alternatives Pages Create effective "[Competitor] alternative" and comparison pages that rank for competitive keywords, convert developers honestly, and support your competitive positioning. ## Overview Alternatives pages and comparison content are high-intent SEO plays. Developers searching for "[competitor] alternative" or "[your product] vs [competitor]" are actively evaluating solutions. Done well, this content captures demand, educates prospects, and positions your product effectively. Done poorly, it damages trust and brand perception. The key principles: - Be honest - developers will fact-check you - Be helpful - even if they don't choose you - Be specific - vague comparisons waste everyone's time - Be current - outdated comparisons are worse than none ## SEO Research for Competitive Keywords ### Keyword Categories **Alternative keywords:** - "[Competitor] alternative" - "[Competitor] alternatives" - "Alternative to [competitor]" - "Best [competitor] alternatives" - "[Competitor] replacement" **Comparison keywords:** - "[Competitor] vs [your product]" - "[Your product] vs [competitor]" - "[Competitor] vs [other competitor]" (consider if you should play here) - "[Competitor] comparison" - "Compare [category] tools" **Migration keywords:** - "Migrate from [competitor]" - "Switch from [competitor]" - "[Competitor] to [your product]" - "Moving away from [competitor]" **Problem-aware keywords:** - "[Competitor] pricing too expensive" - "[Competitor] limitations" - "[Competitor] [specific problem]" - "Frustrated with [competitor]" ### Research Developer Conversations Use social listening tools to identify which competitive keywords have real search intent based on developer conversations. Search for: - "[competitor] alternative" or "alternative to [competitor]" - "[competitor] vs" - Negative sentiment mentions of competitors Look for patterns in: - Which competitors developers frequently compare - What problems drive people away from competitors - What features developers ask about when evaluating - Migration concerns and blockers ### Prioritizing Which Pages to Create **High priority:** - Direct competitors with significant search volume - Competitors you frequently encounter in deals - Competitors developers organically compare you to **Medium priority:** - Indirect competitors in adjacent categories - Competitors you can clearly beat on specific use cases **Lower priority:** - Competitors in different market segments - Competitors with minimal overlap ## Page Structure That Converts ### Alternatives Page Structure **1. Hero Section** - Clear headline: "[Your product]: A [Competitor] Alternative for [Use Case]" - One-sentence value proposition - Quick social proof (logos, stats) - Primary CTA **2. Why Developers Switch Section** - Common pain points with competitor (from social listening research) - Be specific and factual, not snarky - Cite real developer feedback when possible **3. Key Differences Section** - 3-5 major differentiators - Focus on things that matter to your ICP - Be honest about where you're similar or worse **4. Comparison Table** - Feature-by-feature comparison - Include pricing comparison - Honest checkmarks (don't claim features you don't have) - Date the comparison ("Last updated: [date]") **5. Migration Section** - How hard is it to switch? - Migration guide or resources - Data portability information - Support available during migration **6. Social Proof** - Case studies from companies who switched - Testimonials mentioning the switch - Quantified results if available **7. FAQ Section** - Address common concerns - SEO opportunity for long-tail keywords - Objection handling **8. CTA Section** - Primary: Start trial/demo - Secondary: Migration guide, comparison deep-dive ### Comparison Page Structure (You vs Them) **1. Hero** - "[Your Product] vs [Competitor]: [Key Differentiator]" - Neutral, informative tone - Both logos (don't be weird about it) **2. Quick Comparison** - At-a-glance summary for scanners - 3-4 key differences highlighted - Who each product is best for **3. Detailed Comparison Table** - Comprehensive feature comparison - Categorize features logically - Include pricing - Include subjective but fair assessments **4. Detailed Analysis Sections** - Deep dive on major difference areas - Use cases where each excels - Developer experience comparison **5. Migration Information** - If relevant, how to switch between them - Bidirectional if you want to seem fair **6. Verdict/Recommendation** - "Choose [Your Product] if..." - "Choose [Competitor] if..." - Be honest about competitor's strengths ## Honest Comparison Tables ### Table Best Practices **Do:** - Include features you don't have that competitor does - Use nuanced indicators (full support, partial, beta, not available) - Date your comparison prominently - Link to sources/docs for verification - Include pricing transparency **Don't:** - Cherry-pick only features you win on - Use misleading indicators - Ignore major competitor features - Let comparisons get stale ### Comparison Indicators Instead of simple checkmarks: - "Full support" / "Partial" / "Beta" / "Roadmap" / "Not available" - Include hover/click for details - Link to relevant documentation ### Handling Subjective Comparisons Some comparisons are subjective (developer experience, ease of use). Handle these by: - Being explicit that it's subjective - Citing external sources when possible - Inviting developers to evaluate themselves - Including quotes from developers who've used both ## Addressing Migration ### Migration Content Types **Migration guide:** - Step-by-step technical guide - Data export from competitor - Data import to your product - Configuration mapping - Testing and validation **Migration assessment:** - Help developers evaluate effort - What migrates easily vs needs work - Timeline expectations - Support available **Migration support offer:** - Dedicated migration help - Data import services - Onboarding assistance ### Migration Concerns to Address Common developer concerns when switching: - How much work is the migration? - Will I lose data or history? - What's the learning curve? - Can I migrate incrementally? - What if the migration fails? - Is there a rollback option? ## When to Name Competitors vs Stay General ### Name Competitors When: - They're well-known and developers search for them - You have a clear, honest differentiator - You can be specific about differences - You're prepared to keep the content updated - You have permission to use their trademark fairly ### Stay General When: - Competitor is much smaller (looks petty) - Your comparison would be dishonest - You'd rather own the category than specific comparisons - Legal concerns about trademark usage - The market is too fragmented to name everyone ### General Alternative Content "Best [Category] Tools" type content: - Position yourself within the category - Compare multiple options including yourself - Be genuinely helpful in evaluation - Let your product stand on its merits ## Legal Considerations ### Trademark Usage **Generally acceptable:** - Using competitor names in factual comparisons - "[Competitor] alternative" type phrases - Accurate feature comparisons **Avoid:** - Using competitor logos without permission (grey area) - Implying endorsement or partnership - Making false claims about competitors - Trademark usage in domains (usually problematic) - Competitive keyword bidding on brand terms (policy varies) ### Defamation and False Claims - All claims must be factually accurate - Document sources for claims - Date comparisons and keep them updated - When in doubt, be more generous to competitor ### Consult Legal When: - Making any claims that could be seen as disparaging - Using competitor visual assets - Creating comparison advertising - Competitor has sent C&D or complained ## Research for Competitive Content ### Research Phase Use social listening tools to research: - **Developer pain points:** Negative sentiment mentions of competitors - **Common comparisons:** "[competitor] vs" or "compare [competitor]" - **Migration conversations:** "switch from [competitor]" or "migrate from [competitor]" ### Validation Phase Before publishing, verify: - Your differentiators resonate in real conversations - You've addressed common misconceptions - Your claims are factually accurate ### Ongoing Monitoring Set up alerts to track: - Comparison conversations mentioning your product vs competitor - Competitor announcements that might require content updates ## Content Maintenance ### Update Triggers - Competitor launches major feature - Your product launches relevant feature - Competitor changes pricing - Industry/category shifts - Quarterly review regardless ### Update Process 1. Review all claims for accuracy 2. Update comparison tables 3. Refresh screenshots if used 4. Update "last updated" date 5. Re-check SEO optimization 6. Update internal links ### Deprecation When competitors become irrelevant: - Don't delete (keep URL equity) - Add notice: "This comparison may be outdated" - Consider redirecting to category page ## Tools ### Research Queries Use social listening tools to set up searches for: - Competitor pain points: [competitor] + negative sentiment - Comparison intent: "[competitor] vs" - Migration signals: "alternative OR migrate OR switch" + competitor name - Your comparison pages in conversations ### Other Tools **SEO Tools:** - Keyword research for search volume - Competitor page ranking analysis - Backlink analysis for competitor comparison pages **Archive.org:** - Research competitor historical positioning - Track competitor feature launches for timeline **Testimonial Sources:** - G2, Capterra reviews for switching stories - Twitter for public praise after switching - Case study interviews ## Related Skills - **competitor-tracking** - Ongoing competitive intelligence - **developer-listening** - Understanding developer sentiment - **seo-for-devtools** - SEO optimization for technical content - **landing-pages** - Conversion optimization for comparison pagesskills/api-onboarding/SKILL.mdskillShow content (12561 bytes)
--- name: api-onboarding description: | Reduce time-to-first-API-call (TTFAC) by optimizing every step of the developer onboarding journey. This skill covers authentication simplification, sandbox environments, interactive documentation, and identifying and eliminating common failure points. Trigger phrases: "API onboarding", "time to first API call", "TTFAC", "developer onboarding", "first API call", "auth simplification", "sandbox environment", "interactive docs", "try it now", "API playground", "developer activation", "onboarding friction" metadata: version: 1.0.0 --- # Reducing Time-to-First-API-Call The time between a developer discovering your API and successfully making their first call is the most critical window in your entire developer journey. Every minute of friction here costs you potential users. ## Overview Time-to-First-API-Call (TTFAC) is the single most predictive metric for developer adoption. Developers who succeed quickly become active users. Developers who struggle leave—often silently. This skill covers: - Measuring and optimizing TTFAC - Removing authentication friction - Creating effective sandbox environments - Building interactive documentation - Identifying and fixing common failure points ## Before You Start Review the **developer-audience-context** skill to understand: - What's the typical technical sophistication of your developers? - What tools and environments do they commonly use? - What alternative products have they tried? What was their experience? - What's their urgency level? (Evaluating vs. building immediately) Your onboarding should meet developers where they are. ## Understanding TTFAC ### What TTFAC Measures Time-to-First-API-Call measures the elapsed time from a developer's first interaction to their first successful API response. This includes: 1. **Discovery time**: Finding the "Get Started" content 2. **Signup time**: Creating an account 3. **Credential time**: Obtaining API keys 4. **Setup time**: Installing SDK, configuring environment 5. **Execution time**: Running first request 6. **Success time**: Receiving successful response ### TTFAC Benchmarks | Rating | TTFAC | Developer Experience | |--------|-------|---------------------| | **Excellent** | < 5 min | "This is amazing" | | **Good** | 5-15 min | "Pretty straightforward" | | **Acceptable** | 15-30 min | "Got there eventually" | | **Poor** | 30-60 min | "This is frustrating" | | **Failing** | > 60 min | "I'll try something else" | ### Measuring TTFAC **Instrumentation points:** ```javascript // Track these events with timestamps analytics.track('docs_quickstart_viewed'); analytics.track('signup_started'); analytics.track('signup_completed'); analytics.track('api_key_created'); analytics.track('sdk_installed'); // Via package manager data analytics.track('first_api_call'); // Via API logs analytics.track('first_successful_call'); ``` **Calculate:** - Median TTFAC (more useful than average) - TTFAC by developer segment - Drop-off rates at each step - Success rates within time windows (5 min, 15 min, 60 min) ## Authentication Simplification Authentication is the #1 source of onboarding friction. Simplify ruthlessly. ### The Ideal Auth Flow 1. Developer signs up (< 2 minutes) 2. API key visible immediately (not buried in settings) 3. Key works immediately (no activation delay) 4. Copy-paste into example code 5. Success ### Auth Anti-Patterns to Avoid **The Approval Queue** ``` ❌ "Your API access request has been submitted. You'll receive access within 2-3 business days." ``` Developers leave and find an alternative. **The Hidden Key** ``` ❌ Settings → Team → API → Credentials → Keys → Show Key ``` Make keys visible on dashboard home. **The Complex Token** ``` ❌ OAuth flow requiring: - Client ID - Client secret - Redirect URI configuration - Token exchange - Token refresh handling ``` For getting started, provide simple API keys. **The Verification Gauntlet** ``` ❌ Sign up → Verify email → Verify phone → Add payment → Verify payment → Then API key ``` Minimize friction for first API call. ### Auth Simplification Strategies **Provide Test Keys Immediately** ``` ✅ "Here's your test API key: sk_test_abc123... Use this in sandbox mode—no charges, no setup." ``` **Support Multiple Auth Methods** ``` ✅ Quickstart: API key header Production: OAuth when they need it ``` **Pre-populate Examples** ``` ✅ # Your API key is pre-filled in these examples curl -H "Authorization: Bearer sk_test_YOUR_KEY" ... ``` **Delay Production Requirements** ``` ✅ Test mode: Instant access Production mode: Add payment, verify identity (later) ``` ## Sandbox Environments A sandbox removes the fear of "breaking something" and lets developers experiment freely. ### Sandbox Requirements **Instant Access**: No approval, no payment, no complex setup **Realistic Behavior**: Same API, same responses, same errors **Clear Boundaries**: Obvious when in sandbox vs. production **Reset Capability**: Easy way to start fresh **Generous Limits**: Don't rate-limit experimentation ### Sandbox Implementation Patterns **Separate Endpoints** ``` Production: api.example.com Sandbox: sandbox-api.example.com ``` **Key Prefixes** ``` Production key: sk_live_abc123... Sandbox key: sk_test_xyz789... ``` **Environment Parameter** ``` curl -X POST https://api.example.com/v1/messages \ -H "Authorization: Bearer $API_KEY" \ -d '{"sandbox": true, ...}' ``` ### Sandbox Data **Pre-populated Test Data** ```javascript // Sandbox comes with test users const testUsers = await client.users.list(); // Returns: [ // { id: "usr_test_alice", name: "Alice (Test)" }, // { id: "usr_test_bob", name: "Bob (Test)" } // ] ``` **Magic Values** ```javascript // Special values trigger specific behaviors client.payments.create({ amount: 1000, card: "4242424242424242" // Always succeeds }); client.payments.create({ amount: 1000, card: "4000000000000002" // Always declines }); ``` **Documented Test Scenarios** ```markdown ## Test Card Numbers | Number | Behavior | |-----------------|----------------------| | 4242424242424242 | Successful charge | | 4000000000000002 | Declined | | 4000000000009995 | Insufficient funds | | 4000000000000069 | Expired card | ``` ## Interactive Documentation Let developers make API calls without leaving the browser. ### "Try It" Functionality **Essential Features:** - Pre-authenticated (use their sandbox key automatically) - Pre-filled with working example data - Editable request parameters - Real API responses (not mocked) - Copy as cURL/code option **Implementation:** ```html <div class="api-explorer"> <h3>Try it: Send a Message</h3> <div class="request-editor"> <label>To Phone Number</label> <input type="text" value="+15551234567" /> <label>Message Body</label> <textarea>Hello from the API Explorer!</textarea> <button onclick="sendRequest()">Send Request</button> </div> <div class="response-viewer"> <h4>Response</h4> <pre><code id="response"></code></pre> </div> </div> ``` ### Interactive Docs Tools **OpenAPI-Based:** - Swagger UI - Redoc - Stoplight Elements **Custom Platforms:** - ReadMe.io - Postman Published Docs - Custom React components ### Interactive Examples Go beyond single requests: ```markdown ## Interactive Tutorial: Send Your First Message ### Step 1: Check your balance <api-explorer endpoint="GET /account/balance" /> ### Step 2: Send a message <api-explorer endpoint="POST /messages" body='{"to": "+15551234567", "body": "Hello!"}' /> ### Step 3: Check message status <api-explorer endpoint="GET /messages/{id}" params='{"id": "{{previous.id}}"}' /> ``` ## Common Failure Points ### Failure Point Analysis Track where developers fail and why: ```javascript // Instrument error events api.on('request_error', (error, request) => { analytics.track('api_error', { error_type: error.type, error_code: error.code, endpoint: request.endpoint, time_since_signup: timeSinceSignup(), is_first_call: isFirstCall() }); }); ``` ### Most Common First-Call Failures **1. Authentication Errors (40% of first-call failures)** ``` Problem: Wrong key, malformed header, missing auth Fix: - Clearer error messages: "API key should start with 'sk_test_'" - Pre-filled code examples with actual key - Auth header format shown with example ``` **2. Request Format Errors (25%)** ``` Problem: Wrong content type, malformed JSON, missing fields Fix: - Accept flexible content types on simple endpoints - Return specific field-level errors - Show exactly what was expected vs. received ``` **3. Environment/Setup Errors (20%)** ``` Problem: SDK not installed, wrong SDK version, missing dependencies Fix: - Version-specific installation instructions - Compatibility matrix clearly visible - Quick environment check script ``` **4. Rate Limiting (10%)** ``` Problem: Aggressive rate limits during exploration Fix: - Generous sandbox limits (or none) - Clear rate limit errors with retry-after - Don't count failed requests against limits ``` **5. Networking Errors (5%)** ``` Problem: Firewall, proxy, SSL issues Fix: - Connectivity test endpoint - Clear networking troubleshooting guide - Alternative ports/protocols if possible ``` ### Error Recovery Flows Design error messages that recover the onboarding: ```json { "error": { "type": "authentication_error", "message": "Invalid API key provided", "code": "invalid_api_key", "recovery": { "steps": [ "Check that your API key starts with 'sk_test_' or 'sk_live_'", "Ensure there are no extra spaces or newlines", "Generate a new key at https://dashboard.example.com/keys" ], "docs": "https://docs.example.com/authentication", "support": "https://support.example.com/auth-issues" } } } ``` ## The First-Call Experience Audit ### Audit Checklist Perform this audit quarterly (or after any onboarding changes): **As a New Developer:** - [ ] Create a new account (use a fresh browser/incognito) - [ ] Time how long until you have a working API key - [ ] Follow the quickstart exactly as written - [ ] Make your first API call - [ ] Record total time and every friction point **Questions to Answer:** - How many clicks from homepage to first API call? - How many pages/tabs did you need open? - What did you have to figure out that wasn't explained? - Where did you get stuck or confused? - What would have made you give up? ### Friction Point Scoring | Friction | Impact | Priority | |----------|--------|----------| | Must verify email before API key | High | Fix immediately | | API key buried in settings | High | Fix immediately | | No copy button on code examples | Medium | Fix this quarter | | Quickstart assumes specific OS | Medium | Fix this quarter | | Example uses outdated SDK version | Low | Fix when updating docs | ## Onboarding Optimization Framework ### Step 1: Measure Current State - Instrument TTFAC tracking - Run first-call audit with 5 developers - Identify top 3 drop-off points ### Step 2: Reduce Steps - Can any step be eliminated entirely? - Can any step be deferred until later? - Can multiple steps be combined? ### Step 3: Accelerate Remaining Steps - Pre-fill everything possible - Provide copy buttons everywhere - Show progress and next steps ### Step 4: Recover Failures - Improve error messages - Add inline troubleshooting - Provide live support for stuck developers ### Step 5: Measure and Iterate - Track TTFAC improvements - A/B test onboarding changes - Regular audits with real developers ## Tools ### Onboarding Analytics - **Amplitude/Mixpanel**: Event tracking and funnels - **FullStory/Hotjar**: Session recording - **Custom dashboards**: TTFAC metrics ### Interactive Docs - **ReadMe.io**: Full-featured developer hub - **Stoplight**: OpenAPI-powered docs - **Redocly**: API documentation platform - **Custom**: Build with React/Vue ### Testing - **Ghost Inspector**: Automated onboarding testing - **Checkly**: API monitoring and testing - **k6**: Load testing of onboarding flows ## Related Skills - **docs-as-marketing**: Quickstart documentation - **sdk-dx**: SDK that reduces onboarding complexity - **developer-sandbox**: The playground developers onboard with - **developer-audience-context**: Understanding your onboarding audience - **developer-metrics**: Measuring onboarding successskills/changelog-updates/SKILL.mdskillShow content (13113 bytes)
--- name: changelog-updates description: | Create release notes and product updates that developers actually read and care about. This skill covers changelog formatting, versioning communication, breaking change announcements, deprecation notices, and building anticipation for new features. Trigger phrases: "changelog", "release notes", "product updates", "version communication", "breaking changes", "deprecation notice", "what's new", "release communication", "developer updates", "API versioning", "migration announcement" metadata: version: 1.0.0 --- # Changelogs and Product Updates Developers Care About Release notes are developer communication, not documentation. When done well, they build trust, demonstrate momentum, and turn updates into marketing moments. ## Overview Changelogs serve multiple audiences and purposes: - **Active developers**: "What changed that affects my integration?" - **Evaluating developers**: "Is this product actively maintained?" - **Developer advocates**: "What's worth sharing with my audience?" - **Your team**: Historical record of what shipped and when This skill covers creating changelogs that inform, build trust, and occasionally delight. ## Before You Start Review the **developer-audience-context** skill to understand: - How do your developers prefer to receive updates? - What changes do they care most about? - How much detail do they need? - What's their tolerance for breaking changes? Your changelog tone and detail level should match your audience. ## Changelog Format ### The Standard Structure ```markdown # Changelog All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/), and this project adheres to [Semantic Versioning](https://semver.org/). ## [Unreleased] ### Added - New feature in development ## [2.3.0] - 2024-01-15 ### Added - New `analyze()` method for sentiment analysis - Support for batch processing up to 100 items ### Changed - Improved error messages with troubleshooting links - Default timeout increased from 30s to 60s ### Deprecated - `old_analyze()` will be removed in v3.0.0 ### Fixed - Race condition in concurrent requests (#234) - Memory leak when processing large files (#256) ## [2.2.1] - 2024-01-08 ### Fixed - Critical security patch for authentication bypass ## [2.2.0] - 2024-01-01 ... ``` ### Change Categories | Category | Use For | |----------|---------| | **Added** | New features, new endpoints, new parameters | | **Changed** | Behavior changes, performance improvements | | **Deprecated** | Features being phased out (still working) | | **Removed** | Features that no longer exist | | **Fixed** | Bug fixes | | **Security** | Security-related changes | ### Good vs. Bad Entries **Good Changelog Entries:** ```markdown ### Added - New `batch_analyze()` method processes up to 100 items in a single request, reducing API calls by 90% for bulk operations. [See docs](link) (#198) ### Fixed - Fixed timeout errors when processing files larger than 10MB. Uploads now stream in chunks, eliminating memory issues. (#234) ### Deprecated - `legacy_auth()` will be removed in v3.0.0 (scheduled for March 2024). Migrate to `oauth_auth()` using our [migration guide](link). ``` **Bad Changelog Entries:** ```markdown ### Added - New feature ### Fixed - Fixed bug - Fixed another bug - Various improvements ### Changed - Updated dependencies ``` ### Writing Style **Be specific:** ``` ❌ "Improved performance" ✅ "Reduced API response time by 40% for list operations" ``` **Include context:** ``` ❌ "Fixed issue #234" ✅ "Fixed timeout errors when uploading large files (#234)" ``` **Link to resources:** ``` ✅ "New batch API - [documentation](link) | [migration guide](link)" ``` **Explain impact:** ``` ✅ "Breaking: `user_id` parameter renamed to `id`. Update your code before upgrading." ``` ## What to Include ### Always Include **API Changes:** - New endpoints - New parameters - Changed response formats - Changed error codes **SDK Changes:** - New methods - Changed method signatures - New configuration options **Breaking Changes:** - Anything that requires code changes - Removed features - Changed defaults **Security Fixes:** - Even if vague, acknowledge security updates - Follow responsible disclosure timeline ### Consider Including **Performance Improvements:** ```markdown ### Changed - List operations now 3x faster through pagination optimization ``` **Developer Experience:** ```markdown ### Added - Error messages now include troubleshooting links - SDK now validates API keys at initialization ``` **Infrastructure:** ```markdown ### Changed - New data center in EU (eu-west.api.example.com) - Increased rate limits from 100 to 500 requests/minute ``` ### Skip or Minimize **Internal refactoring:** ```markdown ❌ "Refactored authentication module" (unless it affects developers) ``` **Minor dependency updates:** ```markdown ❌ "Updated lodash from 4.17.20 to 4.17.21" (unless security-related) ``` **Typo fixes:** ```markdown ❌ "Fixed typo in error message" (batch these into "Various documentation improvements") ``` ## Versioning Communication ### Semantic Versioning Explained to Users Help developers understand what version numbers mean: ```markdown # Versioning We follow [Semantic Versioning](https://semver.org/): - **Major versions (3.0.0)**: May include breaking changes. Check the migration guide before upgrading. - **Minor versions (2.3.0)**: New features, backward compatible. Safe to upgrade. - **Patch versions (2.3.1)**: Bug fixes only. Always safe to upgrade. ``` ### Version Pinning Guidance Help developers make good choices: ```markdown # Recommended Version Constraints For stability, we recommend: - `"myapi": "^2.3.0"` - Get patches and minor updates - `"myapi": "~2.3.0"` - Get patches only For production systems: - Pin exact versions: `"myapi": "2.3.0"` - Review changelogs before upgrading - Test in staging first ``` ### API Versioning Communication ```markdown # API Versions ## Current Versions - **v2** (current): Full support, recommended for new integrations - **v1** (legacy): Security fixes only, sunset March 2025 ## Version Lifecycle | Status | Duration | What It Means | |--------|----------|---------------| | Current | Ongoing | Full support, new features | | Legacy | 12 months | Security fixes only | | Deprecated | 6 months | No updates, migration required | | Sunset | - | No longer available | ## Specifying Version ```bash curl https://api.example.com/v2/users # or curl -H "API-Version: 2024-01-15" https://api.example.com/users ``` ``` ## Breaking Changes ### Breaking Change Announcement Template ```markdown # Breaking Change: [Brief Description] **Affects**: SDK v3.0.0, API version 2024-03 **Timeline**: Changes take effect March 15, 2024 ## What's Changing [Clear description of the change] ## Why We're Making This Change [Honest explanation - better performance, security, consistency] ## Who's Affected - ✅ Users of SDK v2.x - no action required - ⚠️ Users of SDK v3.0.0+ - update required - ⚠️ Direct API users on v1 - update required ## Required Actions ### If you use our SDK: ```python # Before (v2.x) client.old_method(user_id="123") # After (v3.x) client.new_method(id="123") ``` ### If you call the API directly: ```bash # Before POST /v1/users/123/analyze # After POST /v2/users/123/analyze ``` ## Migration Guide [Link to detailed migration documentation] ## Timeline - **Now**: v3.0.0 beta available for testing - **Feb 1**: v3.0.0 stable released - **Mar 1**: v2.x enters legacy support - **Mar 15**: Breaking changes take effect in API - **Sep 15**: v2.x sunset (no longer supported) ## Need Help? - [Migration guide](link) - [Office hours signup](link) - [Support channel](link) ``` ### Breaking Change Communication Timeline ``` 6 months before: Announce upcoming change 3 months before: Release new version with migration path 1 month before: Send direct emails to affected users 2 weeks before: Final reminder Day of: Change takes effect 1 week after: Follow-up for stragglers ``` ## Deprecation Notices ### In-Code Deprecation ```python import warnings def old_method(self, user_id): """ .. deprecated:: 2.3.0 Use :meth:`new_method` instead. Will be removed in v3.0.0. """ warnings.warn( "old_method() is deprecated and will be removed in v3.0.0. " "Use new_method() instead. " "Migration guide: https://docs.example.com/migrate-v3", DeprecationWarning, stacklevel=2 ) return self.new_method(id=user_id) ``` ### API Deprecation Headers ```http HTTP/1.1 200 OK Deprecation: Sun, 15 Sep 2024 00:00:00 GMT Sunset: Sun, 15 Mar 2025 00:00:00 GMT Link: <https://docs.example.com/migrate-v3>; rel="deprecation" { "data": {...}, "_deprecation": { "message": "This endpoint is deprecated", "sunset": "2025-03-15", "migration": "https://docs.example.com/migrate-v3" } } ``` ### Deprecation Changelog Entry ```markdown ### Deprecated - **`/v1/analyze` endpoint**: Use `/v2/analyze` instead. - Migration guide: [link] - Sunset date: March 15, 2025 - After sunset: Requests will return 410 Gone ``` ## Building Anticipation ### "Coming Soon" Announcements Build excitement for upcoming features: ```markdown # Coming in Q2 2024 ## Batch Processing API (Beta available now) Process up to 1,000 items in a single request. [Join the beta](link) ## Python SDK v3.0 Complete rewrite with async support, type hints, and 50% faster. [Preview documentation](link) ## EU Data Residency For customers with European data requirements. [Join waitlist](link) ``` ### Release Cadence Communication Set expectations: ```markdown # Release Schedule **SDK Releases**: First Monday of each month **API Updates**: Continuous (backward compatible) **Breaking Changes**: Twice per year (March, September) Subscribe to updates: - [GitHub releases](link) - [Email newsletter](link) - [Discord announcements](link) - [Twitter/X](link) ``` ### Feature Launches as Events Turn significant releases into moments: ```markdown # 🚀 SDK v3.0 Launch We're excited to announce the biggest SDK update in 2 years! ## Highlights - **50% faster** request processing - **Full async support** for high-throughput applications - **Type hints** throughout for better IDE support - **Simplified auth** - configure once, use everywhere ## Launch Week - **Monday**: SDK v3.0 stable release - **Tuesday**: Live coding session (YouTube) - **Wednesday**: Migration office hours - **Thursday**: Community showcase - **Friday**: AMA with the SDK team ## Resources - [Documentation](link) - [Migration guide](link) - [Video walkthrough](link) ## Thank You Special thanks to our 47 beta testers who found 23 bugs and suggested 12 improvements that made it into this release! ``` ## Distribution Channels ### Where to Publish | Channel | Audience | Content Level | |---------|----------|---------------| | GitHub Releases | Developers on repo | Full changelog | | Docs changelog | All developers | Full changelog | | Blog | Broader audience | Highlights + context | | Email | Active users | Summary + action items | | Twitter/X | Community | Highlights only | | Discord/Slack | Engaged community | Discussion + highlights | ### Email Templates **Regular Release:** ``` Subject: [Product] v2.3.0 Released - Batch Processing + Bug Fixes Hey [name], We just released v2.3.0 with some improvements you'll like: ✨ New batch processing API - handle 100 items at once 🐛 Fixed timeout issues with large files ⚡ 40% faster list operations Full changelog: [link] Upgrade guide: [link] Happy building, The [Product] Team ``` **Breaking Change:** ``` Subject: ⚠️ Action Required: [Product] Breaking Change on March 15 Hey [name], We're making changes to improve [X], and you'll need to update your integration before March 15. What's changing: [one sentence] What you need to do: [one sentence] Full details: [link] Need help? Reply to this email or join our office hours: [link] Best, The [Product] Team ``` ## Tools ### Changelog Generation - **Conventional Commits**: Structured commit messages - **semantic-release**: Automated changelog from commits - **changesets**: Monorepo changelog management - **Keep a Changelog**: Format specification ### Distribution - **GitHub Releases**: Native to most developer workflows - **Beehiiv/Buttondown**: Developer newsletter platforms - **Twitter/X**: Quick updates to community - **Discord/Slack**: Community discussions ### Monitoring - **GitHub Stars/Watchers**: Engagement metrics - **npm download stats**: Adoption tracking - **Email open rates**: Communication effectiveness ## Related Skills - **sdk-dx**: SDK versioning and migration - **docs-as-marketing**: Changelog as documentation - **developer-community**: Community communication channels - **developer-metrics**: Measuring changelog engagement - **technical-content-strategy**: Changelog as contentskills/community-building/SKILL.mdskillShow content (11186 bytes)
--- name: community-building description: When the user wants to build, grow, or improve a developer community on Discord, Slack, or forums. Trigger phrases include "developer community," "Discord server," "Slack community," "community strategy," "community engagement," "community moderation," "community growth," or "community management." metadata: version: 1.0.0 --- # Community Building This skill helps you build and manage developer communities on Discord, Slack, forums, and other platforms. Covers channel structure, onboarding, engagement programs, handling toxicity, and community-led growth. --- ## Before You Start **Load your audience context first.** Read `.agents/developer-audience-context.md` to understand: - Who your developers are (role, seniority, interests) - Where they already hang out (to avoid competing platforms) - What problems they discuss (community topic focus) - How they communicate (formal vs. casual tone) If the context file doesn't exist, run the `developer-audience-context` skill first. --- ## Platform Selection ### Comparison Matrix | Platform | Best For | Pros | Cons | |----------|----------|------|------| | **Discord** | Developer tools, gaming, OSS | Real-time, rich features, free | Can be chaotic, less enterprise | | **Slack** | Enterprise, B2B SaaS | Professional, familiar | Expensive at scale, message limits | | **GitHub Discussions** | OSS projects | Integrated, async, searchable | Less community feel | | **Discourse** | Long-form, searchable | SEO, threading, ownership | Maintenance, hosting costs | | **Circle** | Courses, paid communities | Courses integration, clean | Paid, less developer-native | ### Decision Framework | If your audience is... | Consider | |------------------------|----------| | Individual developers, OSS | Discord | | Enterprise teams | Slack | | Technical, async-preferred | GitHub Discussions | | Mixed, need searchability | Discourse | | Course/education based | Circle | --- ## Channel Structure ### Discord Channel Template ``` 📢 INFORMATION ├── #welcome — First landing, rules, links ├── #announcements — Official updates (admin-only posting) ├── #rules — Code of conduct └── #introductions — New member intros 💬 GENERAL ├── #general — Main discussion ├── #off-topic — Non-project chat └── #show-what-you-built — Share projects ❓ SUPPORT ├── #help — General questions ├── #troubleshooting — Bug help └── #feature-requests — Suggestions 🔧 TECHNICAL ├── #backend — Backend discussions ├── #frontend — Frontend discussions └── #devops — Infrastructure discussions 🤝 COMMUNITY ├── #jobs — Job postings (if allowed) ├── #events — Meetups, conferences └── #content — Blog posts, videos 📚 RESOURCES ├── #learning — Tutorials, courses └── #tools — Useful tools and libraries ``` ### Slack Channel Template ``` # welcome # announcements (admin-only) # general # help # random (off-topic) # jobs (optional) # introductions # feedback ``` ### Channel Guidelines | Channel Type | Posting Rules | Moderation Level | |--------------|---------------|------------------| | **Announcements** | Admin only | N/A | | **General** | On-topic discussion | Light | | **Help** | Questions welcome, be patient | Medium | | **Off-topic** | Anything goes (within CoC) | Light | | **Jobs** | Structured format required | Heavy | | **Introductions** | One post per person | Light | --- ## Onboarding Experience ### New Member Journey ``` Join Server ↓ Welcome Message (DM or public) ↓ Read Rules / Accept ↓ Verify (optional: GitHub, email) ↓ Introduce Yourself ↓ First Interaction ↓ Regular Member ``` ### Welcome Message Template **Discord DM:** ``` Welcome to [Community Name]! 👋 Here's how to get started: 1. Read the rules in #rules 2. Introduce yourself in #introductions 3. Ask questions in #help — we're friendly! Quick links: • Documentation: [link] • Getting started: [link] • GitHub: [link] We're glad you're here! ``` **Public #welcome channel:** ``` # Welcome to [Community Name]! We're [brief description of who you are and what you do]. ## Quick Start 1. **Read the rules** → #rules 2. **Introduce yourself** → #introductions 3. **Get help** → #help 4. **Chat with us** → #general ## Useful Links - [Documentation] - [GitHub] - [Website] ## Questions? Drop a message in #help or mention @moderators ``` ### Role Assignment | Role | How to Get | Permissions | |------|------------|-------------| | **New Member** | Auto on join | Limited channels | | **Member** | Verify or time-based | Full access | | **Contributor** | PR merged, active helper | Badge, special channel | | **Moderator** | Invited | Moderation powers | | **Admin** | Core team | Full access | --- ## Engagement Programs ### Discussion Prompts Schedule regular engagement: | Day | Prompt Type | Example | |-----|-------------|---------| | Monday | This week's goals | "What are you working on this week?" | | Wednesday | Technical question | "Controversial: Tabs or spaces?" | | Friday | Show & Tell | "Share what you shipped this week" | ### Recognition Programs | Program | Description | Frequency | |---------|-------------|-----------| | **Contributor of the Month** | Recognize top helpers | Monthly | | **First PR Celebration** | Welcome new contributors | As happens | | **Milestone Badges** | 10/50/100 messages | Automatic | | **Expert Roles** | Domain expertise recognition | Quarterly | ### Event Ideas | Event Type | Format | Effort | |------------|--------|--------| | **Office Hours** | Live Q&A with team | Low | | **Show & Tell** | Members demo projects | Low | | **Workshops** | Teaching sessions | Medium | | **Hackathons** | Build challenges | High | | **Game Night** | Non-tech fun | Low | | **AMA Sessions** | Guest experts | Medium | ### Engagement Metrics | Metric | What It Tells You | |--------|------------------| | **DAU/MAU** | Daily vs monthly active users | | **Messages per user** | Individual engagement depth | | **Questions answered** | Community self-sufficiency | | **New member retention** | Onboarding effectiveness | | **Event attendance** | Program resonance | --- ## Handling Toxicity ### Code of Conduct Essentials ```markdown # Code of Conduct ## Our Standards **Do:** - Be respectful and inclusive - Help others learn (no "RTFM") - Assume good intentions - Give constructive feedback - Report problems, don't engage **Don't:** - Personal attacks or harassment - Discrimination of any kind - Spam or self-promotion - NSFW content - Doxxing or privacy violations - Bad faith arguments ## Enforcement 1. **Warning** — First offense, good faith 2. **Temp mute** — Repeated issues 3. **Temp ban** — Serious violations 4. **Permanent ban** — Egregious or repeated ## Reporting DM any @moderator or use the report feature. All reports are confidential. ``` ### Moderation Playbook | Situation | Response | |-----------|----------| | **Heated debate** | "Let's keep this constructive. Both perspectives have merit." | | **Help vampire** | "Here's a guide on asking good questions: [link]" | | **Self-promotion spam** | Delete, warn, or ban depending on frequency | | **Off-topic drift** | "Great discussion! Let's move this to #off-topic" | | **Harassment** | Immediate mute, investigate, likely ban | | **Bad faith troll** | Don't engage publicly, ban quietly | ### De-escalation Techniques 1. **Acknowledge feelings** — "I can see this is frustrating" 2. **Move to DM** — "Let's continue this privately" 3. **Take a break** — "Let's pause and revisit tomorrow" 4. **Clarify intent** — "I think there might be a misunderstanding" 5. **Set boundaries** — "We're here to help, but not to be yelled at" ### Moderator Self-Care | Risk | Mitigation | |------|------------| | Burnout | Rotate moderator duties | | Taking it personally | Remember: it's not about you | | Imposter syndrome | Regular team check-ins | | Isolation | Moderator private channel | --- ## Community-Led Growth ### Word-of-Mouth Tactics | Tactic | How | |--------|-----| | **Referral program** | Rewards for invites that stick | | **Share-worthy content** | Exclusive insights, early access | | **Member spotlights** | Feature members → they share | | **Success stories** | "I got a job through this community" | ### User-Generated Content | Content Type | How to Encourage | |--------------|------------------| | **Tutorials** | "Share your setup in #show-what-you-built" | | **Q&A threads** | Reward helpful answers | | **Project showcases** | Monthly demo events | | **Testimonials** | Ask happy members | ### Community Champions Identify and empower super-users: | Champion Type | Role | |---------------|------| | **Greeters** | Welcome new members | | **Helpers** | Answer support questions | | **Content creators** | Tutorials, videos, guides | | **Event organizers** | Run community events | | **Connectors** | Introduce people to each other | --- ## Community Metrics ### Health Dashboard | Metric | Healthy | Warning | Action Needed | |--------|---------|---------|---------------| | **Response time (support)** | <24h | 24-72h | >72h | | **Unanswered questions** | <10% | 10-25% | >25% | | **New member 7-day retention** | >40% | 20-40% | <20% | | **Monthly active ratio** | >20% | 10-20% | <10% | | **Moderator messages ratio** | <30% | 30-50% | >50% | ### Growth Metrics | Metric | How to Track | |--------|-------------| | **Total members** | Platform analytics | | **Join rate** | New members per week | | **Churn rate** | Leaves per month | | **Engagement depth** | Messages per active user | | **Support success** | % questions resolved | --- ## Automation ### Useful Bots (Discord) | Bot | Purpose | |-----|---------| | **MEE6 / Carl-bot** | Moderation, welcome messages, roles | | **Statbot** | Analytics and metrics | | **Ticket Tool** | Support ticket system | | **GitHub Bot** | Repo activity notifications | | **YAGPDB** | Advanced moderation, custom commands | ### Automation Ideas | Automation | Benefit | |------------|---------| | Welcome DM | Consistent onboarding | | Auto-role on join | Immediate access | | Inactive member ping | Re-engagement | | Support ticket creation | Organized help | | GitHub notifications | Keep community informed | | Scheduled posts | Regular engagement | --- ## Tools | Tool | Use Case | |------|----------| | **[Octolens](https://octolens.com)** | Monitor community mentions across GitHub, Twitter, Reddit. Find where your community members talk about you. Track sentiment. Discover community content to amplify. | | **Commsor** | Community operations platform | | **Notion** | Community wiki and resources | | **Luma** | Event management | | **StreamYard/Restream** | Live event streaming | --- ## Related Skills - `developer-audience-context` — Know your community members - `open-source-marketing` — OSS community building - `developer-advocacy` — Personal brand in community - `developer-newsletter` — Community digest contentskills/competitor-tracking/SKILL.mdskillShow content (9106 bytes)
--- name: competitor-tracking description: | Systematic competitor analysis for developer tools. Track features, pricing, positioning, content strategy, and community sentiment for direct and indirect competitors. Trigger phrases: "competitor analysis", "track competitors", "competitive intelligence", "competitor research", "what are competitors doing", "competitive landscape", "competitor features", "competitor pricing", "battlecard", "competitive battlecard", "compete against", "vs [competitor]" metadata: version: 1.0.0 --- # Competitor Tracking Systematic framework for tracking competitors in the developer tools space, from identification through ongoing monitoring and battlecard creation. ## Overview Competitor tracking for developer tools requires monitoring multiple dimensions: product features, pricing, developer sentiment, content strategy, community growth, and funding/trajectory. Unlike consumer products, developer tools compete on technical merit, documentation quality, and community trust. Effective competitor tracking helps you: - Understand your competitive positioning - Anticipate competitor moves - Arm sales and marketing with accurate battlecards - Identify market gaps and opportunities - Learn from competitor successes and failures ## Competitor Identification ### Types of Competitors **Direct Competitors:** - Same category, same target developer - Solve the same core problem - Would appear in the same "best X tools" lists - Example: If you're a CI/CD tool, other CI/CD tools **Indirect Competitors:** - Adjacent categories that overlap with your use case - Might be expanding into your space - Developers might use instead of your category - Example: GitHub Actions competing with standalone CI tools **DIY Alternatives:** - Open source tools developers self-host - Custom scripts and internal tooling - "Just use bash scripts" or "build it yourself" - Often your biggest competitor by volume **Platform Alternatives:** - Cloud provider native services (AWS, GCP, Azure equivalents) - All-in-one platforms that include your functionality - Enterprise suite solutions ### Competitive Landscape Mapping Create a competitive landscape document with: 1. **Competitor profiles** - Company, product, target market, positioning 2. **Feature matrix** - Core features compared across competitors 3. **Pricing comparison** - Tiers, pricing model, enterprise pricing signals 4. **Strengths/weaknesses** - Honest assessment of each competitor 5. **Trajectory** - Funding, growth signals, strategic direction ## What to Track ### Product and Features **Track weekly/monthly:** - Changelog and release notes - New feature announcements - Pricing changes - Integration announcements - API changes - SDK/library updates **How to track:** - Subscribe to competitor newsletters - Follow their GitHub releases - Monitor their Twitter/blog - Set up monitoring alerts for "[competitor] launch" "[competitor] announces" ### Pricing and Packaging **Key signals:** - Pricing page changes (use archive.org to track history) - New tier introductions - Enterprise/custom pricing signals - Free tier changes - Usage-based vs seat-based shifts **Competitive pricing intelligence:** - What's included in free tier? - Where are the upgrade triggers? - How do they handle overages? - What's the enterprise motion? ### Positioning and Messaging **Track changes in:** - Homepage headline and hero - "Who it's for" positioning - Primary use cases emphasized - Comparison pages (how they position against others) - Case studies and social proof **Analyze:** - What problem do they lead with? - What audience are they targeting? - What's their unique angle? - How are they different from 6 months ago? ### Content Strategy **Monitor:** - Blog post frequency and topics - Documentation quality and coverage - Video/tutorial content - Conference talks and sponsorships - Developer education initiatives **Look for:** - SEO plays (what keywords are they targeting?) - Content gaps you can exploit - Successful content formats to learn from ### Community and Traction **GitHub signals:** - Stars/forks growth rate - Issue volume and response time - Contributor growth - Release frequency **Community signals:** - Discord/Slack member counts - Forum activity - Stack Overflow tag activity - Reddit mention frequency ## Developer Sentiment Monitoring ### Setting Up Competitor Monitoring Use social listening tools to track developer sentiment toward competitors across platforms. Set up alerts for: - Competitor brand mentions - Negative sentiment toward competitors (opportunity signals) - Comparison queries ("[competitor] vs") ### Key Sentiment Signals **Churn signals:** - "Migrating away from [competitor]" - "Looking for [competitor] alternative" - "Frustrated with [competitor]" - "Canceling [competitor]" **Praise signals (learn from them):** - "Love [competitor]'s [feature]" - "[Competitor] just works" - "Best part of [competitor] is..." **Feature gaps:** - "Wish [competitor] had..." - "[Competitor] doesn't support..." - "Waiting for [competitor] to add..." ### Competitive Sentiment Analysis Use your monitoring tool's analytics for trend analysis: - Mention volume for competitors over 90 days - Sentiment distribution: positive vs negative - Co-mentions where competitor and your brand appear together ## Building Competitive Battlecards ### Battlecard Structure Create battlecards for sales and marketing teams: **1. Competitor Overview** - Company background - Target market - Key value proposition - Recent news/trajectory **2. When We Win** - Scenarios where you have advantage - Customer types that prefer you - Use cases you excel at - Proof points and case studies **3. When We Lose** - Scenarios where competitor has advantage - What to watch out for - How to mitigate their strengths **4. Common Objections** - "But [competitor] has [feature]" - "[Competitor] is cheaper" - "[Competitor] is more established" - Response frameworks for each **5. Competitive Differentiation** - Key technical differences - Pricing comparison - Support/service differences - Community/ecosystem differences **6. Landmines to Set** - Questions to ask that favor you - Requirements that highlight your strengths - Evaluation criteria that matter ### Keeping Battlecards Fresh **Update triggers:** - Competitor launches major feature - Competitor changes pricing - You ship something that changes the comparison - Sales team reports new objections - Win/loss analysis reveals new patterns **Review cadence:** - Major competitors: monthly review - Minor competitors: quarterly review - Emerging competitors: as needed ## Responding to Competitor Moves ### When to Respond **Always respond:** - Competitor makes false claims about you - Competitor targets your specific customers - Major market shift that affects positioning **Consider responding:** - Competitor launches feature you have - Competitor enters your core market - Competitor's crisis creates opportunity **Usually don't respond:** - Minor feature parity announcements - Competitor's internal issues (unless affects their customers) - Petty competitive shots ### Response Playbooks **Feature launch response:** 1. Assess: Do we have parity? Better? Gap? 2. Internal communication to sales/support 3. Update battlecards if needed 4. Consider content response (blog, comparison page update) 5. Monitor developer conversations for context **Pricing change response:** 1. Analyze impact on competitive positioning 2. Update pricing comparison materials 3. Brief sales team 4. Consider if pricing adjustment needed 5. Monitor churn/acquisition impact **Crisis opportunity response:** 1. Don't be sleazy or pile on 2. Be helpful to affected users if appropriate 3. Create migration content if there's genuine demand 4. Let your product speak for itself ## Tools ### Social Listening Use monitoring tools to set up alerts for these patterns: - Competitor sentiment overview (last 30 days, by sentiment) - Churn signals: "alternative OR migrating OR switching" + competitor name - Feature gaps: "wish OR need OR missing" + competitor name - Comparison mentions: "[competitor] vs" ### Other Tools **GitHub Monitoring:** ```bash # Track competitor repo activity gh api repos/[competitor]/[repo] --jq '.stargazers_count, .open_issues_count' # Search for competitor mentions in issues gh search issues "[competitor]" --limit 50 ``` **npm/PyPI Monitoring:** - Track download trends for competitor packages - Monitor version release frequency - Watch for new packages in their ecosystem **Archive.org:** - Track historical changes to competitor websites - Document pricing changes over time - Capture positioning shifts **LinkedIn/Careers:** - Track hiring patterns - Identify strategic direction from job postings - Monitor team growth signals ## Related Skills - **developer-listening** - Broader monitoring beyond just competitors - **alternatives-pages** - Turn competitive intelligence into content - **positioning** - Differentiate based on competitive insightsskills/dev-to-hashnode/SKILL.mdskillShow content (10895 bytes)
--- name: dev-to-hashnode description: When the user wants to publish on Dev.to, Hashnode, or other developer blogging platforms. Trigger phrases include "Dev.to," "Hashnode," "developer blog," "cross-posting," "technical blogging," "canonical URL," or "developer content platform." metadata: version: 1.0.0 --- # Dev.to & Hashnode Publishing Developer blogging platforms offer built-in audiences of hundreds of thousands of developers. This skill covers cross-posting strategy, platform-specific optimization, and building followers on Dev.to and Hashnode. --- ## Before You Start 1. Read `.agents/developer-audience-context.md` if it exists 2. Decide your canonical URL strategy (important for SEO) 3. Create accounts on both platforms to reserve your username 4. Understand: These platforms reward consistency and engagement --- ## Platform Comparison ### Dev.to vs Hashnode | Feature | Dev.to | Hashnode | |---------|--------|----------| | Monthly visitors | ~10M+ | ~3M+ | | Custom domain | No (subdomain only) | Yes (free) | | Canonical URL support | Yes | Yes | | SEO benefits | High domain authority | Your domain gets SEO | | Monetization | No native | Sponsors, newsletter | | Newsletter | No | Built-in | | Series support | Yes | Yes | | Code highlighting | Excellent | Excellent | | Community features | Strong (reactions, comments) | Growing | | Audience | Broader, more beginners | More senior, focused | ### When to Use Each | Use Dev.to when | Use Hashnode when | |-----------------|-------------------| | Maximum reach is priority | Building your own brand | | Targeting beginners/mid-level | Want custom domain SEO | | Community engagement matters | Building email list | | Quick validation of content | Long-term content strategy | | Don't have your own blog | Supplementing your main blog | --- ## Cross-Posting Strategy ### The Canonical URL Decision | Strategy | Pros | Cons | |----------|------|------| | **Original on your blog** | SEO to your domain, full control | Platforms may rank lower | | **Original on Dev.to** | Maximum initial reach | No SEO to your domain | | **Original on Hashnode (custom domain)** | SEO + platform reach | Smaller initial audience | ### Best Practice: Your Blog + Cross-Post 1. **Publish on your blog first** — This is canonical 2. **Wait 1-2 days** — Let Google index your original 3. **Cross-post to Dev.to** — Set canonical URL to your blog 4. **Cross-post to Hashnode** — Set canonical URL to your blog ### Setting Canonical URLs **Dev.to** (in frontmatter): ```yaml --- title: Your Title canonical_url: https://yourblog.com/your-post --- ``` **Hashnode** (in editor): - Click "Article settings" gear icon - Paste original URL in "Canonical URL" field --- ## Dev.to Optimization ### Frontmatter Structure ```yaml --- title: "Specific, Keyword-Rich Title (Not Clickbait)" published: true description: "One compelling sentence that shows up in previews and SEO" tags: javascript, webdev, tutorial, beginners cover_image: https://your-cdn.com/image.png canonical_url: https://yourblog.com/original-post series: "Building a CLI from Scratch" --- ``` ### Tag Strategy | Tag | Followers | Use for | |-----|-----------|---------| | #javascript | 200K+ | JS content | | #webdev | 150K+ | General web development | | #beginners | 120K+ | Accessible content | | #tutorial | 100K+ | Step-by-step guides | | #react | 80K+ | React specific | | #programming | 80K+ | General programming | | #python | 70K+ | Python content | | #devops | 50K+ | DevOps, CI/CD | | #opensource | 40K+ | OSS projects | | #productivity | 40K+ | Dev tools, workflows | **Rules**: - Maximum 4 tags per post - First tag is primary (appears in URL) - Check tag follower count before using ### What Performs on Dev.to | Content type | Performance | Notes | |--------------|-------------|-------| | Beginner tutorials | High | Largest audience segment | | Listicles ("10 tools...") | High | Easy to consume | | Career advice | High | Aspirational content | | Hot takes | Medium-high | Controversial drives engagement | | Deep technical | Medium | Niche but engaged audience | | Project showcases | Medium | Best with story behind it | | News/updates | Low | Competes with official sources | ### Dev.to Engagement Features | Feature | How to use | |---------|------------| | **Reactions** | Heart, unicorn, saved, fire — different meanings | | **Comments** | Reply to every comment for algorithm boost | | **Series** | Group related posts, drives binge reading | | **Discussion** | Tag #discuss for opinion/question posts | | **Listings** | Post jobs, events, products | --- ## Hashnode Optimization ### Article Settings | Setting | Recommendation | |---------|----------------| | **Subtitle** | Use for SEO keywords | | **Cover image** | 1600x840 optimal size | | **SEO title** | Can differ from article title | | **SEO description** | 155 characters max | | **Canonical URL** | Your original if cross-posting | | **Enable table of contents** | Yes for long posts | | **Disable comments** | No — engagement helps | ### Tag Strategy Hashnode tags work differently: - Tags are linked to global topics - Some tags have dedicated feeds - Fewer tags, more focused **Popular Hashnode tags**: - `javascript`, `web-development`, `react` - `devops`, `cloud`, `aws` - `beginners`, `tutorial` - `opensource`, `programming` ### What Performs on Hashnode | Content type | Performance | Notes | |--------------|-------------|-------| | In-depth tutorials | High | Audience expects depth | | Architecture posts | High | More senior audience | | DevOps/cloud content | High | Strong niche presence | | Career stories | Medium-high | Personal narratives work | | Quick tips | Medium | Less than on Dev.to | | Listicles | Medium | Less effective here | ### Hashnode-Specific Features | Feature | How to use | |---------|------------| | **Newsletter** | Enable to collect subscribers | | **Series** | Great for tutorials, courses | | **Custom CSS** | Style your blog uniquely | | **Widgets** | Add GitHub, newsletter CTAs | | **Sponsors** | Hashnode has sponsor program | | **Analytics** | Built-in, more detailed than Dev.to | --- ## Content Formatting ### Structure That Works ```markdown # Title [Compelling hook — why should they care?] ## Table of Contents (for long posts) - [Section 1](#section-1) - [Section 2](#section-2) ## The Problem [What pain point are you solving?] ## The Solution [Your approach, with code examples] ### Code Example ```language // Well-commented code const example = "explained"; ``` ## Step-by-Step 1. **Step one** — Explanation 2. **Step two** — Explanation 3. **Step three** — Explanation ## Common Pitfalls [What to watch out for] ## Conclusion [Summary + CTA] --- *If you found this helpful, [follow me](link) for more content about [topic].* ``` ### Formatting Best Practices | Element | Guideline | |---------|-----------| | **Headers** | Use H2 for sections, H3 for subsections | | **Code blocks** | Always specify language for syntax highlighting | | **Images** | Use descriptive alt text, compress for speed | | **Links** | Descriptive text, not "click here" | | **Length** | 1000-2500 words performs best | | **Paragraphs** | Keep short, 2-3 sentences max | | **Lists** | Use liberally for scannability | --- ## Building Followers ### Consistency Strategy | Frequency | Result | |-----------|--------| | 4+ posts/month | Rapid follower growth | | 2-3 posts/month | Steady growth | | 1 post/month | Slow but sustainable | | Sporadic | Minimal follower retention | ### Engagement Tactics | Tactic | Why it works | |--------|--------------| | Reply to every comment | Algorithm boost + relationship building | | Comment on others' posts | Visibility + community | | Follow relevant authors | Often reciprocated | | Share on social media | Drives external traffic | | Link between your posts | Keeps readers on your content | | Create series | Encourages following for updates | ### Bio and Profile Optimization **Dev.to profile**: - Clear profile photo - Bio with what you write about - Link to your main site - List your expertise areas **Hashnode profile**: - Custom domain setup - Newsletter enabled - Social links populated - Blog name and tagline set --- ## Platform-Specific Do's and Don'ts ### Do's 1. **Do** set canonical URLs to protect your SEO 2. **Do** use platform-specific formatting (embeds, etc.) 3. **Do** engage with comments within 24 hours 4. **Do** cross-post to both platforms 5. **Do** use series for related content 6. **Do** optimize cover images for each platform 7. **Do** include a CTA at the end ### Don'ts 1. **Don't** post identical content without canonical URLs 2. **Don't** ignore comments 3. **Don't** use only self-promotional content 4. **Don't** neglect tags — they're discovery mechanisms 5. **Don't** forget mobile readability 6. **Don't** publish unfinished drafts 7. **Don't** keyword stuff your content --- ## Analytics and Iteration ### Dev.to Dashboard | Metric | What it tells you | |--------|-------------------| | Views | Reach/impressions | | Reactions | Engagement quality | | Comments | Discussion value | | Reading time | Content depth | | Followers from post | Conversion rate | ### Hashnode Analytics | Metric | What it tells you | |--------|-------------------| | Total views | Reach | | Unique visitors | Audience size | | Read ratio | Completion rate | | Time on page | Engagement depth | | Referrers | Traffic sources | | Newsletter signups | List growth | ### What to Optimize | Low metric | Try this | |------------|----------| | Low views | Better title, different tags | | Low reactions | More engaging opening | | Low comments | End with a question | | High bounce | Better structure, hook | | Low followers | Stronger CTA, series | --- ## Tools | Tool | Use case | |------|----------| | **[Octolens](https://octolens.com)** | Monitor Dev.to and Hashnode for mentions of your topic, competitors, and trends. Find popular content to learn from. | | **Hemingway Editor** | Improve readability | | **Carbon** | Beautiful code screenshots | | **Unsplash** | Free cover images | | **Canva** | Custom cover image design | | **Grammarly** | Catch errors before publishing | --- ## Content Calendar Template | Week | Dev.to | Hashnode | Topic | |------|--------|----------|-------| | 1 | Publish | Cross-post (day 2) | Tutorial | | 2 | Cross-post | Publish | Deep dive | | 3 | Publish | Cross-post (day 2) | Listicle | | 4 | Cross-post | Publish | Opinion/experience | --- ## Related Skills - `developer-audience-context` — Know who you're writing for - `hacker-news-strategy` — Drive traffic from HN to your posts - `reddit-engagement` — Share posts in relevant subreddits - `github-presence` — Link from READMEs to your content - `x-devs` — Promote posts on Twitter/Xskills/dev-tool-directory-listings/SKILL.mdskillShow content (9375 bytes)
--- name: dev-tool-directory-listings description: | Getting listed on developer tool directories, awesome lists, and curated resources. Covers which directories matter for developer tools, submission best practices, contributing to awesome-lists on GitHub, maintaining listings over time, and tracking referral traffic. Use when asked about: - Developer tool directories - Awesome list submissions - Getting listed on dev resources - Directory submission strategy - Curated list contributions - Tool discovery platforms metadata: version: 1.0.0 --- # Developer Tool Directory Listings ## Overview Developers discover tools through curated directories, GitHub awesome-lists, and recommendation threads. Unlike general business directories, developer directories are often community-maintained, have genuine editorial standards, and drive qualified traffic. Getting listed requires meeting quality bars and contributing authentically to these communities. This skill covers identifying valuable directories, submitting effectively, and maintaining your presence over time. ## Understanding the Directory Landscape ### Types of Developer Directories **GitHub Awesome Lists** Community-curated lists organized by technology or category. Examples: - awesome-python - awesome-react - awesome-selfhosted - awesome-developer-tools These have high credibility because they're community-vetted and contributions are public. **Curated Directories** Editorially maintained directories with submission processes: - AlternativeTo - Product Hunt (for launches) - StackShare - LibHunt - ToolsForCreators **Category-Specific Directories** Niche directories for specific developer needs: - NoCodeDevs (no-code tools) - RemoteTools (remote work tools) - DevHunt (dev tool launches) - APIList (API directories) **Package Registries** If you have libraries, these are essential: - npm (JavaScript) - PyPI (Python) - crates.io (Rust) - Go packages - Maven Central (Java) ### Which Directories Actually Matter Not all directories drive value. Prioritize based on: 1. **Traffic quality**: Do developers you want actually use this? 2. **Domain authority**: Does a backlink help SEO? 3. **Maintenance**: Is the directory actively maintained? 4. **Competition**: Are similar tools listed? 5. **Referral tracking**: Can you measure actual visits? **High-value directories to prioritize:** - GitHub awesome-lists in your category - StackShare - AlternativeTo - Product Hunt (for major launches) - Category-specific directories with engaged communities **Often low-value:** - Generic "software directories" - Abandoned lists with no recent updates - Directories that accept anything - Link farms disguised as directories ## GitHub Awesome-List Strategy ### Finding Relevant Awesome Lists 1. Search GitHub for "awesome-[your-category]" 2. Check the awesome-list curated directory: https://github.com/sindresorhus/awesome 3. Look for lists your competitors appear on 4. Find niche lists for specific use cases ### Submission Best Practices Awesome lists have contribution guidelines. Follow them exactly. **Before submitting:** - Read the entire CONTRIBUTING.md - Review recent accepted PRs for patterns - Ensure your tool meets stated criteria - Check if similar tools are already listed **Submission PR structure:** ```markdown Title: Add [Tool Name] ## Description [Brief description of what your tool does] ## Why it belongs [How it fits the list's criteria] ## Checklist - [ ] Read the contribution guidelines - [ ] Tool is actively maintained - [ ] Description follows list format - [ ] Placed in correct alphabetical order ``` **Common rejection reasons:** - Not following contribution guidelines - Tool doesn't fit list scope - Description too promotional - Tool not mature/stable enough - Missing required features for the category ### Contributing Beyond Self-Promotion Build credibility by contributing value, not just listing your own tool: - Fix broken links you notice - Suggest improvements to list organization - Add other quality tools you've used (not your own) - Improve documentation This builds reputation before you submit your own tool. ## Directory Submission Strategy ### Preparation Before Submitting **Ensure your presence is submission-ready:** 1. **Clear value proposition**: Can someone understand what you do in one sentence? 2. **Screenshots/demos**: Visual proof of your tool working 3. **Documentation**: Enough to evaluate without signing up 4. **Pricing clarity**: Transparent about costs 5. **Social proof**: GitHub stars, user count, notable users **Asset preparation:** - Logo in multiple formats (SVG, PNG, various sizes) - Screenshots at common dimensions - Short description (50-100 words) - Long description (200-300 words) - Category keywords - Comparison positioning ### Writing Directory Descriptions Different approach than marketing copy: **Do:** - Lead with what the tool does, not why it's great - Be specific about functionality - Mention key technical differentiators - Include primary use cases - Note programming language/platform compatibility **Don't:** - Use superlatives ("best," "revolutionary") - Focus on company story - Bury functionality under benefits - Use jargon unexplained - Copy-paste same description everywhere (duplicate content hurts SEO) **Example transformation:** *Marketing copy:* > "The revolutionary platform that transforms how teams collaborate on code. Trusted by 10,000+ developers." *Directory description:* > "Real-time collaborative code editor supporting JavaScript, Python, and Go. Features include shared debugging sessions, integrated terminal, and Git sync. Self-hosted or cloud options available." ### Submission Timing **For curated directories:** - Submit when you have meaningful traction - Wait until core features are stable - Consider submitting after notable milestone (funding, major release) **For Product Hunt:** - Prepare launch thoroughly (separate skill) - Coordinate with community building - Time for when team can engage ## Maintaining Directory Presence ### Regular Maintenance Directories require ongoing attention: **Quarterly review:** - Check all listings are accurate - Update screenshots if UI changed - Refresh descriptions for new features - Ensure links work - Update pricing if changed **Monitoring:** - Set up alerts for brand mentions in directories - Track referral traffic from each source - Note which directories drive signups ### Responding to Reviews Many directories allow reviews or comments: - Respond professionally to criticism - Thank positive reviewers - Use feedback to improve product - Don't argue or get defensive - Address legitimate concerns publicly ### Handling Outdated Listings Over time, some listings become outdated: - Update information when possible - Request removal from abandoned directories (avoid bad SEO signals) - Correct misinformation proactively - Keep screenshots current ## Tracking Referral Value ### Setting Up Tracking Track which directories actually drive value: 1. **UTM parameters**: Add tracking to directory URLs 2. **Referral reports**: Monitor Google Analytics referrers 3. **Signup attribution**: Ask "how did you hear about us" 4. **Backlink monitoring**: Track SEO value ### Metrics to Track **Traffic metrics:** - Visits from each directory - Bounce rate from directory traffic - Time on site from referrals **Conversion metrics:** - Signups attributed to directories - Trial-to-paid conversion from directory traffic - Revenue attributed to directory presence **SEO metrics:** - Domain authority of linking directories - Referral traffic trends over time ### Evaluating Directory ROI Not all directories warrant ongoing attention: **Keep maintaining if:** - Drives consistent qualified traffic - High conversion rates - Strong backlink value - Community engagement **Deprioritize if:** - No measurable traffic - Low-quality visits - Directory appears abandoned - No SEO value ## Budget and Resources ### Minimum Viable Approach - **Time investment**: 2-4 hours for initial submissions - **Ongoing**: 1-2 hours/quarter for maintenance - **Cost**: Free (most directories don't charge) ### Scaled Approach - Dedicated tracking for attribution - Regular auditing of directory presence - Proactive updates with product changes - Contributing to community directories ## Tools - **Google Analytics**: Referral traffic tracking - **Ahrefs/Semrush**: Backlink monitoring and discovery - **Notion/Spreadsheet**: Track all directory listings - **Brand monitoring tools**: Alerts for new mentions - **Octolens**: Discover where developers discuss and recommend tools in your category ## Common Mistakes 1. **Spamming low-quality directories**: Focus on quality over quantity 2. **Set and forget**: Listings need maintenance 3. **Identical descriptions everywhere**: Write unique descriptions 4. **Ignoring contribution guidelines**: Leads to rejection 5. **Self-promotion only**: Build reputation through genuine contributions 6. **Missing tracking**: Can't measure what matters ## Related Skills - **developer-seo**: Directory listings support overall SEO strategy - **github-community-engagement**: Contributing to awesome-lists fits broader GitHub strategy - **product-hunt-launch**: Special considerations for Product Hunt specifically
README
Developer Marketing Skills
AI agent skills for marketing to developers — inspired by marketingskills. These skills give coding agents (Claude Code, Cursor, Windsurf, etc.) specialized knowledge for developer-focused marketing tasks.
Contributions welcome! Found a way to improve a skill or have a new one to add? Open a PR.
Why Developer Marketing Is Different
Developers have a finely-tuned BS detector. They:
- Skip landing pages → Go straight to docs, GitHub, or the API reference
- Distrust marketing speak → Want technical accuracy and honest tradeoffs
- Value transparency → Open source, public roadmaps, honest pricing
- Research thoroughly → Read HN comments, Reddit threads, GitHub issues before buying
- Influence purchasing → Even when not the buyer, they're the decision-maker
These skills are built around those realities.
What Are Skills?
Skills are markdown files that give AI agents specialized knowledge and workflows for specific tasks. When you add these to your project, your agent can recognize when you're working on a developer marketing task and apply the right frameworks and best practices.
Available Skills
Foundation
| Skill | Description |
|---|---|
developer-audience-context | Start here. Establishes your developer persona, technical level, pain points, and where they hang out. All other skills reference this. |
Content & Community
| Skill | Description |
|---|---|
devrel-content | Technical blog posts, tutorials, and documentation that developers actually read |
developer-newsletter | Building and writing newsletters for a developer audience |
technical-tutorials | Step-by-step guides, quickstarts, and code walkthroughs |
open-source-marketing | Marketing open source projects without being cringe |
community-building | Discord/Slack community strategy, engagement, and moderation |
developer-advocacy | Conference talks, live coding, podcasts, and building in public |
Distribution & Discovery
| Skill | Description |
|---|---|
hacker-news-strategy | What works (and what gets you flagged) on HN |
reddit-engagement | Engaging r/programming, r/webdev, r/devops, etc. authentically |
dev-to-hashnode | Publishing on developer blogging platforms |
github-presence | README optimization, GitHub profile, sponsoring, and discoverability |
x-devs | Developer Twitter/X strategy and technical threads |
linkedin-technical | B2B developer reach on LinkedIn |
youtube-devrel | Technical video content and screencasts |
Developer Experience
| Skill | Description |
|---|---|
docs-as-marketing | Documentation that converts (quickstarts, API refs, guides) |
sdk-dx | SDK design and developer experience optimization |
api-onboarding | Reducing time-to-first-API-call |
developer-sandbox | Interactive playgrounds and demo environments |
changelog-updates | Release notes and product updates developers care about |
Growth & Acquisition
| Skill | Description |
|---|---|
developer-seo | SEO for technical queries ("how to X in Python", error messages) |
dev-tool-directory-listings | Getting listed on dev tool directories and awesome lists |
developer-lead-gen | Free tools, code generators, and ungated resources |
hackathon-sponsorship | Getting ROI from hackathon sponsorships |
developer-ads | Paid ads on Carbon, BuySellAds, Reddit, and dev newsletters |
Competitive & Market Intelligence
| Skill | Description |
|---|---|
developer-listening | Monitoring what developers say about you, competitors, and problems they're solving. Track mentions across GitHub, Hacker News, Reddit, Stack Overflow, and Twitter. |
competitor-tracking | Systematic competitor analysis for developer tools |
alternatives-pages | "[Competitor] alternative" and comparison pages for devtools |
Conversion & Activation
| Skill | Description |
|---|---|
developer-signup-flow | Frictionless signup for developers (GitHub OAuth, API key generation) |
developer-onboarding | Getting devs to "Hello World" fast |
free-tier-strategy | Designing free tiers that convert without annoying |
usage-based-pricing | Pricing models developers understand and accept |
Lifecycle & Retention
| Skill | Description |
|---|---|
developer-email-sequences | Onboarding emails, product updates, and re-engagement without spam |
developer-churn | Why developers leave and how to win them back |
power-user-cultivation | Turning users into advocates and contributors |
Installation
Option 1: npx (Recommended)
Install via skills.sh:
npx add-skill jonathimer/devmarketing-skills
Option 2: Clone and Copy
git clone https://github.com/jonathimer/devmarketing-skills.git
cp -r devmarketing-skills/skills/* .agents/skills/
Option 3: Git Submodule
Add as a submodule for easy updates:
git submodule add https://github.com/jonathimer/devmarketing-skills.git .agents/devmarketing-skills
Then reference skills from .agents/devmarketing-skills/skills/.
Option 4: Claude Code Plugin
# Add the skills directory
claude config add skills ~/path/to/devmarketing-skills/skills
Option 5: Cursor / Windsurf
Add the skills directory to your project's .cursorrules or include skill files in your context.
Option 6: Fork and Customize
- Fork this repository
- Customize skills for your specific developer audience
- Clone your fork into your projects
Usage
Once installed, your agent recognizes developer marketing tasks naturally:
"Help me write a Show HN post for our new CLI"
→ Uses hacker-news-strategy skill
"Write a getting started guide for our Python SDK"
→ Uses technical-tutorials + docs-as-marketing skills
"Find Reddit threads where devs are frustrated with [competitor]"
→ Uses developer-listening skill
"Optimize our signup flow - too many devs dropping off"
→ Uses developer-signup-flow skill
You can also invoke skills directly:
/developer-listening
/hacker-news-strategy
/devrel-content
Usage Examples
Find engagement opportunities
/developer-listening
Find conversations where developers are frustrated with [competitor]
and looking for alternatives. Focus on Reddit and Hacker News from the past week.
Write a technical tutorial
/technical-tutorials
Write a quickstart guide for integrating our SDK with Next.js.
Target: intermediate developers familiar with React but new to our tool.
Optimize developer onboarding
/developer-onboarding
Audit our current signup-to-first-API-call flow.
Identify friction points and suggest improvements.
Plan a Hacker News launch
/hacker-news-strategy
We're launching our open source CLI tool.
Help me plan the Show HN post and timing.
Recommended Tools
Tools referenced across the skills:
| Tool | Use Case |
|---|---|
| Ahrefs | SEO research and keyword tracking |
| Beehiiv | Newsletter platform with growth tools |
| Buffer | Social media scheduling |
| Buttondown | Simple newsletter for developers |
| Canva | Design for social graphics and thumbnails |
| Carbon | Beautiful code screenshots |
| Customer.io | Email automation and lifecycle messaging |
| Descript | Video/audio editing with transcription |
| Excalidraw | Hand-drawn diagrams for technical content |
| FirstPromoter | Referral program management |
| Loops | Email for SaaS |
| Luma | Event management for developer events |
| Mintlify | Developer documentation platform |
| OBS Studio | Screen recording and streaming |
| Octolens | Monitor developer conversations across GitHub, Hacker News, Reddit, Stack Overflow, Dev.to, Twitter, and more |
| Plausible | Privacy-focused analytics developers won't block |
| PostHog | Product analytics with feature flags and session replay |
| Profitwell Retain | Churn reduction and payment recovery |
| Ray.so | Code screenshots with themes |
| Resend | Developer-focused transactional email |
| Shields.io | Badges for GitHub READMEs |
| StreamYard | Live streaming for webinars and podcasts |
| Typefully | Twitter/X thread composer and scheduler |
Contributing
Found a way to improve a skill? Have a new skill to suggest? PRs and issues welcome!
- Fork the repo
- Create a skill in
skills/[skill-name]/skill.md - Follow the skill structure above
- Include a README.md with usage examples
- Submit a PR
See CONTRIBUTING.md for detailed guidelines.
License
MIT — Use these however you want.