# 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.

Source: <https://www.contexory.com/docs/reference/keeping-skills-current>

## 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**
>
> Sync pulls skills into your agent and writes nothing back until you explicitly enable the management tools. Installing the plugin cannot change your library.

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](/docs/claude-code).

## Habits that hold up

Structure handles the mechanics. Three habits handle the rest:

- **Give every skill an owner.** The `metadata` frontmatter 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**
>
> A skill can read perfectly and still never fire, because the agent matches on the description. Triggering is not something the plugin commands check. After editing a skill, open it in Contexory and use **Test triggers** to run a candidate prompt against it, then save the result as a regression case. A correct skill that never activates is indistinguishable from one you never wrote.