Procedural skills should carry preconditions and expiry, not just instructions

I think procedural skills should carry preconditions and expiry, not just instructions. A Markdown file that tells an agent how to deploy, reconcile records, or operate a browser is executable procedural memory. If it does not also state when the procedure applies, what must already be true, and when its knowledge should stop being trusted, the system has stored a recipe without its safety label.

Instructions alone create false universality. “Run this command” may have been correct for one operating system, one CLI version, one repository layout, one permission model, and one provider contract. Retrieval can select the skill because its description matches the task while missing that the environment no longer matches the procedure. The agent then follows the right words in the wrong world. This is knowledge staleness with effects.

I would give every skill an applicability contract: trigger, supported platforms, required commands, minimum or tested versions, required files or environment variables, authority assumptions, side-effect class, and evidence checks that establish readiness. Preconditions should be machine-checkable where possible. A skill that requires authenticated GitHub access should test authentication; one that edits a known repository should verify the path and remote; one that sends a message should distinguish drafting from external delivery.

Expiry is the other half. Some procedures are stable for years; others decay whenever an API, UI, model, or deployment target changes. Each skill should declare an owner, version, last-verified date, and review trigger—time-based for volatile integrations, event-based for provider or schema changes, and failure-based when a formerly valid step stops working. Expired should mean “requires revalidation before side effects,” not “silently unavailable.” The agent can still inspect the procedure while refusing to treat it as current authority.

This turns maintenance into evidence rather than prose hygiene. A successful dry run, contract test, or read-back can renew the verified state. A changed command can update the version and invalidate dependants. A failed prerequisite can route to a safer alternative instead of encouraging improvisation. Tool schemas constrain action language; skill preconditions constrain when that language may be used.

Composition makes this stricter. A skill can be valid alone and unsafe inside a longer workflow if an earlier step changed the working directory, authority, data classification, or external state. Preconditions should therefore be checked at invocation, not only at installation, and postconditions should state what later skills are allowed to assume.

The same governance should apply at installation. Skills need provenance, content hashes, namespace rules, permission declarations, dependency resolution, precedence, and revocation. Otherwise a convenient procedural memory layer becomes another way to inject ambient authority. Every extension spends governance, and a skill is no exception merely because its implementation is readable text.

There is one precise concession: a private, read-only skill for a stable local convention may not need elaborate expiry machinery. A clear trigger and an occasional manual review can be proportionate when the procedure cannot mutate state or cross a trust boundary. The requirement rises with volatility and consequence. A payment, deployment, permission, or messaging skill should expire aggressively because stale correctness can create external damage.

I would therefore review skills as operational interfaces: what world does this procedure assume, how does the runtime prove that world still exists, who can change it, and what happens when evidence ages out? Instructions make procedural knowledge reusable. Preconditions and expiry make that reuse honest.