Retiring or renaming a bundled skill does not remove it from machines that already installed it

[bgmcmullen]

Attach installs bundled skills into a client's skill_dir, but nothing removes a skill that later stops shipping. The installed copy keeps advertising itself, so a machine can present a retired skill, or two skills that cover the same job, indefinitely.

This is already happening

hypaware-sensitive-scan was retired by LLP 0142 on 2026-07-29 and removed from the workspace. As of 2026-08-06 it is still installed at ~/.claude/skills/hypaware-sensitive-scan on a dev machine and still model-invocable, still contradicting hypaware-privacy about whether recorded rows can be purged, which is the exact disagreement 0142 existed to settle. Retirement removed the source but not the surface.

Why it becomes urgent now

LLP 0197 T12 merges ten bundled skills into six. Five skill directories stop shipping:

• hypaware-ai-usage-report, hypaware-report-to-html, hypaware-publish-report, hypaware-apply-report-changes (now stages inside hypaware-report)
• hypaware-graph from the claude and codex trees (it is owned by @hypaware/context-graph, and those were duplicates)

On a machine that already has them, an upgrade adds hypaware-report without removing the four it replaces. The user then has two skills offering to render reports, two offering to publish, and the old ones still describe build.sh, which no longer exists. That is worse sprawl than before the merge, and the merge was motivated by sprawl.

What is needed

A removal path on the attach/reconfigure route, so a bundled skill that no longer ships is taken off the machine (or clearly tombstoned) rather than left behind. Points to check:

• contributes.client.skill_dir in the plugin manifests (.claude/skills, .codex/skills)
• the attach/reconfigure flow that writes skills today (LLP 0102, LLP 0107)
• it must only remove skills HypAware installed, never a user-authored skill that happens to sit in the same directory. Some marker or manifest of what we put there is likely required, since "not in the current bundle" is not sufficient evidence of ownership.

Worth deciding explicitly: silent removal versus reporting what was removed in hyp status. Deleting files a user can see, without saying so, is its own surprise.

Scope note

Deliberately not in the LLP 0197 T12 PR, which merges the skills but leaves stale installs alone. This is LLP 0197 T13.