[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JVP399AM149GKA4G8MZ3G4":3,"skill-same:01M6JVP399AM149GKA4G8MZ3G4":61},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":32,"linkOnly":33,"markdownContent":34,"markdownBody":35,"frontMatter":36,"refName":37,"commitSha":38,"skillDirectory":39,"forksCount":40,"repositoryHtmlUrl":41,"repositoryHomepageUrl":42,"ownerHtmlUrl":43,"ownerBlogUrl":44,"ownerDescription":45,"updatedAt":46,"install":47,"resources":60},"01M6JVP399AM149GKA4G8MZ3G4","anti-entropy-governance",null,"Use when touching retiring old logic, collapsing duplicate owners, removing fallbacks, or schema\u002Fpersistence\u002Fsource-of-truth boundaries; identify opportunities automatically; destructive execution requires explicit confirmation.","hashgraph-online\u002Fawesome-codex-plugins","hashgraph-online","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160371962?v=4","01M6CNB6NRJVNNGN14TR01Q6D3","HOL (Hashgraph Online)","01M6JT1HSKKG9V68KQAQGBA7XP",1575,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FGanyuanRan\u002FAegis\u002Fskills\u002Fanti-entropy-governance\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31],"governance","entropy","anti entropy governance","persistence","execution","owners","confirmation","use","schema","logic","duplicate","source","when","2026-11-10 10:12:30",false,"---\nname: anti-entropy-governance\ndescription: \"Use when touching retiring old logic, collapsing duplicate owners, removing fallbacks, or schema\u002Fpersistence\u002Fsource-of-truth boundaries; identify opportunities automatically; destructive execution requires explicit confirmation.\"\n---\n\n# Anti-Entropy\n\n## Overview\n\nUse this skill when the task is not merely \"change code\" but \"remove old paths\nsafely without growing entropy\".\n\nThis skill chooses between:\n\n- `delete-first` for internal code retirement\n- `compat-exception` for proven external dependency boundaries\n- `confirmation-first` for irreversible state or an external contract whose\n  distributed consumers cannot be observed\n\nIt does not replace `brainstorming`, `writing-plans`,\n`systematic-debugging`, or `verification-before-completion`. It is a narrow\ngovernance owner for retirement, fallback collapse, duplicate-owner cleanup,\nand deletion safety.\n\n## When to Use\n\nUse when any of these are true:\n\n- old logic, duplicate owners, or stale fallbacks should be retired\n- a candidate fix is \"delete old path\" vs \"add another fallback\"\n- internal keyword \u002F phrase \u002F trigger logic is being replaced by structured logic\n- a new canonical owner exists and the old owner may still carry real behavior\n- a cleanup, migration, or deprecation task touches schema, persistence,\n  source-of-truth, or external compatibility boundaries\n- the task risks confusing code retirement with live data deletion\n\nDo not use for:\n\n- pure additive feature work with no retirement decision\n- tiny wording edits\n- simple status or read-only Q&A\n- normal bug fixes that do not involve owner collapse, fallback cleanup, or\n  deletion choice\n\n## Auto-Compose Boundary\n\nThis skill should be composed by other owners. It should not become a new\nglobal hot-path entry.\n\nPrefer composition from:\n\n- `brainstorming` for approach selection involving retirement or persistence risk\n- `writing-plans` for plans that delete old paths or touch schema \u002F migration \u002F\n  persistence\n- `systematic-debugging` when the tempting fix is fallback growth or\n  delete-vs-retain\n- `verification-before-completion` for cleanup \u002F retirement \u002F compatibility \u002F\n  migration closeout\n\nLoad automatically when the task touches owner collapse, fallback removal, or schema\u002Fpersistence\u002Fsource-of-truth boundaries. Automatic loading identifies and advises only; destructive execution still requires explicit scoped user confirmation.\n\n## Core Principle\n\nDefault to reducing internal entropy, not preserving internal history.\n\nRetirement is responsibility-scoped before it is carrier-scoped. Name the\nobsolete or duplicated authority first. If the same carrier has a separately\nevidenced legitimate role, remove the invalid responsibility and keep only\nthat role-scoped capability; this is not a compatibility exception. Apply\n`delete-first` to the carrier once no legitimate responsibility remains.\nUnknown consumers alone still do not justify retaining an internal carrier.\n\nUse this rule:\n\n- internal code retirement -> `delete-first`\n- external compatibility boundary -> `compat-exception` with active dependency\n  evidence; `confirmation-first` when distribution is proven but consumers\n  cannot be observed\n- persistent-state or irreversible source-of-truth object ->\n  `confirmation-first`\n\nUnknown alone neither proves an external dependency nor blocks internal\n`delete-first`. Once distribution is proven, unobservable consumers also do not\nprove deletion safe: inspect read-only. Before editing, require user-authored,\nscoped authorization that explicitly accepts the concrete external risk.\nAn informed instruction may already supply it; otherwise disclose the risk\nand request scoped confirmation.\n\nMentioning, loading, or discussing destructive-action rules never authorizes\ndestructive execution. Without explicit scoped user confirmation:\n\n- no irreversible deletion is executed\n- no destructive tool call is made\n- no runnable destructive command is emitted as the next action\n- no broad assent is reinterpreted as deletion approval\n\n## Deletion Classes\n\nClassify the deletion target first:\n\n- `code-retirement`\n  - source code\n  - internal triggers\n  - duplicate owners\n  - stale fallback branches\n  - compat-only carriers\n  - dead tests\u002Fconfig tied to removed internal behavior\n\n- `contract-carrying code`\n  - schema definition files\n  - migration files\n  - public API contract code\n  - host install\u002Fdiscovery code\n  - persistence read\u002Fwrite logic\n\n- `live-state mutation surface`\n  - code or commands that would mutate live databases, object stores, queues,\n    or other persistent state\n\n- `derived-state`\n  - rebuildable caches\n  - generated indexes\n  - temporary exports\n  - recomputable artifacts\n\n- `persistent-state`\n  - live database tables \u002F columns \u002F rows\n  - source-of-truth object storage files\n  - user records\n  - permission \u002F identity \u002F membership records\n  - audit \u002F billing \u002F irreversible business records\n  - non-rebuildable queue or event contents\n\n## Default Path By Class\n\n- `code-retirement` -> `delete-first`\n- `contract-carrying code` -> classify by the Core Principle; internal-only\n  retirement uses `delete-first` with high-risk verification\n- `live-state mutation surface` -> inspect and classify; destructive execution\n  still requires confirmation when it reaches persistent-state\n- `derived-state` -> verify rebuildability first, then decide\n- `persistent-state` -> `confirmation-first`\n\n## Hard Stops\n\nIf the target is `persistent-state` or another irreversible source-of-truth\nobject:\n\n- do not execute deletion automatically\n- do not emit a runnable destructive command as the next action\n- do not call a destructive tool\n- do not interpret generic agreement as confirmation\n- ask for explicit scoped user confirmation\n- request backup \u002F rollback \u002F migration note when relevant\n\nExamples that require confirmation:\n\n- `DROP TABLE`\n- `DROP COLUMN`\n- `TRUNCATE`\n- bulk delete of real business data\n- deleting source-of-truth uploaded files\n- deleting permission, identity, audit, billing, or membership records\n- purging non-rebuildable queues or event streams\n\n## Data Destruction Guard\n\nWhen `confirmation-first` protects persistent-state or an irreversible\nsource-of-truth object, stop normal retirement flow and emit:\n\n```text\nData Destruction Guard:\n- Target Class:\n- Exact Target(s):\n- Environment:\n- Why Irreversible:\n- Backup \u002F Rollback Note:\n- Allowed Read-Only Next Steps:\n- Blocked Destructive Steps:\n- Confirmation Required: yes\n- Status: awaiting scoped confirmation\n```\n\nOnly explicit scoped confirmation can continue. Broad assent such as \"OK\",\n\"continue\", or \"sounds good\" is insufficient. If scope changes at all, previous\nconfirmation is invalid and fresh confirmation is required.\n\n## Anti-Entropy Declaration\n\nBefore deletion, state:\n\n```text\nAnti-Entropy Declaration:\n- Deletion Class:\n- Old Path\u002FObject:\n- Invalid Responsibility \u002F Authority:\n- Legitimate Capability Remaining on Carrier:\n- New Canonical Owner:\n- Expected Preserved Behavior:\n- Expected Retired Behavior:\n- External Boundary Touched: no | yes\n- Source-of-Truth Data Risk: none | possible | confirmed\n- User Confirmation Required: no | yes\n```\n\nFor external-unknown code, fill `User Confirmation Required` with `yes` unless\nthe user's own instruction already names the concrete external risk, accepts\nits possible breakage, and authorizes the exact retirement scope, or the user\nlater gives scoped confirmation after your disclosure. A generic original\ndeletion request does not satisfy this slot. Do not infer acceptance from mere\nawareness of external use or from your own risk summary.\n\nIf `User Confirmation Required: yes`, stop normal delete-first flow.\nPersistent-state or irreversible targets enter `Data Destruction Guard`;\nexternal-unknown code stays in the `Retirement Decision` hold below.\n\n## Retirement Decision\n\nChoose one path only:\n\n```text\nRetirement Decision:\n- Path: delete-first | compat-exception | confirmation-first\n- Why:\n- Non-edits:\n```\n\nRules:\n\n- choose `delete-first` for internal retirement unless a stronger boundary blocks it\n- choose `compat-exception` only when external dependency is proven\n- choose `confirmation-first` for irreversible targets or proven distribution\n  whose consumers cannot be observed\n\nIf `Path = confirmation-first`, no destructive execution may happen until\nscoped confirmation is established. For external-unknown code, earlier generic\ndeletion instructions do not count. An informed, scoped user instruction may\nestablish confirmation before your disclosure; otherwise disclose the risk\nand directly ask the user to confirm the exact retirement scope before editing.\nDo not only state that confirmation is required or quote the words needed.\n\n## Verification Plan\n\nDo not verify only by \"tests are green\". Verify that the old logic actually\ndied and the new owner actually carries the behavior.\n\n```text\nVerification Plan:\n- Main-path check:\n- Lingering-reference check:\n- Negative check:\n- Boundary check:\n```\n\nMeaning:\n\n- `Main-path check`: new canonical owner still satisfies intended behavior\n- `Lingering-reference check`: the retired responsibility is no longer active;\n  when its carrier was deleted, the old path is no longer referenced on the\n  main path\n- `Negative check`: retired trigger\u002Fpath really stopped working\n- `Boundary check`: host\u002FAPI\u002Fschema\u002Fpersistence boundary was not accidentally broken\n\n## Gap Taxonomy\n\nIf a gap appears after deletion, classify it before repairing:\n\n- `expected-retirement`\n- `missing-owner-logic`\n- `stale-internal-consumer`\n- `baseline-gap`\n- `external-compat`\n- `persistent-state-risk`\n\n`persistent-state-risk` is a stop condition, not a normal repair branch.\n\n## Gap Closure\n\nRepair order:\n\n- `expected-retirement`\n  - update tests, docs, or caller expectations\n- `missing-owner-logic`\n  - fix the new canonical owner\n- `stale-internal-consumer`\n  - migrate the internal consumer\n- `baseline-gap`\n  - correct requirement \u002F spec \u002F baseline first\n- `external-compat`\n  - allow compat only if active external dependency evidence exists\n- `persistent-state-risk`\n  - stop and ask for user confirmation\n\nUse this contract:\n\n```text\nGap Closure:\n- Gap Found:\n- Gap Type:\n- Repair Action:\n- Reintroduced Compat: no | yes\n- If yes, External Dependency Evidence:\n- Retirement Trigger:\n```\n\nIf `Gap Type = persistent-state-risk`, stop and return to the confirmation\ngate. Do not improvise destructive repair.\n\n## Compat Exception Gate\n\nRetention is allowed only if all are true:\n\n- an external boundary is touched\n- current active dependency evidence exists\n- deletion would break a published or documented contract\n- the current slice cannot complete owner repair or consumer migration\n- an observation metric exists\n- a retirement trigger exists\n\nWithout these, do not retain compat.\n\n## Completion Semantics\n\nCompletion claims must reflect the real outcome:\n\n- internal retirement with old compat preserved -> `bounded mitigation` or\n  `deferred debt`, not clean retirement\n- external compat retained with full evidence -> `bounded compatibility exception`\n- persistent-state deletion without scoped confirmation -> not complete\n\n## Common Mistakes\n\nDo not:\n\n- treat unknown dependency as proof of dependency\n- treat missing active-dependency evidence as proof that deletion is safe across\n  a proven external boundary\n- keep both owners active \"for safety\"\n- add a fallback before checking whether the gap belongs in the new owner\n- confuse migration-file deletion with live database deletion\n- treat source-of-truth data cleanup as ordinary code retirement\n- call a task \"cleaned up\" when old logic still carries main-path behavior\n- delete a carrier merely because one authority on it was invalid when a\n  separately evidenced legitimate role remains\n- treat a warning or guard card as destructive authorization\n\n## Minimal Reporting Shape\n\nThis shape is the anti-entropy workflow's decision surface, not a separate\nfinal completion report. When anti-entropy materially shapes a completed task,\nits preserved\u002Fretired behavior, deletion class, retained boundary, verification\nplan, and residual risk should flow into `verification-before-completion`'s\nunified Aegis impact\u002Fsafety receipt.\n\n```text\nAegis Visibility:\nAnti-Entropy Declaration:\nRetirement Decision:\nVerification Plan:\nGap Closure:\n```\n\nUse the compact shape by default. Expand only when task risk requires it.\n","# Anti-Entropy\n\n## Overview\n\nUse this skill when the task is not merely \"change code\" but \"remove old paths\nsafely without growing entropy\".\n\nThis skill chooses between:\n\n- `delete-first` for internal code retirement\n- `compat-exception` for proven external dependency boundaries\n- `confirmation-first` for irreversible state or an external contract whose\n  distributed consumers cannot be observed\n\nIt does not replace `brainstorming`, `writing-plans`,\n`systematic-debugging`, or `verification-before-completion`. It is a narrow\ngovernance owner for retirement, fallback collapse, duplicate-owner cleanup,\nand deletion safety.\n\n## When to Use\n\nUse when any of these are true:\n\n- old logic, duplicate owners, or stale fallbacks should be retired\n- a candidate fix is \"delete old path\" vs \"add another fallback\"\n- internal keyword \u002F phrase \u002F trigger logic is being replaced by structured logic\n- a new canonical owner exists and the old owner may still carry real behavior\n- a cleanup, migration, or deprecation task touches schema, persistence,\n  source-of-truth, or external compatibility boundaries\n- the task risks confusing code retirement with live data deletion\n\nDo not use for:\n\n- pure additive feature work with no retirement decision\n- tiny wording edits\n- simple status or read-only Q&A\n- normal bug fixes that do not involve owner collapse, fallback cleanup, or\n  deletion choice\n\n## Auto-Compose Boundary\n\nThis skill should be composed by other owners. It should not become a new\nglobal hot-path entry.\n\nPrefer composition from:\n\n- `brainstorming` for approach selection involving retirement or persistence risk\n- `writing-plans` for plans that delete old paths or touch schema \u002F migration \u002F\n  persistence\n- `systematic-debugging` when the tempting fix is fallback growth or\n  delete-vs-retain\n- `verification-before-completion` for cleanup \u002F retirement \u002F compatibility \u002F\n  migration closeout\n\nLoad automatically when the task touches owner collapse, fallback removal, or schema\u002Fpersistence\u002Fsource-of-truth boundaries. Automatic loading identifies and advises only; destructive execution still requires explicit scoped user confirmation.\n\n## Core Principle\n\nDefault to reducing internal entropy, not preserving internal history.\n\nRetirement is responsibility-scoped before it is carrier-scoped. Name the\nobsolete or duplicated authority first. If the same carrier has a separately\nevidenced legitimate role, remove the invalid responsibility and keep only\nthat role-scoped capability; this is not a compatibility exception. Apply\n`delete-first` to the carrier once no legitimate responsibility remains.\nUnknown consumers alone still do not justify retaining an internal carrier.\n\nUse this rule:\n\n- internal code retirement -> `delete-first`\n- external compatibility boundary -> `compat-exception` with active dependency\n  evidence; `confirmation-first` when distribution is proven but consumers\n  cannot be observed\n- persistent-state or irreversible source-of-truth object ->\n  `confirmation-first`\n\nUnknown alone neither proves an external dependency nor blocks internal\n`delete-first`. Once distribution is proven, unobservable consumers also do not\nprove deletion safe: inspect read-only. Before editing, require user-authored,\nscoped authorization that explicitly accepts the concrete external risk.\nAn informed instruction may already supply it; otherwise disclose the risk\nand request scoped confirmation.\n\nMentioning, loading, or discussing destructive-action rules never authorizes\ndestructive execution. Without explicit scoped user confirmation:\n\n- no irreversible deletion is executed\n- no destructive tool call is made\n- no runnable destructive command is emitted as the next action\n- no broad assent is reinterpreted as deletion approval\n\n## Deletion Classes\n\nClassify the deletion target first:\n\n- `code-retirement`\n  - source code\n  - internal triggers\n  - duplicate owners\n  - stale fallback branches\n  - compat-only carriers\n  - dead tests\u002Fconfig tied to removed internal behavior\n\n- `contract-carrying code`\n  - schema definition files\n  - migration files\n  - public API contract code\n  - host install\u002Fdiscovery code\n  - persistence read\u002Fwrite logic\n\n- `live-state mutation surface`\n  - code or commands that would mutate live databases, object stores, queues,\n    or other persistent state\n\n- `derived-state`\n  - rebuildable caches\n  - generated indexes\n  - temporary exports\n  - recomputable artifacts\n\n- `persistent-state`\n  - live database tables \u002F columns \u002F rows\n  - source-of-truth object storage files\n  - user records\n  - permission \u002F identity \u002F membership records\n  - audit \u002F billing \u002F irreversible business records\n  - non-rebuildable queue or event contents\n\n## Default Path By Class\n\n- `code-retirement` -> `delete-first`\n- `contract-carrying code` -> classify by the Core Principle; internal-only\n  retirement uses `delete-first` with high-risk verification\n- `live-state mutation surface` -> inspect and classify; destructive execution\n  still requires confirmation when it reaches persistent-state\n- `derived-state` -> verify rebuildability first, then decide\n- `persistent-state` -> `confirmation-first`\n\n## Hard Stops\n\nIf the target is `persistent-state` or another irreversible source-of-truth\nobject:\n\n- do not execute deletion automatically\n- do not emit a runnable destructive command as the next action\n- do not call a destructive tool\n- do not interpret generic agreement as confirmation\n- ask for explicit scoped user confirmation\n- request backup \u002F rollback \u002F migration note when relevant\n\nExamples that require confirmation:\n\n- `DROP TABLE`\n- `DROP COLUMN`\n- `TRUNCATE`\n- bulk delete of real business data\n- deleting source-of-truth uploaded files\n- deleting permission, identity, audit, billing, or membership records\n- purging non-rebuildable queues or event streams\n\n## Data Destruction Guard\n\nWhen `confirmation-first` protects persistent-state or an irreversible\nsource-of-truth object, stop normal retirement flow and emit:\n\n```text\nData Destruction Guard:\n- Target Class:\n- Exact Target(s):\n- Environment:\n- Why Irreversible:\n- Backup \u002F Rollback Note:\n- Allowed Read-Only Next Steps:\n- Blocked Destructive Steps:\n- Confirmation Required: yes\n- Status: awaiting scoped confirmation\n```\n\nOnly explicit scoped confirmation can continue. Broad assent such as \"OK\",\n\"continue\", or \"sounds good\" is insufficient. If scope changes at all, previous\nconfirmation is invalid and fresh confirmation is required.\n\n## Anti-Entropy Declaration\n\nBefore deletion, state:\n\n```text\nAnti-Entropy Declaration:\n- Deletion Class:\n- Old Path\u002FObject:\n- Invalid Responsibility \u002F Authority:\n- Legitimate Capability Remaining on Carrier:\n- New Canonical Owner:\n- Expected Preserved Behavior:\n- Expected Retired Behavior:\n- External Boundary Touched: no | yes\n- Source-of-Truth Data Risk: none | possible | confirmed\n- User Confirmation Required: no | yes\n```\n\nFor external-unknown code, fill `User Confirmation Required` with `yes` unless\nthe user's own instruction already names the concrete external risk, accepts\nits possible breakage, and authorizes the exact retirement scope, or the user\nlater gives scoped confirmation after your disclosure. A generic original\ndeletion request does not satisfy this slot. Do not infer acceptance from mere\nawareness of external use or from your own risk summary.\n\nIf `User Confirmation Required: yes`, stop normal delete-first flow.\nPersistent-state or irreversible targets enter `Data Destruction Guard`;\nexternal-unknown code stays in the `Retirement Decision` hold below.\n\n## Retirement Decision\n\nChoose one path only:\n\n```text\nRetirement Decision:\n- Path: delete-first | compat-exception | confirmation-first\n- Why:\n- Non-edits:\n```\n\nRules:\n\n- choose `delete-first` for internal retirement unless a stronger boundary blocks it\n- choose `compat-exception` only when external dependency is proven\n- choose `confirmation-first` for irreversible targets or proven distribution\n  whose consumers cannot be observed\n\nIf `Path = confirmation-first`, no destructive execution may happen until\nscoped confirmation is established. For external-unknown code, earlier generic\ndeletion instructions do not count. An informed, scoped user instruction may\nestablish confirmation before your disclosure; otherwise disclose the risk\nand directly ask the user to confirm the exact retirement scope before editing.\nDo not only state that confirmation is required or quote the words needed.\n\n## Verification Plan\n\nDo not verify only by \"tests are green\". Verify that the old logic actually\ndied and the new owner actually carries the behavior.\n\n```text\nVerification Plan:\n- Main-path check:\n- Lingering-reference check:\n- Negative check:\n- Boundary check:\n```\n\nMeaning:\n\n- `Main-path check`: new canonical owner still satisfies intended behavior\n- `Lingering-reference check`: the retired responsibility is no longer active;\n  when its carrier was deleted, the old path is no longer referenced on the\n  main path\n- `Negative check`: retired trigger\u002Fpath really stopped working\n- `Boundary check`: host\u002FAPI\u002Fschema\u002Fpersistence boundary was not accidentally broken\n\n## Gap Taxonomy\n\nIf a gap appears after deletion, classify it before repairing:\n\n- `expected-retirement`\n- `missing-owner-logic`\n- `stale-internal-consumer`\n- `baseline-gap`\n- `external-compat`\n- `persistent-state-risk`\n\n`persistent-state-risk` is a stop condition, not a normal repair branch.\n\n## Gap Closure\n\nRepair order:\n\n- `expected-retirement`\n  - update tests, docs, or caller expectations\n- `missing-owner-logic`\n  - fix the new canonical owner\n- `stale-internal-consumer`\n  - migrate the internal consumer\n- `baseline-gap`\n  - correct requirement \u002F spec \u002F baseline first\n- `external-compat`\n  - allow compat only if active external dependency evidence exists\n- `persistent-state-risk`\n  - stop and ask for user confirmation\n\nUse this contract:\n\n```text\nGap Closure:\n- Gap Found:\n- Gap Type:\n- Repair Action:\n- Reintroduced Compat: no | yes\n- If yes, External Dependency Evidence:\n- Retirement Trigger:\n```\n\nIf `Gap Type = persistent-state-risk`, stop and return to the confirmation\ngate. Do not improvise destructive repair.\n\n## Compat Exception Gate\n\nRetention is allowed only if all are true:\n\n- an external boundary is touched\n- current active dependency evidence exists\n- deletion would break a published or documented contract\n- the current slice cannot complete owner repair or consumer migration\n- an observation metric exists\n- a retirement trigger exists\n\nWithout these, do not retain compat.\n\n## Completion Semantics\n\nCompletion claims must reflect the real outcome:\n\n- internal retirement with old compat preserved -> `bounded mitigation` or\n  `deferred debt`, not clean retirement\n- external compat retained with full evidence -> `bounded compatibility exception`\n- persistent-state deletion without scoped confirmation -> not complete\n\n## Common Mistakes\n\nDo not:\n\n- treat unknown dependency as proof of dependency\n- treat missing active-dependency evidence as proof that deletion is safe across\n  a proven external boundary\n- keep both owners active \"for safety\"\n- add a fallback before checking whether the gap belongs in the new owner\n- confuse migration-file deletion with live database deletion\n- treat source-of-truth data cleanup as ordinary code retirement\n- call a task \"cleaned up\" when old logic still carries main-path behavior\n- delete a carrier merely because one authority on it was invalid when a\n  separately evidenced legitimate role remains\n- treat a warning or guard card as destructive authorization\n\n## Minimal Reporting Shape\n\nThis shape is the anti-entropy workflow's decision surface, not a separate\nfinal completion report. When anti-entropy materially shapes a completed task,\nits preserved\u002Fretired behavior, deletion class, retained boundary, verification\nplan, and residual risk should flow into `verification-before-completion`'s\nunified Aegis impact\u002Fsafety receipt.\n\n```text\nAegis Visibility:\nAnti-Entropy Declaration:\nRetirement Decision:\nVerification Plan:\nGap Closure:\n```\n\nUse the compact shape by default. Expand only when task risk requires it.\n",{"name":5,"description":7},"main","b0f0a87593c578a7898eccaf1b363f7f87c1f99b","plugins\u002FGanyuanRan\u002FAegis\u002Fskills\u002Fanti-entropy-governance",491,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins","https:\u002F\u002Fhol.org\u002Fplugins\u002Fbest-codex-plugins","https:\u002F\u002Fgithub.com\u002Fhashgraph-online","https:\u002F\u002Fhol.org","Open-source standards and developer tools for interoperable AI agents: discovery, identity, communication, payments, privacy and security.","2026-11-14 14:06:13",{"source":8,"skillName":5,"commands":48,"prompt":58,"zipAvailable":59},[49,52,55],{"tool":50,"command":51},"npx","npx skills add hashgraph-online\u002Fawesome-codex-plugins --skill anti-entropy-governance",{"tool":53,"command":54},"bunx","bunx skills add hashgraph-online\u002Fawesome-codex-plugins --skill anti-entropy-governance",{"tool":56,"command":57},"pnpm","pnpm dlx skills add hashgraph-online\u002Fawesome-codex-plugins --skill anti-entropy-governance","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FGanyuanRan\u002FAegis\u002Fskills\u002Fanti-entropy-governance\u002FSKILL.md",true,[],[62,70,77,84,110,135],{"skillNo":63,"name":64,"nameZh":6,"description":65,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":66,"categories":67,"keywords":68,"publishedAt":69},"01M746ZWACVKMZ1BJXJZHYJSSX","migrate-to-e2e","Moves an existing Playwright, Cypress, Selenium, Appium, Detox, Maestro, or TesterArmy suite to e2e one slice at a time, with the old suite running beside the new one until each ported test is proven. Keeps a MIGRATION.md progress file so any later session resumes where the last stopped. Optionally plants a defect to show both suites catch it. Use for \u002Fmigrate-to-e2e, \"migrate our tests to e2e\", \"port these Maestro flows\", \"move our TesterArmy tests\", or when a project has an e2e config and an older suite still running.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fmigrate-to-e2e\u002FSKILL.md",[],[],"2026-11-11 15:11:14",{"skillNo":71,"name":72,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":69},"01M746ZPTAX1Q0FBKAB1CYND7E","e2e","Writes, runs, and debugs end-to-end tests for web and mobile apps with e2e, the agentic test runner, which mixes agent.act goals with exact locator assertions on a Playwright browser or an iOS or Android device. Also drives a project's running app live over the e2e MCP server to look at a screen, check a UI change, take a screenshot or record a video, and try a locator; and runs bug bashes, parallel e2e explore runs with each bug proven by a repro test. Use when a project depends on e2e or has an e2e.config.ts, when asked for end-to-end, browser, mobile, or agentic UI tests, to check a change in the running app, to QA or bug bash an app or branch, or when an e2e run fails.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fe2e\u002FSKILL.md",[],[],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":83,"publishedAt":69},"01M746ZJN784HVHMDP9MQGCSGG","create-verification-skill","Generate a project-local verify-\u003Capp> skill on top of e2e, so any coding agent can launch the app, check it is worth driving, exercise a feature the way a user does, keep evidence, and bug bash it. Writes the skill, a feature map with one explore charter per feature, and proves it once. Use for \u002Fcreate-verification-skill, \"make a verification skill for this repo\", or when a project has no scripted way to prove UI behavior.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fcreate-verification-skill\u002FSKILL.md",[],[],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":32},"01M716A6ETNB9B1SQ3GXZC75VR","deja-search","deja-vu memory — search the user's past AI coding sessions with the deja CLI. Holds what they already settled and never wrote into the repo (naming rules, banned or already-tried tools, required checks before merge, preferred values, who owns what). Use before your first edit in a task, before you call a change done or ready to merge, before you recommend a tool, library, design or reviewer, before re-debugging an error that may already be solved, when they say 'didn't we fix this before', 'what did we decide about X' or 'I already have that', and before telling them something on this machine does not exist.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-search\u002FSKILL.md",[],[91,92,93,94,95,96,97,98,99,100,101,31,102,103,104,105,106,107,108,109],"search","deja search","never","error","ready","memory","re","decide","fix","design","debugging","you","done","reviewer","io","change","cli","merge","past",{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":116,"publishedAt":32},"01M716A3J2W5SENSE9VGMXB375","deja-reflect","End-of-session reflection and memory curation with deja-vu. Review what was decided, what commands broke and what repaired them, and record durable project rules or decisions with deja remember so the next session starts with them.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-reflect\u002FSKILL.md",[],[117,118,119,105,120,121,122,123,124,125,126,127,128,129,96,130,131,132,133,134],"deja reflect","reflect","review","with","record","github","next","https","node","Rules","decisions","brew","remember","project rules","project","session","end","reflection",{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":152,"publishedAt":32},"01M715T3RR4BAYSR57HPPTJ0PF","revid","Make, edit, export and post AI videos with Revid (revid.ai) through the Revid MCP server. Use whenever the user wants a short-form or long-form video made (from an idea, a script, a URL, an article, a PDF, a tweet, a product page, their own clips, or a song), wants to find what is going viral on TikTok, YouTube, Instagram or X before making something, wants to edit or re-export an existing Revid project, generate a standalone AI image or clip, make a series episode, or publish and schedule a finished video to connected social accounts. Covers setup (hosted MCP with OAuth, or an API key), the 36 tools, credits, polling and the rules for publishing. Routes to the more specific revid-* skills when one fits.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftmakersas\u002Frevid-skills\u002Fskills\u002Frevid\u002FSKILL.md",[141,146,149],{"categoryNo":142,"categoryName":143,"taxonomyType":144,"taxonomyTypeDesc":145},"01JBSEEDCAT000000000000016","图像与多媒体","SCENARIO","使用场景",{"categoryNo":147,"categoryName":148,"taxonomyType":144,"taxonomyTypeDesc":145},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":150,"categoryName":151,"taxonomyType":144,"taxonomyTypeDesc":145},"01JBSEEDCAT000000000000010","后端与接口",[137,153,154,155,156,157,158,131,159,97,160,161,162,163,31,164,165,166,167,168],"URL","Video","short-form","standalone","PDF","viral","tiktok","short","social","MCP","song","image","mcp server","schedule","api","publish"]