[FEATURE] Share skills with user groups, and auto-share to members added to the group later

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Sharing a skill requires selecting every recipient individually, one at a time, every single time — and the share is a frozen snapshot of who existed when you shared it.

I maintain a set of skills for my consulting team and update them almost daily. Every time I share one, I have to type and pick each user by hand. With a team of any size that's a tedious, error-prone ritual repeated per skill, and it scales as skills × people, not skills.

The worse half is what happens afterward. A share is a one-time event against a fixed list. When a new person joins the team, they get nothing. I have to remember every skill I've ever shared and re-share each one to them individually. There's no way to express "this group of people should have my skills" — only "these specific accounts got this specific skill at this specific moment."

Concretely, what goes wrong:

• Onboarding a teammate is a manual replay of my entire sharing history. Miss one and they silently lack a skill everyone else has. There's no view that tells me "person X is missing skills A, C, and F."
• No way to reason about coverage. I can't answer "does everyone on my team have the current set?" because there's no group to compare against — only per-skill recipient lists I'd have to inspect one by one.
• Every new skill restarts the whole ritual. Publish a new skill, re-select the same N people again from scratch.
• Leavers are the same problem inverted — no single place to revoke.

This is ordinary team-permissions modeling that most collaboration tools solved long ago: you grant to a group, membership changes flow through automatically, and access is derived rather than snapshotted.

Proposed Solution

Named user groups as a share target, with membership-derived access.

1. Create and manage groups. Let me define a named group (e.g. "Technical Consultants") containing a set of users, and reuse it. Groups live at the account/org level, not per skill.

2. Share to a group in one action. In the share dialog, pick the group instead of typing N names. One click replaces N selections, per skill.

3. Access is derived from membership, not snapshotted at share time. This is the important part. If I share a skill to a group and someone joins that group next month, they get the skill automatically, with no action from me. If someone leaves the group, access is revoked the same way. The share should be a standing grant to the group, not a one-time expansion into a list of individuals.

4. Coverage should be inspectable. Show, per group, which skills it has — and per skill, which groups and individuals it's shared with. That makes "is my team fully provisioned?" answerable at a glance instead of by auditing N recipient lists.

Nice-to-haves, not required for this to be useful:

• Org-wide groups managed by an admin, so a company can define "Consulting" once and have every skill owner share to it.
• Mapping to existing identity groups (e.g. an IdP/Entra group) so membership isn't maintained twice.
• Nested groups.

Minimum viable version: a personal, user-defined group — just a saved list of people I can pick in the share dialog — would remove most of the per-share tedium even without dynamic membership. But dynamic membership is what actually fixes onboarding, and is the part I'd prioritize.

Environment: Claude Code 2.1.219 (Claude Desktop), macOS 26.5.2. ~45 skills shared via the cloud Skills store.

Related: #69882 (org skills support in the CLI, stale), #57609 (API for reading org-wide skills, stale) — both about consuming org skills; this is about granting them.

Alternative Solutions

What I do today: select each recipient by hand, per skill, every time. For a new skill that's N selections; for a new teammate it's re-opening every skill I've ever shared and adding them one at a time.

Workarounds considered and rejected:

• Keeping my own people × skills list (a spreadsheet) to make onboarding reliable. This is a symptom, not a fix — the product already knows who I shared with; I'd be duplicating that externally and hand-syncing it forever.
• Sharing to everyone / making skills public to avoid per-user selection. Wrong trade: several of these encode internal procedures that shouldn't leave the team.
• Distributing out-of-band (shared drive, repo, passing a .skill file around) so recipients install themselves. Defeats the purpose of the sharing feature, pushes install work onto every recipient, and immediately creates a versioning problem — everyone lands on a different copy with no way to tell which.
• Org-wide skills (#69882, #57609). Wrong granularity: I want one team to get these skills, not the whole company to get everything. Both of those issues are also about consuming org skills rather than granting to a subset.

None of these close the actual gap: there is no way to name a set of people once and grant against it.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

Scenario: a consultant joins the team.

Today:

1. I maintain ~45 skills for my consulting practice — deploy procedures, code-review checklists, client-specific workflows. I share them with the team through the cloud Skills store.
2. A new consultant joins.
3. I now have to remember every skill I have ever shared and open each one's share dialog to add them, individually. There is no list of "skills I've shared" filtered by "people who don't have them."
4. I miss two. The new consultant doesn't know they're missing — a skill they've never seen simply doesn't exist to them. Weeks later they hand-roll a procedure we already have a skill for, and do it the old, wrong way.
5. Meanwhile I publish a new skill and re-select the same 8 people from scratch, by hand, again.

With groups:

1. I define a group once — "Technical Consultants" — and share each skill to that group rather than to 8 individuals. One selection per skill instead of eight.
2. The new consultant is added to the group.
3. They immediately have all 45 skills. I did nothing. There is nothing for me to forget.
4. Someone rolls off the team, comes out of the group, and loses access in one action rather than 45.

The onboarding case is the one that actually costs me. Per-share tedium is annoying, but a teammate silently missing a skill is a correctness problem — they do the work the wrong way and neither of us finds out until it shows up in a review.

Additional Context

_No response_