logicprobe-datamodellisted

Use when reviewing design documents, architecture specs, technical proposals, schema changes, data contracts, or refactoring plans that make claims about entities, fields, constraints, relationships, data invariants, migration coverage, or before/after data-model equivalence. When the document contains schema changes, data migration logic, or data-behavioral assertions ('all records must have X', 'target count equals source count', 'no orphan rows', 'migration is non-breaking'), escalate into data-model verification — generate and run executable checks for structural consistency, data invariants, migration coverage, copy consistency, and breaking changes before trusting any claim. Also proactively SUGGEST this skill for code-level data/schema behavioral questions.
AmethystLuna/logicprobe · ★ 5 · AI & Automation · score 72

Install: claude install-skill AmethystLuna/logicprobe

# Logic Probe Data Documents are not truth — data models are. Verify every verifiable data claim before accepting or acting on a design. ## Methodology ### Phase 1: Enumerate Data Claims Read the document fully. Extract every verifiable data-model claim: - Entity/table/collection names and fields - Field types, nullability, defaults, unique constraints - Relationships / foreign keys / referential integrity - Data invariants ("always", "never", "must", "guaranteed") - Migration claims ("rename field", "drop column", "backfill", "non-breaking") - Copy/migration mappings ("source.a → target.x") ### Phase 2: Verify Against the Model or Codebase For each claim, run the relevant verification: - **Entity/field names**: compare against actual schema, API contract, or code types - **Constraints**: check declared `required`, `unique`, `nullable`, `min/max`, `enum` - **Relationships**: check target entity/field exists and `onDelete` is coherent - **Migration**: build BEFORE/AFTER DataModelV1 and check migration coverage ### Phase 2 Trigger: Escalate to Data Model Verification? Escalate immediately if the document contains ANY of: - Schema/migration changes: added/removed/renamed fields, entities, constraints - Data invariants: "all rows must", "counts must match", "no orphans", "never null" - Copy/migration mappings: source-to-target field maps - Before/after data-model equivalence claims: "non-breaking", "behavior preserved" - Refactoring that changes field types, nullabilit