drizzle-orm-ecosystem-and-extensions

Drizzle ORM Ecosystem and Extensions

Use this skill when the task is about Drizzle’s validator generators, seed tooling, GraphQL helpers, lint rules, Studio product surfaces, Gateway, or extension-style integrations around the ORM core.

Scope

• Zod, Valibot, TypeBox, ArkType, and Effect Schema generation
• validator-package deprecation and import migration
• deterministic fake-data generation with drizzle-seed
• GraphQL schema generation with drizzle-graphql
• ESLint rule setup for destructive query safety
• embeddable Studio package and Gateway product routing
• Prisma extension routing

Routing cues

• drizzle-zod, drizzle-orm/zod, drizzle-valibot, drizzle-typebox, drizzle-arktype, drizzle-seed, drizzle-graphql, eslint-plugin-drizzle, @drizzle-team/studio, or Drizzle Gateway -> use this skill
• initial Drizzle install or stable-vs-beta routing -> use drizzle-orm-overview-and-setup
• schema modeling or relation declaration -> use drizzle-orm-schema-and-relations
• query code and transactions -> use drizzle-orm-queries-and-sql
• migration strategy or drizzle-kit config -> use drizzle-orm-migrations-and-drizzle-kit

Default path

1. Read references/validation-and-schema-generation.md first.
2. If the task touches seed, GraphQL, ESLint, Studio package work, Gateway, or Prisma extension work, read references/ecosystem-tooling-reference.md.
3. Check whether the repo is on stable or beta before changing imports for validator packages.
4. Keep ecosystem utilities aligned with the underlying schema and query surfaces instead of duplicating model logic manually.

When to deviate

• Keep separate validator packages only when the project intentionally stays on the older stable path.
• Add seed, GraphQL, or lint tooling only when the project really needs that surface.
• Treat Gateway and embeddable Studio as product-surface decisions, not default dev dependencies.