1. Another Skill owns the same decision
Overlap is the most common reason to remove a Skill. If two packages both plan the change, review the diff, or drive the same browser flow, the team must reconcile two outputs and two permission boundaries.
Keep the narrower, better evidenced candidate. Record the capability lost by removal; if no one can name one, the second Skill was not earning its place.
2. The source can no longer be reconstructed
Remove or quarantine a Skill when its repository disappears, the install path no longer maps to the reviewed source, referenced scripts change without review, or the pinned revision cannot be reproduced.
A moved repository HEAD alone is only a review signal. The decisive question is whether the indexed Skill files or linked assets materially changed.
3. It requests access the workflow does not use
A report-only task should not need publishing, deployment, messaging, deletion, or broad credential access. If the first representative run does not use a permission, remove that permission or replace the Skill with a narrower option.
Project scope is also part of the access boundary. Remove a personal installation when only one repository needs the workflow.
4. Nobody reviews or acts on the output
A Skill that produces reports, findings, screenshots, plans, or summaries without a named reviewer adds activity rather than evidence. If the output is repeatedly ignored, shorten the workflow or remove it.
Automation is justified when the artifact changes a decision, catches a known risk, or preserves reproducible evidence. Volume alone is not value.
5. It fails the same controlled task twice
Repeated failure on the same small, representative task is stronger evidence than a broad compatibility label. Remove or quarantine the Skill when it needs unexplained permission growth, writes outside scope, calls an unlisted service, or produces an artifact that cannot pass the acceptance check.
Keep the failure record, source revision, environment, and rollback result. Removal is not a claim that the Skill fails everywhere; it is a decision that the current stack cannot justify it.
- The exact failure is reproducible.
- The source revision and Agent environment are recorded.
- No simpler permission or configuration fix explains the result.
- Rollback restores the previous state.
- A replacement has a distinct acceptance test rather than the same marketing promise.
A monthly ten-minute cleanup
List every installed Skill, its scope, source, last use, permissions, output owner, and last successful controlled test. Remove obvious overlap, quarantine unclear sources, and retest only the workflows that still matter.
A smaller stack improves discoverability and permission clarity. The goal is not five forever; it is the fewest Skills that still cover the work you can observe and review.