| name | skill-maintenance |
| description | Audit, clean, upgrade, and repackage your own skills on an ongoing basis. Use whenever the user says "look at my skills", "audit my skills", "are any of my skills stale / bloated / redundant", "upgrade a skill", "clean up a skill", "repackage this skill", "should I retire any skills", or wants to wire skills together. Encodes the packaging contract, the patch protocol, and the failure modes that silently corrupt a skill library. SKIP for building a brand-new skill from scratch (use skill-creator) and for memory-vault work (use project-memory). This skill audits and repackages skills that already exist.
|
Skill maintenance
A standing playbook for keeping a skill library healthy. The point is to never re-derive
the traps or re-hunt for where things live.
Read craft/skill-authoring.md alongside this — that
covers how to write a skill; this covers how to maintain a set of them.
First: know which runtime you are in
Skills that make claims about one runtime — a sandbox, a mount, a host-only tool — without
naming the other case will actively mislead an agent running elsewhere. An agent that
follows sandbox rules on a real host wastes effort staging work it could do directly.
Establish where you are before touching files, and when writing a skill that has runtime
constraints, say which runtime each rule belongs to. scripts/check_scoped.py is the
automated version of this check.
Never edit an installed skill
Installed skills are typically a read-only or app-managed cache. Editing them does
nothing, or worse, appears to work and is silently reverted later.
The loop that actually sticks:
- Edit the skill's source files.
- Package the directory as a
.skill — a zip whose top folder is the skill name and
contains .
