TypeScript · Prisma
Prisma ORM rules for Cursor
Schema, migration and client rules for current Prisma projects.
The rule
Save as .cursor/rules/prisma.mdc. Cursor picks it up on the next request.
.cursor/rules/prisma.mdc
--- description: Prisma schema and client conventions globs: **/*.prisma, prisma.config.ts alwaysApply: false --- - Use the prisma-client generator with an explicit output path, and import the client from that path, not from @prisma/client in node_modules. - Put the database URL and migration settings in prisma.config.ts; it does not load .env automatically, so load it yourself. - Create the client with the driver adapter for your database (for example @prisma/adapter-pg). - Run prisma generate after every schema change; migrate dev does not run it for you. - Use prisma migrate dev to create migrations and prisma migrate deploy in production. Use db push only for throwaway prototypes. - Never edit a migration that has already been applied; create a new one. - Create one shared PrismaClient instance and reuse it; never create a client per request. - Select only the fields you need with select, and use include deliberately to avoid huge payloads. - Group dependent writes in prisma.$transaction, and add @@index on foreign key fields you filter or join on.
How Cursor loads this rule
Read from the frontmatter above, per Cursor's rules documentation.
alwaysApply: falsewithglobs: **/*.prisma, prisma.config.ts: attached automatically when a matching file is in context.- Keep the
.mdcextension. A plain.mdfile in .cursor/rules is ignored by the rules system. - Prefer to generate your own? Type
/create-rulein Agent and describe what you want; Cursor saves the file to .cursor/rules. - Team Rules come first, then Project Rules like this one, then User Rules. Earlier sources win when guidance conflicts.
Cursor rules setup guideCursor Team RulesLet Cursor run commands without asking
Prisma ORM rules for Claude Code, Copilot, Kiro and other agents
The same instructions work as plain Markdown in AGENTS.md, which Codex, Gemini CLI, GitHub Copilot and most other coding agents read.
AGENTS.md (section)
## Prisma ORM - Use the prisma-client generator with an explicit output path, and import the client from that path, not from @prisma/client in node_modules. - Put the database URL and migration settings in prisma.config.ts; it does not load .env automatically, so load it yourself. - Create the client with the driver adapter for your database (for example @prisma/adapter-pg). - Run prisma generate after every schema change; migrate dev does not run it for you. - Use prisma migrate dev to create migrations and prisma migrate deploy in production. Use db push only for throwaway prototypes. - Never edit a migration that has already been applied; create a new one. - Create one shared PrismaClient instance and reuse it; never create a client per request. - Select only the fields you need with select, and use include deliberately to avoid huge payloads. - Group dependent writes in prisma.$transaction, and add @@index on foreign key fields you filter or join on.
Prisma ORM rules for Claude Code.claude/rules/prisma.md
.claude/rules/prisma.md
--- paths: - "**/*.prisma" - "prisma.config.ts" --- - Use the prisma-client generator with an explicit output path, and import the client from that path, not from @prisma/client in node_modules. - Put the database URL and migration settings in prisma.config.ts; it does not load .env automatically, so load it yourself. - Create the client with the driver adapter for your database (for example @prisma/adapter-pg). - Run prisma generate after every schema change; migrate dev does not run it for you. - Use prisma migrate dev to create migrations and prisma migrate deploy in production. Use db push only for throwaway prototypes. - Never edit a migration that has already been applied; create a new one. - Create one shared PrismaClient instance and reuse it; never create a client per request. - Select only the fields you need with select, and use include deliberately to avoid huge payloads. - Group dependent writes in prisma.$transaction, and add @@index on foreign key fields you filter or join on.
Prisma ORM rules for GitHub Copilot.github/instructions/prisma.instructions.md
.github/instructions/prisma.instructions.md
--- applyTo: "**/*.prisma,prisma.config.ts" --- - Use the prisma-client generator with an explicit output path, and import the client from that path, not from @prisma/client in node_modules. - Put the database URL and migration settings in prisma.config.ts; it does not load .env automatically, so load it yourself. - Create the client with the driver adapter for your database (for example @prisma/adapter-pg). - Run prisma generate after every schema change; migrate dev does not run it for you. - Use prisma migrate dev to create migrations and prisma migrate deploy in production. Use db push only for throwaway prototypes. - Never edit a migration that has already been applied; create a new one. - Create one shared PrismaClient instance and reuse it; never create a client per request. - Select only the fields you need with select, and use include deliberately to avoid huge payloads. - Group dependent writes in prisma.$transaction, and add @@index on foreign key fields you filter or join on.
Prisma ORM rules for Kiro.kiro/steering/prisma.md
.kiro/steering/prisma.md
--- inclusion: fileMatch fileMatchPattern: ["**/*.prisma", "prisma.config.ts"] --- - Use the prisma-client generator with an explicit output path, and import the client from that path, not from @prisma/client in node_modules. - Put the database URL and migration settings in prisma.config.ts; it does not load .env automatically, so load it yourself. - Create the client with the driver adapter for your database (for example @prisma/adapter-pg). - Run prisma generate after every schema change; migrate dev does not run it for you. - Use prisma migrate dev to create migrations and prisma migrate deploy in production. Use db push only for throwaway prototypes. - Never edit a migration that has already been applied; create a new one. - Create one shared PrismaClient instance and reuse it; never create a client per request. - Select only the fields you need with select, and use include deliberately to avoid huge payloads. - Group dependent writes in prisma.$transaction, and add @@index on foreign key fields you filter or join on.
Prisma ORM rules for Antigravity.agents/rules/prisma.md
.agents/rules/prisma.md
--- trigger: glob globs: "**/*.prisma, prisma.config.ts" --- - Use the prisma-client generator with an explicit output path, and import the client from that path, not from @prisma/client in node_modules. - Put the database URL and migration settings in prisma.config.ts; it does not load .env automatically, so load it yourself. - Create the client with the driver adapter for your database (for example @prisma/adapter-pg). - Run prisma generate after every schema change; migrate dev does not run it for you. - Use prisma migrate dev to create migrations and prisma migrate deploy in production. Use db push only for throwaway prototypes. - Never edit a migration that has already been applied; create a new one. - Create one shared PrismaClient instance and reuse it; never create a client per request. - Select only the fields you need with select, and use include deliberately to avoid huge payloads. - Group dependent writes in prisma.$transaction, and add @@index on foreign key fields you filter or join on.
Prisma ORM rules for Devin Desktop (Windsurf).devin/rules/prisma.md
.devin/rules/prisma.md
--- trigger: glob globs: **/*.prisma, prisma.config.ts --- - Use the prisma-client generator with an explicit output path, and import the client from that path, not from @prisma/client in node_modules. - Put the database URL and migration settings in prisma.config.ts; it does not load .env automatically, so load it yourself. - Create the client with the driver adapter for your database (for example @prisma/adapter-pg). - Run prisma generate after every schema change; migrate dev does not run it for you. - Use prisma migrate dev to create migrations and prisma migrate deploy in production. Use db push only for throwaway prototypes. - Never edit a migration that has already been applied; create a new one. - Create one shared PrismaClient instance and reuse it; never create a client per request. - Select only the fields you need with select, and use include deliberately to avoid huge payloads. - Group dependent writes in prisma.$transaction, and add @@index on foreign key fields you filter or join on.
Prisma ORM rules for Cline.clinerules/prisma.md
.clinerules/prisma.md
--- paths: - "**/*.prisma" - "prisma.config.ts" --- - Use the prisma-client generator with an explicit output path, and import the client from that path, not from @prisma/client in node_modules. - Put the database URL and migration settings in prisma.config.ts; it does not load .env automatically, so load it yourself. - Create the client with the driver adapter for your database (for example @prisma/adapter-pg). - Run prisma generate after every schema change; migrate dev does not run it for you. - Use prisma migrate dev to create migrations and prisma migrate deploy in production. Use db push only for throwaway prototypes. - Never edit a migration that has already been applied; create a new one. - Create one shared PrismaClient instance and reuse it; never create a client per request. - Select only the fields you need with select, and use include deliberately to avoid huge payloads. - Group dependent writes in prisma.$transaction, and add @@index on foreign key fields you filter or join on.
Prisma ORM rules for Continue.continue/rules/prisma.md
.continue/rules/prisma.md
--- name: "prisma" globs: ["**/*.prisma", "prisma.config.ts"] --- - Use the prisma-client generator with an explicit output path, and import the client from that path, not from @prisma/client in node_modules. - Put the database URL and migration settings in prisma.config.ts; it does not load .env automatically, so load it yourself. - Create the client with the driver adapter for your database (for example @prisma/adapter-pg). - Run prisma generate after every schema change; migrate dev does not run it for you. - Use prisma migrate dev to create migrations and prisma migrate deploy in production. Use db push only for throwaway prototypes. - Never edit a migration that has already been applied; create a new one. - Create one shared PrismaClient instance and reuse it; never create a client per request. - Select only the fields you need with select, and use include deliberately to avoid huge payloads. - Group dependent writes in prisma.$transaction, and add @@index on foreign key fields you filter or join on.
More templates
Next.js App RouterTypeScript (strict)React componentsPythonFastAPIFastifyNode.js and ExpressGoRustData science notebooks and pipelinesTesting disciplineSecurity guardrailsVue 3 (Composition API)NuxtSvelteKit (Svelte 5 runes)Angular (standalone components, signals)DjangoLaravelRuby on RailsNestJSSpring BootASP.NET CoreFlutterSwiftUI (iOS)Android (Kotlin, Jetpack Compose)React Native (Expo)Tailwind CSS (v4)
Get Cursor rules and settings changes by email
When Cursor changes how rules, run modes or settings work, we update these templates from the docs and send a short note. One email a week at most.
Reviewed Oct 20, 2026. Written by AgentAtlas. Adapt it to your codebase before relying on it.