/context-decay

name: context-decay
description: >
  Revalidate persistent agent knowledge by classifying why it can become stale
  and how quickly it changes, then retain, revise, externalize, or retire it.
  Use when reviewing skills, stored instructions, facts, preferences, assumptions, or
  workflows; when a decision or dependency changes; or when self-improvement
  captures, reviews, or promotes a learning. Works independently of self-improvement. Not for runtime
  context-window degradation, unsaved task observations, or age-based deletion.

Context Decay

Persistent context needs a theory of how it could stop being useful. **Decay type determines how to revalidate. Decay rate determines when.** Age alone proves neither that context is wrong nor that it should be removed. Truth and usefulness must be assessed separately.

Install

gh skill install pskoett/pskoett-skills context-decay

Fallback using the Agent Skills CLI:

npx skills add pskoett/pskoett-skills/skills/context-decay

Scope and activation

Work on the context the user selected, context affected by an observed change, or a learning being saved, reviewed, or promoted, including one-off entries. Do not inventory the whole repository on every turn or classify unsaved observations. For a broad audit, prioritize context whose staleness could affect the current work.

Standalone inputs can be authored or installed skills, instruction files, project facts, product priorities, research assumptions, user preferences, or workflow guidance. No learning log, memory service, hook, or scheduled process is required.

For skills, review both whole-skill applicability and individual instructions, references, scripts, and dependencies. They need not share one decay rate. Read [references/skill-review.md](references/skill-review.md) for the review and approval workflow; no source learning is required. Skill changes are proposals until the user explicitly approves the scoped changes. A general maintenance, learning, or repair request is not approval to rewrite a skill.

• `self-improvement` captures and promotes knowledge; this skill maintains its

validity and representation after selection for persistent use.

• `context-surfing` handles coherence and context-window degradation during a

session. It does not determine whether stored knowledge is still correct.

• An active runtime failure belongs to `self-healing`; do not replace its

diagnosis and verification workflow with a context audit.

1. Identify the claim and its authority

Read the exact claim, its scope, and any existing evidence or contract. Split mixed claims when their sources or invalidation triggers differ. A dated historical measurement remains a historical observation; it becomes misleading when reused as a current value.

Identify the authoritative source and the person or role accountable for it when known. Record unknown authority or ownership honestly; do not invent an owner or treat a copied instruction as independent proof of itself. Follow existing source precedence. If equally authoritative sources conflict, report the conflict rather than silently choosing the newest timestamp.

2. Classify cause and cadence

Choose the primary decay type; add another only when it changes the check.

| Type | What changes | How to revalidate | |------|--------------|-------------------| | `reality` | The underlying environment or facts | Read the authoritative source; retrieve live values when needed | | `decision` | A later decision supersedes an earlier one | Find an applicable superseding decision from the responsible authority | | `dependency` | A model, tool, API, schema, or platform changes | Compare the relevant version/configuration and check the claim against current behavior or documentation | | `relevance` | Context stays true but its value in the current scope changes | Check task applicability, usage evidence, recurrence, and cost of omitting it |

| Rate | Default timing | |------|----------------| | `fast` | Check at use; prefer retrieving a value to storing it | | `medium` | Set a source-appropriate review point or cadence; check earlier on a trigger | | `slow` | Check at relevant maintenance milestones or when affected work resumes | | `durable` | No passive expiry; reconsider on contradiction, explicit review, or an invalidating event |

Rates are qualitative planning judgments, not measured probabilities. Explain the basis briefly. Use an exact interval only when an actual source policy or operational need supports it. Do not assign universal half-lives.

Durable is a rate, not a fifth cause: a preference can be `decision` + `durable`. Events override cadence. A new ownership decision invalidates an old one immediately even if its periodic review is months away. Where change events cannot be observed reliably, use a source check at use or a review fallback.

Use the consequence of staleness to choose urgency and unavailable-source behavior. High-consequence actions need current evidence before relying on a questionable claim. Low-consequence, reversible work may proceed with an explicitly stated assumption. Neither frequency of use nor a durable label proves correctness. Lack of use alone does not justify removing a rare safeguard.

3. Check and choose an outcome

Perform the smallest check that can answer the claim. Record the evidence, scope/version checked, and actual check date. A file modification date, repeated quotation, or elapsed review interval is not validation.

For dependency-bound behavioral instructions, a changed model or tool is a reason to test the guidance, not proof it is obsolete. Use a representative check before removing a workaround. If a source or evaluation is unavailable, leave validation pending and name the missing evidence; never advance the last validated date or present a proposed change as verified.

| Outcome | Use when | Result | |---------|----------|--------| | **Retain** | Still supported