samber

225 skills

golang-code-stylesamber43KGolang 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-testingsamber42KProduction-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-benchm golang-error-handlingsamber42KIdiomatic 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; f golang-design-patternssamber41KIdiomatic 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 golang-performancesamber41KGolang 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 `golang-securitysamber41KSecurity 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 golang-concurrencysamber41KGolang 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, slic golang-contextsamber40KIdiomatic 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-namingsamber40KGo (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 aski golang-databasesamber40KComprehensive 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-documentationsamber40KComprehensive 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.golang-safetysamber40KDefensive 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 concu golang-data-structuressamber40KGolang 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 golang-modernizesamber40KModernize 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).golang-project-layoutsamber40KGolang 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-r golang-lintsamber40KLinting 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 golang-troubleshootingsamber39KTroubleshoot 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 optimiz golang-observabilitysamber39KGolang 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 observabilit golang-dependency-managementsamber39KDependency 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 golang-structs-interfacessamber39KGolang 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 a golang-popular-librariessamber39KGolang 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 golang-dependency-injectionsamber39KComprehensive 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 golang-benchmarksamber39KGolang 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-clisamber39KGolang 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@golan golang-stretchr-testifysamber39KComprehensive 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-continuous-integrationsamber39KGitHub 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. Cov golang-grpcsamber39KProvides 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.golang-stay-updatedsamber38KGolang 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 meet golang-samber-losamber38KFunctional 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/sa golang-samber-dosamber38KDependency 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.golang-samber-slogsamber38KStructured 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.golang-samber-oopssamber38KStructured 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.golang-samber-mosamber38KMonadic 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 golang-samber-hotsamber38KIn-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.golang-samber-rosamber38KReactive 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 pi golang-swaggersamber37KGolang 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/ec golang-spf13-cobrasamber37KGolang 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 configurati golang-graphqlsamber37KImplements 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-google-wiresamber36KCompile-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-ub golang-spf13-vipersamber36KGolang 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 a golang-uber-fxsamber36KGolang 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.golang-uber-digsamber36KImplements 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.golang-how-tosamber36KGolang 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 (per golang-pkg-go-devsamber7.3KGolang 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@gola golang-refactoringsamber6.6KGolang 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 golang-goplssamber6.3KGolang 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 c copywriting-hookssamber3.3KWrites 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, copywriting-tone-of-voice-creatorsamber2.8KBuilds 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 s linkedin-ghostwritingsamber2.7KB2B 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.copywriting-ctasamber2.6KDesigns 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, G frontend-design-deslopsamber2.6KDesigns 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 technical-article-writersamber2.5KWrite 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 humaniseur-frsamber2.5KRemove 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, uni copywriting-prose-creatorsamber2.5KCodifies 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 — deep-researchsamber2.5KDeep 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 trend conventional-gitsamber2.4KConventional 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 organiz substack-ghostwritingsamber2.4KWrite, 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 n press-release-writersamber2.4KWrite 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 announ chrome-extensionsamber2.4KBuild 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 influence-and-negotiationsamber2.4KInfluence 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, ch promql-clisamber2.3KCLI 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-checklistsamber2.3KPre-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 revi skill-progressive-disclosure-designsamber2.3KDecide 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 wher crxjssamber2.3KCRXJS 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 trigg snyk-agent-scan-compliancesamber2.3KCompliance 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 training-reportsamber2.3KProduce 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 business-event-formatssamberChoose 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 even corporate-event-strategysamberDecide 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 cross-event-promotionsamberSet 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 w dev-event-careersamberPlans 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 quo dev-event-hiringsamberEmployer-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 dev-event-kickoffsamberBefore 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 recu event-accessibility-inclusionsamberDecide 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 accom event-attendee-email-sequencessamberDesign 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-befor event-attendee-experiencesamberDesign 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 event-b2b-matchmakingsamberDesign 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 event-booth-experiencesamberDesign 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 s event-budgetsamberBuild 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, p event-cfp-designsamberDesign 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 wr event-code-of-conductsamberWrite 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 event-comms-channelssamberDesign 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, event-community-buildingsamberAnimate 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, ho event-content-repurposingsamberTurn 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-up event-continuous-improvementsamberTurn 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 relear event-cultural-identitysamberDesign 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 au event-date-selectionsamberPick 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 a event-debriefsamberRun 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 ed event-feedbacksamberDesign 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 event-first-editionsamberLaunch 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 event-format-selectionsamberChoose 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 event-growth-strategysamberGrow 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 event-hospitalitysamberDecide 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 t event-landing-pagesamberBuild 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-learning-expedition-designsamberDecide 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 learnin event-market-fitsamberRead 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 event-marketing-plansamberBuild 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 regis event-media-partnershipssamberSet 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 event-no-show-managementsamberReduce and absorb no-shows at a technical event - an overbooking ratio against the room's real capacity and a stated ceiling, the waitlist and what triggers a promotion off it, the day-of walk-in lane, and the expected-show-up number handed to catering instead of the registration count. Use whenever asked how many registrations to accept for a free event, whether to overbook, how to run an event waitlist, why half the RSVPs did not turn up, or how many people to order food for. Do NOT use for re event-official-social-programsamberDecide 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 occa event-planning-timelinesamberBuild 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 t event-portfolio-strategysamberShape 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, event-positioningsamberDefine 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 event-press-relationssamberRun 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 event-productionsamberEngineer 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, record event-risk-managementsamberBuild and maintain the standing risk register for a technical event - risks named by category, scored on a likelihood x impact matrix adapted to a dated one-shot deliverable, split into prevention, contingency or insurance, the insurance stack including the communicable-disease buy-back, internal go/no-go decision dates set against the venue's escalating cancellation-fee curve, and the on-site emergency plan. Use whenever the user mentions event insurance, cancelling or postponing an event, a go event-run-of-showsamberWrite 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 event-schedule-designsamberLay 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, sess event-side-event-coordinationsamberApprove 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 event-social-mediasamberRun 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 hash event-speaker-cold-outreachsamberWrite 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 spea event-speaker-experiencesamberRun 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 event-speaker-sourcingsamberFind 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 speake event-sponsor-agreementsamberTurn 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 r event-sponsor-fulfillmentsamberDeliver 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 event-sponsor-outreachsamberRun 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 event-sponsor-pricingsamberBuild 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 event-sponsor-prospectussamberAssemble a technical event's sponsorship prospectus - the published document packaging an existing sponsor value proposition and rate card into a credibility-before-price section anatomy, a checkmark tier table with real disclosed caps, named per-tier perks and add-on packages, an audience-demographics evidence section, and a distribution format (web page or PDF kit) refreshed every edition. Use whenever the user mentions a sponsor deck, a sponsorship kit, a sponsor packages document, a prospect event-sponsor-value-propositionsamberArticulate what sponsors of a technical event genuinely get and why each sponsor segment buys - brand exposure, product feedback, recruiting, community goodwill, and (vendor-run events only) pipeline - one segment at a time through a six-part jobs-to-be-done template, bounded by what the event type can honestly promise and backed by proof points a diligent sponsor will check. Use whenever the user mentions why a company should sponsor an event, sponsor benefits or motivations, or building the va event-talk-selectionsamberRun the review and selection process on CFP submissions a technical event already collected - committee composition, how blind review executes (platform hiding versus a dedicated anonymizer role) and what it cannot fix, scoring rubrics, multi-round score-to-shortlist-to-program-fit cascades, conflict-of-interest recusal, diversity and first-time-speaker balancing, acceptance-rate management, and accept/decline/waitlist communication. Use whenever the user mentions a program committee, a talk rat event-team-structuresamberDesign the standing organizing team of a recurring technical event - the structure that persists between editions. Covers legal-entity posture (none, fiscal sponsorship, own non-profit), decision-rights shape (board-plus-organizers split, domain-lead federation, consensus committee), the role taxonomy, succession and bus-factor planning, burnout guardrails, and the volunteer-to-paid-staff hiring gate. Use whenever the user mentions structuring or governing an organizing team, forming an associat event-ticket-pricingsamberSet attendee ticket prices for a technical event - free, nominal or priced against the funding model, comps subtracted from capacity, a ladder split by who pays (employer-funded, self-funded, student), gating on a date or a ticket count, the need-gated scholarship rung, group and invoicing mechanics, and the refund and transfer policy written before tickets go on sale. Use whenever the user mentions ticket prices, early-bird tiers, free versus paid entry, student, diversity or group rates, invoi event-vendor-sourcingsamberSource, vet and contract the suppliers a venue does not include - caterers, AV and production suppliers, security firms, insurance brokers, swag and print. Covers the venue-exclusivity check that precedes any evaluation, one identical brief per category, sourcing posture and quote-comparison depth, contract red flags and the certificate-of-insurance ask, ordering lead times, delivery buffers, and day-of coordination. Use whenever the user mentions finding a caterer, comparing supplier quotes, br event-venue-sourcingsamberFind and negotiate the venue for a technical event. Covers the written space program built from an attendance estimate and chosen format (main room, breakouts, hallway track, sponsor tables, power and WiFi density, load-in), a sourcing ladder treating free campus, civic and company-hosted space as a real first rung, site visits at the depth the risk warrants, several venues carried against several dates, and the contract traps - attrition, food-and-beverage minimum, cancellation curve, insurance event-vip-managementsamberReceive named guests who are neither speaking nor sponsoring but whose presence creates escort, protocol, security or discretion obligations the general attendee flow cannot absorb - public officials, dignitaries, major funders, executives with no booth duty. Covers the qualification test (obligation, never status), the identification roster, escort depth, and a visibility posture that meets the obligation without building a status tier attendees can read. Use whenever the user mentions receivin event-vip-social-programsamberRun the private gathering alongside a public technical event, once a named-guest programme already exists - how the seat list is assembled when sponsors, speakers and the organizer all put names forward, how invitations and the door work without publishing a tier, and where the gathering sits against the public programme. Use whenever the user mentions a private dinner or reception at a conference, refusing a sponsor's seat request, an invite-only room without a VIP badge, or when to schedule on event-volunteer-experiencesamberDesign what a volunteer gets when they are not standing at a post, and how one edition closes with them - off-duty time they can actually use, the volunteer-specific hospitality top-up on the event's general standard, recognition not tied to a shift, a public thank-you, and the past-volunteer list next edition's recruitment starts from. Use whenever the user mentions looking after volunteers beyond their shift, whether volunteers get to see a talk, a volunteer lounge or volunteer meal, thanking event-volunteerssamberRecruit and organize the volunteer workforce that staffs one edition of a technical event - roster sizing built bottom-up from the posts the schedule needs standing, role definitions with real fit criteria, shift plans with arrival buffers, sign-up and confirmation, the briefing including the code-of-conduct escalation script, a named replacement protocol holding coverage, and recognition for the people who showed up. Use whenever the user mentions how many volunteers an event needs, recruiting hackathon-brief-designsamberWrite the hackathon challenge document teams read before they build - problem statements sized to the time box, thematic challenge tracks, the published rules and eligibility text, the submission-artifact checklist, sponsor-challenge framing, and naming (never weighting) the evaluation categories. Use whenever the user mentions a hackathon brief, challenge or track prompts, hackathon rules or eligibility, submission guidelines, or turning a sponsor's API into a challenge - even if they never say hackathon-cash-prizesamberStructure what a hackathon actually awards - cash versus non-cash medium including no monetary prize at all, total pool size inside the event budget's prizes line, how that pool splits across places and sponsor tracks, and who may legally receive a payout. Use whenever the user mentions hackathon prize amounts, cash versus hardware or credits, splitting a prize pool across tracks, prize eligibility for minors, sponsor employees or cross-border winners, or how winners actually get paid - even if hackathon-judgingsamberDesign the rubric and the scoring process for judging projects built during a hackathon - evaluation criteria and their weights, the scoring scale, judge coverage and the allocation arithmetic that fits the judging window, cross-judge score normalization, tie-breaking, sponsor and judge conflict-of-interest handling, judge recruitment and briefing, and results announcement including a contested result. Use whenever the user mentions a hackathon judging rubric, criteria weights, how many judges a hackathon-mentoringsamberDesign the mentor programme for one hackathon edition - coverage depth sized against the challenge tracks rather than a headcount, recruitment through community and sponsor channels, expertise tagging matched to the brief's tracks and any sponsor API, the request mechanic a stuck team uses to reach a mentor, the mentor briefing including the help-versus-build boundary, and rotation by expertise across shifts. Use whenever the user mentions how many mentors a hackathon needs, recruiting or briefi hackathon-team-formationsamberDecide how participants at a hackathon end up on teams - the published team-size rule including whether solo entry is allowed, the matchmaking mechanic that runs on the day, what happens to someone still unteamed after it, when membership freezes relative to the opening, and any track-conditioned team-composition rule. Use whenever the user mentions hackathon team size, a pitch-and-join or team-matching session, whether solo hackers are permitted, a participant nobody picked, or teams changing m hybrid-event-designsamberDesign a technical event serving an in-room and a remote audience at once, after the format decision has already chosen hybrid - which sessions the remote audience gets, how far a remote attendee's voice reaches the stage, the cue track the stream needs beside the room's, and the crew split between them. Use whenever the user mentions streaming talks to a remote audience, remote Q&A, staffing the remote side, or running a day for two audiences at once - even if they never say "hybrid". Do NOT us startup-pitch-contestsamberRun a startup pitch contest or demo day inside a technical event - the pre-event application and selection funnel, the pitch format and the time it costs, the rubric dimensions an investor judge actually scores, the conflict of interest specific to a judge who may want to invest in the company just ranked, and a prize built from introductions and committed meetings rather than cash. Use whenever the user mentions a pitch competition or demo day, opening applications for startups, picking a slate tech-podcast-youtube-channelsamberRun an organizer's own standing podcast or video channel as a cross-edition media property - whether to sustain a channel at all, the cadence commitment and its named owner in the quiet months, guest sourcing from the speaker pool outward, the two-way feed with the event cycle, and the wind-down or handover when organizers change. Use whenever the user mentions starting a conference podcast or YouTube channel, publishing between editions, where episode guests come from, who owns the show when an virtual-event-productionsamberRun the technical and audience-facing delivery of a fully-remote technical event once the format decision has already chosen virtual - the platform that replaces the venue, remote-speaker connectivity and local backup recordings, live chat and Q&A moderation staffing, and the failure drills an event with no physical room needs. Use whenever the user mentions a virtual event platform, an online or remote-only conference or meetup, preparing remote speakers, staffing chat and Q&A moderation, or wh workshop-program-designsamberDesign how a hands-on technical workshop or training session actually runs, once the format decision has committed hours to it - facilitator coverage, participant prerequisites and environment setup, capacity ceilings, session length, materials, and what breaks when a room of laptops cannot reach the network. Use whenever the user mentions planning the sessions inside a workshop day, how many helpers a lab needs, writing prerequisites or setup instructions, capping workshop seats, bring-your-own api-auth-key-managementsamberDesign the API-key authentication surface a platform issues to its own API consumers - key format with prefix+checksum conventions, hashed (irretrievable) vs encrypted (retrievable) storage, zero-downtime rotation with dual-key overlap, least-privilege scoping, individual vs org vs service-account ownership, self-service key dashboard behavior, and SOC 2 / PCI-DSS 4.0 lifecycle governance. Use whenever the user mentions API keys, secret keys, key prefixes, key rotation, key scoping, or revoking api-error-designsamberDesign 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 bo api-idempotency-retrysamberDesign 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-submi api-integration-surface-strategysamberDecide 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 sur api-rate-limit-policysamberDesign 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 api-reference-qualitysamberAudit 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 api-status-communicationsamberDesign 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, in api-test-mode-designsamberDesign 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 api-versioning-policysamberDefine 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. app-marketplace-launch-marketingsamberDesign 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 spotlight app-marketplace-listing-standardssamberWrite 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, app-marketplace-monetization-modelsamberDesign 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, deve app-marketplace-reviewsamberDesign 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,bulk-data-sharing-designsamberDesign 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 m connector-marketplace-strategysamberDecide 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 developer-platform-careersamberPlans 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 developer-platform-hiringsamberEmployer-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 PlatformCo developer-platform-kickoffsamberBefore 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 in developer-portal-designsamberDesign 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 mention etl-connector-strategysamberPlan 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 integration-error-observabilitysamberDesign 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 das integration-listing-optimizationsamberOptimize a B2B SaaS vendor's own listing on a third-party app marketplace - Salesforce AppExchange, HubSpot, Atlassian Marketplace, Shopify App Store, Slack, or comparable directories. Covers the view-to-install funnel, keyword placement in title and tagline, screenshot and demo-video ordering, category choice, compliant review-velocity programs (incentivized reviews are banned everywhere), badge pursuit ranked by confirmed ranking effect, and defending rank against listing decay. Use whenever t integration-partnership-strategysamberSelect 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 partner mcp-server-offeringsamberDesign 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, MCP Apps interactive UI, 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 oauth2-provider-designsamberDesign 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 scr partner-app-onboardingsamberDesign 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 public-api-design-reviewsamberAudit 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, public-graphql-api-designsamberDesign 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 public-grpc-api-designsamberDesign 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 sdk-portfolio-strategysamberDecide 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 sql-jdbc-access-designsamberDesign 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. U webhook-platform-designsamberDesign 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 consu build-in-publicsamberDesigns a sustainable build-in-public practice for an open-source project or developer tool: how far up the disclosure ladder to go (shipping log, decisions, failures, metrics, revenue), a cadence the maintainer can hold, the platform mix, and the boundaries that keep security, customer and roadmap detail off the public record. Use whenever someone mentions building in public, a devlog, weekly updates, an open-startup or transparency dashboard, sharing metrics or revenue openly, fear of copycats changelog-writingsamberTurns 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 coding-agent-docs-optimizationsamberMakes 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 ag conference-cfp-submissionsamberTurns 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 KubeCo developer-case-studysamberTurns 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 developer-championssamberDesigns 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 quie developer-community-healthsamberDesigns and runs a developer community health measurement framework: activity, responsiveness, contributor-funnel and sentiment metrics, honest instrumentation, baseline-derived thresholds, and a report that ends in decisions. Use whenever someone asks how to measure their developer community, which community health metrics to track, whether their Discord, Slack or forum is dying, why the community feels quiet, or wants a community health dashboard, contributor funnel, community KPI set or engag developer-community-launchsamberDecides 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 f developer-community-moderationsamberWrites 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 developer-docs-structure-auditsamberAudits 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,developer-ecosystem-strategysamberDecides 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 developer-education-strategysamberDecides 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 enab developer-event-sponsorshipsamberBuilds 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 (sambe developer-first-gtmsamberDesigns 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 developer-journey-mapsamberMaps 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 o developer-keyword-researchsamberBuilds 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 sear developer-live-demo-designsamberEngineers 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 dem developer-meetup-programsamberDesigns 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 developer-quickstart-guidesamberWrites 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 developer-relations-kickoffsamberBefore 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 developer-segmentationsamberCuts 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 whe developer-troubleshooting-docssamberTurns 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 th developer-tutorialsamberWrites 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 devrel-analyticssamberBuilds 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 devrel-budget-allocationsamberSplits 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 whe devrel-careersamberPlans, 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 devrel-competitor-analysissamberBenchmarks 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 devrel-content-calendarsamberPlans 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 devrel-hiringsamberEmployer-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, d devrel-metricssamberBuilds 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, im devrel-radarsamberBuilds 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 des devrel-strategysamberDesigns 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 devrel-team-structuresamberDesigns 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 ro devtools-business-modelsamberChooses 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 devtools-pricing-strategysamberDesigns 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 aga docs-code-sample-standardssamberDefines 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 docs-seosamberRuns 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", "engineering-blog-postsamberWrites 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 github-profile-optimizationsamberAudits and rebuilds a personal or organization profile on GitHub as a developer-relations surface - the profile README, the six pinned items, bio and social fields, the organization profile repository, and the contribution signals visitors read as evidence. Use whenever someone says "optimize my GitHub profile", "profile README", "our GitHub org page is empty", "what should I pin", "nobody knows what our company builds on GitHub", or is preparing a launch, a talk or a job search - even if they o open-source-company-strategysamberDecides 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 open-standards-strategysamberDecides 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 v oss-contributor-onboardingsamberDesigns 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 onboard oss-distribution-strategysamberDesigns 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, oss-governancesamberChooses 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 prep oss-issue-triagesamberDesigns 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 oss-launchsamberPlans 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 oss-license-strategysamberChooses 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, wh oss-sponsors-brand-strategysamberBuilds 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 oss-sponsors-fundraisingsamberDesigns 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, won readme-optimizationsamberAudits 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 st tech-employer-brandingsamberDesigns 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", "t tech-podcast-interview-prepsamberPrepares 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 tech-press-relationssamberRuns 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 "ho tech-talk-outlinesamberTurns 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 technical-video-scriptsamberWrites 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, chapters, a runtime budget, accessible narration, a cut list and a YouTube description with one CTA. Also storyboards 2-5 minute animated or motion design explainers. Use whenever someone mentions a screencast script, a demo or walkthrough video, a video tutorial script, a YouTube Shorts, TikTok or Reels script, an animated explain version-migration-guidesamberWrites 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 -