Use this skill when designing SDKs, writing onboarding flows, creating changelogs, or authoring migration guides. Triggers on developer experience (DX), API ergonomics, SDK design, getting-started guides, quickstart documentation, breaking change communication, version migration, upgrade paths, developer portals, and developer advocacy. Covers the full DX lifecycle from first impression to long-term retention.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
The command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
File Explorer
7 files
Showing SKILL.md
SKILL.md
Source instructions · Read-only preview
name
developer-experience
version
0.1.0
description
Use this skill when designing SDKs, writing onboarding flows, creating changelogs, or authoring migration guides. Triggers on developer experience (DX), API ergonomics, SDK design, getting-started guides, quickstart documentation, breaking change communication, version migration, upgrade paths, developer portals, and developer advocacy. Covers the full DX lifecycle from first impression to long-term retention.
When this skill is activated, always start your first response with the 🧢 emoji.
Developer Experience
Developer Experience (DX) is the practice of designing tools, SDKs, APIs, and
documentation so that developers can go from zero to productive with minimal
friction. Great DX reduces time-to-first-success, prevents common mistakes through
ergonomic API design, and communicates changes clearly so upgrades feel safe rather
than scary. This skill equips an agent to design SDKs, write onboarding flows,
craft changelogs, and author migration guides that developers actually trust.
When to use this skill
Trigger this skill when the user:
Wants to design or review an SDK's public API surface
Needs to create a getting-started guide or quickstart tutorial
Asks about developer onboarding flows or time-to-first-success
Wants to write a changelog entry for a release
Needs to author a migration guide for a breaking change
Asks about API ergonomics, naming conventions, or method signatures
Wants to evaluate or improve developer portal structure
Needs to communicate deprecations or upgrade paths
Do NOT trigger this skill for:
Internal team onboarding or HR processes (not developer tooling)
End-user UX design for non-developer products (use UX skills instead)
Key principles
Time-to-first-success is the metric that matters - Every decision in DX
should minimize the gap between "I found this tool" and "I got it working."
If a developer cannot achieve something meaningful in under 5 minutes with
your quickstart, you have a DX problem.
Pit of success over pit of despair - Design APIs so that the obvious,
easy path is also the correct path. Defaults should be safe and sensible.
Make it harder to misuse an API than to use it correctly.
Changelog is a contract, not a diary - Every entry should answer three
questions: what changed, why it changed, and what the developer needs to do.
Internal refactors that don't affect consumers do not belong in changelogs.
Migration guides are empathy documents - A breaking change without a
clear migration path is a betrayal of trust. Every breaking change needs a
before/after example, a mechanical upgrade path, and an explanation of why
the break was necessary.
Progressive disclosure over information dump - Show developers only what
they need at each stage. Quickstart shows the happy path. Guides add depth.
API reference covers everything. Never front-load complexity.
Core concepts
The DX funnel mirrors a marketing funnel but for developers: Discovery
(finding the tool) -> Evaluation (reading docs, trying quickstart) -> Adoption
(integrating into a real project) -> Retention (staying through upgrades). Each
stage has different documentation and design needs.
API surface area is the set of public methods, types, configuration options,
and behaviors a developer must learn. Smaller surface area means lower cognitive
load. Every public method is a commitment - it must be supported, documented,
and maintained. Prefer fewer, composable primitives over many specialized methods.
The upgrade treadmill is the ongoing cost developers pay to stay current.
Changelogs, deprecation notices, migration guides, and codemods are all tools to
reduce this cost. High upgrade cost leads to version fragmentation and eventual
abandonment.
Error messages as documentation - For many developers, the first "docs" they
read are error messages. An error that says what went wrong, why, and how to fix
it is worth more than a perfect API reference.
Common tasks
Design an SDK's public API
Start with use cases, not implementation. List the 5-8 most common things a
developer will do, then design the minimal API that covers them.
Checklist:
Write the README code examples first (README-driven development)
Every method name should be a verb-noun pair (createUser, sendEmail)
Required parameters go in the function signature; optional ones go in an options object
Return types should be predictable - same shape for success, typed errors for failure
Provide sensible defaults for every configuration option
Use builder or fluent patterns only when construction is genuinely complex
Avoid: client.createUserAndSendWelcomeEmail() - compound operations hide
behavior and make error handling ambiguous.
See references/sdk-design.md for the full SDK design checklist.
Write a getting-started guide
Structure every quickstart with this template:
One-sentence value prop - what this tool does for the developer
Prerequisites - language version, OS, required accounts (keep minimal)
Install - one command, copy-pasteable
Configure - environment variables or config file (show the minimum)
First working example - the smallest code that produces a visible result
Next steps - links to 2-3 natural follow-on tasks
The entire guide should be completable in under 5 minutes. If it takes longer,
cut scope - move advanced setup to a separate guide.
See references/onboarding.md for the full onboarding framework.
Write a changelog entry
Follow the Keep a Changelog format. Each entry needs:
## [2.3.0] - 2026-03-14### Added-`client.users.archive()` method for soft-deleting users (#342)
### Changed-`client.users.list()` now returns paginated results by default.
Pass `{ paginate: false }` to get the previous behavior.
### Deprecated-`client.users.delete()` is deprecated in favor of `client.users.archive()`.
Will be removed in v3.0. See migration guide: /docs/migrate-v2.3
### Fixed-`client.invoices.send()` no longer throws on zero-amount invoices (#401)
Rules:
Group by Added, Changed, Deprecated, Removed, Fixed, Security
Link to issues/PRs with parenthetical references
For Changed/Removed: always include the migration path inline or link to one
Never include internal refactors that don't affect the public API
See references/changelog.md for the full changelog guide.
Author a migration guide
Every migration guide follows this structure:
Title: "Migrating from vX to vY"
Who needs to migrate: which users are affected
Timeline: when the old version loses support
Breaking changes table: change, before code, after code, reason
Step-by-step upgrade: ordered instructions with copy-paste commands
Verification: how to confirm the migration succeeded
Troubleshooting: 3-5 most common migration errors and fixes
### Breaking: `createPayment` renamed to `createPaymentIntent`**Before (v1.x):**
const payment = await client.createPayment({ amount: 1000 });
**After (v2.x):**
const intent = await client.createPaymentIntent({ amount: 1000 });
**Why:** Aligns with industry terminology. The old name implied the charge
was immediate, but the object represents an intent that may require
additional confirmation steps.
**Codemod:**`npx @acme/migrate rename-create-payment`
See references/migration-guides.md for the full migration guide template.
Design error messages
Every error message should contain three parts:
What happened - factual description of the failure
Why it happened - the likely cause
How to fix it - actionable next step
AcmeAuthError: Invalid API key provided.
The key starting with "sk_test_abc..." is not recognized.
Get your API key at: https://dashboard.acme.com/api-keys
Docs: https://docs.acme.com/auth#api-keys
Never expose stack traces or internal identifiers in user-facing errors.
Never say "something went wrong" without context.
Evaluate DX quality
Use this scorecard to audit an existing tool's developer experience:
Dimension
Question
Score (1-5)
Time to first success
Can a developer get a working result in < 5 min?
Error quality
Do errors explain what, why, and how to fix?
API consistency
Do similar operations use similar patterns?
Docs freshness
Are docs in sync with the latest release?
Upgrade cost
Is there a migration guide for every breaking change?
Discoverability
Can developers find what they need without support?
A score below 3 on any dimension indicates a DX gap worth prioritizing.
Anti-patterns / common mistakes
Mistake
Why it's wrong
What to do instead
Quickstart requires account creation
Adds 10+ minutes of friction before the developer sees value
Offer a sandbox mode, test keys, or local-only mode for first experience
Changelog says "various improvements"
Developers cannot assess upgrade risk without specifics
List every user-facing change with its impact and migration path
Migration guide without before/after code
Developers cannot pattern-match the change to their codebase
Always show the old code and the new code side by side
Exposing internal abstractions in the SDK
Coupling consumers to implementation details creates fragile upgrades
Only expose what developers need; hide internal plumbing behind a clean facade
Deprecating without a timeline
Developers don't know when to prioritize the migration
Always state when the deprecated feature will be removed (version or date)
Giant config object with no defaults
Forces developers to understand every option before they can start
Provide sensible defaults; require only what is truly required
Version-locked docs with no selector
Developers on older versions get wrong information
Provide a version switcher or clearly label which version each doc applies to
Gotchas
README-driven development only works if you test the README literally - Write the quickstart, then follow it step-by-step in a fresh environment with no prior knowledge. Steps that "obviously" work to the author often fail for a developer with a different OS, different shell, or missing global dependencies.
Changelog entries for "Changed" items without migration paths create upgrade anxiety - Developers read changelogs to assess upgrade risk. A vague "Changed: sendEmail behavior" without before/after examples causes developers to skip the upgrade entirely rather than risk breakage.
Deprecation warnings in the SDK must be impossible to miss - Emitting a console.warn that gets swallowed by log levels or a CI environment means developers never see the deprecation. Use both a runtime warning and a TypeScript @deprecated JSDoc annotation so IDEs surface it at code-writing time.
Error messages that expose internal stack traces in production erode security trust - Returning raw stack traces or internal service names to SDK callers is a common DX anti-pattern from copy-pasting dev-mode error handling to production. Sanitize all user-facing errors before release.
Version-locked docs that lack a version selector actively mislead developers on older versions - If your docs always show the latest API and a developer is on v1.x, they'll write broken code confidently. Either provide a version selector or prominently banner every page with the applicable version range.
References
For detailed content on specific sub-domains, read the relevant file from
references/:
references/sdk-design.md - Full SDK design checklist covering naming, error
handling, configuration, and extensibility patterns
references/onboarding.md - Complete onboarding framework with templates for
quickstarts, tutorials, and developer portal structure
references/changelog.md - Changelog format guide, semantic versioning rules,
and deprecation communication playbook
references/migration-guides.md - Migration guide template, codemod patterns,
and breaking change communication strategy
Only load a references file if the current task requires deep detail on that topic.
Companion check
On first activation of this skill in a conversation: check which companion skills are installed by running ls ~/.claude/skills/ ~/.agent/skills/ ~/.agents/skills/ .claude/skills/ .agent/skills/ .agents/skills/ 2>/dev/null. Compare the results against the recommended_skills field in this file's frontmatter. For any that are missing, mention them once and offer to install:
