Sharing, Versioning and Maintaining Skills

Skills are code, so maintain them

Once several people rely on a skill, it needs normal engineering care. Keep project skills in git and review changes in pull requests (a skill change alters how Claude behaves for the whole team). Give each skill an owner, note changes in a short changelog or the commit history, and record a version if you distribute it. When procedures change (a new deploy tool, a renamed script), update the skill in the same PR as the change, otherwise it silently rots and Claude follows outdated steps. Review skills periodically: delete unused ones, merge overlapping ones, and check descriptions still match how people ask. Treat skills from outside your team like third-party dependencies: read them before installing (see the security section).

Name an owner

Every shared skill should have a person who answers for it and reviews changes.

Quick check: Why update a skill in the same PR as the procedure it describes?

• It makes the model faster
• Skills must be edited only once a year
• PRs cannot contain Markdown
• Otherwise the skill silently becomes outdated and Claude follows stale steps