WorkOS skills is in the Claude plugin marketplace

Most developers don't read docs anymore, they ask Claude. That shift changes where developer tools need to live. WorkOS skills are now available in Claude's official plugin marketplace, which means any Claude user can install them with a single command and start managing identity, auth, and directory sync resources by just talking.

The problem with "go read the docs"

Every API company has the same story: great docs, great SDKs, and a long tail of developers who still get stuck on the first integration. The reason isn't bad documentation. It's that context-switching between an editor, a dashboard, and a docs site to wire up SSO or SCIM is friction that compounds across a workday.

The AI assistants developers already use (Claude in particular) are increasingly where that friction gets resolved. If your tooling isn't reachable from inside that surface, you're invisible at the moment of need.

What WorkOS skills actually do

WorkOS skills let you manage identity, auth, and directory sync resources through natural language. Instead of navigating the dashboard or writing a script against the API, you describe what you want: set up a new SSO connection for this customer, check the status of this directory sync, create a test organization. The skill handles the underlying API calls.

The more interesting capability is with multi-step or ambiguous tasks, where natural language compresses real cognitive overhead. "Walk me through configuring SSO for a new tenant" isn't a single API call. It's a sequence of decisions and operations that the skill can guide you through without requiring you to hold the entire WorkOS resource model in your head.

Installing WorkOS skills

The install path is standard. Any Claude user can run /plugin, search for WorkOS, and install. Once installed, the skill is available in any Claude conversation.

  
/plugin
> search: workos
> install
  

That's it. Once installed, the skills are available in any Claude conversation. You can ask Claude to provision a connection, inspect a directory, or walk you through configuring SSO for a new tenant, and it will invoke the skill rather than generating API calls from training data.

First use

Try whatever you'd normally open the dashboard for, or paste into a docs search. The examples below are grouped by what you're trying to do.

Setting up auth

• "Add AuthKit to my Next.js App Router project."
• "Set up AuthKit in my SvelteKit app and create the callback route."
• "I'm using React Router v7. Walk me through the AuthKit integration."
• "Generate a magic-auth link for this user."

The skill detects your framework context and loads the right reference automatically. You don't need to specify which SDK or which installation path.

Managing organizations and SSO

• "Create a new organization called Acme and give me the org ID."
• "Set up a SAML connection for this organization."
• "Show me the active SSO connections for org_01JXYZ."
• "Debug the SSO connection for this customer: what's the current state and are there recent auth errors?"

Directory sync

• "What's the directory sync status for this customer, and when did it last sync?"
• "Show me the users and groups currently synced for this directory."
• "The directory sync for this org looks stalled. What should I check?"

Roles and permissions

• "List the roles in this environment."
• "Create a viewer role with read-only permissions."
• "What permissions does the admin role have?"

Migrations

• "I'm migrating from Auth0. What's the right approach for user records?"
• "We're moving off Clerk. Walk me through the migration steps."
• "What do I need to handle when migrating from Firebase Auth?"

Events and audit logs

• "Show me recent webhook events for this organization."
• "What audit log events are available and how do I filter by actor?"

General management

• "Provision a test organization and seed it with an admin and viewer role."
• "Onboard a new user to this organization with the admin role."
• "List all environments and show me which one I'm currently working in."

Why this matters beyond a single integration

There's a broader pattern worth naming: developer tools are increasingly showing up inside AI assistant marketplaces, not just as standalone SDKs and CLIs. The plugin shelf inside Claude functions as a discovery surface, a place where developers find capabilities, not just install them.

That has a few implications:

• ‍Discovery moves into the assistant. When a developer asks Claude "how do I add SSO to my app", the answer is no longer just a link to docs. If a relevant skill is installed (or installable) the answer is "let's do it now." Being in the marketplace means being part of that answer.‍
• The unit of integration shrinks. A skill is a focused capability the assistant can invoke, scoped more narrowly than a full SDK or CLI. That lowers the bar for trying a tool: you don't commit to a dependency, you install a skill and see if it helps.‍
• Documentation becomes a runtime, not a reference. The skill introduces εa lower commitment threshold. Installing a skill isn't taking on a dependency. You try it on the next thing you'd have opened the dashboard for. If it helps, it becomes part of how you work. If it doesn't, nothing was added to a package.json.

The documentation-as-runtime idea

One implication worth sitting with: when behavior is encoded in a skill rather than written in a doc, errors surface differently. A doc can be read correctly and implemented incorrectly. A skill either calls the API right or it fails loudly. The feedback loop compresses from "ship a broken integration and find out later" to "the call failed, here's why."

That's a meaningful shift for developer experience, and it puts pressure on the skill author to encode correct behavior, not just explain it.

What this signals

The WorkOS move is an early data point in a pattern that's likely to repeat. Developer tools are beginning to show up inside AI assistant marketplaces as a primary distribution channel, not a secondary one. The SDKs and dashboards aren't going away. But for a growing share of developer workflows, the starting point is a conversation, and the tools that are reachable from inside that conversation have a structural advantage over the ones that aren't.