AI Guides › Skills & Agents
Skills That Should Come With An Expiry Date
By Nigel Guy · 3 min read
Most advice about maintaining a skill library assumes the risk is decay —
something that used to work slowly stops working. There's a different
category that's more dangerous precisely because it doesn't decay: a skill
built for a specific season, event, or tool version that keeps running
perfectly well, producing confidently correct-looking output for a
situation that no longer applies.
The rule: some skills are only ever going to be correct for a bounded
window — tag them with an expiry condition when you build them, because a
skill that still runs cleanly isn't the same claim as a skill that's still
relevant.
The mechanism
Three categories of skill genuinely need an expiry tag, not just the
general audit every skill deserves:
- Seasonal — built for a recurring window (tax season, a holiday
campaign, an annual event) where the assumptions baked in are only true
during that window. These are the easiest to spot and the easiest to
forget, because they go quiet for months and reappear looking untouched.
- Event-based — built around a single occasion (a launch, a
conference, a one-off campaign) that has a hard end date. These should
arguably expire completely, not just pause.
- Tool-tied — built against a specific version, endpoint, or one-off
integration that you know, even at build time, won't be the current
state of that tool indefinitely.
For each:
- Decide the category at build time, not later. Most skills don't need
an expiry tag at all — only flag the ones that genuinely fall into one
of these three.
- Write the expiry condition into the skill file itself. "Only valid
for the 2026 filing year," "built against the v2 API, check before
reusing after a major version bump" — in the document, not just in your
head, where it won't survive you forgetting.
- Set an actual check-in date or trigger, not a vague intention to
revisit it. A seasonal skill gets a calendar reminder for the next time
its season comes round; a tool-tied one gets tied to that tool's
changelog if one exists.
- Archive rather than wait to notice. The failure mode here isn't the
skill breaking loudly — it's the skill running fine and producing
confidently wrong output for a situation it was never built for.
- Treat "still works" and "still relevant" as separate questions. A
campaign skill from last year will happily generate content in last
year's voice for this year's campaign unless something stops it.
What to skip
Skip tagging every skill in your library with an expiry condition "just in
case" — most skills are durable by design and the tagging adds noise nobody
reads. And skip assuming a seasonal or event-based skill is self-evidently
expired just because the season's passed; nothing stops it from running
again next year on stale assumptions unless you've actually archived or
gated it.
Guardrails
- This overlaps with the general quarterly-audit habit described elsewhere
in this library, but it isn't a substitute for it — expiry tags catch a
narrower, sharper failure mode than the general rot a routine audit is
built to catch.
- An expiry condition you write once and never enforce is exactly as
useless as no expiry condition — the enforcement step is the point, not
the label.
- Whether something counts as "seasonal" or "durable" is a judgement call
you're making at build time with incomplete information; if you're
unsure which it is, err towards tagging it and removing the tag later if
it turns out to be durable, rather than the reverse.
All 751 AI guides · JulieMango plans from £17/mo