LobeHub Drizzle ORM schema and query style. Use for pgTable schemas, indexes, joins, inferred types, db.select/db.query, schema fields, foreign keys, junction tables, or postgres query patterns.
This skill is a Drizzle ORM schema and query style guide extracted from the LobeHub / lobe-chat codebase. It solves the problem of keeping database schema definitions consistent across a large PostgreSQL project by codifying the team's conventions for pgTable schemas, column definitions, keys, indexes, enums, and query patterns. It is marked non-user-invocable, functioning as an internal convention reference that agents consult when adding or modifying database models.
The guide documents configuration locations (drizzle.config.ts, schemas, migrations directories), helper functions for timezone-aware timestamps, and naming conventions favoring plural snake_case tables and consistent noun families. It gives opinionated rules with good/bad examples: avoid auto-incrementing primary keys in favor of application-generated text IDs or uuid, keep $defaultFn ID generators, prefer single-column surrogate primary keys with uniqueIndex over composite keys (citing a real migration 0110 that rebuilt composite PKs), define foreign keys with cascade deletes, spread standard timestamps, avoid sentinel strings in favor of nullable columns, default away from pgEnum toward text/varchar with TypeScript $type value types, and add JSDoc field descriptions for non-obvious columns. It also reminds contributors to ship a sibling test for every new model or repository file.
It targets engineers contributing to the lobe-chat project or teams wanting a mature reference for Drizzle + PostgreSQL schema design. It is a style reference, not runnable tooling.
It is a style/convention reference for Drizzle ORM schema design, marked user-invocable: false, meant to be consulted rather than executed.
PostgreSQL via Drizzle ORM, configured with the postgresql dialect and strict mode.
Avoid auto-incrementing serial/bigserial keys; prefer application-generated text IDs (via idGenerator or nanoid) or uuid, and use single-column surrogate keys with a uniqueIndex rather than composite primary keys.
Yes. It recommends defaulting away from pgEnum toward text/varchar columns typed with $type<...> TypeScript value types, because database enums are costly to evolve.
Yes. It states that every new model or repository file needs a matching sibling test in the same PR, pointing to the project's testing skill for the integration pattern.
Quick Setup:
.claude/skills/Repository
lobehub/lobe-chat