What problem does it solve? Keeping SQLModel ORM classes consistent with a dbmate-managed database schema is error-prone: developers may accidentally generate tables from models, leak password hashes into API responses, or drift from the migration-defined schema. This Skill enforces a strict modeling pattern so the Portal backend stays aligned with its migrations. ## Core Features & Use Cases - Three-class pattern: Defines XBase (shared Pydantic fields), X (table=True ORM), and XOut/XCreate/XUpdate API contracts so routers never expose internal fields. - Schema mirroring, not generation: Models reflect the dbmate schema for app_user, catalog_source, catalog_field, catalog_tribal_note, and export_job; SQLModel.metadata.create_all() is forbidden outside isolated test fixtures. - Security and audit rules: Soft delete via disabled = true, hashed_password never serialized in *Out models, role enums matching JWT scopes, and created_at audit timestamps on every table. - Use Case: When adding a new catalog table or modifying the export job model, apply this Skill to produce SQLModel classes with pgvector embeddings, JSONB columns, and async SQLAlchemy session compatibility that exactly match the existing migrations. ## Quick Start Use the portal-db-models skill to create the SQLModel models for the catalog tables mirroring the existing dbmate schema.
