developer-platform-skills eklentisi

• agent-integration-surfaces

  Plans how a SaaS or developer platform opens itself to AI agents, provider side - which agent classes may reach which surface, how an agent proves its identity and acts for a user (Web Bot Auth, delegated tokens, provision-then-claim signup), which execution path each gets, where agents find it (Context7, api-catalog) and how agent usage is counted. Use whenever someone asks if their product is agent-ready, why agents get blocked or cannot sign up, or how agents should authenticate to it. Do NOT use for MCP tool design (samber/developer-platform-skills@mcp-server-offering), surface build order (samber/developer-platform-skills@api-integration-surface-strategy) or agent-readable docs (samber/developer-relations-skills@coding-agent-docs-optimization).

• agent-skill-offering

  Ships an Agent Skill (SKILL.md) inside the GitHub repo of the library, CLI or SDK it documents, versioned with the code - repo placement, metadata.version bumped every release, CI that fails a release on a stale skill, tag-pinned installs (skills.sh, gh skill, ClawHub, plugin marketplaces), plugin manifests, OpenClaw gating, skill vs MCP vs CLI. Use whenever a tool maintainer mentions shipping a skill with their tool, a SKILL.md for their library, keeping a skill in sync with releases, or plugin.json versions for a skill beside code - even if they never say "agent skill". Not for standalone skill collections. Do NOT use for CLI command or --json design - use samber/developer-platform-skills@cli-interface-design; nor for MCP servers - use samber/developer-platform-skills@mcp-server-offering.

• api-auth-key-management

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

• api-beta-program

  Runs an early-access, preview, beta or design-partner program for a new API feature: program shape, what each pre-GA label guarantees (SLA, support, breaking-change notice, pricing, data terms), stage on the wire, partner selection, per-account access, feedback cadence, exit to GA or kill, and rescuing betas that never ended. Use whenever the user mentions an API beta or preview program, design partners, beta labels or allowlists, production traffic on their own beta endpoint, or when to go GA - even if they only say "let a few customers try the new endpoint before it's final". Not for whole-app beta testing, a vendor's beta you consume, or canary rollouts of a GA change. Do NOT use for the stable version lifecycle - use samber/developer-platform-skills@api-versioning-policy.

• api-changelog-automation

  Designs the provider-side pipeline that turns contract diffs of an API you publish (OpenAPI, GraphQL SDL, protobuf, AsyncAPI) into a breaking-change CI gate and a traced, per-version API changelog feed, classified by your own policy. Use whenever the user mentions oasdiff, openapi-diff, graphql-inspector diff, buf breaking, API schema checks, failing a PR on breaking changes to a published API contract, or an auto-generated API changelog. Do NOT use for release-note prose (samber/developer-relations-skills@changelog-writing), consumer-side upgrades (samber/developer-relations-skills@version-migration-guide), deprecation policy (samber/developer-platform-skills@api-versioning-policy) or callers of deprecated endpoints (samber/developer-platform-skills@integration-health-monitoring).

• api-error-design

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

• api-idempotency-retry

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

• api-integration-surface-strategy

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

• api-rate-limit-policy

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

• api-reference-quality

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

• api-status-communication

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

• api-test-mode-design

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

• api-versioning-policy

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

• app-marketplace-launch-marketing

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

• app-marketplace-listing-standards

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

• app-marketplace-monetization-model

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

• app-marketplace-review

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

• atlassian-marketplace-playbook

  Takes a B2B SaaS vendor's Jira, Confluence or Jira Service Management app onto the Atlassian Marketplace and keeps it there - Forge vs Connect, Free vs Paid via Atlassian for a connector to a paid SaaS, payment-model locks, pricing and revenue share, approval prerequisites, major versions needing review and admin consent, Connect-to-Forge migration, Enterprise Certified (successor to Cloud Fortified), bug-fix SLAs. Use whenever a vendor mentions listing on the Atlassian Marketplace, a Marketplace Forge or Connect app, a stalled ECOHELP review, or applying for Cloud Fortified. Do NOT use for listing copy or search rank (use samber/developer-platform-skills@integration-listing-optimization), for Forge code, internal-only apps, Bitbucket, Compass or Trello apps, or buyers vetting apps.

• aws-marketplace-playbook

  Takes a B2B SaaS vendor onto AWS Marketplace as the ISV seller - whether to list, irreversible account and pricing model choices, going public, private offers, CPPO resale authorizations, EDP/PPA commit drawdown, and co-selling through ACE and ISV Accelerate. Use whenever a vendor mentions AWS Marketplace, a private offer, CPPO, burning a customer's AWS commit, the Deployed on AWS badge, or ACE, ISV Accelerate or FTR for its listing, even if they only ask how to sell through AWS. ISV side only: not buyers, not resellers. Do NOT use for listing copy or search rank (use samber/developer-platform-skills@integration-listing-optimization), for your own marketplace's billing (use samber/developer-platform-skills@app-marketplace-monetization-model), or for metering code.

• bulk-data-sharing-design

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

• chrome-web-store-playbook

  Gets a B2B SaaS or developer-tools vendor's companion Chrome extension through Chrome Web Store review and keeps it published - permission scoping, reviewer access to login-gated features, the Privacy practices tab, violation IDs such as Purple Potassium, permission changes in updates, rollout and rollback, publisher-account security, per-customer and enterprise distribution. Use whenever a vendor mentions publishing a Chrome extension, a Chrome Web Store rejection or takedown, the item limit, or white-label builds for customers. Vendor side only: not IT admins, Firefox AMO, Edge Add-ons or code. Do NOT use for VS Code or JetBrains extensions (use samber/developer-platform-skills@ide-extension-offering) or listing copy (use samber/developer-platform-skills@integration-listing-optimization).

• cli-interface-design

  Design the public CLI that wraps a developer platform's API - which commands exist (curated commands plus a raw api escape hatch, not a 1:1 REST mirror), grammar, flag/env/config precedence, a frozen --json and exit-code contract, TTY behavior, login and CI tokens, pagination and --wait, errors, help, flag deprecation, telemetry, and safe use by scripts and coding agents. Use whenever the user mentions designing or reviewing a CLI for their API, CLI command naming, --json output, exit codes, CLI login, or an agent-friendly CLI - even without saying "CLI design". Not for API-less tools or parser code. Do NOT use for whether to offer a CLI (samber/developer-platform-skills@api-integration-surface-strategy) or a skill shipped with it (samber/developer-platform-skills@agent-skill-offering).

• connector-certification-program

  Design the certification program a platform operator runs for connectors partners build on it - go/no-go, ownership-first labels, measurable criteria, test kit, telemetry gates, support routing, renewal, decertification. Use whenever the user mentions connector certification, a certified or verified badge for partner-built connectors, a partner integration test suite, certification renewal or expiry, decertification, or certified-vs-community labels - even without saying "certification". Do NOT use for app admission security review (samber/developer-platform-skills@app-marketplace-review), earning a badge on someone else's platform (samber/developer-platform-skills@etl-connector-strategy), or certifying people (samber/developer-relations-skills@developer-certification-program).

• connector-marketplace-strategy

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

• developer-platform-career

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

• developer-platform-hiring

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

• developer-platform-kickoff

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

• developer-portal-design

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

• etl-connector-strategy

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

• github-action-offering

  Ships a vendor's official GitHub Action customers run in CI to call its product - setup vs task action, composite vs JavaScript vs container, action.yml as a frozen contract, major tags plus immutable releases, OIDC instead of long-lived keys, hardening against injection and tag hijack, Marketplace listing, ports to GitLab components, CircleCI orbs and other CI. Use whenever a vendor team mentions an official action, action.yml, a setup-<tool> action, moving the v1 tag, or an orb or GitLab component - even if they only say "customers want us in CI". Not for pinning third-party actions, internal-only actions or OIDC to clouds. Do NOT use for CLI design - use samber/developer-platform-skills@cli-interface-design; nor registry publishing - use samber/developer-platform-skills@sdk-package-publishing.

• github-engagement-playbook

  Plans a repository's post-launch engagement on GitHub as a social platform - stars, watchers and release notifications, Discussions, topics, labels, Trending, the home feed and traffic tracking - with ready-to-paste issue, PR and release templates. Use whenever GitHub stars are flat, someone asks how to grow engagement on a repo or SDK, set up Discussions Q&A or a label scheme, get a Release seen by watchers, or whether to buy or trade stars, even if they only say nobody notices the repo. Not a launch - use samber/developer-relations-skills@oss-launch. Not README copy - use samber/developer-relations-skills@readme-optimization. Not cross-channel cadence - use samber/developer-relations-skills@oss-distribution-strategy. Not license choice - use samber/developer-relations-skills@oss-license-strategy.

• github-marketplace-playbook

  Gets a vendor's GitHub App or GitHub Action listed on GitHub Marketplace and, for apps, selling there - free vs paid listing, publisher verification, marketplace_purchase billing duties, immutable pricing plans, enterprise buyers Marketplace cannot bill, the verified creator badge, delisting. Use whenever a vendor mentions GitHub Marketplace, listing a GitHub App, Marketplace paid plans, or selling through GitHub billing. Publisher side only; not for buying or allowlisting Marketplace apps as a customer. Do NOT use for building the action (use samber/developer-platform-skills@github-action-offering), repository growth (use samber/developer-platform-skills@github-engagement-playbook), or launch announcements (use samber/developer-platform-skills@app-marketplace-launch-marketing).

• google-workspace-marketplace-playbook

  Gets a SaaS vendor's Google Workspace integration through Google OAuth app verification and onto the Google Workspace Marketplace - Gmail, Drive and Chat scope choice, the CASA security assessment, listing review, admin domain-wide install, changes after listing. Use whenever a vendor mentions publishing a Workspace add-on, Gmail or Drive integration, or Chat app, the "Google hasn't verified this app" screen, the 100-user cap, CASA, restricted scopes, or a rejected Marketplace review. Do NOT use for listing copy (use samber/developer-platform-skills@integration-listing-optimization), for your own API's OAuth (use samber/developer-platform-skills@oauth2-provider-design), or for internal-only apps.

• graphql-federation-offering

  Design how a platform lets outside partners and third-party apps contribute fields or data to its own public GraphQL graph - the extension ladder from app-owned custom fields and platform-run connectors up to partner-hosted subgraphs, what partner SDL may claim (@override, @requires), what the router forwards to a partner, blast radius, and offboarding. Use whenever the user mentions partner subgraphs, letting partner apps add fields to their schema, a partner-extensible supergraph, or stitching partner APIs into the graph they publish - even without saying federation. Not for consuming third-party APIs in your own client, or building an app on another platform. Do NOT use for a single-owner schema or internal federation - use samber/developer-platform-skills@public-graphql-api-design instead.

• hubspot-marketplace-playbook

  Gets a B2B SaaS vendor's app listed on the HubSpot Marketplace and keeps it there - the three-active-install gate, the 25-install cap on unlisted apps, apps HubSpot refuses, scopes and the Shared data table, Draft bounces, review timelines, version deadlines, AI connector and MCP rules, App Certification, Technology Partner tiers. Use whenever a vendor mentions listing or certifying its app on HubSpot, a listing sent back to Draft, or HubSpot technology partner tiers. Do NOT use for listing copy or install conversion (use samber/developer-platform-skills@integration-listing-optimization), for running your own marketplace (use samber/developer-platform-skills@app-marketplace-review), for CMS themes, for admins vetting another vendor's app, or for CRM admin, API code or agency work.

• huggingface-playbook

  Publishes a company's own models, datasets and Spaces demos on the Hugging Face Hub - org verification, repo-per-variant layout, card metadata, license and gating (incl. EU AI Act open-weights duties), demo Spaces, inference widgets, trending and the Community tab. Use whenever a team plans a model or dataset release on Hugging Face, asks whether to gate it, why their model has no traction or no inference widget, how to trend on HF, or what their Hub downloads mean - even if they only say "our model goes on HF". Publisher side only, not for choosing or deploying someone else's model. Do NOT use for PyPI or npm releases of the loading library - use samber/developer-platform-skills@sdk-package-publishing; or cross-channel launch planning - use samber/developer-relations-skills@oss-launch.

• ide-extension-offering

  Decides whether a developer platform should ship an official IDE extension (VS Code, JetBrains), and runs it: job versus cheaper surfaces, IDE families and forks, a thin shell over the CLI, shared login, publishing to VS Code Marketplace, Open VSX and JetBrains Marketplace, telemetry obeying the IDE setting, deprecation. Use whenever a vendor mentions building or maintaining a VS Code extension or JetBrains plugin for their product, vsce, ovsx, Open VSX, or "developers want us in the editor" - even without saying "IDE extension". Not for internal or personal extensions, writing extension or language-server code, or choosing extensions to install. Do NOT use for CLI design - use samber/developer-platform-skills@cli-interface-design; nor agent tools - use samber/developer-platform-skills@mcp-server-offering.

• integration-error-observability

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

• integration-health-monitoring

  Find third-party integrations on your platform that will break on a known date - version drift, deprecated-endpoint usage, SDK end of life, expiring or dormant credentials - reach their owners, and decide when a deprecated surface is safe to turn off. Use whenever the user mentions version drift, who still calls a deprecated endpoint, partners on old API versions, chasing integrations before a sunset, brownouts, or retiring an API surface third parties call, even without saying "integration health". Not for migrating off another vendor's API. Do NOT use for live error dashboards (samber/developer-platform-skills@integration-error-observability), deprecation policy (samber/developer-platform-skills@api-versioning-policy) or key expiry design (samber/developer-platform-skills@api-auth-key-management).

• integration-listing-optimization

  Optimize a B2B SaaS vendor's own listing on a third-party app marketplace - Salesforce AppExchange, HubSpot, Atlassian, Shopify, Slack or similar. Covers the view-to-install funnel, keyword placement, screenshot and demo-video order, category choice, compliant review velocity, badge pursuit and rank decay. Use whenever the user mentions an AppExchange listing, marketplace listing conversion, marketplace search rank, app installs or app reviews - even without saying "listing optimization". Do NOT use for the operator's own rulebook (use samber/developer-platform-skills@app-marketplace-listing-standards), AppExchange packaging or security review (samber/developer-platform-skills@salesforce-appexchange-playbook), or Slack app review (samber/developer-platform-skills@slack-app-directory-playbook).

+21