/anti-entropy-governance

name: anti-entropy-governance
description: "Use when touching retiring old logic, collapsing duplicate owners, removing fallbacks, or schema/persistence/source-of-truth boundaries; identify opportunities automatically; destructive execution requires explicit confirmation."

Anti-Entropy

Overview

Use this skill when the task is not merely "change code" but "remove old paths safely without growing entropy".

This skill chooses between:

• `delete-first` for internal code retirement
• `compat-exception` for proven external dependency boundaries
• `confirmation-first` for irreversible state or an external contract whose

distributed consumers cannot be observed

It does not replace `brainstorming`, `writing-plans`, `systematic-debugging`, or `verification-before-completion`. It is a narrow governance owner for retirement, fallback collapse, duplicate-owner cleanup, and deletion safety.

When to Use

Use when any of these are true:

• old logic, duplicate owners, or stale fallbacks should be retired
• a candidate fix is "delete old path" vs "add another fallback"
• internal keyword / phrase / trigger logic is being replaced by structured logic
• a new canonical owner exists and the old owner may still carry real behavior
• a cleanup, migration, or deprecation task touches schema, persistence,

source-of-truth, or external compatibility boundaries

• the task risks confusing code retirement with live data deletion

Do not use for:

• pure additive feature work with no retirement decision
• tiny wording edits
• simple status or read-only Q&A
• normal bug fixes that do not involve owner collapse, fallback cleanup, or

deletion choice

Auto-Compose Boundary

This skill should be composed by other owners. It should not become a new global hot-path entry.

Prefer composition from:

• `brainstorming` for approach selection involving retirement or persistence risk
• `writing-plans` for plans that delete old paths or touch schema / migration /

persistence

• `systematic-debugging` when the tempting fix is fallback growth or

delete-vs-retain

• `verification-before-completion` for cleanup / retirement / compatibility /

migration closeout

Load automatically when the task touches owner collapse, fallback removal, or schema/persistence/source-of-truth boundaries. Automatic loading identifies and advises only; destructive execution still requires explicit scoped user confirmation.

Core Principle

Default to reducing internal entropy, not preserving internal history.

Retirement is responsibility-scoped before it is carrier-scoped. Name the obsolete or duplicated authority first. If the same carrier has a separately evidenced legitimate role, remove the invalid responsibility and keep only that role-scoped capability; this is not a compatibility exception. Apply `delete-first` to the carrier once no legitimate responsibility remains. Unknown consumers alone still do not justify retaining an internal carrier.

Use this rule:

• internal code retirement -> `delete-first`
• external compatibility boundary -> `compat-exception` with active dependency

evidence; `confirmation-first` when distribution is proven but consumers cannot be observed

• persistent-state or irreversible source-of-truth object ->

`confirmation-first`

Unknown alone neither proves an external dependency nor blocks internal `delete-first`. Once distribution is proven, unobservable consumers also do not prove deletion safe: inspect read-only. Before editing, require user-authored, scoped authorization that explicitly accepts the concrete external risk. An informed instruction may already supply it; otherwise disclose the risk and request scoped confirmation.

Mentioning, loading, or discussing destructive-action rules never authorizes destructive execution. Without explicit scoped user confirmation:

• no irreversible deletion is executed
• no destructive tool call is made
• no runnable destructive command is emitted as the next action
• no broad assent is reinterpreted as deletion approval

Deletion Classes

Classify the deletion target first:

• `code-retirement`
• source code
• internal triggers
• duplicate owners
• stale fallback branches
• compat-only carriers
• dead tests/config tied to removed internal behavior

• `contract-carrying code`
• schema definition files
• migration files
• public API contract code
• host install/discovery code
• persistence read/write logic

• `live-state mutation surface`
• code or commands that would mutate live databases, object stores, queues,

or other persistent state

• `derived-state`
• rebuildable caches
• generated indexes
• temporary exports
• recomputable artifacts

• `persistent-state`
• live database tables / columns / rows
• source-of-truth object storage files
• user records
• permission / identity / membership records
• audit / billing / irreversible business records
• non-rebuildable queue or event contents

Default Path By Class

• `code-retirement` -> `delete-first`
• `contract-carrying code` -> classify by the Core Principle; internal-only

retirement uses `delete-first` with high-risk verification

• `live-state mutation surface` -> inspect and classify; destructive execution

still requires confirmation when it reaches persistent-state

• `derived-state` -> verify rebuildability first, then decide
• `persistent-state` -> `confirmation-first`

Hard Stops

If the target is `persistent-state` or another irreversible source-of-truth object:

• do not execute deletion automatically
• do not emit a runnable destructive command as the next action
• do not call a destructive tool
• do not interpret generic agreement as confirmation
• ask for explicit scoped user confirmation
• request backup / rollback / migration note when relevant

Examples that require confirmation:

• `DROP TABLE`
• `DROP COLUMN`
• `TRUNCATE`
• bulk delete of real business data
• deleting source-of-truth uploaded files
• deleting p