Start a fresh conversation. Replace the highlighted placeholders.
Use sdk-dx to review the public API design for [SDK] after reading the required detailed guide, and return a prioritized developer-experience recommendation covering native-feeling APIs and actionable error messages; do not make changes until dependencies, environment-specific tests, security review, and approval are verified.
Required inputs
[SDK]
User-approved starter prompt based on a pinned source version; check current skill requirements before running. Task evidence ↗
SKILL.md
name: sdk-dxdescription: "Design SDKs that developers love to use—APIs that feel native, error messages that guide, and experiences that reduce friction. This skill covers creating SDKs that drive adoption through exceptional developer experience rather than aggressive marketing."risk: criticalsource: https://github.com/jonathimer/devmarketing-skills/tree/main/skills/sdk-dxsource_repo: jonathimer/devmarketing-skillssource_type: communitydate_added: 2026-07-01license: MITlicense_source: https://github.com/jonathimer/devmarketing-skills/blob/main/LICENSE
SDK Design and Developer Experience
Detailed Guide
Read the detailed guide before executing this skill. It retains the complete procedure and reference material. Treat its safety, prerequisites, and validation requirements as mandatory. For focused work, load the relevant sections; for end-to-end work, read the guide completely.
When to Use
Use this skill when you need design SDKs that developers love to use—APIs that feel native, error messages that guide, and experiences that reduce friction. This skill covers creating SDKs that drive adoption through exceptional developer experience rather than aggressive marketing. Trigger phrases: "SDK design",...
The best SDK marketing is an SDK that developers can't stop talking about. When your SDK makes developers feel productive and competent, they become your advocates. When it frustrates them, no amount of marketing will save you.
Limitations
Use this skill only when the task clearly matches its upstream source and local project context.
Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.