Notebook Entry 024
The Stub Conversion That Ate Five Skills
July 31, 2026
Did consolidating five skills into pointers actually verify the destination held real content?
What happened
A same-day migration converted 41 installed AI skills into thin pointer stubs, with content consolidated to vault master files — killing a chronic two-copies-drift problem. Five of those masters turned out to be hollow (frontmatter, no body). The installed copies had held the only full content, the stubs overwrote them, and the last cached copies re-synced away before rescue. Five working skills reduced to pointers at empty files, in one motion, with every individual step reporting success.
Root cause
The migration verified the new artifact (do the stubs point at the right paths?) but not the invariant (do the destinations actually contain the content?). Redundancy was treated as waste to eliminate rather than as the backup it silently was — right up until the moment of deletion.
What changed
Master-completeness verification is now written law in the skills spec: no stub ships until its master's body is confirmed real. A monthly automated auditor carries a hollow-file guard as a standing check. The five skills were rebuilt — better, system-tailored — from their surviving trigger descriptions. The failure and rebuild are both logged in a skills decision log that now records every removal's archival details BEFORE the removal.
The lesson
In any two-copies-to-one consolidation, the copy you keep must be verified complete before the copy you discard is destroyed — the redundant copy IS your backup until the instant it isn't. And "success" at every step is compatible with losing data overall: step-level checks verify steps; only an invariant check verifies the migration.
One implementation insight every other Tuesday.
What actually works when you ship AI in real organizations. Nothing you could get from a press release.