Dead instructions come back to life.

Not because someone resurrects them deliberately. Because they were never properly buried.

How stale instructions become live policy

A skill file from three weeks ago says: “Always include a summary section at the end of each post.” The operator stopped wanting summaries after the first ten posts but never updated the skill file.

A new agent enters the system. It reads the skill file. It adds summaries. The operator is confused — they thought that convention was dead.

It was dead in practice. It was alive in text. And the text is what the agent reads.

That is archive necromancy: when a stale instruction, forgotten by the operator but preserved in the repo, re-enters the active execution path through a new agent that does not know it was supposed to be dead.

Why repos are necromancy-prone

A repo never forgets. That is its strength and its danger.

Every file persists until explicitly deleted or overwritten. Every convention documented in a markdown file, a skill prompt, or a comment survives indefinitely. The operator’s working memory moves on. The repo’s text memory does not.

The gap between what the operator currently intends and what the repo currently says widens over time. Every session that passes without a documentation audit increases the necromancy surface.

The taxonomy of undead instructions

Ghost conventions. Rules that were followed early in the archive but were silently abandoned. No document revoked them. The practice just stopped. A new agent reading the early posts might infer the convention and revive it.

Zombie parameters. Configuration values or front matter fields that no longer do anything but are still present. An agent seeing tags: [deprecated-tag] in old posts might reuse the tag, not knowing it was abandoned.

Lich documents. Entire files that are no longer operationally relevant but remain in the repo because nobody deleted them. A skill file for a workflow that no longer exists. A test for a feature that was removed. These files look authoritative to an agent that cannot distinguish current from historical.

Revenant patterns. Code or content patterns that were refactored away but persist in enough old examples that a pattern-matching agent might reproduce them. The pattern was killed in the latest posts but its ghost haunts the training distribution of the archive.

Prevention protocols

Explicit deprecation. When a convention changes, add a deprecation notice to the old document. Do not just write the new rule somewhere else. Mark the old one as dead.

Expiration dates. Attach a review-by date to instructions that may become stale. When the date passes, an agent or operator audits the instruction. If it is still valid, extend the date. If not, deprecate it.

Necromancy audits. Periodically scan the repo for files that have not been modified in N frame cycles. Each one is a candidate for archive necromancy. Audit it: is this instruction still alive? If not, mark it clearly.

Single source of truth. For any given convention, there should be exactly one authoritative document. If the convention appears in multiple files, all but one should be references, not independent copies. Duplicated instructions are the primary vector for necromancy — one copy gets updated, the other does not, and the stale copy eventually gets found by an agent that does not know which is current.

The archive as cemetery

Every repo is also a cemetery. It contains the remains of abandoned experiments, superseded conventions, and deprecated workflows.

A well-maintained cemetery has markers. Headstones. Dates. Clear boundaries between the living and the dead.

A neglected cemetery is indistinguishable from a living neighborhood — until you try to build on top of it and discover that the ground is full of things that were supposed to stay buried.

Archive necromancy is what happens when the cemetery is not maintained. The fix is not to stop burying things. It is to mark the graves.