Adopt Prisma Next into a new project, onto an existing database, or as the first move after a bootstrap tool dropped you into a scaffold. Use for "what can I do with Prisma Next", "what can I do next with Prisma", "where do I start", "what should I do first", "just ran createprisma", "createprisma",

Prisma Next — Quickstart (Adoption) Edit your data contract. Prisma handles the rest. This skill takes the user from zero (or near zero) to a first working query against Prisma Next. Three paths — and they all converge on the same first arc: connect → write → read . Schema editing comes after the first arc, not before. First touch orientation — the user has arrived at a Prisma Next project for the first time (a scaffold tool like npx createprisma dropped them in, they cloned a teammate's repo, or they ran prisma next init themselves and now want to make their first move) and they're asking "what can I do with Prisma Next?" , "where do I start?" , or "what's next?" . The goal is to anchor them on the contract, get them connected to a database, round trip one row, and let further commands surface organically. Greenfield — new project, fresh database. User runs prisma next init themselves. init seeds a starter contract with a sample model, so the path joins the first touch orientation arc as soon as the database is initialised. Brownfield DB — existing database, no contract yet. Infer the contract from the database with contract infer , sign the marker with db sign , then write queries against one of the existing tables. This skill does not cover migrating from another ORM (Drizzle, Prisma 6/7, Sequelize, TypeORM, Kysely, Knex, raw drivers). Those are separately installable skills. When to Use User asks "what can I do with Prisma Next?" , "what can I do next with Prisma?" , "where do I start?" , "what should I do first?" — and a PN project already exists on disk. First touch orientation path below. User just ran createprisma (or equivalent scaffold tool) and is asking what to do next. First touch orientation path. User is starting a new project and wants to use Prisma Next. Greenfield path. User has an existing database (no PN contract) and wants to introduce PN. Brownfield DB path. User typed "prisma next init" , "get started with PN" , "set up PN" , "how do I scaffold a project" . Greenfield path. User says "I have an existing Postgres/Mongo, how do I start using PN?" . Brownfield DB path. When Not to Use User already has a PN project and wants to add a model → prisma next contract . User wants to migrate FROM a specific ORM → install @prisma next/migrate from <orm skill (separate). User wants to wire db.ts in a project that already has a contract → prisma next runtime . User wants to integrate Prisma Next with a build tool (Vite plugin, Next.js, …) → prisma next build . Key Concepts Contract : the data model. Authored as contract.prisma (PSL, the canonical surface) or contract.ts (TypeScript builder). The framework reads it and emits two artefacts: contract.json (runtime IR) and contract.d.ts (types). Target : the backing store. Today: postgres or mongodb . Picked at init time; baked into the @prisma next/<target façade the scaffold imports from. Authoring mode : how you write the contract. psl (Prisma Schema Language, default) or typescript (programmatic builder, optionally paired with the Vite plugin for auto emit during vite dev — see prisma next build ). Façade packages. The scaffold installs exactly one façade per target — @prisma next/postgres (or @prisma next/mongo ). User code imports from façade subpaths ( @prisma next/postgres/config , @prisma next/postgres/runtime , @prisma next/postgres/contract builder ). The façade bakes in the family / target / adapter / driver wiring; never reach past it. See prisma next contract for the full list. db.ts : the runtime entry point. Lives next to the contract source at src/prisma/db.ts . Imports the contract artefacts and exports a db value the rest of the app uses. Marker : a pn meta marker row in your database that records the contract hash. Lets PN detect drift between contract and live DB. Created by db init (greenfield / first touch orientation) or db sign (brownfield). Canonical on disk layout Every application that consumes Prisma Next uses the same shape: Three things to internalise: src/prisma/ is the home for the contract — source + emitted artefacts + db.ts all colocated. The rest of src/ imports from ./prisma/db (or ../prisma/db , depending on file depth). migrations/app/ — the app/ segment is the consuming application's space id. Extensions you depend on get sibling directories under migrations/ (one per extension contract space), but you don't write into those — only the app/ subtree is your migrations. prisma next.config.ts lives at the repo root , not under src/ . Every command resolves paths relative to the config's directory. Contributors building extension packages or aggregate root monorepo packages use a different layout — src/contract.{prisma,ts} (no prisma/ subdir) + migrations/<timestamp <slug / (no app/ segment). That distinction is intentional; see prisma next contract for which path applies to you. Heads up — prisma next init currently scaffolds the wrong layout. It writes prisma/contract.{prisma,ts} and prisma/db.ts at the repo root instead of under src/prisma/ . Tracked as [TML 2532](https://linear.app/prisma company/issue/TML 2532). Until the fix lands, either pass schema path src/prisma/contract.prisma to init , or move the scaffolded prisma/ directory into src/prisma/ after init and update the contract path in prisma next.config.ts to match. The canonical layout above is what the demo example uses and what the rest of the framework expects. Your first arc — connect, write, read All three paths in this skill converge here. Once the project is scaffolded and the database is reachable, the first move is always the same: connect, write a row, read it back, against whatever model the contract already declares. Don't touch the contract source on this first move — extend it later, after the round trip works. Write the snippet in a fresh file directly under src/ (e.g. src/first arc.ts ) so the relative import resolves to one level deep: If that prints [{ id: 1, email: 'alice@example.com' }] , the project is wired end to end and the user has crossed from "I have a project" to "I'm building." db.orm.<Model is the default ORM lane — model shaped, fully typed against the contract, lazily connects to the database on first use (it picks up DATABASE URL from .env via the runtime's dotenv/config loaded environment). The deeper prisma next queries skill covers the rest of the surface (filters, joins, transactions, the SQL builder, raw SQL, TypedSQL) when the user is ready. Mongo target: the snippet above is SQL target shape. On @prisma next/mongo , db.orm is keyed by the collection's storage name ( @@map(...) , or the lowercased model name if no @@map ), so the same arc reads await db.orm.users.create(...) / await db.orm.users.select('id', 'email').all() — not db.orm.User . Full rule and rewrite recipe in prisma next queries § MongoDB ORM addressing . Prerequisites for the arc to work. All three paths leave these in place by the time you reach the arc: prisma next.config.ts exists at the repo root and declares the target + contract source (typically src/prisma/contract.prisma or src/prisma/contract.ts ). The contract source exists at src/prisma/contract.{prisma,ts} (a starter model from init , or the inferred contract from contract infer , or whatever the bootstrap tool generated). src/prisma/db.ts exists and instantiates the runtime with the emitted contract. DATABASE URL is set in .env (or wherever the runtime's config tells it to look). The database has been initialised ( db init ) or marker signed ( db sign ), so the marker row exists and the schema matches the contract. The three workflows below each describe how their path gets the user to that state. After that, the arc above is the same. Workflow — First touch orientation Triggers: "what can I do with Prisma Next?" , "what can I do next with Prisma?" , "where do I start?" , "I just ran createprisma" , "what's next?" , or any close variant — paired with a PN project already on disk (scaffolded by createprisma , by prisma next init , by a teammate, however). The user's high level intent is "I want to be running an application against my database, against this thing called Prisma Next." The job of this workflow is to anchor them on the contract, get one round trip working, and let further commands surface organically as their next move requires them. It is orientation, not a tour, not a feature inventory, not a syllabus. Concept — what to communicate first Prisma Next is contract first. Everything the framework does — query types, migrations, runtime types, drift detection — flows from a single source of truth: the contract . The contract describes the user's application's data model. The framework reads it; the framework derives the rest. Lead with this. The first response to "what can I do with Prisma Next?" names the contract path, frames its role in one sentence, and then steers toward getting the user's application running. Don't open with a feature inventory. Don't open with a list of commands. Open with: "Your contract is at <path . It describes your application — your query types, migrations, and runtime types all flow from it. Let's get you connected to a database so your app can actually run against it." The first arc — once oriented — is connect → write → read . Not edit the contract first, not plan a migration first. The user's win is I have application code running against my database . Step 1 — Read the project, name the contract Before saying anything specific to the user, read: prisma next.config.ts at the repo root — what target ( postgres / mongodb ) is wired, what contract: path it declares, what extensions are installed. The contract source the config declares (canonically src/prisma/contract.prisma or src/prisma/contract.ts ; a project that pre dates [TML 2532](https://linear.app/prisma company/issue/TML 2532) may have it at prisma/contract.{prisma,ts} instead — check the contract field of the config) — what starter models, if any, exist. src/prisma/db.ts (next to the contract) — the runtime entry point. .env / .env.example — is DATABASE URL set, or only the example? Optionally pnpm prisma next db verify — does the live DB match the contract? Then say the contract path back to the user, with its role attached . Something like: "Your contract is at src/prisma/contract.prisma , and it currently declares a User model. The contract describes your app — every query type, migration, and runtime type the framework gives you flows from this file. Let's get your app connected to a database next." The exact wording is up to the agent; what matters is that the user leaves the first response knowing where the contract is and that it is the source of truth . Step 2 — Get the user's app connected and round tripping The motivation is "so your app can actually run against your database" , not "so the prerequisite checklist passes" . The mechanics depend on what's already in place from Step 1: Everything already wired. Go straight to writing and reading a row (see Your first arc — connect, write, read above). Adapt the snippet to whatever model the contract declares. DATABASE URL not set. Have the user set it in .env (not in prisma next.config.ts — see Pitfall 5). Then pnpm prisma next db init to apply the current contract to that database and write the marker row. Now the app can connect. Database is connectable but not yet aware of the contract (marker row missing; db verify reports drift). Run pnpm prisma next db init . ( db update is the alternative for quick dev cycles — it's looser, doesn't write a migration history, and is what

prisma-next-quickstart