Share a skill with your team, and keep it under one owner

Often on a compliance team, one person ends up owning the method for a recurring job. How a vendor SOC 2 report gets reviewed. How a risk gets written up so it survives the audit. How a gap analysis is scored. That person has worked out the exact instructions, the order to check things in, the wording that holds up. Others ask them, or try to remember what they said last time.

Custom skills already let that person write the method down. A skill is a saved instruction pack the assistant applies when your request matches what you described, with a small chip above the response so you can see which one fired. It is a tool in a drawer, not a uniform you wear: it activates on the tasks it fits and stays out of the way otherwise.

The gap was that a skill lived in one account. If you built the good SOC 2 review skill, your teammate could not use it. So teams did the obvious workaround, which was the wrong one: paste the instructions into chat by hand, or have each person rebuild their own version. Both drift. You end up with several slightly different versions of the method and no clear sense of which one is current.

What shipped

In a team, any member can now share one of their custom skills with everyone. Teammates enable it and use it like any other skill, built-in or their own. Your personal skills stay private unless you choose to share one.

The part that matters for a compliance team is what does not change hands. A shared skill stays read-only for everyone except its owner. Teammates can turn it on and use it; only the owner can edit it, unshare it, or delete it. So the team works from one maintained skill, kept by its owner, instead of each person's private version of it.

Why read-only is the point

The instinct on a collaboration feature is to let everyone edit. For how a team uses an assistant on regulated work, a single maintainer is often the better default. When one person owns the shared skill, there is one authored instruction set for the task and a clear line between using the method and changing it.

Teammates can still write and use their own skills; sharing just puts the owner's version on the shelf for everyone to enable. What read-only adds is a single point of maintenance for the shared one, so it does not drift as more people reach for it. The owner keeps the pen, and the team gets a common version to work from.

It carries across the surface

A shared skill is not only a chat shortcut. When a teammate runs Beyond, the multi-document mode, on a job the skill fits, the skill shapes that run too: it follows the same tone, format, and rules while Beyond plans and drafts each document. So the house method holds from a quick answer in chat to a full drafting run over a set of documents, for whoever on the team has the skill enabled, not just the person who wrote it.

Who it is for

This is for the team that has already found its good way of doing a thing and wants everyone on it. The reviewer who wants every vendor assessment to hit the same bar. The lead who wants risks written in one house format instead of five personal ones. The person who is the de facto standard and would rather share the standard than answer the same question again.

It is less useful if your skills are genuinely personal, a way you like your own answers formatted, and there is nothing to make private about that. Those stay yours. Sharing is a deliberate act, one skill at a time, when the method is worth spreading and worth keeping under one owner.