[FEATURE] Let recipients propose edits to a shared skill, with owner approval and automatic republish

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

Shared skills are single-owner and read-only for everyone else, so the person who finds a problem is never the person allowed to fix it.

I maintain and share a large set of skills with my team. People hit issues in them constantly — a path that changed, a step that's now wrong, a missing edge case. The only remedy today is to contact me out-of-band, describe the problem in chat, and wait for me to edit and republish.

In practice that loop mostly doesn't happen. The person hits the bug, works around it locally, moves on, and the shared skill stays wrong for everyone else. The next person hits the same wall and does the same thing.

What this costs:

• The best-placed fixer is locked out. They just debugged it. They know the one-line change. They can't make it.
• Every skill has a single bottleneck. I'm a hard dependency for every correction to anything I've shared, including trivial typo fixes, and including while I'm on leave.
• Knowledge silently fails to propagate. A colleague's local workaround never reaches the shared copy. The team accumulates private divergence nobody can see.
• Reports are lossy. Even when someone does tell me, I'm reconstructing intent from a chat message instead of reading a diff. I frequently fix the wrong thing or miss the real cause.
• Forking is the only escape, and it's worse. Someone copies the skill, edits their copy, and now the team is on divergent versions with no way to tell which is current or what changed.

This is a collaboration model problem: skills are treated as personal artifacts that happen to be readable by others, when in a team they're shared infrastructure that many people maintain.

Proposed Solution

A propose → review → publish loop for shared skills. Pull requests for skills.

1. A recipient can edit a shared skill and submit the change back, rather than only consuming it. From their side it's "I fixed this, here it is" — not a chat message asking someone else to do it.
2. The owner receives it as a reviewable diff, with the proposer's identity and an optional note explaining why.
3. The owner approves, amends, or rejects. Approval is the gate — the owner stays in control of what ships under their name.
4. On approval the new version publishes automatically to everyone the skill is already shared with. No manual re-share, no drift between who has which version.
5. Version history with attribution, and the ability to roll back a bad change.

Worth having, not required for v1:

• Co-maintainers — designate specific people who can publish directly without the approval step, for skills where a team genuinely co-owns the artifact.
• Update notifications to recipients when a skill they use changes, with the diff.
• Comments on a proposal so the owner can ask "why this way?" without leaving the tool.

Minimum viable version: just "submit a proposed edit that reaches the owner as a diff" fixes most of the pain. Today there is no path at all from recipient back to owner inside the product — everything routes through chat. Even without auto-republish, closing that loop would change the behavior from "work around it silently" to "send the fix."

Why the approval gate matters: I'm not asking for a free-for-all wiki. These skills encode procedures that have to be right, and I'm accountable for them. The owner approving is what makes it safe to let anyone propose.

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

Related: filed alongside #82719 (share skills to user groups). Both come from the same root — skill sharing models a single author broadcasting to passive recipients, rather than a team maintaining shared artifacts.

Alternative Solutions

What we do today: message the owner. Someone hits a problem, tells me in chat, I context-switch, reconstruct what they meant, edit, republish. High friction on both sides, lossy in translation, and it depends on the person bothering to report at all — which, being honest, is the exception rather than the rule.

Recipient edits their local copy. Fixes exactly one person. The change is invisible to everyone else, and it's either silently lost on the next update from me or — worse — it isn't, and that person is now on a permanent private fork nobody knows about.

Keep the skills in a git repo and distribute manually instead. This is the workaround that technically gives us real review, and I've considered it seriously. It means abandoning the sharing feature entirely: every recipient has to clone, install, and re-install on every change, and there's no link between what's in the repo and what people actually have loaded. We'd be rebuilding distribution by hand to get collaboration, and lose the thing sharing was for.

Ask everyone to file issues with me in a tracker. Same bottleneck, plus a tool nobody wants to open for a one-line fix. It also doesn't help the lossy-translation problem — an issue description still isn't a diff.

Make skills public / share more widely so others can copy and re-share their own version. Actively harmful — it multiplies versions instead of converging them, and several of these encode internal procedures anyway.

Every one of these is a way to route around the fact that there's no path from recipient back to owner inside the product.

Priority

High - Significant impact on productivity

Feature Category

Other

Use Case Example

Scenario: a deploy step goes stale and a colleague already knows the fix.

Today:

1. I own a deploy skill shared with the team. It documents the exact upload sequence for our dev server.
2. The server path changes. The skill is now wrong.
3. A colleague runs it, it fails, and they spend twenty minutes working out that one line needs updating. They now know the fix precisely.
4. They cannot apply it. The skill is mine.
5. Realistically, they patch their local copy or just remember to do that step manually, and say nothing. The shared skill stays broken.
6. Two weeks later a third person hits the identical failure and burns the same twenty minutes.
7. Eventually someone mentions it to me in passing. I fix it from a verbal description, guess wrong about which path, and publish a fix that's still subtly incorrect.

With this feature:

1. Same failure. Same twenty minutes of debugging — once.
2. That colleague edits the skill and submits it back with a note: "path moved, see line 40."
3. I get a diff. I can see exactly what changed and why, and approve it in about ten seconds — I don't have to reconstruct anything.
4. On approval it republishes to everyone. The third person never hits the bug.

The multiplier is what matters. Right now every stale step in a shared skill gets rediscovered by every person independently, and the fix reaches nobody. The knowledge exists in the team immediately; there's just no channel for it to travel back along.

Additional Context

_No response_