Org-Wide Skills: One Folder, Every Account

The Zip That Lands in Every Account

A zip file. Twelve kilobytes. Inside, a folder; inside the folder, a SKILL dot M D file; inside that file, thirty lines of Y A M L frontmatter and Markdown instructions. The owner of a Team-plan organisation signs into Claude, opens Organisation settings, clicks Skills, clicks the Add button, drops the zip on the upload target. Six seconds later, every user in that organisation opens their own Customise menu, opens their own Skills list, and sees a new entry that wasn't there before, marked with a small badge saying it came from the organisation. Nothing has been emailed. No one has been told. The skill is just there.

This is the mechanic that shipped on the eighteenth of December, twenty twenty-five. Skills for Teams and for the plans above them, what Anthropic calls organisation-wide skill provisioning. The previous episode walked the SKILL file format, the progressive disclosure flow, the description-as-trigger discipline. That was the folder. This episode is the layer above the folder, the layer that decides which folders land in which accounts.

The mechanic has prerequisites. Two toggles in Organisation settings, under Capabilities. Code execution must be on. File creation must be on. Skills run inside a code-execution container, so if code execution is disabled, no skill loads. Once both are on, the Skills tab in Organisation settings becomes useful, and the Add button accepts zip files containing at least one SKILL file. The skill is immediately provisioned to every user in the organisation. Default is enabled. Users can toggle the skill off for themselves if they don't want it loading, but only the owner can remove it from the organisation entirely.

This is the part that matters editorially. The owner uploads; the user receives; the user cannot delete; the user can only toggle. That asymmetry is the whole point of organisation-wide management. If the company has decided that everyone who drafts a board memo should use a specific brand-styled document skill, the company can land that skill in every account at once, and the user can either use it or turn it off, but not throw it away. Authorship sits at the top of the tree.

The Hierarchy and the Indicator

There are now three kinds of skill visible in any given user's Customise menu, and they sit in three sections with three different visual markers. First, the Anthropic skills, the pre-built ones for Word documents, Excel spreadsheets, PowerPoint, P D F, and a handful of others. These are global, available everywhere, identical for every Claude user across every surface. Second, the user's own custom skills, uploaded into that one account, visible only to that user. Third, the organisation-provisioned skills, with the small badge indicating they came from above.

[serious] The user cannot delete a provisioned skill. The user can toggle it off. The owner can remove it from the organisation, in which case it disappears from every account at once. That single removal pathway is also the rollback pathway: if a skill turns out to misbehave, one click in Organisation settings deprovisions it from everyone simultaneously. The personal skills people uploaded for themselves continue to exist; only the organisation-wide instance disappears.

Only owners can add or remove organisation-wide skills. Individual users cannot delete provisioned skills, though they can toggle them off for their own use.

That is the documentation, stated cleanly. Below the owner-provisioning flow there are two more sharing modes, both off by default. Skill sharing lets a member share a skill they have built with named colleagues; the recipient sees it in a Shared With You section of their skill list. Share with organisation lets a member publish a skill to an organisation directory, where anyone in the company can find and install it. The owner controls whether either toggle is enabled. There is no approval step for peer-to-organisation sharing once it is on, which means a company that turns this on has accepted that anyone in the company can publish to a shared catalogue. For most teams that's fine. For a regulated team it might not be.

Now the cross-surface gap, which is the most-commonly-tripped-over thing in this whole release. The previous episode covered the four surfaces where skills exist: Claude dot a i in a browser, Claude Code in a terminal, the Messages A P I as code, and the Bedrock or Foundry deployments via the partner clouds. A skill provisioned through Organisation settings on Claude dot a i is available to users in Claude dot a i. It is not available to the same users when they call the Messages A P I directly. A skill placed in a Claude Code project directory is visible to that project, not to anyone hitting Claude dot a i. Each surface is its own delivery channel. A multi-surface organisation must deploy the same skill to each surface separately, and there is no central console that does this for you.

The pre-built skills, the Anthropic Word and Excel and PowerPoint and P D F skills, do cross all surfaces automatically. Custom skills, including organisation-provisioned ones, do not. This is by design, given the current shape of the surfaces, but it lands as a gotcha for every team that thinks one upload covers every Claude and discovers later that it was really one upload, every Claude dot a i account. Useful to know before you start.

The Directory, the Plugins, the Missing Path

Alongside the organisation-wide flow, Anthropic launched a Skills Directory at claude dot com slash connectors. This is a catalogue of partner-built skills, ready to install. Atlassian skills that turn product specs into Jira backlogs. Notion skills that pull and structure documents. Canva skills that render branded marketing assets without going near the Canva interface. Figma skills for design hand-offs. The admin browses, clicks Install, and the skill flows through the same organisation-provisioning system; the partner skill lands in every user account just like a custom one would.

This is the part of the release that does the most lifting for organisations that don't want to author anything. The Atlassian skill in particular has been described by its makers as the layer that makes Claude not just see Jira tickets but know what to do with them, turning specs into backlogs, generating status reports, triaging issues. Whether or not that lives up to the pitch in practice, the structural point is that an admin can provision a partner-authored workflow to several hundred users without writing one line of skill code.

Now Claude doesn't just see Jira tickets or Confluence pages. It knows what to do, turning specs into backlogs, generating status reports, surfacing company knowledge, triaging issues.

The skill format itself, the frontmatter and the Markdown body of every SKILL file, sits as a published open standard at agent-skills dot i o, alongside a reference Python software development kit. Microsoft has built skill support into V S Code. OpenAI has shipped structurally identical architecture inside ChatGPT and the Codex command-line tool, with the same file naming, the same metadata fields, the same directory organisation. Atlassian, Figma, Canva, and Notion all shipped skills against the spec on day one. Whatever happens to the organisation-wide provisioning details, the underlying file format is now portable across at least three major model vendors and several enterprise software companies. A skill written for Claude this year sits closer to a skill written for any agent surface next year than it did six months ago.

Above skills sits another layer, called Plugins, which package skills together with Model Context Protocol connectors and with sub-agents. There is an admin marketplace flow for plugin distribution, parallel to the skills flow but covering the larger bundle. For developers working in Claude Code on managed laptops, there is a separate piece called M D M-managed settings, where the Code installation is configured through operating-system-level policy delivery, dropping a directory of skills and permissions onto every developer machine the company controls. That is the side of the release aimed at the I T team rather than the user.

Now the gap. There is a public skills A P I, with the beta header skills dash twenty twenty-five dash ten dash oh two. You can use it to create, list, get, update, and delete skills programmatically. What you cannot do, today, is manage organisation-wide skills through it. The public skills A P I is workspace-scoped, not organisation-scoped. The admin interface at Claude dot a i has internal endpoints behind it, with names like upload dash org dash skill and delete dash org dash skill, but those use session-cookie authentication, which makes them unsuitable for any continuous-integration setup or any deployment pipeline. Two public feature requests on the Claude Code repository have asked for an admin path so that organisations can keep their skills in Git and have them auto-deploy on merge. As of recording, the answer is still: not yet.

The Operator and the Paper

[calm] Now the editorial angle, which is the part that's speculative for one solo person sitting in Kall but earns its place because of the shape of what's being built.

The newspaper Pär runs, Årebladet, is one paper for one valley, distributed to roughly six and a half thousand households in Åre kommun, summer edition as the year's anchor revenue event. Behind it sits a plan called Årebladet Live, a multi-tenant version of the same operator pattern, intended to be licensed to other small local papers in other geographies. Same dashboard, different paper. Same workflows, different brand kit, different region, different roster of staff.

In that future shape, a single operator account sitting inside Årebladet Live might play several roles in a single day. The editor role drafts articles, mostly using the arebladet skill, which knows the house tone, the pratminus discipline, the spelling of the regional places, the rules for how a quote is opened, the way an interview transcription is restructured. The sales role builds advertising contracts and calculates the political-advertising disclosure pricing under the European media rules. The distribution role plans the newspaper delivery route through the valley with the B M W telemetry coming in from the side, files mileage as a deductible expense in the corporate accounts.

Each of those roles wants different skills. The arebladet skill makes sense for the editor flow and is useless for sales. A sales skill knowing the contract templates would be a distraction during article drafting. Today the pattern would be: pick the right skill in the moment, manually. With organisation-wide provisioning, the pattern shifts: each Årebladet Live deployment provisions a baseline of skills appropriate to that paper, the editor role has access to the editorial set, the sales role has the contract set, the distribution role has the route-and-telemetry set, and the operator doesn't have to remember which one to load.

The prior art here, the structurally identical pattern Pär has actually shipped, is the multi-tenant shop infrastructure called PärCel. PärCel powers Derbyshop dot s e, Shop dot parception dot s e, and Butik dot arebladet dot s e from a single FastAPI codebase with per-domain branding driven by configuration. One codebase, three deployments, per-tenant customisation through a centralised config layer. Skills for organisations is the same shape, applied to skill bundles instead of shop fronts. The PärCel pattern teaches that the centralised-config-with-per-tenant-overrides approach is workable; whether it generalises from product pages to skill bundles depends on whether the per-tenant differences are smaller than the per-tenant similarities. For small local papers, they probably are.

This entire walk is speculation. Pär does not currently run an organisation Claude deployment. Årebladet Live is on the roadmap after the summer edition of Årebladet ships. The episode is a walk of what exists, mapped to what the operator pattern would use it for when the operator pattern exists. The honest framing is: here is the layer; here is how this particular operator would mount it.

What's Provisioned, What's Missing

[serious] Three maturity gaps to call out plainly before closing.

First, the cross-surface non-sync gap already discussed. Provisioned skills on Claude dot a i do not appear on the Messages A P I or in Claude Code project directories. Multi-surface organisations deploy three times. Pre-built skills cross surfaces; custom and provisioned skills do not. This is the most-tripped-over part of the release.

Second, the missing admin path. The public skills A P I covers workspace-scope. Organisation-scope sits behind a session cookie. Continuous-integration deployment of organisation skills is therefore manual today, browser-mediated, owner-keyed. A team that maintains its skills in Git, the way most teams maintain code, cannot push to main and have the change land in every account without a human clicking the upload button. The feature requests are open; the future state will probably close this; the present state is what it is.

Third, the analytics gap. There is no per-skill usage dashboard. Anthropic has a Compliance A P I that covers broader workspace activity, but there is no surface where an admin can see which skills got loaded how many times, by which users, with what success rate. The recommended pattern from the community is a Slack channel where users post feedback, or a form that collects responses; neither of those is a measurement system, both are surveys. For an organisation that wants to know whether the brand skill it provisioned is actually being used, the honest answer today is: ask.

So this is the state. The layer above the folder exists. It is real, it is usable on Team plans and on the plans above, it provisions one zip to every account in seconds, it is gated by two toggles in Organisation settings, it has a partner directory full of pre-built workflows, it has plugins as the bundle layer and managed-settings as the developer-machine layer, it is missing an admin path for code-as-config rollouts and missing per-skill analytics, and the format underneath the whole thing is now a portable open standard. The Skills primitive that the previous episode walked is one bridge. The organisation layer is the bridge crew, deciding which bridges everyone in the company gets to cross. For an operator like Pär, sitting on a planned multi-tenant deployment that doesn't yet exist, the value is mostly future: the pattern is the right pattern, and the surface is ready when the deployment is. The work that closes the gap between now and then is, almost entirely, the summer edition of Årebladet.