Share what you build with your team

In this lesson, you'll explain how plugins get distributed across an Enterprise organization and apply good habits for keeping a shared plugin healthy over time.

Scaling workflows across your team

By this point, your team has a handful of skills that have earned their place. They started as someone's personal way of working, they've been run through evals, and they hold up on more than one person's use cases.

When you want to scale those across the whole team efficiently, you bundle them into a plugin — you covered how in Lesson 8. This lesson is about the next step: getting that plugin to everyone who needs it.

Distributing a plugin in your organization

Inside a larger company, the recommended way to share a plugin is through your organization's private marketplace — a catalog of company-approved plugins that an admin manages.

In practice, distribution is a hand-off. You bring the plugin to whoever owns the marketplace for your org — that might be a team lead, an enablement or operations owner, or IT — and they publish it. When they do, they choose how it lands for everyone else:

• Available — it appears in the company Directory and people can install it if they want it.
• Installed by default — it's already there when people open Cowork; they can turn it off.
• Required — it's installed and stays on; useful for things like compliance checks that everyone needs to run the same way.

From your teammates' seat, the plugin simply shows up in their Directory labeled as coming from your company, alongside the public Anthropic ones. They can use it and turn it off (unless it's required), but they can't edit it — updates flow from whoever maintains it.

What this looks like for you depends on what your admin has set up. Some organizations have a marketplace running and a clear owner to hand things to; others haven't switched it on yet.

Habits worth keeping

A short set of practices that prevent a shared plugin from quietly going stale:

• One owner. Every shared plugin has a named person who reviews changes, runs the evals after edits, and decides when to update or retire it.
• Evals before every publish. Treat the eval loop as the gate — if the cases you care about don't hold up after a change, don't push it to everyone.
• Name skills and plugins specifically. "meeting-prep" may collide with three other meeting-prep skills across your organization's plugins directory. "sales-customer-renewal-prep" won't.