Samuel Berthe

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.

Write technical articles and blog posts for developer audiences — tutorials, explainers, benchmarks, bug hunts, postmortems, and 'we rewrote it in X' posts — with title variants and developer-grade article structure. Use whenever the user asks to write a blog post, technical article, dev.to or Medium post, or any long-form technical content, including 'write about [technical topic]', 'turn this into a blog post', or 'I want to publish something about X', even without naming a format. Do NOT use for newsletter or Substack issues — use samber/cc-skills@substack-ghostwriting instead. Do NOT use for codifying an author's voice — use samber/cc-skills@copywriting-prose-creator instead.

Write, optimize, and grow Substack content — newsletter issues (email-first) and web posts (web-first essays). Covers voice matching, Substack algorithm and Notes strategy, email formatting, SEO, growth tactics, and paid-subscriber monetization. Use when the user mentions Substack, a newsletter issue, a Substack post or article, evergreen content, newsletter growth, Notes, paid subscribers, 'ghostwrite for', or 'write in the style of' — and for newsletter or essay writing even when Substack is not named, or when adapting a blog post, talk, or thread into newsletter format. Do NOT use for generic blog post writing without a newsletter context — use samber/cc-skills@technical-article-writer instead.

Compliance expert for snyk-agent-scan — the agent skill file scanner — NOT for other Snyk CLI tools (snyk test, snyk code SAST, snyk iac, snyk container). Fixes alerts through content restructuring, never by suppressing or deleting information. Covers every file in a skill directory: SKILL.md, references/, assets/, and any secondary markdown. Apply when authoring a new skill, editing an existing one, triaging a failed snyk-agent-scan run locally or in CI, or unblocking a PR held by agent scanner failures. Not applicable to dependency vulnerabilities, code security findings, or infrastructure misconfigurations — those are out of scope.

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.

Pre-launch checklist for shipping a new website or web app. Scope: analytics (GA4, PostHog, Google Search Console, Ahrefs), DNS, TLS and backups, legal and CNIL/GDPR compliance, security headers, SEO and GEO (robots.txt, sitemaps, llms.txt, hreflang, schema markup, keyword research), copywriting voice via TONE.md and a humanizer pass, OpenGraph and social previews, favicons and web manifest, Lighthouse, Core Web Vitals and WCAG quality gates, directory submissions, Product Hunt, G2/Capterra reviews, post-launch monitoring. Use when the user says 'checklist for the site', 'ready to ship', 'before I go live', 'ready for prod', 'audit before launch', or asks for a site review, pre-launch audit, or help launching a site or app, deploying a domain to production, or shipping a marketing, docs, SaaS, or lead-magnet site.

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.

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.

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.

Influence and negotiation toolkit for any interaction needing another person's agreement, even when the user never says 'negotiation'. Covers B2B sales, salary reviews and raise asks, collective bargaining and unions, hard 1:1s, recruitment closes, cross-cultural deals, mediation, and diplomatic messages — declining, pushing back on scope, justifying a delay, raising a concern, getting alignment. Use when the user says 'they just said X, what do I say' or 'draft a reply', or mentions a buyer, champion, procurement, RFP, sponsor, HR, union, or candidate, or a pushback, refusal, ghosting, no-decision, escalation, fixed budget, counter-offer, comp band, strike, BATNA, anchor, or concession.

Write or rewrite English into ASD-STE100 Simplified Technical English and strip AI artifacts (decorative emojis, Markdown residue) from technical documentation — maintenance manuals, procedures, medical device instructions, and API docs read by non-native speakers or machine translation. Enforces approved word meanings, technical noun and verb categories, the 20/25-word sentence limits, banned verb tenses, and passive-voice restrictions. Trigger on simplified technical english, STE, ASD-STE100, controlled language, translation-ready docs, de-slop this manual. Do NOT use for marketing copy, brand voice, or narrative writing; for French text use samber/cc-skills@humaniseur-fr instead.

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.

Designs distinctive, non-generic UI — typography, OKLCH color, design tokens (DESIGN.md), layout, components, motion, dark mode, accessibility — for landing pages, SaaS apps, dashboards, ecommerce, decks, docs, portfolios, avoiding the AI-slop / Claude-esque default look. Use 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 on a bare "build a UI for X" with no aesthetic named. Not for writing marketing copy.

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, key authors), person/org (due diligence on a company or public figure), financial (funding landscape, valuation multiples, revenue signals), legal (IP, patent landscape, litigation, compliance), trend (emerging signals, foresight, scenario mapping), community (ecosystem health, key voices, governance, fragmentation). Trigger even when phrased casually: 'look into X', 'what's the deal with Y', 'dig into Z', 'I need to understand the space', 'catch me up on X'. Do NOT use for single-fact lookups or one-off web questions.

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.

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.

Codifies how a person or brand writes — lexicon, syntax, rhythm, structure, signature moves — into a PROSE.md guide, independent of emotional tone. Builds from SOUL.md and TONE.md, ports a guide to another channel, or reverse-engineers prose patterns from a corpus. Trigger on PROSE.md, writing style guide, prose guide, house style, ghostwriter style, writing playbook, banned words, sentence-length targets, or multi-writer consistency in a content factory. Do NOT use for writing actual content — use samber/cc-skills@linkedin-ghostwriting or samber/cc-skills@technical-article-writer instead. Not for tone decisions (samber/cc-skills@copywriting-tone-of-voice-creator), hooks, or CTAs.

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.

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.

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.

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.

Golang application framework using uber-go/fx — fx.New, fx.Provide, fx.Invoke, fx.Module, fx.Lifecycle hooks, fx.Annotate (name/group/As), fx.Decorate, fx.Supply, fx.Replace, fx.WithLogger, and signal-aware Run(). Apply when using or adopting uber-go/fx, when the codebase imports `go.uber.org/fx`, or when wiring services with fx.New. For raw DI without lifecycle, see `samber/cc-skills-golang@golang-uber-dig` skill.

Implements dependency injection in Golang using uber-go/dig — reflection-based container, Provide/Invoke, dig.In/dig.Out parameter and result objects, named values, value groups, optional dependencies, scopes, and Decorate. Apply when using or adopting uber-go/dig, when the codebase imports `go.uber.org/dig`, or when wiring an application graph at startup. For higher-level lifecycle and modules, see `samber/cc-skills-golang@golang-uber-fx` skill.

Troubleshoot Golang programs systematically - find and fix the root cause. Use when encountering bugs, crashes, deadlocks, races, or unexpected behavior in Go code. Covers debugging methodology, common Go pitfalls, test-driven debugging, pprof setup and capture, Delve, race detection, GODEBUG tracing, and production debugging. Start here for any 'something is wrong' situation. Not for interpreting profiles or benchmarking (→ See `samber/cc-skills-golang@golang-benchmark` skill), applying optimization patterns (→ See `samber/cc-skills-golang@golang-performance` skill), or designing new code (→ See `samber/cc-skills-golang@golang-safety` skill for defensive coding, `samber/cc-skills-golang@golang-concurrency` skill for concurrency design).

Production-ready Golang tests — table-driven tests, testify suites and mocks, parallel tests, fuzzing, fixtures, goroutine leak detection with goleak, snapshot testing, code coverage, integration tests, idiomatic test naming. Use when writing or reviewing Go tests, choosing a testing approach, setting up Go test CI, or debugging flaky/slow tests. For testify-specific APIs see `samber/cc-skills-golang@golang-stretchr-testify`; for measurement methodology see `samber/cc-skills-golang@golang-benchmark`.

Golang OpenAPI/Swagger documentation with swaggo/swag — annotation comments (@Summary, @Param, @Success, @Router, @Security), swag init code generation, framework integrations (gin, echo, fiber, chi, net/http), security definitions (Bearer/JWT, OAuth2, API key), and struct tags (swaggertype, enums, example, swaggerignore). Apply when adding or maintaining Swagger/OpenAPI docs in a Go project, or when the codebase imports github.com/swaggo/swag, github.com/swaggo/gin-swagger, github.com/swaggo/echo-swagger, github.com/swaggo/http-swagger, or github.com/swaggo/files.

Golang struct and interface design patterns — composition, embedding, type assertions, type switches, interface segregation, dependency injection via interfaces, struct field tags, and pointer vs value receivers. Use this skill when designing Go types, defining or implementing interfaces, embedding structs or interfaces, writing type assertions or type switches, adding struct field tags for JSON/YAML/DB serialization, or choosing between pointer and value receivers. Also use when the user asks about "accept interfaces, return structs", compile-time interface checks, or composing small interfaces into larger ones.

Comprehensive guide to stretchr/testify for Golang testing. Covers assert, require, mock, and suite packages in depth. Use when writing tests with testify, creating mocks, setting up test suites, or choosing between assert and require. Covers testify assertions, mock expectations, argument matchers, call verification, suite lifecycle, and advanced patterns like Eventually, JSONEq, and custom matchers. Apply when the codebase imports github.com/stretchr/testify.

Golang ecosystem watch list — official sources (go.dev/blog, pkg.go.dev, tour.golang.org, golang-nuts), newsletters (Golang Weekly, Awesome Go Newsletter), communities (r/golang, gophers.slack.com, Go Forum, go.dev/wiki), blogs (Dave Cheney, Ardan Labs, Rob Pike), YouTube channels (Gopher Academy, GopherCon EU/UK), conferences, and Go contributors to follow on GitHub, X and Bluesky. Use when seeking Golang learning resources, discovering new libraries or tools, finding community channels or meetups, picking Go people to follow, or keeping up with Go language changes and releases. Not for querying a specific module's versions, docs, or vulnerabilities from the CLI (→ See `samber/cc-skills-golang@golang-pkg-go-dev` skill).

Golang configuration library using spf13/viper — layered precedence (flag > env > file > KV > default), BindPFlag/BindPFlags, SetEnvPrefix + SetEnvKeyReplacer + AutomaticEnv, ReadInConfig + ConfigFileNotFoundError, Unmarshal + mapstructure struct tags, Sub for sub-trees, WatchConfig + OnConfigChange for hot reload, viper.New() for test isolation, and remote KV integration. Apply when using or adopting spf13/viper, or when the codebase imports `github.com/spf13/viper`. For CLI command structure alongside viper, see the `samber/cc-skills-golang@golang-spf13-cobra` skill. For general CLI architecture, see `samber/cc-skills-golang@golang-cli`.

Golang CLI command tree library using spf13/cobra — cobra.Command, RunE vs Run, PersistentPreRunE hook chain, Args validators (NoArgs, ExactArgs, MatchAll, custom), persistent vs local flags, command groups, ValidArgsFunction, RegisterFlagCompletionFunc, ShellCompDirective, usage/help template customization, man-page and markdown doc generation, and testing with SetArgs/SetOut/SetErr. Apply when using or adopting spf13/cobra, or when the codebase imports `github.com/spf13/cobra`. For configuration layering alongside cobra, see the `samber/cc-skills-golang@golang-spf13-viper` skill. For general CLI architecture (project layout, exit codes, signal handling, I/O patterns), see `samber/cc-skills-golang@golang-cli`.

Security best practices and vulnerability prevention for Golang — injection (SQL, command, XSS), cryptography, path traversal, SSRF and HTTP security headers, cookies, secrets management, memory safety, PII in logs, STRIDE/DREAD threat modeling, plus `gosec` SAST, race detection, and fuzz testing. Apply when writing, reviewing, or auditing Go code for security, or when touching crypto, file or network I/O, secrets, user input, or authentication. Not for non-exploitable defensive bugs such as nil panics or slice aliasing (→ See `samber/cc-skills-golang@golang-safety` skill), dependency vulnerability scanning with govulncheck (→ See `samber/cc-skills-golang@golang-dependency-management` skill), or wiring security scanners into CI pipelines (→ See `samber/cc-skills-golang@golang-continuous-integration` skill).

Structured logging extensions for Golang using samber/slog-**** packages — multi-handler pipelines (slog-multi), log sampling (slog-sampling), attribute formatting (slog-formatter), HTTP middleware (slog-fiber, slog-gin, slog-chi, slog-echo), and backend routing (slog-datadog, slog-sentry, slog-loki, slog-syslog, slog-logstash, slog-graylog...). Apply when using or adopting slog, or when the codebase already imports any github.com/samber/slog-* package.

Reactive streams and event-driven programming in Golang using samber/ro — ReactiveX implementation with 150+ type-safe operators, cold/hot observables, 5 subject types (Publish, Behavior, Replay, Async, Unicast), declarative pipelines via Pipe, 40+ plugins (HTTP, cron, fsnotify, JSON, logging), automatic backpressure, error propagation, and Go context integration. Apply when using or adopting samber/ro, when the codebase imports github.com/samber/ro, or when building asynchronous event-driven pipelines, real-time data processing, streams, or reactive architectures in Go. Not for finite slice transforms (→ See `samber/cc-skills-golang@golang-samber-lo` skill).

Structured error handling in Golang with samber/oops — error builders, stack traces, error codes, error context, error wrapping, error attributes, user-facing vs developer messages, panic recovery, and logger integration. Apply when using or adopting samber/oops, or when the codebase already imports github.com/samber/oops.

Monadic types for Golang using samber/mo — Option, Result, Either, Future, IO, Task, and State types for type-safe nullable values, error handling, and functional composition with pipeline sub-packages. Apply when using or adopting samber/mo, when the codebase imports `github.com/samber/mo`, or when considering functional programming patterns as a safety design for Golang. Not for nil-safety and zero-value design without this library (→ See `samber/cc-skills-golang@golang-safety` skill), nor for native error wrapping with fmt.Errorf, errors.Is and errors.As (→ See `samber/cc-skills-golang@golang-error-handling` skill).

Functional programming helpers for Golang using samber/lo — 500+ type-safe generic functions for slices, maps, channels, strings, math, tuples, and concurrency (Map, Filter, Reduce, GroupBy, Chunk, Flatten, Find, Uniq, etc.). Core immutable package (lo), concurrent variants (lo/parallel aka lop), in-place mutations (lo/mutable aka lom), lazy iterators (lo/it aka loi for Go 1.23+), and experimental SIMD (lo/exp/simd). Apply when using or adopting samber/lo, when the codebase imports github.com/samber/lo, or when implementing functional-style data transformations in Go. Not for streaming pipelines (→ See `samber/cc-skills-golang@golang-samber-ro` skill).

In-memory caching in Golang using samber/hot — eviction algorithms (LRU, LFU, TinyLFU, W-TinyLFU, S3FIFO, ARC, TwoQueue, SIEVE, FIFO), TTL, cache loaders, sharding, stale-while-revalidate, missing key caching, and Prometheus metrics. Apply when using or adopting samber/hot, when the codebase imports github.com/samber/hot, or when the project repeatedly loads the same medium-to-low cardinality resources at high frequency and needs to reduce latency or backend pressure.

Dependency injection in Golang using samber/do — service containers, lifecycle management, scopes, health checks, graceful shutdown, and module organization. Apply when using or adopting samber/do, when the codebase imports github.com/samber/do or github.com/samber/do/v2, or when refactoring manual constructor injection into a DI container.

Defensive Golang coding against accidental bugs — nil panics, typed-nil interfaces, `append` backing-array aliasing, silent int64-to-int32 truncation, float `==` comparison, `defer` inside loops, defensive copies of slices and maps, and usable zero values. Use when a Go program panics on a nil map write or nil pointer dereference, when reviewing code for nil-safety, numeric conversion overflow, or resource lifecycle, or when designing a type whose zero value must be safe. Not for designing concurrent access with goroutines, channels, or sync primitives (→ See `samber/cc-skills-golang@golang-concurrency` skill), not for exploitable vulnerabilities such as injection, weak crypto, or leaked secrets (→ See `samber/cc-skills-golang@golang-security` skill), and not for debugging an already-failing program (→ See `samber/cc-skills-golang@golang-troubleshooting` skill).

Golang refactoring — safe, at-scale restructuring of existing Go code: a coverage-adaptive safety net, behavior-preserving transforms (gopls Rename/Extract, `gofmt -r`, `gopatch`), the Fowler catalog mapped to Go, breaking import cycles, and small stacked PRs. Apply when a function or type has grown too large, a code smell blocks a feature, or the user asks to refactor Go code — also for renaming at scale, extracting functions or interfaces, moving code between packages, or planning a multi-step refactor. Target styles owned elsewhere → See `samber/cc-skills-golang@golang-naming` (renames), `samber/cc-skills-golang@golang-project-layout` (splits), `samber/cc-skills-golang@golang-modernize` (idioms), `samber/cc-skills-golang@golang-code-style` (control flow), `samber/cc-skills-golang@golang-design-patterns` (patterns/DI).

Golang project layout and workspace setup — cmd/internal/pkg directory conventions, module and package naming, go.work workspaces, and essential configuration files. Use when starting a new Go project, organizing an existing codebase, setting up a monorepo with multiple packages, creating CLI tools with multiple main packages, or discussing package restructuring, package splits, or module splits. Not for restructuring existing code without a layout change (→ See `samber/cc-skills-golang@golang-refactoring` skill).

Golang library and framework selection — vetted production-ready options by category (web, database, testing, logging, messaging), new and experimental stdlib packages, standard-library-first tradeoffs, and maturity signals (maintenance, license, importer counts). Apply when the user asks for library suggestions, wants to compare alternatives, needs to choose a library for a specific task, or when a new dependency is being added to the project. Not for a specific library's API once chosen (→ See that library's dedicated skill, e.g. `samber/cc-skills-golang@golang-samber-lo`), nor for go.mod mechanics, upgrades, or vulnerability audits (→ See `samber/cc-skills-golang@golang-dependency-management` skill).

Golang package and module lookup via `godig`, a pkg.go.dev API client (CLI + MCP server). Use for any Go/Golang library's documentation, API signatures, symbols, usage examples, which versions exist, licenses, whether a dependency has CVEs, or who imports a package — prefer this over Context7 for any Go package or module. Read-only, no auth. Not for upgrading dependencies (→ See `samber/cc-skills-golang@golang-dependency-management` skill), choosing a library (→ See `samber/cc-skills-golang@golang-popular-libraries` skill), or local symbols and an already-used dependency's resolved source, call sites, and generic instantiations (→ See `samber/cc-skills-golang@golang-gopls` skill).

Golang performance optimization patterns and methodology - if X bottleneck, then apply Y. Covers allocation reduction, CPU efficiency, memory layout, GC tuning, pooling, caching, and hot-path optimization. Use when profiling or benchmarks have identified a bottleneck and you need the right optimization pattern to fix it. Also use when performing performance code review to suggest improvements or benchmarks that could help identify quick performance gains. Not for measurement methodology (→ See `samber/cc-skills-golang@golang-benchmark` skill) or debugging workflow (→ See `samber/cc-skills-golang@golang-troubleshooting` skill).

Golang everyday observability — the always-on signals in production. Covers structured logging with slog, Prometheus metrics, OpenTelemetry distributed tracing, continuous profiling with pprof/Pyroscope, server-side RUM event tracking, alerting, and Grafana dashboards. Apply when instrumenting Go services for production monitoring, setting up metrics or alerting, adding OpenTelemetry tracing, correlating logs with traces, migrating legacy loggers (zap/logrus/zerolog) to slog, adding observability to new features, or implementing GDPR/CCPA-compliant tracking with Customer Data Platforms (CDP). Not for temporary deep-dive performance investigation (→ See `samber/cc-skills-golang@golang-benchmark` and `samber/cc-skills-golang@golang-performance` skills).

Go (Golang) naming conventions — covers packages, constructors, structs, interfaces, constants, enums, errors, booleans, receivers, getters/setters, functional options, acronyms, test functions, and subtest names. Use this skill when writing new Go code, reviewing or refactoring, choosing between naming alternatives (New vs NewTypeName, isConnected vs connected, ErrNotFound vs NotFoundError, StatusReady vs StatusUnknown at iota 0), debating Go package names (utils/helpers anti-patterns), or asking about Go naming best practices. Also trigger when the user mentions MixedCaps vs snake_case, ALL_CAPS constants, Get-prefix on getters, or error string casing. Do NOT use for general Go implementation questions that don't involve naming decisions.

Modernize Golang code to use recent language features, standard library improvements, and idiomatic patterns. Use when reviewing Go code with old-style patterns, when encountering a deprecation warning, or when the user asks for modernization, a Go version upgrade (e.g. to Go 1.27), or a CI/tooling refresh. Not for structural refactors, extracting functions, or moving code between packages (→ See `samber/cc-skills-golang@golang-refactoring` skill).

Linting best practices and golangci-lint configuration for Golang projects — running linters, configuring .golangci.yml, suppressing warnings with nolint directives, interpreting lint output, and selecting linters. Use when configuring golangci-lint, asking about lint warnings or nolint suppressions, setting up code quality tooling, or choosing linters. Also use when the user mentions golangci-lint, go vet, staticcheck, or revive. Not for wiring a lint step into a GitHub Actions pipeline (→ See `samber/cc-skills-golang@golang-continuous-integration` skill).

Golang skills orchestrator — always active on any Golang coding, review, debug, or setup task. Reads the task context and loads the most relevant skills from samber/cc-skills-golang, often multiple at once: writing a gRPC service loads golang-grpc + golang-testing + golang-error-handling; debugging a panic loads golang-troubleshooting + golang-safety; auditing security loads golang-security + golang-lint + golang-safety. Also: disambiguates competing clusters when two skills seem to overlap (performance vs benchmark vs troubleshooting, samber/lo vs mo vs ro, DI cluster, safety vs security), and configures the project's agent-config file (CLAUDE.md, AGENTS.md, GEMINI.md, Cursor rules, or Copilot instructions) to force-trigger skills in a project (/golang-how-to configure).

Provides gRPC usage guidelines, protobuf organization, and production-ready patterns for Golang microservices. Use when implementing, reviewing, or debugging gRPC servers/clients, writing proto files, setting up interceptors, handling gRPC errors with status codes, configuring TLS/mTLS, testing with bufconn, or working with streaming RPCs.

Implements GraphQL APIs in Golang using gqlgen or graphql-go. Apply when building GraphQL servers, designing schemas, writing resolvers, handling subscriptions, or integrating GraphQL with existing Go HTTP services. Also apply when the codebase imports `github.com/99designs/gqlgen` or `github.com/graph-gophers/graphql-go`.

Golang semantic code intelligence via `gopls`, the official Go language server — go-to-definition, find references, call/implementation hierarchy, workspace symbol search, package API discovery, diagnostics, safe rename, refactors (extract/inline/fill/rewrite code actions), formatting, and generated tests. Reaches an agent via gopls's own MCP server (`go_*` tools), Claude Code's native `LSP` tool, or the `gopls` CLI. Use when navigating or refactoring Go code — jumping to a definition, finding call sites before a rename, understanding a file's or package's dependencies, running diagnostics after an edit, or extracting/inlining/renaming. Not for the published ecosystem — packages not in your `go.mod`, versions, licenses, importers — → See `samber/cc-skills-golang@golang-pkg-go-dev` skill (`godig`). Not for a whole-tree vulnerability audit → See `samber/cc-skills-golang@golang-security` skill (`govulncheck`).

Compile-time dependency injection in Golang using google/wire — wire.NewSet, wire.Build, wire.Bind (interface→concrete), wire.Struct, wire.Value, wire.InterfaceValue, wire.FieldsOf, cleanup functions, //go:build wireinject injector files, and generated wire_gen.go. Apply when using or adopting google/wire, when the codebase imports `github.com/google/wire`, or when wiring an application graph at compile time via `wire.Build`. For runtime DI with reflection, see `samber/cc-skills-golang@golang-uber-dig` skill.

Idiomatic Golang error handling — creation, wrapping with %w, errors.Is/As, errors.Join, custom error types, sentinel errors, panic/recover, the single handling rule, structured logging with slog, HTTP request logging middleware, and samber/oops for production errors. Built to make logs usable at scale with log aggregation 3rd-party tools. Apply when creating, wrapping, inspecting, or logging errors in Go code. For samber/oops specifics → See `samber/cc-skills-golang@golang-samber-oops` skill; for slog handler ecosystem → See `samber/cc-skills-golang@golang-samber-slog` skill.

Comprehensive documentation guide for Golang projects, covering godoc comments, README, CONTRIBUTING, CHANGELOG, Go Playground, Example tests, API docs, and llms.txt. Use when writing or reviewing doc comments, documentation, adding code examples, setting up doc sites, or discussing documentation best practices. Triggers for both libraries and applications/CLIs.

Idiomatic Golang design patterns — functional options, constructor APIs, `init()` and global-state avoidance, enums, panic vs error decisions, resource management and lifecycle, graceful shutdown, timeouts and retries, streaming and iterators, and architecture styles (clean, hexagonal, DDD, flat). Apply when choosing between architectural patterns, implementing functional options, designing constructor APIs, setting up graceful shutdown, applying resilience patterns, or asking which idiomatic Go pattern fits a specific problem. Not for wiring a DI container or comparing DI libraries (→ See `samber/cc-skills-golang@golang-dependency-injection` skill), nor for error wrapping, `errors.Is`/`As`, or logging mechanics (→ See `samber/cc-skills-golang@golang-error-handling` skill).

Dependency management for Golang projects — go.mod and go.sum, `go get` install and upgrade flows, Minimal Version Selection, conflict resolution with replace/exclude/retract, `govulncheck` scanning of the module tree, outdated dependency and binary size auditing, vendoring, `tool` directives, and go.work workspaces. Use when adding, removing, or upgrading Go dependencies, deciding whether to take on a package, resolving version conflicts, or auditing what a module pulls in. Covers choosing and upgrading dependency versions, not the surrounding tooling: do NOT use for fixing an exploitable vulnerability in code (→ See `samber/cc-skills-golang@golang-security` skill) or for wiring Dependabot/Renovate update bots into CI workflows (→ See `samber/cc-skills-golang@golang-continuous-integration` skill).

Comprehensive guide for dependency injection (DI) in Golang. Covers why DI matters (testability, loose coupling, separation of concerns, lifecycle management), manual constructor injection, and DI library comparison (google/wire, uber-go/dig, uber-go/fx, samber/do). Use this skill when designing service architecture, setting up dependency injection, refactoring tightly coupled code, managing singletons or service factories, or when the user asks about inversion of control, service containers, or wiring dependencies in Go. For a specific DI library, → See `samber/cc-skills-golang@golang-google-wire`, `samber/cc-skills-golang@golang-uber-dig`, `samber/cc-skills-golang@golang-uber-fx`, or `samber/cc-skills-golang@golang-samber-do` skills.

Comprehensive guide for Go database access — parameterized queries, struct scanning, NULLable columns, transactions, isolation levels, SELECT FOR UPDATE, connection pool, batch processing, context propagation, and migration tooling. Use when writing, reviewing, or debugging Golang code that interacts with PostgreSQL, MariaDB, MySQL, or SQLite; for database testing; or for questions about database/sql, sqlx, or pgx. Does NOT generate database schemas or migration SQL.

Golang data structures — slices (internals, capacity growth, preallocation, slices package), maps (internals, hash buckets, maps package), arrays, container/list/heap/ring, strings.Builder vs bytes.Buffer, generic collections, pointers (unsafe.Pointer, weak.Pointer), and copy semantics. Use when choosing or optimizing Go data structures, implementing generic containers, using container/ packages, unsafe or weak pointers, or questioning slice/map internals. Not for applying optimization patterns once profiling has identified a bottleneck (→ See `samber/cc-skills-golang@golang-performance` skill).

GitHub Actions CI/CD pipeline configuration for Golang projects — workflow files for test, lint, SAST, coverage and vulnerability-scan jobs, Dependabot and Renovate config files, GoReleaser release pipelines, Docker build/push, repository security settings, and AI-driven PR review. Use when setting up or improving Go project CI, writing or fixing `.github/workflows/*.yml`, adding a linter or security scanner as a pipeline job, wiring automated dependency-update bots, or adding quality gates. Covers wiring tools into a pipeline, not the analysis they perform: do NOT use for choosing or interpreting security findings (→ See `samber/cc-skills-golang@golang-security` skill) or for choosing, upgrading, or auditing dependency versions (→ See `samber/cc-skills-golang@golang-dependency-management` skill).

Idiomatic context.Context usage in Golang — propagation through API boundaries, cancellation, timeouts and deadlines, request-scoped values, context.WithoutCancel for background work outliving requests. Apply when designing context propagation across layers, debugging leaked or unexpired contexts, choosing between context.Background/TODO/WithoutCancel, or storing values in context. Not for code that merely accepts ctx as first parameter.

Golang concurrency design — goroutine lifecycle and leak prevention, channels and `select`, channel ownership and direction, `sync.Mutex`/`RWMutex`/`sync.Map`/`sync.Once`/atomics, `errgroup`, `singleflight`, worker pools, and fan-out/fan-in pipelines. Use when writing or reviewing concurrent Go code, when choosing between channels and mutexes, when protecting a shared map or counter, or when a goroutine has no clear exit. Not for defensive coding unrelated to concurrency such as nil panics, slice aliasing, or numeric overflow (→ See `samber/cc-skills-golang@golang-safety` skill), and not for debugging a specific hung, crashing, or racing program after the fact (→ See `samber/cc-skills-golang@golang-troubleshooting` skill).

Golang code style conventions — line length and breaking, variable declarations, control flow clarity, when comments help vs hurt. Use when writing or reviewing Go code, asking about style or clarity, or establishing project coding standards. Not for naming conventions (→ See `samber/cc-skills-golang@golang-naming` skill), linter configuration (→ See `samber/cc-skills-golang@golang-lint` skill), or doc comments (→ See `samber/cc-skills-golang@golang-documentation` skill).

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.

Golang benchmarking, profiling, and performance measurement. Use when writing, running, or comparing Go benchmarks, profiling hot paths with pprof, interpreting CPU/memory/trace profiles, analyzing results with benchstat, setting up CI benchmark regression detection, or investigating production performance with Prometheus runtime metrics. Also use when the developer needs deep analysis on a specific performance indicator - this skill provides the measurement methodology, while `samber/cc-skills-golang@golang-performance` provides the optimization patterns.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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).

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.

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.

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.

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).

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.

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).

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.

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.

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.

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).

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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).

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.

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.