Per-role skill scoping is a hybrid: build one plugin per pack, then assign it with a native toggle

The question

"Does Anthropic's Skills API (/v1/skills) or Cowork org-admin expose native per-role/per-workspace enablement scoping, or must skill-packs be enforced by shipping separate plugin bundles per rail? (Config toggle vs distribution-build decision.)"

Context: this is open follow-up 1 from [[2026-07-07-claude-skill-count-degradation-skill-packs]]. That brief set the rule "install broad, enable narrow" for the ~60-skill Organizational Intelligence (OI, formerly "CAF") deployment. This brief checks whether Anthropic's own admin surfaces can apply that rule as a setting, as of 2026-09-15.

What we already know (from the vault)

• The packaging rule we are trying to enforce. [[2026-07-07-claude-skill-count-degradation-skill-packs]] recommends role packs (a pre-sales pack for the ~60 sales users on Cowork, a build pack for the ~12 engineers on Claude Code) and phase packs, with an active surface of about 15 to 20 skills per user. It flagged that no formal "skill packs" mechanism was published as of July.
• One plugin now spans both rails. [[2026-07-09-anthropic-plugin-ecosystem-vs-rdco-brigade-plugins]] found that the same plugin installs in Cowork (Customize sidebar, claude.com/plugins) and in Claude Code (claude plugin marketplace add). The June "skills ride two rails" constraint has converged. Anthropic's own knowledge-work plugins are already role-shaped (sales, legal, finance...), with one plugin per role.
• The guide's distribution chapter is the reference. [[2026-06-30-anthropic-skill-guide-vs-brigade-comparison]] treats Chapter 4 of the Complete Guide (Cowork org-admin rail plus Code plugin rail) as the reference for OI distribution.
• Token cost is not the reason to scope. [[2026-09-14-oi-skill-description-token-cost-audit]] measured the OI skill descriptions at about 3K to 5K tokens always-on. The OI Snowflake frontend repo's .claude/settings.json holds only enabledPlugins, so per-project plugin enablement is already in use. Scoping is about trigger collision and role fit, not budget.
• Plan split already assumed. [[2026-06-14-caf-restructure-organizing-brief]] puts skills in the plugin and data tools in a separate remote MCP (Model Context Protocol) server. That split stays valid under the findings below.

What the web says

• claude.ai / Cowork: skills uploaded org-wide go to everyone. "When you upload a skill through organization settings, it becomes available to everyone in your organization." Users can turn off individual provisioned skills, but they cannot delete them. The article describes no admin force-on. (Provision and manage skills for your organization, Team and Enterprise, undated "updated over a week ago")
• claude.ai / Cowork: group scoping exists, but the unit is a plugin. To limit skills to some users, admins "bundle your skills into a plugin and assign that plugin to a group. The group's members see those skills." Group targeting set up for Cowork "carries over to chat." Provisioning is web UI only. No admin API is documented. (same article)
• Enterprise custom roles gate feature categories, not skill identity. Roles are assigned to groups, not individuals, and grants add up across groups. Capabilities include "Skills management," skill and plugin security scanning, Claude Code, Claude Cowork, and Claude Design. Admin areas include "Libraries" (skills, plugins, connectors). Connectors get per-tool "Always allow / Needs approval / Blocked." No role setting picks which skills or plugins a group gets. That is handled by plugin-to-group assignment. (Manage custom roles on Enterprise plans, Enterprise only)
• Claude Code: one managed policy per delivery target, no group targeting in the console yet. The managed-settings doc says: "A managed settings file, an MDM profile, or the claude.ai console applies one policy to everyone it reaches. To give one group of developers a different policy, deploy a different file or profile to that group; the claude.ai console can't target a group yet, while a self-hosted Claude apps gateway delivers managed settings per IdP group." (Deploy managed settings). MDM is mobile device management (Jamf, Intune). IdP is the identity provider (Okta, Entra).
• Claude Code: plugin keys work at whole-plugin granularity. enabledPlugins written at project scope (.claude/settings.json) enables a plugin for everyone who clones the repo. Plugins force-enabled through managed enabledPlugins "cannot be disabled" by local settings (Discover plugins, Plugin marketplaces). Managed-only restriction keys are strictKnownMarketplaces, blockedMarketplaces, disableSideloadFlags, and strictPluginOnlyCustomization. The last one blocks skills, agents, hooks, and MCP servers from user and project sources, either all four or a named subset. The docs say nothing about turning off individual skills inside an enabled plugin.
• API: /v1/skills is scoped to the workspace, with no per-user access control. Custom skills are "private to their workspace," and "all workspace members can access them." Anthropic's docs describe no finer access control (Using Agent Skills with the API, Skills API reference). Two ways to scope: split across separate API workspaces, or have the calling app list only the skills it wants in each Messages request (the container.skills array). In that case the app does the routing. Not re-verified this run: the per-request skill cap (recalled as 8).

Convergences and contradictions

• Convergence: the plugin is the unit of scoping on every surface that has scoping. The July brief guessed that packs would come "from Claude Code plugins (bundle skills, enable per-project)." Anthropic's September docs confirm it and extend it to Cowork. Group assignment works on plugins, not on loose skills.
• Contradiction in the question's framing: "separate plugin bundles per rail" is the wrong split. The July plugin-ecosystem note showed that one plugin now spans Cowork and Code. The build split is per pack (role or phase), not per rail. A sales pack plugin and a build pack plugin can each install on either surface.
• Partial gap: Code-side group targeting lags Cowork. Cowork can assign a plugin to a group in the admin console today. Claude Code's console "can't target a group yet." Code group scoping needs either a per-group MDM profile or file, per-repo enabledPlugins, or a self-hosted Claude apps gateway keyed to IdP groups.

Synthesis for RDCO

Verdict: hybrid. The pack boundary is a build decision. Assigning a pack to a role is a native toggle on Cowork and a configuration job on Claude Code. No Anthropic surface lets you ship one 60-skill plugin and then toggle which subset each role sees. The finest admin-controlled unit is the whole plugin. Org-wide uploaded skills are all-or-nothing, apart from users switching them off for themselves. So "install broad, enable narrow" becomes "build narrow, assign by group." Each OI pack has to be its own plugin. Once it is, the assignment step is a setting, not a new build.

What this means for the OI plugin build. The distribution pipeline (brigade-house as dev home, distribute.py as generator) should produce one plugin per role pack. A likely first cut is oi-presales (Phases 1 to 4, the use-case and Build Manifest work) and oi-delivery, plus a router skill in each. They should ship from one private marketplace rather than as one monolithic OI plugin. Each pack plugin keeps its own ~15-to-20-skill surface, which puts the July brief's cap directly into the package boundary. After that, a phData Enterprise admin assigns oi-presales to the sales group and oi-delivery to the engineers in the Cowork console. That is a two-click toggle, and it carries over to chat. For engineers in Claude Code, the realistic path today is a project-scope enabledPlugins entry in each engagement repo, plus a managed strictKnownMarketplaces pinning the phData marketplace. Per-person enforcement at the machine level would need phData IT to push MDM profiles per group, which is a heavier ask. The self-hosted apps gateway is a project of its own.

Two things this does not give us. First, Cowork provisioning does not guarantee a skill stays on. Users can switch off provisioned skills, and the article describes no admin lock. "Enable narrow" is enforceable. "Always present" is not. Second, finer per-phase scoping inside a role (for example, hiding delivery-phase skills during pre-sales) can only come from more, smaller plugins or from the router skill. Admins have no per-skill switch. That tilts the design toward a router skill per pack plugin rather than a large number of micro-plugins, because each extra plugin adds admin assignment work.

Why this is in the vault

This settles whether the OI fleet deployment to phData's ~60 sales users and ~12 engineers needs a packaging change in the distribution build (it does: one plugin per role pack) or only admin configuration (only after that change). It also sets what we ask of phData's Enterprise admin (group-to-plugin assignment in Cowork) versus phData IT (MDM profiles or project settings for Claude Code).

Open follow-ups

• Does Cowork group assignment of a plugin auto-install it for group members or only make it available in their directory, and can an admin lock a group-assigned plugin so members cannot switch it off?
• Is assigning a plugin to a group available on the Team plan, or only on Enterprise (the custom-roles and group-spend articles are marked Enterprise only)?
• What does the self-hosted Claude apps gateway require to deploy, and is group targeting for server-managed settings in the claude.ai console on Anthropic's published roadmap?

Related

• [[2026-07-07-claude-skill-count-degradation-skill-packs]] - parent brief; this closes its open follow-up 1
• [[2026-07-09-anthropic-plugin-ecosystem-vs-rdco-brigade-plugins]] - one plugin spans Cowork and Code; role-shaped first-party plugins
• [[2026-09-14-oi-skill-description-token-cost-audit]] - measured OI description cost; existing per-project enabledPlugins use
• [[2026-09-13-cortex-code-client-deployable-surface-p3-p4]] - P4 "Cowork sales org" deployment profile that this verdict feeds
• [[2026-06-30-anthropic-skill-guide-vs-brigade-comparison]] - Chapter 4 two-rail distribution reference
• [[2026-06-14-caf-restructure-organizing-brief]] - skills-in-plugin, tools-in-separate-MCP split
• [[2026-06-28-caf-8-phase-structure-and-skill-pipeline-mapping]] - phase cut lines for phase packs

Sources

• Vault: [[2026-07-07-claude-skill-count-degradation-skill-packs]]
• Vault: [[2026-07-09-anthropic-plugin-ecosystem-vs-rdco-brigade-plugins]]
• Vault: [[2026-09-14-oi-skill-description-token-cost-audit]]
• Vault: [[2026-09-13-cortex-code-client-deployable-surface-p3-p4]]
• Vault: [[2026-06-30-anthropic-skill-guide-vs-brigade-comparison]]
• Vault: [[2026-06-14-caf-restructure-organizing-brief]]
• Vault: [[2026-06-28-caf-8-phase-structure-and-skill-pipeline-mapping]]
• Web: Claude Help Center - Provision and manage skills for your organization (https://support.claude.com/en/articles/13119606-provision-and-manage-skills-for-your-organization)
• Web: Claude Help Center - Manage custom roles on Enterprise plans (https://support.claude.com/en/articles/13930452-manage-custom-roles-on-enterprise-plans)
• Web: Claude Code Docs - Deploy managed settings (https://code.claude.com/docs/en/managed-settings)
• Web: Claude Code Docs - Discover and install prebuilt plugins (https://code.claude.com/docs/en/discover-plugins) and Create and distribute a plugin marketplace (https://code.claude.com/docs/en/plugin-marketplaces), search excerpts only
• Web: Claude Platform Docs - Using Agent Skills with the API (https://platform.claude.com/docs/en/build-with-claude/skills-guide) and Skills API reference (https://platform.claude.com/docs/en/api/beta/skills), search excerpts only