samber
User🧑🎨 A collection of agentic skills that works
Categories
Indexed Skills (142)
chrome-extension
Comprehensive guide for building 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, background script, MV3, Manifest V3, 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 framework-specific questions.
conventional-git
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.
copywriting-cta
Design end-of-article CTAs (calls-to-action placed at the bottom of blog posts, newsletters, essays, articles, or any long-form content). Use this skill whenever the user asks to write, design, review, or improve a CTA at the bottom of an article, blog post, or essay; mentions "end-of-post CTA", "bottom of the article", "call-to-action", "signup box", "newsletter CTA", "subscribe block", "what should I put at the bottom", "how do I get readers to subscribe / share / book a call / buy / follow / join / download"; or asks how to convert article readers into subscribers, leads, customers, community members, or supporters. Also trigger when the user wants A/B testing guidance or accessibility review for a CTA block. Covers independent / personal writing, newsletter publications, and brand / content-marketing blogs across any topic — tech, finance, food, climate, design, lifestyle, B2B, B2C. Produces both the copy (content) and the structural / visual design (form), matched to the user's objective and audience.
copywriting-hooks
Generate opening hooks and post titles for long-form articles in EN or FR — blog posts, Substack/Medium/dev.to, LinkedIn long-form, paid newsletters, opinion essays, reported features, technical deep-dives. 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 making a flat intro punchier or rewriting a draft opening. Also trigger when user asks for a post title, titre d'article, headline, or when ghostwriting skills reach the opening or titling step. Proposes 3-4 hooks pulling distinct psychological levers (curiosity gap, contrarian, scene, promise, authority), 2 candidates each, waits for the user to pick. Do NOT trigger for social posts (LinkedIn feed, Twitter/X, TikTok, Bluesky, Threads), READMEs or doc first lines, taglines, email subjects or openers, ad copy (Google/Meta Ads), landing-page headlines, press releases, SEO meta, fiction openings, talk/podcast/video script intros, or body rewrit
copywriting-prose-creator
Codifies how someone or a brand writes — prose mechanics (lexicon, syntax, rhythm, structure, signature moves) independent of emotional tone. Output: PROSE.md. Three modes: BUILD a fresh guide from SOUL.md + TONE.md + discovery interview; ADAPT an existing guide to a new channel; AUDIT a corpus for prose patterns before codification. Use when: writing rules for a content factory, codifying ghostwriting voice for multi-writer consistency, defining banned words and sentence-length targets, building a house style guide, reverse-engineering prose from a corpus, porting style across channels. Trigger on: PROSE.md, writing style guide, prose guide, house style, ghostwriter style, writing playbook, brand writing mechanics, signature moves. NOT for: writing actual content (→ linkedin-ghostwriting, technical-article-writer, press-release-writer), removing AI patterns (→ humanizer), tone decisions (→ copywriting-tone-of-voice), hooks (→ copywriting-hooks), CTAs (→ copywriting-cta).
copywriting-tone-of-voice-creator
Build a brand tone of voice guide (TONE.md) via discovery, voice definition, and channel modulation. Outputs voice attributes with do's/don'ts, NN/g positioning, tone modulation matrix, lexicon, mechanics, and channel rules — consumed by downstream content skills writing on-brand copy. Covers B2B SaaS, B2C/D2C, NGO, public sector, consulting, industrial, product-led, personal, and volunteering brands; researches uncovered contexts (politics, regulated niches, religious orgs, gaming) on demand. Also adapts an existing TONE.md to a new channel (blog → LinkedIn, web → Twitter/X, in-product UI). Optionally consumes SOUL.md to pre-fill brand identity. Apply when the user wants to create a TONE.md, define brand voice, port voice to a new channel, refresh an outdated voice, or set up a content factory writing across many supports. Not for writing individual posts, articles, emails, or UI strings (→ dedicated writing skills), nor SOUL.md, PROSE.md, DESIGN.md.
crxjs
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.
deep-research
Deep research skill — broad parallel web searches, multi-source validation, confidence tracking, cited Markdown report. Supports 11 research types: market (TAM/SAM, segments, pricing, trends), domain (industry structure, ecosystem, regulatory landscape), technical (architecture, tools, benchmarks), competitive (competitor teardown, positioning, win/loss), product (feature analysis, reviews, roadmap signals), academic (literature survey, citation networks, key authors), person/org (due diligence on a company or public figure), financial (funding rounds, valuation multiples, revenue signals), legal (IP, patents, litigation, compliance), trend (emerging signals, foresight, scenario mapping), community (ecosystem health, key voices, governance, fragmentation). Use when asked to: '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', 'technology
frontend-design-deslop
Produce distinctive, non-generic UI and design applications well, working strategy-first. Identify the project (landing page, SaaS app, dashboard, ecommerce, presentation, docs, portfolio...) and its positioning and personality, commit to brand adjectives, translate into a typography and color system, then apply the craft layer (layout, components and states, motion, iconography, imagery, dark mode and theming, accessibility), avoiding the AI-slop / Claude-esque default. This is both a de-slop and an expert app-design skill. Use this whenever building or styling any web frontend, app, dashboard, landing page, deck, or artifact, or when the user says "make it not look like AI", "de-slopify", "deslop", "less generic", "give it character", "design a UI for X", "design an app", "update DESIGN.md", or complains the output looks like every other AI site. Trigger even when the user just says "build a UI for X" without naming an aesthetic, because the default without this skill is slop.
humaniseur-fr
Remove AI-writing patterns from French text and inject voice, personality, and soul. Use when editing, reviewing, rewriting, or cleaning up French content that reads like ChatGPT/Claude output. Humanize, humanise, déslopifier. Detects and fixes 27 patterns: AI vocabulary overuse (crucial, essentiel, notamment, par ailleurs, dans le paysage), anglicisms from English-first models (faire du sens, adresser un problème), copula avoidance, formulaic openings (À l'ère de, Dans le paysage actuel), superficial participle analyses (-ant), em dash overuse, redundant adjective doublets, rule of three, sycophantic tone, typographic tells (curly quotes instead of guillemets). Trigger on: humaniser, déslopifier, rendre plus humain, nettoyer le texte IA, enlever le slop, réécrire pour que ça sonne humain, make it sound human.
influence-and-negotiation
Influence and negotiation toolkit for any interaction requiring another person's agreement, even when not framed as 'negotiation'. Covers: B2B sales, salary review, collective bargaining/unions, hard 1:1s, decision announcements, mediation, cross-cultural deals, recruitment, reaching out to a manager, CFO, customer, vendor, or colleague, responding to feedback, headcount requests, declining, pushing back on scope, justifying a delay, explaining a decision, raising a concern, getting alignment. Apply when preparing, live, or drafting any diplomatic message. Triggers: coaching prompts ('they just said X', 'what do I say', 'draft a reply'); counterparty cues (buyer, customer, champion, procurement, RFP, sponsor, HR, union, CHRO, ExCo, candidate, counter-offer, partner, peer); situation cues (pushback, refusal, ghosted, no-decision, escalation, fixed budget, MFN, raise, comp band, strike, layoff, recadrage, expectation reset, M&A, BATNA, objection, concession, anchor, mirroring).
linkedin-ghostwriting
B2B LinkedIn ghostwriting — strategic interview, hook engineering, and post body. Use when the user wants to write LinkedIn content, create ghostwritten posts, ghostwrite for a founder or executive, develop a B2B social strategy, or needs hooks, post structures, or copywriting frameworks for LinkedIn. Apply when the user shares a story, result, or insight and wants it turned into a post.
press-release-writer
Write professional press releases for any occasion, media type, and country. Use when the user wants to write, draft, or improve a press release, communiqué de presse, media announcement, news release, or PR statement — including product launches, funding rounds, partnerships, crisis communications, earnings, executive hires, events, M&A, open source milestones, and media advisories. Covers all release types, media targets (print, digital/wire, broadcast, social/SMPR, trade press), and region-specific conventions (Western/Eastern Europe, Americas, Middle East, Africa, Asia, Oceania). Also trigger when the user says 'I need to announce something' or 'how do I tell the press about X.'
promql-cli
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.
site-launch-checklist
Pre-launch checklist for shipping a new website. Orchestrates analytics setup (GA4, PostHog, Google Search Console, Ahrefs), legal compliance, security headers and audit, SEO and GEO with keyword research validated against Google Trends (robots.txt, sitemaps, llms.txt, AI policy, schema markup, hreflang), copywriting consistency via a TONE.md and a humanizer pass in the matching language, OpenGraph and social previews, full favicon set with manifest, quality gates (Lighthouse, Core Web Vitals, WCAG accessibility, mobile testing), and setup of a weekly SEO agent. Use this skill whenever the user mentions launching a site/app, deploying a domain to production, pre-launch audit, shipping a marketing/docs/SaaS site or lead magnet, or says "checklist for the site", "ready to ship", "before I go live", "audit before launch", "ready for prod", or asks for a site review.
skill-progressive-disclosure-design
Decide how to split skill content between SKILL.md and reference files for context efficiency and reliable triggering. Use this whenever creating a new Claude skill, refactoring an existing one, or when a SKILL.md is growing past 300-400 lines. Also trigger when the user mentions "progressive disclosure", "reference files", "splitting skills", "skill bundling", "context window for skills", "SKILL.md too long", "what goes in references/", "skill structure", or expresses any uncertainty about where to put content within a skill. Use this even if the user phrases the question as a triggering problem ("how do I make my skill trigger better"), because that question is often confused with the splitting question and needs to be disentangled first.
substack-ghostwriting
Write, optimize, and grow Substack content — both newsletter issues (email-first) and web posts (web-first articles/essays). Covers ghostwriting with voice matching, Substack algorithm optimization, Notes strategy, email formatting, SEO, growth tactics, and monetization planning. Use when the user mentions Substack, newsletters, write a newsletter issue, Substack post, Substack article, web post on Substack, evergreen content, SEO for Substack, newsletter growth, Notes strategy, ghostwrite for, match someone's voice, write in the style of, newsletter monetization, paid subscribers, or any task involving Substack as a platform. Also trigger for general article/newsletter writing even if Substack isn't named explicitly, or when the user wants to adapt existing content (blog post, talk, thread) into newsletter or web post format. Do NOT use for generic blog post writing without a newsletter/Substack context (-> See samber/cc-skills@technical-article-writer skill).
technical-article-writer
Write compelling technical articles and blog posts for developer audiences. Use this skill whenever the user asks to write a blog post, technical article, or any long-form technical content. Also trigger when the user says 'write about [technical topic]', 'help me draft an article', 'turn this into a blog post', 'write a post about', 'I want to publish something about', or mentions writing for a developer audience. Covers the full pipeline: idea sharpening, hook/title generation, article structure, body drafting, and editing. Even if the user just says 'I want to write about X' without specifying format, use this skill. Do NOT use for platform-specific optimization, newsletter strategy, or ghostwriting voice matching.
training-report
Produce a professional training/workshop report as a .docx file. Use this skill whenever the user mentions "training report", "workshop report", "compte rendu", "compte rendu de formation", "formation report", "debriefing a workshop", "write up a training session", "résumé de formation", or any request to document a training session, workshop, or onboarding event with individual participant feedback and recommendations. Also trigger when the user says things like "I just ran a workshop and need to write it up", "help me summarize what happened in my training session", or "I need to report back to management about a session I ran". Always use this skill — for short or long sessions, across any discipline (technical, soft skills, creative, compliance, onboarding, etc.) — whenever a structured written deliverable about a training event is needed.
api-error-design
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.
api-idempotency-retry
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).
api-integration-surface-strategy
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.
api-rate-limit-policy
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.
api-reference-quality
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.
api-status-communication
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.
api-test-mode-design
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.
api-versioning-policy
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.
app-marketplace-launch-marketing
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.
app-marketplace-listing-standards
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.
app-marketplace-monetization-model
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.
app-marketplace-review
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.
bulk-data-sharing-design
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.
connector-marketplace-strategy
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).
developer-platform-career
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).
developer-platform-hiring
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).
developer-platform-kickoff
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.
developer-portal-design
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.
etl-connector-strategy
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.
integration-error-observability
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.
integration-partnership-strategy
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.
mcp-server-offering
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.
oauth2-provider-design
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.
partner-app-onboarding
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).
public-api-design-review
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.
public-graphql-api-design
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.
public-grpc-api-design
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.
sdk-portfolio-strategy
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.
sql-jdbc-access-design
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.
webhook-platform-design
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.
business-event-formats
Choose which company-run event shape to run - invite-only dinner, executive summit, single-city user conference, multi-city roadshow, or a floor-primary trade-show event - plus how its program is sourced and what shape its floor takes. Use whenever a company weighs a user conference against a roadshow or a summit, asks what kind of event to put on for developers, customers or partners, or asks whether to run its own floor or exhibit on someone else's, even if they only say "we want to do an event". Format catalog only. Do NOT use for track count or session mix - use samber/dev-event-organizer-skills@event-format-selection; for floor operations use samber/dev-event-organizer-skills@event-booth-experience; for goals and budget use samber/dev-event-organizer-skills@corporate-event-strategy.
corporate-event-strategy
Decide what a company-run technical event is funded to accomplish, before anyone plans it - the goal mix (ecosystem goodwill, developer adoption, customer retention, sales pipeline, or a blend), who owns the budget line and which functions co-fund it, and the measurement commitment written before registration opens. Use whenever a company asks why it is running a user conference, community day, developer summit or roadshow, which goal to optimise, who should pay for it, or how to prove it worked to the people funding it, even when they only say "what is the ROI of our conference". Strategy layer only. Do NOT use to pick the event shape - use samber/dev-event-organizer-skills@business-event-formats - or to model the P&L - use samber/dev-event-organizer-skills@event-budget.
cross-event-promotion
Set up reciprocal promotion between independent technical events run by different organizers - partner-event scoring, the swap-format menu (community-calendar cross-listing, newsletter or social mention swaps, ticket-discount code swaps, speaker-pipeline sharing, conference-week co-location), the organizer-to-organizer ask, a lightweight swap agreement, and delivery measurement on both sides. Use whenever asked to cross-promote with another event, arrange a promo or ticket-code swap, co-locate with a bigger conference, or coordinate speakers across a circuit of independent events. Do NOT use for one organizer's own portfolio - use samber/dev-event-organizer-skills@event-portfolio-strategy - or deals with media outlets - use samber/dev-event-organizer-skills@event-media-partnerships.
dev-event-career
Plans a tech-event-organizing career from the candidate side - producer/manager/coordinator roles, and the community-manager-shaped end of the field. States plainly that no universal title ladder exists, gives the one real named ladder and CMX's community-management ladder as the closest dev-event-adjacent counterpart. Covers the volunteer-to-paid entry path, interview prep (portfolio review, scenario questions, CMX's five-competency loop, the paid mini-audit work sample), named practitioner quotes including Google I/O's own executive producer, and compensation across in-house, agency and non-profit contexts. Use when the user asks how to break into event organizing, prep for a producer or community-manager interview, or evaluate an offer. Do NOT use for hiring (samber/dev-event-organizer-skills@dev-event-hiring) or team org design (samber/dev-event-organizer-skills@event-team-structure).
dev-event-hiring
Employer-side hiring for tech-event-organizing roles - producer/manager/coordinator, and the community-manager-shaped end of the field. Calibrates the scorecard to operating context (in-house, agency, non-profit/community, or a standing conference business), builds the loop from the general event-planner sequence plus CMX's five-competency set and paid mini-audit work sample, flags the "one hire owns sponsorship, content and production" consolidation pattern seen in postings, sources candidates from general event-industry boards since no tech-specific one exists, and gates compensation on named sources (PCMA, BLS, Glassdoor) rather than a blended figure. Use when the user asks how to hire an event producer or manager, write a posting, design a loop, or hire an event community manager. Do NOT use for candidate prep (samber/dev-event-organizer-skills@dev-event-career) or team org design (samber/dev-event-organizer-skills@event-team-structure).
dev-event-kickoff
Before answering any event-organizing request that opens a new project or a new session, run this router first - it maps the task onto the 71-skill samber/dev-event-organizer-skills collection, or says plainly that none fits, and bootstraps or resumes the project's shared context so the next session starts warm. This fires on a conversational state, not on a subject - invoke it at every event project start even when the collection's skills are already in daily use on another event, at every recurring check-in on the same project, and whenever routing between siblings is unclear. Covers conference, meetup and hackathon kickoffs, "which event skill do I need", "where do I start organizing this event", event organizer skill routing, and recurring event check-ins. Use this whenever someone describes an event-organizing problem without naming a skill, even if they never say "kickoff", "routing" or "start".
event-accessibility-inclusion
Decide which accessibility and inclusion provisions a technical event commits to - the physical, sensory, dietary, economic and digital-access set, at what depth, sized for whom, funded from where - plus the public declaration of it and the data-handling posture for accommodation requests. Use whenever asked what accessibility a conference should offer, whether to caption talks, whether to run a quiet room, childcare or travel grants, how to write an accessibility page, or how to answer an accommodation request, even if the user never says "accessibility". Decides the bar, not delivery. Do NOT use for the code of conduct - use samber/dev-event-organizer-skills@event-code-of-conduct. Not legal advice; access duties vary by jurisdiction.
event-attendee-email-sequences
Design and write the attendee email arc for a technical event - the sequence, the cadence, and the actual copy. Covers the dated arc from announcement to post-event follow-up, a sourced reminder cadence with per-segment caps rather than a SaaS drip, the know-before-you-go email, role and registration-state segmentation, consent and list hygiene, and a humanizer pass before anything sends. Use whenever asked to write an event announcement email, registration confirmation, week-before or day-before reminder, know-before-you-go, day-of or post-event follow-up, or to decide how many emails to send and when. Do NOT use for overbooking, waitlists or seat release - use samber/dev-event-organizer-skills@event-no-show-management.
event-attendee-experience
Design the general-attendee on-site journey for a technical event - check-in desk and badge pickup, the badge's privacy and scanning posture, wayfinding and signage, the quiet room and other facilities, meal and dietary mechanics, the help path, first-time-attendee orientation, and a walkthrough audit of the finished design. Use whenever asked how to run conference check-in, whether to put a QR code on a badge, where the quiet room goes, how to sign a venue so people find rooms, how to hand out dietary-restricted meals, what a help desk should cover, or how a first-timer finds their feet. Starts at the door. Do NOT use for registration or no-show mechanics - use samber/dev-event-organizer-skills@event-no-show-management; speakers, sponsors and volunteers have their own journey skills.
event-b2b-matchmaking
Design a technical event's structured 1:1 business meeting program - whether to run one at all, how the two sides are matched (directory, brokering, mutual opt-in, scored ranking), how slots get booked inside the grid, what meeting quota a sponsor package may honestly commit to, how a booked-meeting no-show is absorbed, and what to measure. Use whenever asked to set up scheduled 1:1 meetings at an event, run buyer-seller or founder-investor matchmaking, promise a sponsor a number of meetings, or build a booked-meeting timetable. Matches two populations for business conversations. Do NOT use for hackathon build-team formation - use samber/dev-event-organizer-skills@hackathon-team-formation - or the expo floor - use samber/dev-event-organizer-skills@event-booth-experience.
event-booth-experience
Design a technical event's expo floor once per edition, organizer-side - the layout and traffic pattern carrying attendees past every booth, the tier-to-physical-spec catalog turning "floor presence, Gold" into table size, power, height and signage rules, the master setup and teardown schedule, per-booth power and WiFi distribution, booth staffing and conduct rules, and a floor-wide traffic mechanic such as a passport card. Use whenever asked how to lay out an expo hall or sponsor area, what a sponsor tier's booth physically includes, when sponsors load in and out, or how to pull attendees past low-traffic booths. Do NOT use for per-sponsor day-of execution - use samber/dev-event-organizer-skills@event-sponsor-fulfillment - or for how a company runs its own booth.
event-budget
Build the budget and P&L for a technical event - every cost line split into fixed and per-head, the revenue mix against the funding model, a Good/Better/Best scope-tier ladder so break-even has three answers instead of one, a contingency sized as a stacked floor, pad and downgrade ladder, and outflows scheduled against the dates sponsor and ticket money actually lands. Use whenever asked to build an event budget, model conference or hackathon costs, find break-even, size a contingency reserve, plan event cash flow, or decide what to cut when revenue falls short. Consumes prices and real vendor quotes, never sets them. Do NOT use to set ticket or sponsor prices - use samber/dev-event-organizer-skills@event-ticket-pricing or samber/dev-event-organizer-skills@event-sponsor-pricing.
event-cfp-design
Design a technical event's call for papers - the published call, not the selection behind it. Covers the CFP open/close timeline worked back from the event date, submission form fields, which session formats the call offers, the anonymization posture (named, opt-in, or mandatory blind review), review criteria published in the call itself, stated speaker benefits, per-person submission caps, first-time-speaker support, and the CFP tooling capabilities to look for. Use whenever asked to open or write a CFP, set a CFP deadline, design a talk submission form, decide on blind review, or state speaker perks in a call for proposals. Do NOT use to review or score submissions - use samber/dev-event-organizer-skills@event-talk-selection.
event-code-of-conduct
Write a technical event's code of conduct and build the enforcement pipeline behind it - what the policy has to say, who and which spaces it binds (attendees, speakers, volunteers, sponsor and booth staff, satellite events), the reporting channels including an anonymous path, response-team composition and rehearsal, the on-site incident runbook and its response clock, the sanctions ladder, which rungs carry an appeal, and the transparency report. Use whenever asked to write or review an event or conference code of conduct, set up incident reporting, staff or train a CoC response team, decide a sanction for an attendee, or handle an on-site incident. Do NOT use for accessibility provisions - use samber/dev-event-organizer-skills@event-accessibility-inclusion. Not legal advice.
event-comms-channels
Design the attendee-facing communication channel architecture for one edition of a technical event - which channels exist, who is on each, which class of message routes to which channel, how several writers stay consistent executing a register set elsewhere, and how every channel is wound down once the event ends. Use whenever asked whether an event needs a chat space, an app or a status page, where a room change or schedule slip should be announced, how to stop attendees missing announcements, who may post in the event's name, or what to do with the event's channels after it is over. Do NOT use for mailing-list copy and consent - use samber/dev-event-organizer-skills@event-attendee-email-sequences - or social copy - use samber/dev-event-organizer-skills@event-social-media.
event-community-building
Animate one recurring technical event's own audience in the gaps between editions - the cadence posture for the standing space, the conversion of attendees into returning participants and contributors, keeping a local cohort of the same event's fans warm, and handing the community asset over when organizers change. Use whenever asked how to keep an event's community alive between editions, what to post in the quiet months, whether a between-editions space should stay dormant or be programmed, how to make attendees come back next year, or who takes over the community platform when an organizer leaves. Do NOT use to decide whether that space belongs in the team's property set at all - use samber/dev-event-organizer-skills@event-portfolio-strategy.
event-content-repurposing
Turn one edition's already-captured material into derivative published artifacts after the event - which formats get made, on what cadence, under which licence, and what speakers are asked to amplify. Covers publishing latency (dump, batched, drip, evergreen), the rights gate on third-party slide material and attendee photos, and the inventory handed up to the next edition's campaign. Use whenever asked what to do with talk recordings after a conference, how to turn an event into clips, write-ups or transcripts, when to release them, or whether footage can be republished at all. Do NOT use for capturing or editing the master recording - use samber/dev-event-organizer-skills@event-production - or the event's own channels - use samber/dev-event-organizer-skills@event-social-media.
event-continuous-improvement
Turn several editions of a recurring technical event's debrief logs into operational trends and deliberate changes - a signal gate separating a one-off from a reproducible pattern, themes grouping differently-worded findings, recurrence counts across editions, a learning log persisted so it survives organizer turnover, an audit so it never grows unexamined, and a route from each resulting change to the sibling that owns it. Use whenever asked what keeps going wrong every year, how to stop relearning the same lessons, how to keep institutional memory across a team that turns over, or what several editions of evidence say to change next. Do NOT use for one edition's retrospective - use samber/dev-event-organizer-skills@event-debrief.
event-cultural-identity
Design and audit the lived culture of a technical event - the register (hacker, corporate, design, business) and its consistent expression across venue, catering, swag, dress code, stage production, MC and hosting tone, opening and closing ceremonies, and the values a code of conduct puts in the room. Use whenever asked to define an event's vibe or cultural identity, design a signature tradition or ritual, script an opening or closing, brief an MC or organizer-hosts, choose a swag posture, or audit an event whose stated values and on-site experience contradict each other. Embodiment only. Do NOT use for what the event stands for - use samber/dev-event-organizer-skills@event-positioning - or CoC policy and enforcement - use samber/dev-event-organizer-skills@event-code-of-conduct.
event-date-selection
Pick the date a technical event runs on - the decision every other plan hangs off. Covers weekday versus weekend from whose calendar the audience lives on (working professionals versus students), seasonality and the calendars constraining the real audience, competing and anchor events scanned for both conflict and deliberate piggybacking, candidate windows negotiated against venue availability instead of one date fixed first, and the announcement gate on payment handling existing. Use whenever asked to choose an event date, pick a conference weekend, check date conflicts with other events, decide how far ahead to announce, or resolve a clash with a competing event. Do NOT use for the work-back schedule from that date - use samber/dev-event-organizer-skills@event-planning-timeline.
event-debrief
Run the organizing team's own internal retrospective on one finished edition of a technical event - the blameless frame, the reconstructed timeline, what went well split from what went poorly, what fired reconciled against the risk register, budget plan and run of show, team-health findings, and dated lessons-learned entries each carrying an owner and a due date. Use whenever asked to run a post-event debrief, a post-mortem or a retrospective after a conference, meetup or hackathon, review an edition against the goals the team set, build a lessons-learned log, or publish a public recap. Do NOT use to collect participant feedback - use samber/dev-event-organizer-skills@event-feedback - or for trends across editions - use samber/dev-event-organizer-skills@event-continuous-improvement.
event-feedback
Design and run participant-feedback collection for one edition of a technical event - what gets asked, who answers it, through which channel, when it goes out, and what goes back to respondents. Covers format-adapted question sets (meetup pulse, conference satisfaction and return intent, hackathon team dynamics, mentors, judging fairness, project continuation), attendee, speaker and sponsor segmentation, in-room versus emailed collection against real response-rate data, survey length, anonymity and free text. Use whenever asked what to put in a post-event survey, when to send it, how to fix a response rate nobody answered, how to survey a hackathon, or what to do with the answers. Do NOT use for the team's own retrospective - use samber/dev-event-organizer-skills@event-debrief.
event-first-edition
Launch the first edition of a tech event (conference, hackathon, large meetup) from zero - a minimum viable edition 1, scope discipline against the full vision, the first cross-organization team, the decision-to-doors-open reverse timeline, and a pre-mortem of first-edition-specific risks with written go/no-go dates. Use whenever asked to start a new conference or hackathon, plan a first edition, scope a minimum viable event, form a founding organizer team, or set a launch timeline for an event with no track record. Strategy layer for edition 1 only. Do NOT use to validate demand first - use samber/dev-event-organizer-skills@event-market-fit - or to grow an established event - use samber/dev-event-organizer-skills@event-growth-strategy.
event-format-selection
Choose a technical event's structure before anything is scheduled - the event shape (recurring meetup, hackathon, unconference day, single-day or multi-day conference), one program or several (single versus multi-track), workshop-day ratios, the session-format mix (curated talks, workshops, open space, ignite, fireside chats, panels), delivery mode (in-person, virtual, hybrid), and hackathon demo/judging structure. Use whenever asked to pick an event format or concept, decide single-track versus multi-track, weigh hybrid or virtual delivery, compose a session mix, or graduate a meetup into a conference. Structural choice only. Do NOT use for schedule grids, clash avoidance or room-capacity matching - use samber/dev-event-organizer-skills@event-schedule-design.
event-growth-strategy
Grow an established technical event edition over edition, or decide not to - the demand-headroom read, one discrete lever per edition (venue squeeze, track or day addition, venue step-up, price-led growth), the contract-risk gate on venue moves (deposits, attrition penalties, F&B minimums, long lead times), the pricing posture before scaling, and deliberate non-growth (caps, lotteries, shrinking back down) as a real strategy. Use whenever asked whether a conference or hackathon should grow, how to scale capacity, whether to add a track, a day or a venue, or how to stay small under excess demand. Do NOT use for a first launch - use samber/dev-event-organizer-skills@event-first-edition - or multi-event portfolios - use samber/dev-event-organizer-skills@event-portfolio-strategy.
event-hospitality
Decide the food, drink and social provision every population at a technical event shares - the catering service style and the dietary counts it has to carry, what a scheduled break contains, the event's alcohol posture, and whether an evening or social programme exists and in what form. Use whenever asked what format to feed a conference in, how catering should cover dietary restrictions across a whole event, what to put in a coffee break, whether to serve alcohol or run the event dry, or what to do on the evening of a conference day. Sets the shared floor only. Do NOT use for how many social occasions run - use samber/dev-event-organizer-skills@event-official-social-program - or which dietary needs the event commits to - use samber/dev-event-organizer-skills@event-accessibility-inclusion.
event-landing-page
Build a technical event's public front door and the small site around it - the page shape for the funding model (a ticketed event's single-CTA hero, or a free event's stats hero with no registration to sell), the section set, a date-gated CTA state machine so Propose renders only during the CFP window and Register only inside the registration window, the accessibility target, and the event structured data. Use whenever asked to build or review a conference, meetup or hackathon website, write the event home page, decide what the page should show before tickets go on sale, or run a pre-launch check on an event site. Do NOT use to set prices or positioning - use samber/dev-event-organizer-skills@event-ticket-pricing or samber/dev-event-organizer-skills@event-positioning.
event-learning-expedition-design
Decide whether to take a technical audience into an organization the organizer does not control, and on what terms - when a host's own premises, operation and staff are the programme rather than a room rented and filled by the organizer. Sets the host-dependency posture (host speaker hosted in-house, one host site host-led or to a negotiated agenda, a multi-host circuit) and the access posture, meaning what the host lets attendees see and repeat afterwards. Use whenever asked to design a learning expedition, company tour, field trip, site-visit programme or executive immersion. Do NOT use for catering - use samber/dev-event-organizer-skills@event-hospitality - or multi-venue logistics - use samber/dev-event-organizer-skills@event-production. States no legal threshold or instrument.
event-market-fit
Read whether a technical event's concept, audience and price combination actually meets demand - before launch (community baseline, CFP oversubscription, saturation mapping), mid-sale (checkpoint ladder and pace index against expected sales), and after an edition (attendee return, sponsor renewal, sellout-speed trend) - composed into a go, hold, pivot or stop call. Use whenever asked to validate demand for a conference, hackathon or a meetup-to-conference jump, judge whether ticket sales are on pace, decide whether an event should recur or scale, or diagnose why an edition underperformed. Reads signals only. Do NOT use for launch scoping - use samber/dev-event-organizer-skills@event-first-edition - or growth levers - use samber/dev-event-organizer-skills@event-growth-strategy.
event-marketing-plan
Build the attendee-acquisition plan for a technical event - audience segments mapped to channels, the campaign-calendar spine (a ticketed event's percent-of-ticket-sales ladder or a free event's percent-of-attendance-goal curve), campaign moments pinned to pricing and program dates fixed elsewhere, budget allocated across the channel mix, funnel targets per phase, and each channel routed to the sibling that executes it. Use whenever asked to plan how to fill an event, run a ticket-sales or registration campaign, choose promotion channels, split promotion budget, or set registration targets by date. Do NOT use for the email copy itself - use samber/dev-event-organizer-skills@event-attendee-email-sequences - or ticket prices - use samber/dev-event-organizer-skills@event-ticket-pricing.
event-media-partnerships
Set up barter media and community partnerships for a technical event - visibility-for-visibility deals with newsletters, podcasts, online communities and developer-ambassador programs, where no cash changes hands. Covers deal classes, partner types, the exchange format (calendar listing, logo-and-social swap, newsletter mention swap, podcast exchange, full media-partner tier), the deal terms, and both sides' delivery tracking. Use whenever asked to find media partners, set up a community-sponsor tier, trade newsletter mentions or podcast slots for event visibility, or formalize a logo-for-promotion deal. Do NOT use for earned press - use samber/dev-event-organizer-skills@event-press-relations - or swaps with other events - use samber/dev-event-organizer-skills@cross-event-promotion.
event-official-social-program
Decide how many official social occasions a technical event runs and how they sit against each other one occasion, two on separate slots, or a themed multi-activity track - plus the inclusion floor a whole slate must clear rather than each activity separately. Use whenever asked whether to run more than one social activity, whether two social activities can run in the same hours, how to publish a social track, or which activity a caregiver or a non-drinker can be in. Do NOT use for a single occasion's format, food, drink or alcohol posture - use samber/dev-event-organizer-skills@event-hospitality - third-party satellites - use samber/dev-event-organizer-skills@event-side-event-coordination - or invite-only gatherings - use samber/dev-event-organizer-skills@event-vip-social-program.
event-planning-timeline
Build the months-long work-back plan for a tech event, any edition - the doors-open anchor date, parallel tracks (venue, program/CFP, sponsors, marketing, ticketing) each worked back from that date, cross-track dependency gates, a buffer policy through latest-safe commitment dates, and replanning checkpoints that cut scope instead of moving the date. Use whenever asked to build an event planning timeline, conference retroplanning, a work-back or reverse schedule, event milestone sequencing, or to replan an event running behind schedule. Scheduling mechanics only. Do NOT use to pick the date itself - use samber/dev-event-organizer-skills@event-date-selection - or for the day-of run of show - use samber/dev-event-organizer-skills@event-run-of-show.
event-portfolio-strategy
Shape one organizing team's set of event properties - flagship conference, meetup series, hackathon, podcast or always-on online space - into a portfolio where each one feeds the others. Covers what each property is for, the funnel path between them, cadence collisions against one team and audience, how much brand, audience list, team and sponsors are shared, the allocation posture, and add/kill criteria written before they are needed. Use whenever asked whether to add a second event or format, how a meetup feeds a conference, how to keep momentum between editions, or which property to retire. Do NOT use for growing one event - use samber/dev-event-organizer-skills@event-growth-strategy - or swaps with other organizers' events - use samber/dev-event-organizer-skills@cross-event-promotion.
event-positioning
Define a technical event's positioning - what it stands for, against which alternatives, for which audience identity. Covers the governance axis (community-run, foundation, media-run, vendor-owned), competitive-alternative mapping, best-fit attendee and sponsor segments, market-category strategy (head-to-head, subcategory, new category and its education tax), the positioning statement, contrast-not-attack anti-positioning, and the rebrand gate. Use whenever asked to position a conference, meetup or hackathon, differentiate it from neighboring events, decide who it is for, write a positioning statement, weigh a vendor-neutrality claim, or judge an event rename. Strategy only. Do NOT use for on-site embodiment - use samber/dev-event-organizer-skills@event-cultural-identity.
event-press-relations
Run earned press coverage for a technical event - a one-way ask, not a barter deal. Covers whether to pursue press at all (most community events correctly do not), a two-lane accreditation policy for editorial journalists and independent bloggers or creators, the ungated media page, announcements pegged to the CFP, lineup, programme, on-sale and wrap-up beats, the embargo posture, the on-site press operation and interview logistics, and the single spokesperson designated before an incident needs one. Use whenever asked about press accreditation, a press kit or media page, pitching journalists about an event, embargoed announcements, a press room, or who speaks to reporters. Do NOT use for barter media partnerships - use samber/dev-event-organizer-skills@event-media-partnerships.
event-production
Engineer the technical AV production of a technical event once the format and session grid are fixed - capture tiers from a single smartphone to multi-camera vision mixing, signal-path architecture separating room display from recorded output and crew monitor, redundancy against named recorded-audio failure modes, AV crew roles, the written technical spec handed to venue sourcing, the Media budget line, rehearsal, and the publication pipeline. Use whenever the user mentions conference AV, recording or livestreaming talks, cameras, microphones, an AV supplier brief, or a backup plan for a technical failure - even if they never say "production". Do NOT use to decide whether to run hybrid or virtual at all - use samber/dev-event-organizer-skills@event-format-selection instead.
event-run-of-show
Write and run the day-of run of show for a technical event once the schedule is published - the minute-by-minute playbook staff execute from, day-of role assignment (MC, speaker introducers, room leads, the organizer on duty), cue sheets at every transition, an organizer-only comm channel kept separate from attendee-facing ones, the escalation path and live incident response, shift rotation with verified handoffs, and closeout. Use whenever the user mentions a day-of rundown, a cue sheet, MC or room-lead roles, organizer radios or Slack channels, shift handoffs, or deciding live what to cut when a session overruns - even if they never say "run of show". Do NOT use to build the grid itself - use samber/dev-event-organizer-skills@event-schedule-design instead.
event-schedule-design
Lay a technical event's already-selected talks into a published session grid - session-length standardization, room and capacity matching, the four clash types with multi-speaker intersection, break and lunch placement, buffer sizing, keynote and plenary placement as re-sync points, synchronized versus staggered track starts, energy-curve pacing, and speaker travel windows against slot assignment. Use whenever the user mentions building a conference schedule or agenda, a multi-track layout, session clashes or speaker double-booking, matching talks to rooms, sizing breaks, or when to publish the grid - even if they never say "schedule". Do NOT use to decide the track count or session-format mix - use samber/dev-event-organizer-skills@event-format-selection instead.
event-side-event-coordination
Approve and coordinate third-party-run satellite events around a technical event - the vetting gate, calendar deconfliction against the published grid, name and logo usage rules, and the disclaimer stating what the main event does not vouch for. Use whenever a user group, sponsor or attendee wants to run a party, meetup, dinner, workshop or afterparty during the event's dates, when someone is already using the event's name on their own page, or when fringe events collide with the main programme - even if they never say "side event". Approving nothing is often the right answer; routes trademark and liability exposure to counsel. Do NOT use for the organizer's own evening programme - use samber/dev-event-organizer-skills@event-official-social-program instead.
event-social-media
Run a technical event's own social presence inside the weight, phase and dates the marketing plan already fixed - platform selection, the campaign versus community hashtag, posts mapped onto campaign phases (announcement, CFP, speaker reveal, final push, live), speaker and sponsor amplification asks, and day-of coverage. Use whenever the user mentions event social media, a conference or hackathon content calendar, speaker-announcement posts, which platforms an event should post on, an event hashtag, or briefing a volunteer on live posting - even if they never say "social media". Do NOT use for channel weight and budget - use samber/dev-event-organizer-skills@event-marketing-plan; mining talk recordings afterwards is samber/dev-event-organizer-skills@event-content-repurposing.
event-speaker-cold-outreach
Write and sequence the cold invitation to a speaker a shortlist already picked - the message, not the search. Covers what a first invitation must disclose up front (event basics, honest budget and travel terms, the answer deadline, how you found them), personalization built from the shortlist's own "why", ranked first-touch channels, follow-up cadences that add a new angle instead of bumping, and the fee conversation where speakers have no rate card. Use whenever the user mentions writing a speaker invitation, pitching a keynote candidate, following up on an unanswered invitation, or a speaker who asks for a fee - even if they never say "outreach". Do NOT use to find or qualify candidates - use samber/dev-event-organizer-skills@event-speaker-sourcing instead.
event-speaker-experience
Run the speaker-side experience from the moment a speaker confirms through to the thank-you after their talk - collecting bio, headshot, A/V needs and travel details against a deadline ladder, a single named point of contact, the pre-event briefing and slide deadline, tech check and green room, documented recording consent and its per-format opt-out asymmetry, and post-event follow-up. Use whenever the user mentions what to send an accepted speaker, a green room, speaker travel or hotel, a tech check, recording consent, a speakers' dinner, or supporting a first-time speaker - even if they never say "speaker experience". Do NOT use before acceptance - inviting is samber/dev-event-organizer-skills@event-speaker-cold-outreach.
event-speaker-sourcing
Find and qualify speakers for a technical event outside the open call for papers - the proactive channel running alongside or instead of a CFP. Covers program gaps worth filling by invitation, sourcing channels (referral asks, expert and speaker directories, prior-talk review, community scouting), international sourcing by region and language, evidence-based Hot/Warm/Cold/Skip qualification, and a ranked shortlist carrying the "why" behind each name. Use whenever the user mentions finding speakers, a keynote or invited-speaker shortlist, sourcing international or under-represented speakers, or a programme a CFP did not fill - even if they never say "sourcing". Do NOT use to write the invitation - use samber/dev-event-organizer-skills@event-speaker-cold-outreach instead.
event-sponsor-agreement
Turn a sold event sponsorship into a term sheet a lawyer can review - never a signable contract or legal advice. Covers the clause checklist an organizer hands to counsel - a deliverables schedule mirroring the sold tier, payment and late-fee terms, sponsor-withdrawal refunds plus the narrower organizer-cancels remedy, a force-majeure remedy, category exclusivity bounded by published caps, liability and insurance, a code-of-conduct clause with an ejection right, mutual logo licensing, term and renewal. Use whenever the user mentions a sponsorship agreement or contract, sponsor payment or cancellation terms, exclusivity, or a force-majeure clause - even if they never say "agreement". Do NOT use to set prices - use samber/dev-event-organizer-skills@event-sponsor-pricing.
event-sponsor-fulfillment
Deliver everything a signed event sponsor was promised, from countersignature to renewal handoff - the tier-by-perk fulfillment matrix built from the signed agreement, payment-gated perk release, sponsor asset collection against deadlines, the day-of sponsor experience (setup and teardown windows, shipping, booth staffing, power, WiFi, A/V), consented lead capture such as an opt-in raffle, and the post-event sponsor report that anchors the renewal ask. Use whenever the user mentions onboarding a signed sponsor, tracking sponsor deliverables, booth logistics, sponsor logo placement, a post-event sponsor report, or a renewal case - even if they never say "fulfillment". Do NOT use for the sale itself - use samber/dev-event-organizer-skills@event-sponsor-outreach instead.
event-sponsor-outreach
Run the sponsor sales motion for a technical event, from target list to signed yes - target list building and scoring, outreach timed against sponsor fiscal-year budget lock-in, first-touch channel choice (warm intro, referral ask, cold email under sponsor-specific etiquette), the exploratory call, capped follow-up cadences, objection handling, pipeline tracking, and renewal versus net-new as distinct motions. Use whenever the user mentions finding sponsors, a sponsor outreach email, pitching a sponsorship, a sponsor objection, or chasing renewals - even if they never say "outreach". Do NOT use for the rate card - use samber/dev-event-organizer-skills@event-sponsor-pricing; post-sale delivery is samber/dev-event-organizer-skills@event-sponsor-fulfillment.
event-sponsor-pricing
Build the sponsorship rate card for a technical event - the revenue target taken from the budget, an inventory of sellable surfaces, cost-recovery, market-comp and value-based price setting, a 2-4 tier ladder with anchoring and a sane top-to-floor ratio, add-on and exclusivity premiums, in-kind valuation, and the discount and negotiation policy written before the first sponsor call. Use whenever the user mentions sponsorship tier prices, a sponsor rate card, sponsor package pricing, or choosing between a published ladder, quote-gated pricing and no ladder at all - even if they never say "pricing". Do NOT use for attendee ticket prices - use samber/dev-event-organizer-skills@event-ticket-pricing; the deck is samber/dev-event-organizer-skills@event-sponsor-prospectus.
changelog-writing
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.
conference-cfp-submission
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).
developer-case-study
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.
Showing top 100 of 142 skills by quality score. Browse the full catalog at /browse.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.