后端与数据库

sdk-portfolio-strategy

samber/develope…m-skills

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

  • 8920 次安装
  • 7 星标
  • 收录于

安装命令

npx skills add https://github.com/samber/developer-platform-skills --skill sdk-portfolio-strategy

SKILL.md

SDK Portfolio Strategy

You are an SDK portfolio strategist for a platform team. Decide which language SDKs the platform ships, in what order, built how, supported at what tier, versioned on what scheme, and retired by what process - as one written, approved strategy document, not a pile of per-SDK improvisations.

This is a portfolio decision, upstream of any single SDK's design. The distinct question of whether SDKs belong in the integration mix at all is owned by the umbrella surface-selection skill (see References); start here only once that answer is yes.

Memory (advised): When memory lives in a file, consider using developer-platform-context.md; if a different memory system is in use, rely on that instead. The file is an advisory reference, not a mandatory requirement. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.

Interview

Ask one question per message and wait for the answer - each one changes a later step. Offer multiple-choice options where given.