What problem does it solve? Refactors that promise "data moved from XML/files/legacy store to a database" often ship without proof: the migration tool may never have run against the real DB, tables may be silently empty, or deletion commits may destroy the only recovery path. This Skill verifies delivery with direct evidence instead of trusting commit messages, tool docstrings, or plan checkboxes. ## Core Features & Use Cases - DB Forensics: Read-only inspection of the real database — table lists, per-table row counts, and __EFMigrationsHistory — to distinguish "migration applied" from "data actually imported". - Timestamp & Connection-String Forensics: Detects importers that never ran (original dates preserved) and the CWD-relative connection-string trap that silently creates fresh empty databases. - Data-Loss Path Detection: Finds latent bugs like derived-field re-render wipes, empty-table fallback failures, and non-idempotent importers before merge. - Use Case: Before merging a multi-phase refactor that claims "DB is the single source of truth, old XML files deleted", run this audit to confirm every migrated table has data, recovery paths survive, and no admin save path can wipe imported content. ## Quick Start Ask the agent to verify that the data migration refactor actually delivered data into the database before merging the deletion commits.
