Keeping skills current across a team
A skill is only useful while it still describes how the work is actually done. The failure mode is not a broken skill; it is a confidently wrong one.
How skills go stale
Skills do not rot loudly. They keep producing confident output that matches last quarter's process.
Three things go wrong, and all three are invisible from inside a session:
- Copies diverge. A skill pasted into three repositories becomes three skills, and the one you fix is not the one your colleague is running.
- The process changes and the skill does not. Nothing fails; the agent simply follows the old checklist.
- Nobody knows which version is live. Without a record of what was published, "is this current?" has no answer.
One source of truth
The first fix is structural: keep one copy. Skills live in the library, and the plugin mirrors them into whichever agent you work in, so editing a skill once updates every destination and no destination is authoritative.
Read-only by default
That inverts the usual problem. Instead of asking which copy is current, there is one copy, and the question becomes whether your agent has synced it yet, which the plugin can answer.
Review before publish
The second fix is a decision about who may change a shared skill. Two modes, set per install:
| Mode | What happens on a change | Suits |
|---|---|---|
require-review | The change opens a review. A named reviewer approves before it reaches anyone else. | Shared libraries, and anything a customer-facing agent relies on. |
auto-publish | The change publishes immediately. | A library only you use, or early drafting where review is friction. |
require-review is the default, deliberately: the cost of a bad skill reaching the whole team is higher than the cost of one approval.
Versioned releases
Every publish creates a release: a snapshot of every file in the skill at that moment. Three properties make it useful:
- Versions only ever increase. v1, v2, v3, never reset and never recycled, so a version number identifies exactly one snapshot forever.
- The whole skill is captured, not just SKILL.md. References and scripts are part of the release.
- You can go back. A regression is answerable with a previous release rather than with everyone's memory of what changed.
Checking from the agent
Most staleness questions are answerable from inside the session, without opening the app:
| What you want to know | Command |
|---|---|
| Which skills do I have, and are they current? | /contexory:status |
| Pull the latest now. | /contexory:sync |
| Am I connected, and can the agent see my skills? | /contexory:test |
| Change whether changes need review. | /contexory:mode require-review |
The commands shown are Claude Code's; OpenClaw exposes the same operations through its own CLI. Both are covered in the plugin guides.
Habits that hold up
Structure handles the mechanics. Three habits handle the rest:
- Give every skill an owner. The
metadatafrontmatter field is a good home for it. A skill nobody owns is a skill nobody updates. - Update the skill in the same change as the process. When the checklist changes, the skill is part of that work, not a follow-up nobody schedules.
- Delete skills that no longer apply. An obsolete skill is worse than a missing one, because the agent will still use it.
Test the trigger, not just the text