samber

@samber source repo

150 skills
0 followers
last month last updated

▌
Developer Segmentation · samber bundle
Cuts a developer audience into a few named, sized and ranked segments - the two dimensions worth cutting on, a size range with a confidence tier, the user/champion/approver/buyer split inside each, a weighted score, one primary and one secondary segment, and a written anti-segment. Use whenever someone asks who their developers actually are, which developer audience to serve first, how big a language ecosystem or persona is, whether to target hobbyists or enterprise platform teams, who signs when the developer is not the buyer, or why content reaches everyone and converts nobody - even if they only say "who is this for". Not the journey map - use samber/developer-relations-skills@developer-journey-map.

4 installs
▌
Tech Employer Branding · samber bundle
Designs an employer-brand strategy for attracting software engineers - the engineering EVP, the channel plan (engineering blog, OSS presence, referrals, conference talks, compensation-transparency artifacts), a verification-surface audit (employer-review sites, compensation databases, anonymous forums), and the measurement baseline. Use whenever someone raises "engineering employer brand", "why can't we attract engineers", "developer hiring content strategy", "should we publish salary bands", "tech recruiting brand", or engineering offer-acceptance dropping - even if they frame it as a recruiting problem. Covers early-stage through big-company stages, junior through staff-level targeting. Not DevRel program strategy - use samber/developer-relations-skills@devrel-strategy.

5 installs
▌
Technical Video Script · samber bundle
Writes or reviews a shooting-ready script for a technical video or screencast - a two-column visual/narration beat sheet with a 30-second hook, code-on-screen pacing, segment chapters, a runtime budget, integrated description for accessibility, and a pre-decided cut list. Use whenever someone mentions a screencast script, a demo or walkthrough video, a video tutorial script, narrating a code walkthrough, turning a blog post, changelog, docs page or existing demo into a video, or asks why viewers drop off in the first minute - even if they only say they are recording something. Not a live stage demo - use samber/developer-relations-skills@developer-live-demo-design. Not video editing or podcast guesting.

4 installs
▌
Devrel Content Calendar · samber bundle
Plans a quarter of developer-relations content as a dated slot plan with named owners and reviewers - fixed anchors (releases, launches, CFP deadlines, conferences), a surface, pillar, journey and shelf-life mix, and sizing against real writing and review capacity. Use whenever the user asks for a devrel content calendar, an editorial calendar or content plan for a developer audience, what to publish next quarter, how to balance evergreen against launch-tied content, how many pieces a small team can ship, or says their content plan keeps slipping - even if they only say "we publish randomly". Plans the quarter only; individual pieces go to the per-format skills such as samber/developer-relations-skills@engineering-blog-post.

4 installs
▌
Devtools Business Model · samber bundle
Chooses the business model for a developer tool - proprietary SaaS, open core, hosted open source, support and LTS subscription, dual licensing, source-available, consumption metering, marketplace take-rate, OEM licensing - and the go-to-market each one forces. Use whenever a founder or exec asks how a developer tool should make money, whether open core or a managed cloud fits better, where the line between free and paid belongs, whether to open-source the product at all, or why adoption is high and revenue flat, and on any monetization, revenue model or commercial open source question - even if they never say "business model". Not price points, packaging or free-tier limits - use samber/developer-relations-skills@devtools-pricing-strategy.

4 installs
▌
Open Standards Strategy · samber bundle
Decides how a company engages a named open standard or protocol - ignore it, consume it, certify conformance, extend it, contribute upstream, co-found a spec with peers, or drive its own as a de facto standard - plus the venue (Git-based spec, foundation, consortium, IETF/W3C/OASIS, ISO transposition), the patent-licensing mode, the conformance plan and the kill rule. Use whenever someone raises open standards participation, protocol strategy, standards body engagement, standards wars, joining versus competing with an emerging protocol, donating a specification to a neutral foundation, whether to standardize an interface at all, or a competitor's rival spec - even if they never say "standard". Not project governance - use samber/developer-relations-skills@oss-governance.

4 installs
▌
Version Migration Guide · samber bundle
Writes or audits the migration guide for a breaking change - what breaks, ordered by blast radius, with a detection signal and before/after code per entry, a deprecation timeline, the codemod's coverage boundary, and verification by a cold upgrade of a real project. Use whenever someone mentions a migration guide, an upgrade guide, a breaking-changes page, a major version bump, "how do we tell users about v3", an API version cutover, a deprecation or sunset notice, or a codemod or compat build - even if they only say they are shipping v2. Covers libraries, SDKs, CLIs, frameworks, hosted APIs and schema runbooks. Not release notes - use samber/developer-relations-skills@changelog-writing.

5 installs
▌
Developer Tutorial · samber bundle
Writes or audits a teaching tutorial for a developer product - one new concept per step, checkpoints the learner can verify and resume from, guidance that fades, troubleshooting hooks, and a demonstrable skill at the end. Use whenever the user mentions a tutorial, a build-along or hands-on guide, a "learn X by building Y" article, a workshop or lab handout, a developer course lesson, or says nobody finishes their tutorial - even if they just say "write a guide that teaches this". Do NOT use for a zero-to-first-success quickstart (samber/developer-relations-skills@developer-quickstart-guide) or a video script (samber/developer-relations-skills@technical-video-script).

4 installs
▌
Developer Champions · samber bundle
Designs an unpaid, perks-only developer champions or ambassador program end to end - readiness check, intake model, published selection criteria, behaviour-based obligations, an access-first perk ladder, fixed terms with renewal and alumni status, and a cohort scorecard. Use whenever the user mentions an ambassador or champions program, MVP-style recognition, community heroes, "how do we recognise our top community members", what perks ambassadors should get, an ambassador program that went quiet, or removing an inactive champion - even if they never say "champion". Not for paid creator, affiliate or revenue-share partnerships. For measuring the community itself use samber/developer-relations-skills@developer-community-health.

2 installs
▌
Developer First Gtm · samber bundle
Designs the go-to-market motion for a developer-facing product - bottom-up self-serve adoption, developer-influenced sales, top-down with developer proof, or ecosystem-mediated distribution - plus the self-serve entry, the developer-to-buyer handoff rule and the land-and-expand path. Use whenever a founder, devrel or growth owner asks how developer adoption turns into revenue, whether to go bottom-up or hire sales, when to contact a free user, why signups are high and paid accounts flat, or how landed teams expand across an enterprise - even if they only say "our funnel is broken". Not price points - use samber/developer-relations-skills@devtools-pricing-strategy.

0 installs
▌
Readme Optimization · samber bundle
Audits and rewrites a repository README so a developer who has never seen the project can tell what it is, why it beats the alternative, and run the first command inside a minute - every claim and the documented install verified against the source, the page ordered into a bail-fast funnel, badges that earn nothing pruned. Use whenever someone says "review my README", "my readme is bad", "write a README for this repo", "nobody understands what my project does", "repo first impression", "readme structure", "too many badges", or is preparing an open-source launch - even if they only call it the repo landing page. Not a profile README - use samber/developer-relations-skills@github-profile-optimization.

4 installs
▌
Developer Case Study · samber bundle
Turns a customer's real production deployment into a technical case study engineers believe - measured numbers tied to how they were measured, before-and-after architecture, published limitations, and cleared naming and quote approval. Use whenever the user mentions a customer case study, a technical case study, a developer adoption or success story, a reference customer, or wants to turn a user interview, migration or production rollout into published proof - even if they only say "a post about how Acme uses us". Do NOT use for a post about your own system - use samber/developer-relations-skills@engineering-blog-post; for your own project's ongoing progress use samber/developer-relations-skills@build-in-public.

2 installs
▌
Oss License Strategy · samber bundle
Chooses an open-source project's license and contribution policy as one decision - permissive vs weak, strong or network copyleft, dependency-driven compatibility constraints, DCO vs CLA vs nothing, dual licensing and open core, source-available options (BUSL, FSL, Elastic License, SSPL), and the fork risk of relicensing. Use whenever someone asks which license to pick, whether MIT, Apache-2.0, GPL or AGPL fits, whether to require a CLA or a DCO sign-off, how to relicense an existing project, whether AGPL really protects against cloud providers, or which LICENSE, SPDX and NOTICE files to ship - even if they only voice a legal worry. Not what the company open-sources at all - use samber/developer-relations-skills@open-source-company-strategy. Never legal advice.

4 installs
▌
Tech Press Relations · samber bundle
Runs press and light analyst relations for a developer-facing product - news qualification, the angle, a reporter-to-beat media map, the pitch, embargo and exclusive handling, the press page and briefing pack, and what coverage is honestly worth. Use whenever someone raises tech press relations, getting press coverage, pitching a journalist, a tech media pitch, building a media list, a press kit, an embargo briefing, announcing a funding round, a launch coverage plan, an analyst briefing, or "how do we get written about" - even if they only say they want to be in the news. Nothing to do with pull requests. Not the announcement post itself - use samber/developer-relations-skills@engineering-blog-post.

4 installs
▌
Developer Journey Map · samber bundle
Maps the developer journey for one audience segment - discovery, trial, adoption, contribution, advocacy - as a stage-by-stage table where each stage carries an exit event, a named owner, cited friction evidence and one signal, and names the single leak worth fixing next. Use whenever someone asks what their developer journey looks like, wants a developer adoption funnel or journey map, asks why developers try the product but never reach production, where adoption drops off, who owns each step of developer experience, or how developers become contributors - even if they only say "we lose people somewhere". Not the metrics framework - use samber/developer-relations-skills@devrel-metrics.

3 installs
▌
Devrel Team Structure · samber bundle
Designs the developer relations org - which function DevRel reports to (marketing, product, engineering, CEO, sales) and what that line starves, the shape (centralized, split, embedded, hub-and-spoke), the coverage map across advocacy, community, docs and education, the interlocks with product, docs, support and sales, and the trigger for the next re-org. Use whenever someone asks where DevRel should sit, who DevRel should report to, how to structure or restructure a devrel team, which devrel roles to staff at this size, whether to embed advocates in product teams, why devrel keeps getting pulled into other teams' work, or how devrel and docs divide ownership - even if they only say the team feels wrong. Not the budget split - use samber/developer-relations-skills@devrel-budget-allocation.

4 installs
▌
Engineering Blog Post · samber bundle
Writes or edits a technical blog post a skeptical developer audience will believe - the right post pattern, evidence behind every claim, published trade-offs and limitations, runnable snippets, and no marketing voice. Use whenever the user wants an engineering blog post, a technical article, a "how we built it" or "we rewrote it in X" story, a debugging write-up, a public postmortem, a benchmark post, or a product post that must not read as marketing, and when they ask to review, edit, de-jargon or de-market an existing technical draft - even if they only call it "the article". Not a teaching tutorial - use samber/developer-relations-skills@developer-tutorial. Not release notes, a migration guide, a case study or a talk.

2 installs
▌
Devrel Hiring · samber bundle
Employer-side DevRel hiring - writes the job posting and outcome-based scorecard, designs the interview loop and question bank across the field's formats (presentation round, take-homes, DevRel-opinion round), scores a portfolio against the six-signal rubric, designs a paid work sample instead of unpaid spec work, and builds a 30-60-90 ramp anchored on a friction log. Splits by company type and funding driver. Use when the user asks how to hire a developer advocate, write a DevRel job posting, design a loop for a community manager or educator, evaluate a candidate's portfolio, or plan a ramp. Do NOT use for candidate-side prep (samber/developer-relations-skills@devrel-career) or org design (samber/developer-relations-skills@devrel-team-structure).

4 installs
▌
Devrel Metrics · samber bundle
Builds a developer relations measurement framework - a handful of metrics tiered from reach to product and business impact, each with a written attribution rule, a baseline-derived target, an owner and an action, and vanity metrics cut. Use whenever someone asks how to measure DevRel, which devrel KPIs matter, how to prove devrel value or ROI to an exec, what belongs in a devrel scorecard or quarterly report, why their numbers look good but leadership stays unconvinced, or reports only stars, impressions and event counts - even if they never say "metrics". Do NOT use for tracking instrumentation and dashboards - use samber/developer-relations-skills@devrel-analytics. Not community-only health metrics, not a single event's ROI.

2 installs
▌
Oss Governance · samber bundle
Chooses and documents an open-source project's governance model - decision rights, maintainer roles and promotion, voting and consensus rules, conflict escalation, succession, trademark and asset control, and whether to join a foundation or fiscal host. Use whenever someone asks who decides in their project, wants to write or fix a GOVERNANCE.md, is adding or removing maintainers, worries about bus factor or a single-vendor-controlled project, faces a deadlocked or contested decision, or is preparing a foundation donation - even if they only say the project has no rules. Covers solo, company-backed and multi-vendor projects. Not license, CLA or DCO choice - use samber/developer-relations-skills@oss-license-strategy. Never legal advice.

4 installs
▌
Build In Public · samber bundle
Build in Public

4 installs
▌
Devrel Strategy · samber bundle
Designs a company's developer relations program from the top - the business driver that funds it, the two goals it is allowed to serve, the pillar mix (advocacy, marketing, enablement, community) for its stage, audience priority, build-vs-buy per bet, staffing sequence, and a written refused list. Use whenever someone asks whether to start doing DevRel, what a new devrel program should do first, why devrel work is busy but not landing, how to justify the program to an exec, which pillar deserves the next investment, who to hire next, or whether to outsource content, events or community - even if they never say "strategy". Not the first-90-days plan - use samber/developer-relations-skills@developer-relations-kickoff. Not metrics, org chart or budget math.

2 installs
▌
Devrel Analytics · samber bundle
Builds the tracking plan that instruments developer-relations surfaces - docs, blog, repositories, package registries, community venues, and off-web appearances - with an event taxonomy, an identity spine, link-tagging discipline, source-confidence labelling, and funnel views. Use when the user says "devrel tracking plan", "docs analytics", "utm discipline", "event taxonomy for our docs", "our GitHub numbers don't match analytics", "how do we instrument the developer funnel", "join docs traffic to signups", or wants to know why devrel numbers disagree between tools. Instrumentation layer only - which KPIs deserve a target belongs to samber/developer-relations-skills@devrel-metrics.

4 installs
▌
Oss Issue Triage · samber bundle
Designs an issue and pull-request triage system a maintainer team can sustain - response targets sized against real capacity, the label taxonomy, intake cuts through structured forms and off-tracker routing, a separate security-report path, triage duty assignment, and the closing, staleness and volume-gating policy. Use whenever someone says "our issue tracker is out of control", "design an issue triage process", "set up labels for our repo", "we have 900 open issues", "should we run a stale bot", "PR backlog nobody reviews", "triage rotation", or "we are drowning in AI-generated reports" - even if they only say maintenance is overwhelming. Not good-first-issue curation - use samber/developer-relations-skills@oss-contributor-onboarding.

4 installs
▌
Changelog Writing · samber bundle
Turns raw commits, pull requests and tickets into release notes developers actually read - a scannable record of what shipped, what it means in practice, and what breaks. Use whenever the user mentions a changelog, CHANGELOG.md, release notes, a GitHub release body for a tag, a hosted "what's new" page, app-store release notes, Keep a Changelog, or Common Changelog, or asks what to write for a release they just cut - even when the commit history is messy and follows no commit convention. Not for version bumping, tagging or publishing pipelines. Do NOT use for a full breaking-change upgrade guide - use samber/developer-relations-skills@version-migration-guide; for a narrative release post use samber/developer-relations-skills@engineering-blog-post.

3 installs
▌
Tech Talk Outline · samber bundle
Turns an accepted conference talk abstract into a rehearsable outline - the one-sentence takeaway, a narrative arc, a minute-by-minute time budget, demo placement, and a slide skeleton with cut checkpoints. Use whenever someone says "talk outline", "technical talk structure", "slide skeleton", "my talk got accepted, now what", "how do I structure this conference talk", "my talk runs over time", "what do I cut from my talk", or "where should the demo go" - even if they only say they are preparing a conference session. Structures what the talk says. Not the CFP abstract - use samber/developer-relations-skills@conference-cfp-submission. Not slide files, not stage-delivery coaching.

4 installs
▌
API Integration Surface Strategy · samber bundle
Decide which integration surfaces a platform offers external developers and AI agents - REST, GraphQL, gRPC, SQL access, bulk data sharing, webhooks, SDKs, CLI, MCP, embedded components - and in what build order, sequenced by reversal cost and audience rather than novelty. Use whenever the user mentions which API to build first, adding a GraphQL or MCP layer, an integration-surface roadmap, API-first vs embedded-first, or a missing surface blocking deals - even if they never say "integration surface". Umbrella strategy only - once a surface is chosen, per-surface design belongs to siblings such as samber/developer-platform-skills@webhook-platform-design and samber/developer-platform-skills@sdk-portfolio-strategy.

2 installs
▌
App Marketplace Launch Marketing · samber bundle
Design a B2B SaaS marketplace operator's launch and ongoing app co-marketing program - sizing and gating the founding launch cohort, the keynote-anchored reveal and partner embargoes, featured-placement and app-of-the-month spotlight governance, and the budget split between marketplace-wide demand generation and rationed per-partner co-marketing (MDF, paid catalogs, tier gates). Use whenever the user mentions launching an app marketplace, picking launch partners, featured apps, partner spotlights, MDF, or a joint launch announcement - even if they never say "marketplace launch". Operator side only. Do NOT use for a vendor optimizing its own listing elsewhere - use samber/developer-platform-skills@integration-listing-optimization instead.

4 installs
▌
Integration Listing Optimization · samber bundle
Optimize a B2B SaaS vendor's own listing on a third-party app marketplace - Salesforce AppExchange, HubSpot, Atlassian Marketplace, Shopify App Store, Slack, or comparable directories. Covers the view-to-install funnel, keyword placement in title and tagline, screenshot and demo-video ordering, category choice, compliant review-velocity programs (incentivized reviews are banned everywhere), badge pursuit ranked by confirmed ranking effect, and defending rank against listing decay. Use whenever the user mentions AppExchange, marketplace listing conversion, marketplace search rank, app installs, or app reviews - even if they never say "listing optimization". Do NOT use for the operator's own rulebook - use samber/developer-platform-skills@app-marketplace-listing-standards instead.

4 installs
▌
Integration Partnership Strategy · samber bundle
Select which technology partners a B2B SaaS vendor integrates with and how deep each partnership goes - demand-data partner prioritization (deal-attached revenue, retention lift, competitive necessity), the referral-to-OEM depth ladder with graduation gates, joint-roadmap and co-build governance, certification-program joins with budgeted renewals, sourced-vs-influenced pipeline attribution, and where the technology-partnerships function reports. Use whenever the user mentions integration partners, ISV alliances, technology partnerships, partner tiers, certification programs, or partner-pipeline attribution - even if they never say "partnership strategy". Strategy layer only. Do NOT use for ETL-platform listings - use samber/developer-platform-skills@etl-connector-strategy instead.

4 installs
▌
App Marketplace Listing Standards · samber bundle
Write the listing-content rulebook for the operator of a B2B SaaS app marketplace - the standard every third-party listing must meet, covering required fields with objective reject criteria, screenshot and video specs, description quality bars, category taxonomy design, localization posture, badge display rules, and staleness/decay enforcement. Use whenever the user mentions listing standards, a listing rubric or marketplace quality bar, screenshot or media requirements, marketplace categories, rejection criteria, or delisting stale listings - even if they never say "listing standards". Operator side only. Do NOT use for optimizing a vendor's own listing - use samber/developer-platform-skills@integration-listing-optimization instead.

4 installs
▌
App Marketplace Monetization Model · samber bundle
Design how a B2B SaaS app/connector marketplace makes money, operator side - merchant-of-record posture (marketplace-billed vs developer-billed), billing rails and account configuration, the fee stack (revenue share collected at source, program fees, processing pass-through), fee waivers and incentive tiers, payout cadence and hold windows, and the marketplace-facilitator/VAT tax layer. Use whenever the user mentions charging for apps, rev-share collection, paid-app billing or billing APIs, developer payouts, fee waivers, or merchant of record - even if they never say "marketplace monetization". Mechanics layer only. Do NOT use for take-rate level and tiers - use samber/developer-platform-skills@connector-marketplace-strategy instead.

2 installs
▌
Docs SEO · samber bundle
Runs on-page and technical SEO for a documentation site - indexability, canonicals and hreflang across versioned and translated pages, redirects, the generator's title and description templates, internal linking, and an owner-assigned fix list against an agreed pass threshold. Use whenever someone says "docs SEO", "our docs don't rank", "documentation search optimization", "the old version of our docs outranks the current one", "our docs pages aren't indexed", "fix the canonicals on our docs", "docs sitemap problems", "hreflang on our translated docs" or "preview docs got indexed" - even if they never say SEO. Covers versioned, translated and auto-generated reference docs. Not keyword research - use samber/developer-relations-skills@developer-keyword-research.

2 installs
▌
Oss Launch · samber bundle
Plans and runs an open-source project launch end to end - name and license clearance, the readiness gate, positioning and one-liner, channel sequencing, the launch-day war room, star-velocity and GitHub Trending mechanics, and post-launch measurement. Use whenever someone is about to release, announce, open-source or "Show HN" a repository, asks how to reach GitHub Trending, wants the first real users or stars for a new library, is planning a Product Hunt post or a multi-day launch week, or asks why a launch fell flat (even if they only say they are pushing a repo public). Covers individual-developer and company adoption. Not ongoing distribution afterwards - use samber/developer-relations-skills@oss-distribution-strategy instead.

2 installs
▌
Devrel Radar · samber bundle
Builds a personalised, time-budgeted watch list of developer-relations information sources - DevRel podcasts, newsletters, practice hubs, peer communities, conference calendars, ecosystem data reports and practitioners worth following - plus the routine that keeps it verified and fresh. Use whenever a developer advocate, community manager, DevRel lead or OSS maintainer asks for a DevRel radar, how to stay current on developer relations, which DevRel podcasts, newsletters or Slack communities deserve their time, which developer conferences to attend or speak at, who to follow in DevRel, or to refresh a radar built earlier - even if they only say they feel out of the loop. Not for tracking a rival vendor - use samber/developer-relations-skills@devrel-competitor-analysis.

6 installs
▌
Devrel Career · samber bundle
Plans, lands and advances a developer relations career from the candidate side - developer advocate, developer evangelist, DevRel engineer, community manager, developer educator, DX engineer. Covers portfolio audits against real hiring signals, a zero-to-hireable artefact curriculum, the six-rung IC ladder, the interview formats DevRel loops use (talk round, content and coding take-homes, DevRel-opinion round), gatekeeper and pit-trap patterns in postings, and offer evaluation weighing reporting line before pay. Use whenever someone asks how to break into DevRel, prep a developer advocate interview, build a DevRel portfolio, choose a track, plan the next rung, or weigh a DevRel offer - even if they only say "should I take this advocate job". Not a job-search tool.

3 installs
▌
Tech Podcast Interview Prep · samber bundle
Prepares a guest for someone else's technical podcast, YouTube interview, livestream or panel - show reconnaissance, the angle, an ABT message spine backed by evidence and stories, a self-contained opening answer, clip-safe sound bites, depth calibration, recording-day mechanics, and the post-publication promotion loop. Use whenever someone says "podcast guest prep", "I'm going on a podcast next week", "youtube interview prep", "devrel media training", "prep my talking points", "sound bites", "I'm on a panel", or "what do I say when they ask about competitors" - even if they only mention an upcoming recording. Not running your own show - use samber/dev-event-organizer-skills@tech-podcast-youtube-channel.

2 installs
▌
Developer Ecosystem Strategy · samber bundle
Decides whether, when and how far a developer product should open into a platform other companies build on - extension points, partner-built integrations, third-party apps, a complement ecosystem - and what that permanently obliges you to. Use whenever someone asks if the product should become a platform, whether to open extension points or an app model to third parties, how to start an integration ecosystem, why nobody builds on the API, whether partners should build the connectors, or how much value complementors must keep - even if they only say "we want an integrations story". Not marketplace operations or API design. Do NOT use for the revenue model - use samber/developer-relations-skills@devtools-business-model.

2 installs
▌
Developer Education Strategy · samber bundle
Decides whether and how to invest in structured developer education, such as learning paths, a developer academy, hands-on labs, badges or a full certification program - instead of more ad-hoc content, then designs its operating model, staffing, refresh cadence, measurement and kill rules. Use whenever someone mentions a developer academy, certification, a developer curriculum, training for developers, learning paths, skill badges or credentials, "should we certify our users", partner or SI enablement training, or scaling developer onboarding beyond docs - even if they only say "we need more training content". Covers B2B, partner and bottom-up motions. Never writes the courses themselves. Use samber/developer-relations-skills@developer-tutorial for a lesson.

4 installs
▌
Open Source Company Strategy · samber bundle
Decides what a company open-sources and what stays proprietary, names the strategic motive for each side of the line, says who owns the decision, and states what the company commits never to close. Use whenever someone asks "should we open source this?", "what should we open source", "where do we draw the open-core line", "which features stay paid", "who signs off on open sourcing this", or wants a company-level open source strategy rather than a plan for one project - even if they frame it as a licensing question. Produces an asset-by-asset open/closed verdict, a value-capture and irreversibility check, a public non-reversal commitment and a re-evaluation trigger. Not license selection - use samber/developer-relations-skills@oss-license-strategy.

4 installs
▌
Coding Agent Docs Optimization · samber bundle
Makes SDK, API or protocol documentation something a coding agent can integrate from unattended - crawler access, machine-readable entry points (llms.txt, markdown endpoints, OpenAPI and JSON Schema files), self-contained copy-paste-safe pages, and a measured first-attempt agent success rate. Use whenever the user mentions agent-readable or AI-ready docs, agent experience or AX, llms.txt or llms-full.txt, docs for coding agents, agents inventing API calls that do not exist, or asks whether an agent could wire up their SDK from the docs alone - even if they never say "agent". Not for AI-search citation, nor a repo's own contributor-facing agent instructions. For human docs architecture use samber/developer-relations-skills@developer-docs-structure-audit.

4 installs
▌
Developer Community Moderation · samber bundle
Writes a developer community's code of conduct and the moderation playbook behind it - scope, enforcement ladder, reporting channels, incident-response runbook, moderator roster, platform controls. Use whenever the user mentions a code of conduct, CODE_OF_CONDUCT.md, community moderation, moderator recruitment, an escalation ladder, banning or suspending a member, harassment, trolls, brigading, spam or AI-slop floods, or a conduct report they need to handle - including vaguer phrasings like "our Discord is getting out of hand", "we need community rules", or "someone reported a maintainer". Covers company-run and volunteer open-source communities. Do NOT use to pick the platform - use samber/developer-relations-skills@developer-community-launch.

4 installs
▌
Developer Docs Structure Audit · samber bundle
Audits an existing developer documentation set's structure - a page-by-page inventory classified against the Diátaxis modes (tutorial, how-to, reference, explanation), mixed-mode and misplaced pages, coverage gaps per product surface, navigation drift against the file tree, a CNCF TechDocs rubric score, and a prioritized remediation queue. Use whenever the user mentions a docs structure or content audit, docs information architecture, Diátaxis, "our documentation is a mess", a docs gap analysis, what docs are missing, where a page should live, or reorganizing a documentation site - even if they only say "our docs are hard to navigate". Not for writing pages. Do NOT use for docs search ranking - use samber/developer-relations-skills@docs-seo.

4 installs
▌
Developer Troubleshooting Docs · samber bundle
Turns support tickets, issue history and error telemetry into troubleshooting and error-reference pages a developer finds by pasting the error string - symptom, conditions, cause, fix and verification entries, an error-code catalog generated from one source of truth, and fixes wired back into the product's own error output. Use whenever the user mentions troubleshooting docs, documenting error codes, error message pages, a known-issues page, building an FAQ from support tickets, or "we answer the same question every week" - even if they only say "users keep hitting this error". Not for debugging a live incident. Do NOT use for docs search ranking - use samber/developer-relations-skills@docs-seo.

1 install
▌
API Status Communication · samber bundle
Design how an API platform communicates status and incidents to external consumers - status-page modeling (the four-stage incident lifecycle, degraded/partial/major component semantics, component granularity), monitoring-driven status instead of a hand-flipped green light, pull and push channels, incident-update cadence and templates, public postmortems for a developer audience, public SLA/SLO reporting, and maintenance-window notices. Use whenever the user mentions a status page, Statuspage, incident updates, uptime or SLA reporting, postmortems, or scheduled maintenance - even if they never say "status communication". Do NOT use for deprecation and breaking-change notices - use samber/developer-platform-skills@api-versioning-policy instead.

2 installs
▌
Bulk Data Sharing Design · samber bundle
Design bulk file and lake export as a B2B product surface - the two-camp choice between Parquet file-drops on object storage and native warehouse/lake sharing (Snowflake shares, Delta Sharing, linked datasets), the partitioning and schema-evolution contract across batches, delivery cadence and freshness commitments (full dump vs incremental vs CDC vs streaming), shared-bucket security with per-recipient credentials, egress cost allocation, and cross-border data residency. Use whenever the user mentions bulk export, data dumps to S3, Parquet, Snowflake shares, Delta Sharing, or export freshness SLAs - even if they never say "bulk data sharing". Do NOT use for live SQL endpoints - use samber/developer-platform-skills@sql-jdbc-access-design instead.

2 installs
▌
Public API Design Review · samber bundle
Audit an existing or proposed public REST API surface as a checklist-driven design review - resource and URI naming, HTTP method and status-code correctness, field-naming consistency, pagination pattern choice, filtering/sorting/field-selection conventions, one consistent error envelope, and Hyrum's-Law backward-compatibility risk - every finding bucketed Must-change or Improvement against a cited rule, plus the standing review program (audience, lifecycle triggers, reviewer authority, linting, federation). Use whenever the user mentions an API design review, REST API consistency, endpoint naming, pagination style, or API design governance - even if they never say "design review". Do NOT use for GraphQL schemas - use samber/developer-platform-skills@public-graphql-api-design instead.

3 installs
▌
Developer Platform Career · samber bundle
Plans a developer-platform career from the candidate side - API Product Manager, Platform Engineer/Architect, Partner/Integration Engineer. Disambiguates "platform engineer" first - the term overwhelmingly means internal developer platforms (Kubernetes, Backstage, golden paths) elsewhere in the industry; this skill covers only the external/public-API-platform track. States the key finding that splits this track from DevRel's - platform compensation rides the general engineering/PM ladder, not a separate undersurveyed one. Covers GitLab's real Partner Engineer ladder, the API-design-vs-system-design interview split, and RFC/design-doc portfolio signals. Use when the user asks how to break into platform/API product work, prep for a platform or API-PM interview, or evaluate an offer. Do NOT use for hiring (samber/developer-platform-skills@developer-platform-hiring) or advocate/community/educator roles (samber/developer-relations-skills@devrel-career).

4 installs
▌
Developer Platform Hiring · samber bundle
Employer-side hiring for developer-platform roles - API Product Manager, Platform Engineer/Architect, Partner/Integration Engineer. Disambiguates "platform engineer" first, since the term overwhelmingly means internal developer platforms elsewhere in the industry. Calibrates the scorecard to company archetype (infra/API-first, bolt-on public API, enterprise partner ecosystem), flags a scope-collapse pattern distinct from DevRel's gatekeeper/pit-trap taxonomy, sources from apidays, not PlatformCon's internal-IDP audience, builds the loop from the API-design-vs-system-design interview split, and benchmarks compensation against the general engineering/PM ladder rather than a bespoke platform title. Use when the user asks how to hire a platform engineer, API product manager, or partner/integration engineer, write a posting, or design a loop. Do NOT use for candidate prep (samber/developer-platform-skills@developer-platform-career) or DevRel hiring (samber/developer-relations-skills@devrel-hiring).

2 installs
▌
Public GRAPHQL API Design · samber bundle
Design a public GraphQL API for third-party developers - the GraphQL-or-not gate, schema conventions (naming, nullability, Node interface, input/payload types), Relay cursor-connection pagination, union/interface error result types, depth and complexity ceilings as design decisions, the federation trust boundary (only the router is ever public), and a persisted-query policy that allowlists first-party traffic only. Use whenever the user mentions GraphQL, a public schema, Relay connections, query depth limits, persisted queries, federation, or GraphQL vs REST - even if they never say "GraphQL API design". Design layer only. Do NOT use for a REST surface review - use samber/developer-platform-skills@public-api-design-review instead.

4 installs
▌
Developer Platform Kickoff · samber bundle
Before starting any developer-platform, public-API, or integration work - or whenever no other platform skill has been chosen - route the task to the right skill in samber/developer-platform-skills, or say plainly that none fits, then bootstrap or resume the project's shared platform context. Fires at every API or platform project start, at each recurring platform review, and whenever routing is unclear. Use whenever the user mentions a developer platform kickoff, a new public API program, an integration-surface roadmap, "which platform skill do I need", "where do I start with our public API", platform skill routing, or a recurring platform check-in - even if they never name a skill or ask to be routed. It spans REST, GraphQL and gRPC design, webhooks, SDKs, MCP, OAuth and API keys, rate limits, versioning, developer portals, docs, sandboxes, marketplaces, and partner strategy, so an ambiguous platform question belongs here first. Outputs a short-list and an ordered skill chain, never the design itself.

4 installs
▌
Connector Marketplace Strategy · samber bundle
Decide whether and when a SaaS should build its own app/connector marketplace, versus joining others' marketplaces or buying embedded iPaaS, and design its operating model - curation level, partner mix, governance rules, take-rate, and seeding sequence. Use whenever the user mentions building an app store or integration marketplace, ecosystem readiness, marketplace revenue share or take-rate, curated vs open admission, third-party app governance, or seeding a two-sided developer ecosystem - even if they never say "marketplace strategy". Strategy layer only. Do NOT use for billing and payout mechanics (samber/developer-platform-skills@app-marketplace-monetization-model) or for being a connector on others' data platforms (samber/developer-platform-skills@etl-connector-strategy).

4 installs
▌
Integration Error Observability · samber bundle
Design how a platform surfaces integration failures to the external developers and partners who built against it - per-integration request/event/delivery logs with replay, correlation IDs that survive from response header to support ticket, error-rate aggregation per API key or app split by 4xx/5xx/429, proactive partner notification with cooldowns against alert fatigue, and a provider-side fleet view of which integrations are breaking. Use whenever the user mentions a developer-facing error dashboard, exposing request logs to integrators, alerting partners about broken integrations, or cutting integration support tickets - even if they never say "observability". Do NOT use for platform-wide incident comms - use samber/developer-platform-skills@api-status-communication instead.

4 installs
▌
Developer Live Demo Design · samber bundle
Engineers a technical demo so it survives the stage - risk triage, the fidelity tier it should run at, independently enterable checkpoints, a one-command environment reset, offline mode, a recorded fallback and rehearsed recovery lines, shipped as a demo runbook with a pre-flight checklist. Use whenever the user mentions a live demo, live coding, demo reliability or a fallback plan, "my demo broke on stage", whether to demo live or pre-record, a demo environment reset, a clean demo laptop, a demo profile or a panic button, or is preparing a talk, workshop, webinar or launch stream containing a demo - even if they only say "I'm nervous about the demo" or "what if I share the wrong screen". Not the talk's structure - use samber/developer-relations-skills@tech-talk-outline.

4 installs
▌
Developer Quickstart Guide · samber bundle
Writes or audits a developer quickstart that carries a reader from zero to one verified success - minimal path, copy-paste commands, expected output at every step, fail branches, and a cold-run time budget. Use whenever the user mentions a quickstart, a getting-started page, a hello-world doc, "time to first success" or "time to first value", onboarding docs for an API, SDK, CLI or self-hosted tool, or complains nobody finishes their getting-started page - even if they only say "our setup is too hard". Do NOT use for a teaching tutorial (samber/developer-relations-skills@developer-tutorial) or a README rewrite (samber/developer-relations-skills@readme-optimization).

4 installs
▌
Devrel Competitor Analysis · samber bundle
Benchmarks a competitor's developer relations motion from publicly observable signals - documentation and quickstart quality, open-source repository health, community size and responsiveness, Q&A tag activity, content cadence by format, event presence, hiring signals - and returns a gap plan with a close, ignore or counter verdict per row. Use whenever the user asks for a devrel competitive benchmark, a developer experience comparison, "how do we compare to <competitor> for developers", "what is <competitor> doing in devrel", a community size or content cadence comparison, or a docs comparison against rivals - even if they only say "why do they get more developers". Not for measuring your own program alone - use samber/developer-relations-skills@devrel-metrics.

4 installs
▌
Docs Code Sample Standards · samber bundle
Defines the policy every code sample in developer documentation must meet and audits an existing sample corpus against it, returning a ranked fix queue. Use whenever the user mentions docs code samples, code snippets in documentation, runnable examples, examples that no longer compile, copy-paste failures, snippet drift after an API change, testing docs examples in CI, SDK snippet parity across languages, sample maintenance ownership, or asks why the examples in their docs do not work - even if they only say the docs are broken. Covers sample anatomy, copy-paste and security safety, execution tiers, single-sourcing from tested code, and language parity. Not for writing a quickstart page - use samber/developer-relations-skills@developer-quickstart-guide.

2 installs
▌
Oss Contributor Onboarding · samber bundle
Designs and verifies the path a stranger walks to their first merged contribution on an open-source project - the CONTRIBUTING file, the good-first-issue queue, a clone-to-passing-tests command that works cold, and the first-pull-request review and recognition loop, scored against a blocking-plus-weighted rubric. Use whenever someone says "nobody contributes to my project", "write a CONTRIBUTING.md", "our good first issues get no takers", "first-time contributors disappear", "contributor onboarding", "first pull request experience", or "how do we get more open-source contributors" - even if they only complain about a lonely repo. Not triage-system design - use samber/developer-relations-skills@oss-issue-triage. Not governance or CLA choice.

4 installs
▌
Developer Event Sponsorship · samber bundle
Builds a developer-event sponsorship plan - which conferences, meetups and hackathons to sponsor, at which tier, with which on-site activation, and how to prove the money worked. Use whenever a DevRel lead, developer marketer or founder mentions sponsoring a conference, booth cost, a sponsorship tier or package negotiation, splitting an event budget across events, hackathon sponsorship, or event ROI - even if they only ask "is this booth worth it". Do NOT use for organizing your own event (samber/developer-relations-skills@developer-meetup-program), getting a talk accepted (samber/developer-relations-skills@conference-cfp-submission), or sponsoring open-source projects.

2 installs
▌
Developer Relations Kickoff · samber bundle
Before starting any developer-relations work - and again at the start of each new session on an existing DevRel project - routes the current task to the right skill of the samber/developer-relations-skills collection, or says plainly that none fits, then bootstraps or resumes the project's shared devrel-context.md artifact. Covers documentation, open source, community, events, technical content, program strategy, devtools business strategy, employer brand and measurement; the output is a routing short-list plus an ordered skill chain. Run it at every project start even when the collection's skills are already in daily use elsewhere, at each periodic DevRel check-in, and whenever routing is unclear - a devrel kickoff, a new developer-relations project, "which devrel skill do I need", devrel, docs or open-source skill routing, or a recurring developer-program review - even if the user only describes a devrel problem and never asks which skill to use.

4 installs
▌
Github Profile Optimization · samber bundle
GitHub Profile Optimization

2 installs
▌
Oss Sponsors Brand Strategy · samber bundle
Builds a company's open-source sponsorship portfolio - which projects and maintainers to fund, through which allocation model, at what amount each, and how to prove it worked. Use whenever a company, OSPO, DevRel lead or engineering leader asks which open-source projects to sponsor, how much to budget for open-source funding, whether sponsoring maintainers is worth it, how to run an employee-nominated FOSS fund, how to fund dependencies at scale, how to pick a sponsorship tier on a maintainer's ladder, or how to measure the return on money paid to maintainers - even if they only say they want to give back. Not the maintainer side of raising sponsorship - use samber/developer-relations-skills@oss-sponsors-fundraising. Not event sponsorship.

4 installs
▌
API Error Design · samber bundle
Design the error surface of a public API so integrators self-serve fixes - a machine-readable error-code taxonomy (flat catalog, code/subcode, Google-style domain/reason), the RFC 9457 problem-details envelope with extension members, actionable error messages, retryability signaling (retryable flag, Retry-After), and per-endpoint error documentation with request-ID tracking. Use whenever the user mentions API error codes, an error taxonomy, RFC 9457, application/problem+json, 4xx/5xx response bodies, or confusing API error messages - even if they never say "error design". Do NOT use for client-side retry mechanics - use samber/developer-platform-skills@api-idempotency-retry - nor for incident and status-page communication - use samber/developer-platform-skills@api-status-communication instead.

3 installs
▌
MCP Server Offering · samber bundle
Design a SaaS product's MCP server as a product surface AI agents operate - sizing the build investment, curating a 5-15 workflow-tool agent surface instead of mirroring API endpoints, named write-tool safety patterns (scoped credentials, read-only lockdown, human-in-the-loop approval, risk-tiered server-side gates, dry-run preflight, idempotency and spend caps), remote hosting with OAuth 2.1, versioning the tool surface, MCP registry discoverability, and measuring agent adoption. Use whenever the user mentions MCP, Model Context Protocol, an agent-facing tool surface, exposing a product to AI agents or coding assistants, or MCP write-tool safety - even if they never say "MCP server". Design layer only - code-generation MCP builder skills scaffold what this specifies.

1 install
▌
API Test Mode Design · samber bundle
Design the test/sandbox mode of a public API platform so external integrators build and validate without touching real money, messages, or data - isolation architecture (soft test-mode toggle vs hard separate-copy sandbox), test-key prefixing, magic test values, simulated objects and personas, on-demand test events, deterministic time manipulation, reset and seeding, sandbox quotas, abuse controls, and graduation to live. Use whenever the user mentions a sandbox, test mode, test API keys, magic or dummy test values, simulated webhook events, or demo data - even if they never say "test mode". Not code-execution sandboxing or unit-test mocking. Do NOT use for partner sandbox provisioning - use samber/developer-platform-skills@partner-app-onboarding instead.

4 installs
▌
API Idempotency Retry · samber bundle
Design idempotency-key support and client retry guidance for a public API so integrators retry safely - key derivation and per-caller scoping, storage TTL and replay windows, atomic claim mechanisms (DB unique constraint, SERIALIZABLE row lock, conditional writes), payload-mismatch rejection, in-flight duplicate handling, exponential backoff with jitter, retry budgets, timeout propagation, and SDK retry defaults. Use whenever the user mentions an Idempotency-Key header, duplicate or double-submitted requests, safe POST retries, backoff, or jitter - even if they never say "idempotency". Do NOT use for what the error response signals (samber/developer-platform-skills@api-error-design) or webhook delivery retries (samber/developer-platform-skills@webhook-platform-design).

0 installs
▌
API Rate Limit Policy · samber bundle
Design the rate-limit policy a public API publishes to its consumers - the metering model per paradigm (REST request counting vs GraphQL cost points), tier and quota-vs-burst numbers, multi-tenant fairness, rate-limit headers (legacy X-RateLimit-* vs IETF RateLimit fields), 429 and Retry-After behavior, enterprise and partner overrides, and change-notice rules. Use whenever the user mentions rate limits, quotas, throttling tiers, 429 responses, noisy neighbors, or limit-increase requests - even if they never say "rate-limit policy". Policy layer only, not gateway configuration. Do NOT use for the 429 error envelope - use samber/developer-platform-skills@api-error-design instead.

4 installs
▌
API Reference Quality · samber bundle
Audit a published API reference at the endpoint level against its spec surface - every operation, parameter, response code, and error documented, request/response examples present, per-language code snippets in parity, try-it affordances working - and install the source-of-truth gates that stop reference drift (spec-driven generation, OpenAPI lint, contract tests, snippet parity in CI). Use whenever the user mentions API reference docs, OpenAPI docs completeness, undocumented endpoints or error codes, stale or drifting docs, or docs CI gates - even if they never say "reference quality". Endpoint-level reference only. Do NOT use for portal IA and onboarding - use samber/developer-platform-skills@developer-portal-design instead.

4 installs
▌
API Versioning Policy · samber bundle
Define the versioning and deprecation policy for an API - version scheme choice (URI path, header, date-based account-pinned, or deliberate no-versioning), a written breaking-change definition, deprecation notice windows by audience, sunset communication (RFC 9745 Deprecation and RFC 8594 Sunset headers), enforcement at the sunset date (fall-forward vs hard cutoff), and breaking-change governance, with REST version-and-sunset and GraphQL continuous schema evolution treated as separate policies. Use whenever the user mentions API versioning, /v2, breaking changes, deprecation, sunset dates, or migration windows - even if they never say "versioning policy". Client SDK versioning is plain SemVer and belongs to samber/developer-platform-skills@sdk-portfolio-strategy.

6 installs
▌
App Marketplace Review · samber bundle
Design the operator-side review and approval process for third-party apps on a B2B SaaS marketplace - review-pipeline shape scaled to data sensitivity, permission and data-access audit checkpoints, automated pre-screening with human triage, objective re-review-on-update triggers, publish-channel hardening against supply-chain attacks, appeal paths, and a severity-tiered revocation policy. Use whenever the user mentions app review, marketplace approval criteria, third-party app permission audits, re-review after an app update, rejection appeals, or delisting and revocation - even if they never say "app review". Operator side only. Do NOT use for submitter onboarding - use samber/developer-platform-skills@partner-app-onboarding instead.

4 installs
▌
Etl Connector Strategy · samber bundle
Plan a SaaS vendor's presence as a source connector on third-party ETL/ELT platforms - demand validation before any build, platform selection from where customers' data stacks run, a build-path menu (platform-managed listing, vendor-maintained SDK connector, custom open-source tap) ranked by who absorbs the maintenance tax, an extraction-readiness audit of the product API, honest CDC scoping (API sources ship pseudo-CDC, never log-based), certification targets, and a funded maintenance plan. Use whenever the user mentions an ETL or ELT catalog listing, a source connector, data-pipeline integration, or adding CDC - even if they never say "connector strategy". Do NOT use for the vendor's own inbound marketplace - use samber/developer-platform-skills@connector-marketplace-strategy instead.

0 installs
▌
Oauth2 Provider Design · samber bundle
Design the OAuth2 authorization-server surface a B2B SaaS offers third-party apps - the OAuth 2.1 protocol baseline (PKCE for every client, no implicit or password grants, exact redirect matching), token TTL and refresh-rotation policy, scope taxonomy and granularity, consent-screen design with partial and incremental grants, client registration posture, and the tiered app-verification program. Use whenever the user mentions OAuth, "Sign in with X", access and refresh tokens, scopes, consent screens, PKCE, or third-party apps acting on a customer's behalf - even if they never say "OAuth provider". Issuer side only, not integrating against someone else's OAuth. Do NOT use for API-key design - use samber/developer-platform-skills@api-auth-key-management instead.

6 installs
▌
Partner App Onboarding · samber bundle
Design the partner-developer onboarding journey on a B2B SaaS platform - from partner signup through dev-account and sandbox provisioning, docs, education and certification posture, and support channels, to the first submitted app. Use whenever the user mentions partner developer onboarding, developer program entry, self-service vs application-gated registration, sandbox tenancy for partners, certification gating submission, partner support channels, or time-to-first-submitted-app - even if they never say "onboarding". Journey design only. Do NOT use for review-gate mechanics (samber/developer-platform-skills@app-marketplace-review) or sandbox isolation architecture (samber/developer-platform-skills@api-test-mode-design).

4 installs
▌
Public Grpc API Design · samber bundle
Design a public gRPC surface for external developers - the when-gRPC-at-all gate (most platforms keep gRPC internal and publish REST or transcoded JSON), AIP proto package and versioning conventions, buf breaking-change gates and their google.api.http blind spot, unary-by-default streaming decisions, the google.rpc.Status error model with its HTTP-mapping traps, transcoding and gateway architecture (Connect-RPC, grpc-gateway, Envoy), and external auth and TLS. Use whenever the user mentions gRPC, protobuf or .proto files, buf, Connect-RPC, grpc-gateway, or gRPC-JSON transcoding at a public edge - even if they never say "gRPC API design". Design layer only, not language-specific server implementation.

4 installs
▌
Sdk Portfolio Strategy · samber bundle
Decide a public API's language-SDK portfolio - which languages get official SDKs and in what order, generated vs handwritten build model, official and community support tiers with a promotion gate, SDK deprecation and end-of-life, and decoupling SDK SemVer from API versioning and release cadence. Use whenever the user mentions client libraries, SDKs, which languages to support first, an SDK generator (Stainless, Fern, OpenAPI Generator), community SDKs, or sunsetting an SDK - even if they never say "SDK portfolio". Portfolio strategy only, not single-SDK ergonomics or registry publishing. Do NOT use for whether to offer SDKs as a surface at all - use samber/developer-platform-skills@api-integration-surface-strategy instead.

2 installs
▌
SQL Jdbc Access Design · samber bundle
Design customer-facing SQL access to a product's data - a JDBC/ODBC endpoint, warehouse share, or hosted query surface. Covers the architecture gate by scan frequency (zero-copy share, replicated copy, per-tenant compute isolation), engine-level tenant isolation with secure views and row-level security, an additive-only schema-stability contract enforced in CI, BI-tool connectivity and driver certification, query governance and cost caps, short-lived credential issuance, and the pricing shape. Use whenever the user mentions JDBC, ODBC, SQL access for customers, connecting Tableau or Power BI to product data, or pricing a SQL add-on - even if they never say "SQL access". Do NOT use for bulk file delivery - use samber/developer-platform-skills@bulk-data-sharing-design instead.

2 installs
▌
API Auth Key Management · samber bundle
Design the API-key authentication surface a platform issues to its own API consumers - key format with prefix+checksum conventions, hashed (irretrievable) vs encrypted (retrievable) storage, zero-downtime rotation with dual-key overlap, least-privilege scoping, individual vs org vs service-account ownership, self-service key dashboard behavior, and SOC 2 / PCI-DSS 4.0 lifecycle governance. Use whenever the user mentions API keys, secret keys, key prefixes, key rotation, key scoping, or revoking keys after an employee departure - even if they never say "API key management". Provider side only, not consuming another vendor's API. Do NOT use for OAuth authorization-server design - use samber/developer-platform-skills@oauth2-provider-design instead.

4 installs
▌
Developer Portal Design · samber bundle
Design an external developer portal as a product surface, not a documentation site - information architecture for business evaluators and integrating engineers, the signup-to-first-call onboarding path governed by time to first call (TTFC), placement of each self-service surface (key dashboard, request logs, sandbox, usage metering, docs entry points), portal search with an AI answer assistant, RBAC and multi-tenant hierarchy, and the build-vs-buy platform decision. Use whenever the user mentions a developer portal, developer console, API dashboard, developer onboarding, or time to first call - even if they never say "portal". External API-consumer portals only, not internal service catalogs.

4 installs
▌
Webhook Platform Design · samber bundle
Design a provider-side outbound webhook platform - event taxonomy and catalog, payload envelope and schema versioning, an HMAC signing scheme (Standard Webhooks), at-least-once delivery with retry/backoff and dead-letter policy, subscription lifecycle states, and the developer-facing debugging surface (delivery logs, replay, test-event triggering). Use whenever the user mentions webhooks, event callbacks, push events to customer endpoints, webhook signatures, delivery retries, or a webhook consumer portal - even if they never say "webhook platform". Provider side only. Do NOT use for consumer-side retry mechanics - use samber/developer-platform-skills@api-idempotency-retry instead.

6 installs
▌
Developer Meetup Program · samber bundle
Designs and runs a recurring developer meetup or user group - purpose and host model, format menu, cadence, a standing speaker pipeline, in-kind venue and food sponsors with their conduct limits, no-show planning, the attendee-to-co-organizer ladder, and a health scorecard. Use whenever someone mentions starting a developer meetup or user group, dying meetup attendance, finding meetup speakers, getting a venue or pizza sponsor, how often to meet, RSVPs who never show, or handing the meetup over - even if they only say "we want to do local events". Covers independent, vendor-backed and company-staffed groups. Not for speaking at a conference - use samber/developer-relations-skills@conference-cfp-submission.

4 installs
▌
Devrel Budget Allocation · samber bundle
Splits a developer relations budget across pillars - events, content, community, tooling, education, OSS sponsorship - into line items that each carry a cash cost, an hours cost, a pre-set return threshold, a review date and a reallocation rule, plus a ranked cut list. Use whenever someone asks how to plan or split a devrel budget, how much to spend on events versus content versus community, whether a line item is worth its money, how to defend a devrel budget at review, or what to cut first when the budget shrinks - even if they only say "we spend too much on conferences". Not the metrics framework (samber/developer-relations-skills@devrel-metrics) or one event's ROI (samber/developer-relations-skills@developer-event-sponsorship).

4 installs
▌
Oss Sponsors Fundraising · samber bundle
Designs a maintainer-side open-source sponsorship program - the tier ladder and its pricing for individual and corporate sponsors, rewards that stay deliverable at ten times the sponsor count, funding-goal and sustainability framing, and the invoice-and-entity path a company needs before it can pay. Use whenever a maintainer asks how to get sponsors or funding for a project, sets up or fixes GitHub Sponsors, Open Collective or FUNDING.yml, writes sponsor tiers, rewards or a sponsorship page, wonders why nobody sponsors a widely used project, considers sponsorware, or wants a company to fund maintenance work - even if they only say the project is unsustainable. Not the company side - use samber/developer-relations-skills@oss-sponsors-brand-strategy.

3 installs
▌
Conference Cfp Submission · samber bundle
Turns a talk idea into a submission-ready conference proposal for one specific event, or helps choose which conferences to target and plan a submission calendar across several - track fit, title options, an attendee-facing abstract, verb-first takeaways, the reviewer-only fields, a credibility package, and a self-review against the committee's own criteria. Use whenever the user mentions a CFP, a call for papers, a conference proposal, a talk abstract, a session description, submitting to KubeCon, PyCon or FOSDEM, which conference to submit to, planning a CFP season, or says their proposals keep getting rejected - even if they only ask to shorten an abstract. Covers community-run and vendor-run events. Do NOT use for structuring the accepted talk (samber/developer-relations-skills@tech-talk-outline) or its demo (samber/developer-relations-skills@developer-live-demo-design).

4 installs
▌
Devtools Pricing Strategy · samber bundle
Designs the pricing and packaging architecture of a developer tool - the value metric (seats, consumption, capacity, outcome, or a hybrid), free-tier limits, the tier ladder up to enterprise gating, price points bounded by a margin floor and the self-host and build-it ceilings, and a plan to change prices without a backlash. Use whenever someone asks what to charge for a developer tool, how to package tiers, where free ends and paid begins, whether to bill per seat or per usage, how to price against their own open-source edition, or how to raise prices safely - even if they only say the pricing page feels wrong. Not which business model to run - use samber/developer-relations-skills@devtools-business-model. Not pricing-page copy.

4 installs
▌
Oss Distribution Strategy · samber bundle
Designs an open-source project's ongoing distribution mix after the launch window - registry metadata, code-host discovery surfaces, curated lists, downstream packaging, extension and connector marketplaces, the release stream, dependency-graph position, creator seeding, and procurement trust signals - ranked against real maintainer capacity. Use whenever a maintainer asks how people will keep finding the project, which registries or awesome lists to target, why adoption flattened after launch, how often to release for visibility, or how to spend limited maintainer hours on distribution - even if they only say nobody is using it. Not the launch itself - use samber/developer-relations-skills@oss-launch. Not the build-in-public practice.

4 installs
▌
Developer Community Health · samber bundle
Developer Community Health

4 installs
▌
Developer Community Launch · samber bundle
Decides whether, where and when to launch a developer community, then plans its seeding and first 90 days - venue selection, founding-member seeding, go/no-go criteria, the cheaper no-community alternatives, and shutdown criteria. Use whenever someone asks whether to start a Discord, Slack or forum for their users, which community platform to pick, how to launch or seed a developer community from zero, or how to reach critical mass - even if they only say "we should have a Discord". Do NOT use for a community that already exists; measurement is samber/developer-relations-skills@developer-community-health and moderation is samber/developer-relations-skills@developer-community-moderation.

6 installs
▌
Developer Keyword Research · samber bundle
Builds a prioritized keyword list for technical search queries (error strings, "how to X in Y" tasks, integration intents, comparisons, migrations) mined from docs search logs, support tickets, issue trackers and first-party query data rather than keyword-tool volume. Use whenever the user asks what developers actually search for, wants keywords for a developer tool, API, SDK or docs site, an error-message keyword list, demand sizing for a technical topic, or which docs pages to create from search demand - even if they never say "keyword". Does not write the pages. Do NOT use for on-page or docs-site SEO - use samber/developer-relations-skills@docs-seo.

2 installs
▌
Copywriting Tone Of Voice Creator · samber bundle
Builds a brand tone of voice guide (TONE.md) — voice attributes with do's/don'ts, NN/g positioning, tone modulation matrix, lexicon, channel rules — for downstream content skills to consume. Also ports an existing TONE.md to a new channel (blog → LinkedIn, web → Twitter/X, in-product UI). Covers B2B SaaS, B2C/D2C, NGO, public sector, consulting, industrial, product-led, personal, and volunteering brands. Apply when the user wants to define or refresh a brand voice, port it to a new channel, or set up a content factory. Not for writing individual posts, articles, emails, or UI strings — use the dedicated writing skills. Not for SOUL.md, PROSE.md (samber/cc-skills@copywriting-prose-creator), or DESIGN.md.

5 installs
▌
Golang CLI · samber bundle
Golang CLI application development. Use when building, modifying, or reviewing a Go CLI tool — especially for command structure, flag handling, configuration layering, version embedding, exit codes, I/O patterns, signal handling, shell completion, argument validation, and CLI unit testing. Also triggers when code uses cobra, viper, or urfave/cli. For cobra-specific APIs → See `samber/cc-skills-golang@golang-spf13-cobra` skill; for viper configuration layering → See `samber/cc-skills-golang@golang-spf13-viper` skill.

6 installs
▌
Crxjs · samber
CRXJS Chrome extension development — true HMR for popup, options, content scripts, side panels, manifest-driven builds, dynamic content script imports (`?script`, `?script&module`), and `defineManifest` for type-safe manifests. Uses Vite as its build tool. Use when the user mentions CRXJS, crxjs, @crxjs/vite-plugin, 'extension with hot reload', 'HMR for chrome extension', or wants to set up a CRXJS-based Chrome extension project with any framework (React, Vue, Svelte, Solid, Vanilla). Also trigger when the user has an existing CRXJS project and wants to add features, fix HMR issues, or configure content scripts with CRXJS. For general Chrome extension architecture (messaging, CSP, storage, permissions) -> See `samber/cc-skills@chrome-extension` skill.

5 installs
▌
Promql CLI · samber bundle
CLI for querying Prometheus and PromQL-compatible engines (Thanos, Cortex, VictoriaMetrics, Grafana Mimir, Grafana Tempo...) — instant queries, range queries, metric discovery (metrics/labels/meta subcommands), output formats (table/csv/json/graph). Apply when executing PromQL queries, troubleshooting performance issues on a software having observability, investigating latency/error rates/saturation, or analyzing time series data.

5 installs
▌
Deep Research · samber bundle
Deep research on any topic — broad parallel web searches, multi-source validation, confidence tracking, and a cited Markdown report. Use whenever the deliverable is a thorough sourced report rather than a quick answer: 'research <topic>', 'deep dive on X', 'analyze the landscape', 'competitive analysis', 'compare these options', 'who are the players in Z', 'literature review', 'background on Y', 'what papers exist on X', 'product teardown', 'regulatory overview', 'funding landscape', 'what trends are emerging in X', 'patent landscape', 'community health', or any request requiring scanning many sources and producing a cited written analysis. Covers 11 research types: market (TAM/SAM, segments, pricing, trends), domain (industry structure, ecosystem, regulatory overview), technical (architecture, tooling, benchmarks, technology evaluation), competitive (competitor teardown, positioning, win/loss), product (feature analysis, reviews, teardowns, roadmap signals), academic (literature survey, citation networks, ke

6 installs
▌
Humaniseur Fr · samber bundle
Remove AI-writing patterns from French text and inject voice and personality. Use when editing, reviewing, or rewriting French content that reads like ChatGPT or Claude output. Detects and fixes 38 patterns: AI vocabulary (crucial, essentiel, notamment, dans le paysage), anglicisms from English-first models (faire du sens, adresser un problème), formulaic openings (À l'ère de, Dans un monde où), participle clauses in -ant, em dash overuse, decorative emojis, mixed guillemets and apostrophes, uniform sentence length. Trigger on humaniser, déslopifier, nettoyer le texte IA, enlever le slop, make it sound human. Do NOT use for English text — use samber/cc-skills@humanizer-en-asd-ste100 instead.

4 installs
▌
Copywriting Cta · samber bundle
Designs end-of-article CTAs — copy, layout, placement, A/B test plan, accessibility — for blog posts, newsletters, and essays. Use whenever the user asks to write, review, or improve a CTA at the bottom of an article; mentions "end-of-post CTA", "call-to-action", "signup box", "newsletter CTA", "subscribe block", or "what should I put at the bottom"; or asks how to turn readers into subscribers, leads, customers, or paying supporters. Covers personal blogs, paid newsletters (Substack, beehiiv, Ghost), and brand content-marketing blogs. Do NOT use for opening hooks, ledes, or post titles — use samber/cc-skills@copywriting-hooks instead. Not for landing-page, ad, or email copy.

5 installs
▌
Chrome Extension · samber bundle
Build Chrome extensions with Manifest V3. Use this skill whenever the user mentions Chrome extension, browser extension, manifest.json, content script, service worker (in extension context), popup, side panel, chrome.runtime, chrome.tabs, chrome.storage, chrome.scripting, or any Chrome extension API. Also trigger when the user wants to inject scripts into web pages, communicate between page and background, bypass CSP from a content script, build an RPC layer over chrome messaging, or publish to the Chrome Web Store. Covers both new extension projects and adding features to existing ones. Do NOT use for CRXJS/Vite-based builds with HMR — use samber/cc-skills@crxjs instead.

2 installs
▌
Conventional Git · samber bundle
Conventional Commits v1.0.0 branch naming, worktree naming, and commit message standards for GitHub and GitLab projects. Use when creating branches, naming worktrees, writing commits, generating commit messages, reviewing branch conventions, or setting up changelog automation. Apply when your project needs consistent git history, SemVer-driven releases, parseable changelog generation, or automatic issue closing. Trigger when the user asks how to name a worktree, create a git worktree, or organize worktrees alongside branches.

4 installs
▌
Copywriting Hooks · samber bundle
Writes opening hooks and post titles for long-form articles in EN or FR — blog posts, Substack/Medium/dev.to, LinkedIn long-form, newsletters, essays. Trigger whenever the user asks for a hook, opening, lede, intro, first sentence/paragraph, opener, accroche, attaque, phrase d'accroche, or première phrase — including punching up a flat intro or draft opening — or for a post title, titre d'article, or headline. Do NOT trigger for social posts (LinkedIn feed, Twitter/X, TikTok, Bluesky), READMEs, taglines, email subjects, ad copy, landing-page headlines, press releases, SEO meta, or body rewrites. Do NOT use for end-of-article CTAs — use samber/cc-skills@copywriting-cta instead.

7 installs
▌
Press Release Writer · samber bundle
Write professional press releases for any occasion, media type, and region. Use when the user wants to write, draft, or improve a press release, communiqué de presse, media announcement, or news release — including product launches, funding rounds, partnerships, crisis communications, executive hires, events, M&A, and open source milestones. Covers media targets (print, digital/wire, broadcast, social/SMPR, trade press) and region-specific conventions worldwide. Also trigger on 'I need to announce something' or 'how do I tell the press about X'. Do NOT use for blog posts or technical articles — use samber/cc-skills@technical-article-writer instead; for newsletter issues, use samber/cc-skills@substack-ghostwriting.

3 installs
▌
Linkedin Ghostwriting · samber bundle
B2B LinkedIn ghostwriting — hooks, post structures, and copywriting frameworks for conversion-focused posts. Use when the user wants to write LinkedIn content, create ghostwritten posts, ghostwrite for a founder or executive, or develop a B2B social strategy. Apply when the user shares a story, result, or insight and wants it turned into a post. Do NOT use for newsletter or Substack issues — use samber/cc-skills@substack-ghostwriting instead.

6 installs

150 published skills · page 1 of 2