diff --git a/.claude/skills/docs-writer/SKILL.md b/.claude/skills/docs-writer/SKILL.md
index 8a5c28a235..5deeb1c857 100644
--- a/.claude/skills/docs-writer/SKILL.md
+++ b/.claude/skills/docs-writer/SKILL.md
@@ -64,6 +64,7 @@ A how-to gets the reader through a task. Two other types come up often. Same voi
 - List every parameter with type, whether it's required, and the default.
 - Give one runnable example per entry.
 - No narrative. The reader is scanning, not reading.
+- Order options the way readers need them: the common case first, then selection and targeting, then advanced or CI-specific behavior.
 
 ## Improving an existing page
 
@@ -154,6 +155,27 @@ Delete these on sight. They add length, not clarity.
 - **Em dashes**. Use a comma, colon, or period instead.
 - **Hype**: don't sell inside docs. The reader already chose the product; they want it to work.
 
+## Don't write like a model
+
+Model-drafted docs share habits a reviewer can spot in one pass. None of these is wrong in isolation; their density is what gives a page a synthetic voice. Check for each before finishing.
+
+- **Frontmatter echo**: the body's first sentence repeats the frontmatter `description` almost verbatim. The description summarizes the page for cards and search results; the opening orients the reader. Write them differently, and define the product once, not once per metadata field.
+- **Contrast slogans**: "X, not Y" constructions ("injected, not discovered", "built for agents, not just terminals", "refuses to guess"). One per page at most. A page of balanced contrasts reads like ad copy; state the behavior plainly instead.
+- **Absolute stacking**: "never", "every", "nothing", "always", "cannot drift" piling up across a page. Each absolute is a promise the product has to keep. Keep the ones you can verify and that the reader needs; describe what happens rather than asserting what can't.
+- **Exception-packed sentences**: one sentence carrying the normal case, an exception, its reason, the alternative, and a safety condition, held together by semicolons. One idea per sentence: state the default first ("By default, the command uses…"), then the exception as its own sentence ("In CI or other headless environments, set…"). A semicolon joining distinct ideas is usually two sentences.
+- **Manager-voice openers**: "`service` manages services…", "handles", "manages everything around". Lead with the user action or outcome ("Use `service` commands to manage…") and use concrete verbs: creates, stores, uses, selects, targets, deploys, builds.
+- **Coined shorthand**: compressed phrases invented mid-page ("local pin", "pick a target") instead of saying what actually happens. Spell out the relationship, and keep one consistent user-facing vocabulary: service, project, configuration, deployment, credentials.
+- **Implementation language**: internal detail that doesn't help the reader act ("the root node is `<entry>`'s default export"). Translate it into the behavior they observe ("the application exported as the default export from `<entry>`").
+- **Buried caveats**: a warning folded into a trailing clause. Turn it into a direct instruction: "The deploy command does not build your application. Run your build command before deploying."
+- **Confusable state left implicit**: when two things could be mixed up (local state vs committed configuration), contrast them directly: what is local, what is committed, and what each is used for.
+- **Mid-clause links**: a link dropped between unrelated clauses. Introduce it after the context it supports: "See [Deploying](…) for details."
+- **Definition cascade**: a landing page that defines every noun in identical rhythm ("An application is… A service is… A branch is…"). Define a term where the reader first needs it. If a glossary earns its place, keep it short and hand off to a page that goes deeper.
+- **Prose restating code**: after a code block, narrating what each line does. Explain only what the code can't show: why, or a non-obvious consequence.
+- **Triad reflex**: three-part lists everywhere ("reviewable, repeatable, and versioned"). Vary list length; cut members that don't earn their place.
+- **Exhaustive nav dumps**: a "What to read next" that lists every sibling page in the same grammatical form. Pick the two or three pages this reader most likely needs next; the sidebar already lists everything.
+
+The same applies to PR descriptions for docs changes: write a short reviewer-facing summary of what changed and why, and put validation details (commands run, environments used) in a collapsed section. Don't paste the working session's log.
+
 ## Voice
 
 - Calm and direct. The reader is mid-task, not browsing a landing page.
@@ -169,4 +191,5 @@ Before you finish, check:
 - [ ] Does each step say what it does before showing the command?
 - [ ] Is there a way to verify success at the end?
 - [ ] Did you cut every phrase from "Cut the slop"?
+- [ ] Did you check the page against every pattern in "Don't write like a model"?
 - [ ] Are product names and limitations accurate?
diff --git a/apps/docs/content/docs/(index)/getting-started.mdx b/apps/docs/content/docs/(index)/getting-started.mdx
index 41b3e7f828..62115e2cd2 100644
--- a/apps/docs/content/docs/(index)/getting-started.mdx
+++ b/apps/docs/content/docs/(index)/getting-started.mdx
@@ -6,11 +6,11 @@ metaTitle: Prisma 7 getting started
 metaDescription: Choose the fastest Prisma 7 setup path. Quickstarts and existing-project guides for Prisma ORM 7, Prisma Postgres, and Prisma Compute, plus an agent prompt.
 ---
 
-Prisma 7 is the current generally available release of Prisma ORM, and `npx prisma@latest init` installs it. This page collects the Prisma 7 starting points: start a new project, add Prisma to an existing one, then deploy.
+Prisma 7 is the current generally available release of Prisma ORM. Install it with `npx prisma@latest init`. This page collects the Prisma 7 starting points: start a new project, add Prisma to an existing one, then deploy.
 
 :::note
 
-Starting a new project? [Prisma 8](/v8) is the recommended path for new apps. It is the next major version of Prisma ORM, now available as a Release Candidate. The [getting started page](/) covers it.
+Starting a new project? [Prisma 8](/v8) is the recommended path for new apps. It is the next major version of Prisma ORM, now available as a Release Candidate. To start with Prisma 8, see the [getting started page](/).
 
 :::
 
@@ -41,10 +41,10 @@ Once your app runs locally, [Prisma Compute](/compute) (currently in Public Beta
 
 1. Sign in with `npx @prisma/cli@latest auth login`.
 2. Run `npx @prisma/cli@latest app deploy` from your app directory to get a live URL, adding `--env .env` so environment variables like `DATABASE_URL` reach the deployment.
-3. `--env .env` applies to that one deployment. Persist variables for future deploys with `npx @prisma/cli@latest project env add --file .env --role production`; see [environment variables](/compute/environment-variables).
+3. `--env .env` applies to that one deployment. Persist variables for future deployments with `npx @prisma/cli@latest project env add --file .env --role production`. See [environment variables](/compute/environment-variables).
 4. Keep deploying from the CLI, or [connect GitHub](/compute/github) to deploy on push.
 
-The [deploy guide](/prisma-compute/deploy) covers build settings, frameworks, and troubleshooting.
+`app deploy` is part of the earlier beta CLI (`@prisma/cli@latest`). The Prisma 8 RC CLI (`prisma@next`) that the [Compute docs](/compute) describe deploys through a git push, the Console, or [Prisma Composer](/composer) instead. Both CLIs talk to the same platform. For the git-push path, follow the [deploy quickstart](/prisma-compute/deploy).
 
 ## Use with your agent
 
diff --git a/apps/docs/content/docs/(index)/index.mdx b/apps/docs/content/docs/(index)/index.mdx
index 33490815b2..8e28514a1f 100644
--- a/apps/docs/content/docs/(index)/index.mdx
+++ b/apps/docs/content/docs/(index)/index.mdx
@@ -51,7 +51,7 @@ If I have not told you which framework, stop and ask before scaffolding. Valid -
 
 1. Scaffold the app: `npx create-prisma@next create my-app --template [framework] --provider postgres --prisma-postgres --yes`. The `--prisma-postgres` flag provisions a Prisma Postgres database. If I give you a connection string, pass `--database-url "<url>"` instead of `--prisma-postgres`.
 2. From the project directory, apply the starter contract and seed: `npm run db:init`, then `npm run db:seed`. If seeding fails with `Cannot read properties of undefined (reading 'where')`, change `db.orm.User` to `db.orm.public.User` in `src/prisma/seed.ts`, `src/prisma/users.ts`, and any route files that query `db.orm`, then rerun.
-3. Edit the starter contract under `src/prisma/` into a small schema for my use case, then run `npm run contract:emit` and plan and apply the migration: `npx @prisma/cli@next migration plan`, then `npx @prisma/cli@next migrate --yes`. Migration planning diffs the emitted contract, so the emit step is required.
+3. Edit the starter contract under `src/prisma/` into a small schema for my use case, then run `npm run contract:emit` and plan and apply the migration: `npx prisma@next migration plan`, then `npx prisma@next migrate --yes`. Migration planning diffs the emitted contract, so the emit step is required.
 4. Update the seed script and the app routes to query the new schema, start `npm run dev` in the background, and verify with a request against the running app. For the `nest` template, if routes return 500s with `reading 'findAll'` in the logs, add explicit `@Inject()` tokens as shown in https://www.prisma.io/docs/guides/v8/frameworks/nestjs.md.
 5. Deploy with Prisma Compute. First apply the framework's deploy requirement from the guide at https://www.prisma.io/docs/guides/v8/frameworks/[guide].md, where [guide] is the template name except: template `next` → guide `nextjs`, `nest` → `nestjs`, `svelte` → `sveltekit`. The requirements: Next.js needs `output: "standalone"` in `next.config.ts` (without it the deployed app returns 504s), TanStack Start needs the nitro build plugin, Astro needs the `@astrojs/node` adapter plus `--env HOST=0.0.0.0`, and Elysia needs `--framework bun --entry src/index.ts` on the deploy command. If the template is `svelte`, skip this step; Compute does not support SvelteKit yet. Check `npx @prisma/cli@latest auth whoami`. If I am not signed in, stop and ask me to run `npx @prisma/cli@latest auth login`, because that step opens a browser. Then run `npx @prisma/cli@latest app deploy --create-project my-app --env .env` so DATABASE_URL reaches the deployment, and verify the deployed URL with curl.
 
@@ -79,7 +79,7 @@ If you're using Express or another Node.js server, follow the [existing-project
 
 </SectionRow>
 
-<SectionRow title="Using Prisma 7?" description="Prisma 7 is the current generally available release of Prisma ORM, fully supported, and `npx prisma@latest init` installs it. It pairs with Prisma Postgres and Prisma Compute the same way. When you're ready, Prisma 8 is the upgrade path.">
+<SectionRow title="Using Prisma 7?" description="Prisma 7 is the current generally available release of Prisma ORM and remains fully supported. Install it with `npx prisma@latest init`. It pairs with Prisma Postgres and Prisma Compute the same way. When you're ready, Prisma 8 is the upgrade path.">
 
 <IconGrid>
   <IconLink href="/getting-started" title="Prisma 7 setup paths" description="All database quickstarts, plus the agent prompt" icon={<Milestone />} />
@@ -107,9 +107,9 @@ Add Prisma 8 to this existing project.
 
 This flow is for PostgreSQL. If the project uses MongoDB, follow https://www.prisma.io/docs/v8/add-to-existing-project/mongodb.md instead; for other databases, stop and tell me.
 
-1. Run `npx @prisma/cli@next orm init`. It writes `prisma-next.config.ts`, a starter contract and `db.ts` under `src/prisma/`, and installs Prisma 8 skills for you.
+1. Run `npx prisma@next orm init`. It writes `prisma.config.ts`, a starter contract and `db.ts` under `src/prisma/`, and installs Prisma 8 skills for you.
 2. Set `DATABASE_URL` in `.env` to my database. If I did not give you one, create a Prisma Postgres database with `npx create-db@latest`, put its connection string in `.env`, and show me the claim URL it prints so I can keep the database.
-3. If the database already has tables, infer the contract from it: `npx @prisma/cli@next contract infer`, then `npx @prisma/cli@next contract emit`, then sign it with `npx @prisma/cli@next db sign`. If the database is empty, keep the starter contract and run `npx @prisma/cli@next db init`.
+3. If the database already has tables, infer the contract from it: `npx prisma@next contract infer`, then `npx prisma@next contract emit`, then sign it with `npx prisma@next db sign`. If the database is empty, keep the starter contract and run `npx prisma@next db init`.
 4. Write one query with the generated `db` client in an existing code path, run it, and show me the returned rows.
 
 Follow https://www.prisma.io/docs/v8/add-to-existing-project/postgresql.md and the installed Prisma 8 skills.
@@ -126,7 +126,7 @@ If I have not given you a connection string, stop and ask; do not invent one. Va
 
 1. Scaffold: `npx create-prisma@next create my-app --template [framework] --provider postgres --database-url "<my connection string>" --yes`.
 2. From the project directory: `npm run db:init`, then `npm run db:seed`, then start `npm run dev` in the background and verify the sample query returns data. If seeding fails with `Cannot read properties of undefined (reading 'where')`, change `db.orm.User` to `db.orm.public.User` in `src/prisma/seed.ts`, `src/prisma/users.ts`, and any route files that query `db.orm`, then rerun.
-3. Evolve the starter contract under `src/prisma/` into my schema, then run `npm run contract:emit`, `npx @prisma/cli@next migration plan`, and `npx @prisma/cli@next migrate --yes`.
+3. Evolve the starter contract under `src/prisma/` into my schema, then run `npm run contract:emit`, `npx prisma@next migration plan`, and `npx prisma@next migrate --yes`.
 
 Do not provision any hosted database. Use the installed Prisma 8 skills and https://www.prisma.io/docs/llms.txt for current docs.
 ```
@@ -179,7 +179,7 @@ Current docs: https://www.prisma.io/docs/prisma-compute/deploy.md.
 
 </AgentPrompt>
 
-If you're using MongoDB, follow the [MongoDB quickstart](/v8/quickstart/mongodb) or [add Prisma 8 to an existing MongoDB app](/v8/add-to-existing-project/mongodb). If you work with [Kysely](/prisma-postgres/quickstart/kysely), [Drizzle](/prisma-postgres/quickstart/drizzle-orm), or [TypeORM](/prisma-postgres/quickstart/typeorm), the Prisma Postgres quickstarts cover those tools.
+If you're using MongoDB, follow the [MongoDB quickstart](/v8/quickstart/mongodb) or [add Prisma 8 to an existing MongoDB app](/v8/add-to-existing-project/mongodb). If you work with [Kysely](/prisma-postgres/quickstart/kysely), [Drizzle](/prisma-postgres/quickstart/drizzle-orm), or [TypeORM](/prisma-postgres/quickstart/typeorm), follow the Prisma Postgres quickstart for that tool.
 
 </ModalRow>
 
diff --git a/apps/docs/content/docs/(index)/prisma-compute/deploy.mdx b/apps/docs/content/docs/(index)/prisma-compute/deploy.mdx
index 06c5142626..81fa3c0efd 100644
--- a/apps/docs/content/docs/(index)/prisma-compute/deploy.mdx
+++ b/apps/docs/content/docs/(index)/prisma-compute/deploy.mdx
@@ -13,13 +13,13 @@ This is a quickstart: sign in, connect, and ship. There are two ways in:
 - **To start fresh**, scaffold a new app with `create-prisma`. Follow [Option A](#option-a-scaffold-a-new-app-with-create-prisma).
 - **To deploy an app you already have**, connect its repository and push. Follow [Option B](#option-b-connect-a-project-you-already-have).
 
-Deployments on Compute come from a git push, the [Console](https://pris.ly/pdp), or [Prisma Composer](/composer); the CLI manages everything around them. To learn more about how Compute works, see the [resource model](/compute#the-model) for a mental model.
+Deployments on Compute start from a git push, the [Console](https://pris.ly/pdp), or [Prisma Composer](/composer). The CLI creates projects, connects repositories, and promotes or rolls back deployments. To learn how Compute works, see the [resource model](/compute#the-model).
 
 ## Prerequisites
 
 Before you start, make sure you have:
 
-- **A JavaScript runtime.** Node.js 22 or newer for `npx`/`pnpm dlx`, or Bun for `bunx`.
+- **A JavaScript runtime.** Node.js 22.18 or newer for `npx`/`pnpm dlx`, or Bun for `bunx`.
 - **A [Prisma Data Platform account](https://pris.ly/pdp).** Free to create, and it holds your workspace.
 - **An app in a GitHub repository, if you are bringing your own.** Compute builds **Next.js**, **Nuxt**, **Astro**, **Hono**, **NestJS**, **TanStack Start**, and plain **Bun** servers today, including **Elysia** (which runs on Bun). Skip this if you are scaffolding a new app below.
 
@@ -35,13 +35,13 @@ export default { output: "standalone" };
 
 ## 1. Sign in
 
-Sign in once. This is the only step that needs a human, because it opens your browser:
+Sign in once. This is the only interactive step, because it opens your browser:
 
 ```npm
-npx @prisma/cli@next auth login
+npx prisma@next auth login
 ```
 
-It stores a session on your machine that every later command reads automatically, including a coding agent working in your directory. Confirm it any time with `auth whoami`.
+Signing in stores a session on your machine. Every later command reads it automatically, including commands a coding agent runs in your directory. Confirm it any time with `auth whoami`.
 
 Two shortcuts from here:
 
@@ -73,15 +73,15 @@ Push the scaffolded app to a GitHub repository, then continue with [Option B](#o
 From your app's directory, describe the app, create a project, and connect the repository:
 
 ```npm
-npx @prisma/cli@next init
-npx @prisma/cli@next project create my-app
-npx @prisma/cli@next git connect
+npx prisma@next init
+npx prisma@next project create my-app
+npx prisma@next git connect
 ```
 
 What each step does:
 
-1. **`init` detects your framework** and writes `prisma.compute.ts`, the committed config the platform builds from. To choose the framework yourself, pass `--framework` (use `--framework bun --entry <server file>` for a Bun or Elysia server).
-2. **`project create` sets up a project** and pins this directory to it via `.prisma/local.json`, a gitignored local cache. If your team already has a project, run `project link` instead.
+1. **`init` detects your framework** and writes `prisma.compute.ts`, the committed configuration the platform builds from. To choose the framework yourself, pass `--framework` (use `--framework bun --entry <server file>` for a Bun or Elysia server).
+2. **`project create` creates a project** and records it in `.prisma/local.json`. This file is gitignored and only stores your local link, so it is not committed configuration. If your team already has a project, run `project link` instead.
 3. **`git connect` links the repository**, starting the GitHub App install flow if needed.
 
 Now push. Your default Git branch builds and deploys to production; every other branch gets its own isolated [preview](/compute/branching) with its own URL:
@@ -95,51 +95,51 @@ git push
 Confirm the service and its deployment, then open the live URL:
 
 ```npm
-npx @prisma/cli@next service show
-npx @prisma/cli@next service open
+npx prisma@next service show
+npx prisma@next service open
 ```
 
 `service show` prints the current deployment and its build id. If something looks wrong, stream the build's logs:
 
 ```npm
-npx @prisma/cli@next build logs <buildId> --follow
+npx prisma@next build logs <buildId> --follow
 ```
 
 You can also inspect everything in the [Console](https://pris.ly/pdp) instead of the terminal: projects, branches, services, deployments, integrations, and domains.
 
 ## 4. Ship changes
 
-Push again whenever you want to ship. Every push builds and deploys its branch: your default branch goes to production, and feature branches get isolated previews, so you can ship previews as often as you like without touching production.
+Push again whenever you want to ship. Every push builds and deploys its branch: your default branch goes to production, and feature branches get isolated previews. You can ship previews as often as you like without touching production.
 
 To manage what is live, promote a preview deployment to production (it rebuilds with production environment variables) or roll back to a known-good one:
 
 ```npm
-npx @prisma/cli@next service deployment promote dep_123
-npx @prisma/cli@next service deployment rollback
+npx prisma@next service deployment promote dep_123
+npx prisma@next service deployment rollback
 ```
 
 To learn more, see [Deployments](/compute/deployments).
 
 ## Hand it to your agent
 
-You can let a coding agent do the work. Sign in once yourself ([step 1](#1-sign-in)), because the browser step needs a human. After that, anything running in your environment inherits the session, including your agent. Paste this into your agent and fill in the blanks:
+You can let a coding agent do the work. Sign in once yourself ([step 1](#1-sign-in)). The browser sign-in is the one step an agent can't do for you. After that, anything running in your environment inherits the session, including your agent. Paste this into your agent and fill in the blanks:
 
 ```text
-Build [what you want] in [framework] and get it deployed to Prisma Compute using `npx @prisma/cli@next`.
+Build [what you want] in [framework] and get it deployed to Prisma Compute using `npx prisma@next`.
 
 Notes:
-- Before starting, run `npx @prisma/cli@next auth whoami`; if I am not signed in, stop and ask me to run `npx @prisma/cli@next auth login` (it opens a browser).
-- Run every CLI command as `npx @prisma/cli@next <command>`, and add `--json` for structured output; on errors, follow the `nextActions` the CLI returns.
+- Before starting, run `npx prisma@next auth whoami`; if I am not signed in, stop and ask me to run `npx prisma@next auth login` (it opens a browser).
+- Run every CLI command as `npx prisma@next <command>`, and add `--json` for structured output; on errors, follow the `nextActions` the CLI returns.
 - Compute supports Next.js, Nuxt, Astro, Hono, NestJS, TanStack Start, and plain Bun servers. If you build a Next.js app, set `output: "standalone"` in its config. For a Bun or Elysia server pass `--framework bun --entry <server file>` to `init`.
 - Set up with `init`, then `project create <name>`, then `git connect`; deploys happen on git push. Verify with `service show` and confirm the live URL responds with curl.
-- To give the app a database, create one with `npx @prisma/cli@next postgres create <name>` and set its connection string as an environment variable.
-- If the app needs config or secrets, scope them to the environment you are deploying: `npx @prisma/cli@next project env add KEY=value --role production` (or `--role preview`), then redeploy. Full scoping rules: https://www.prisma.io/docs/compute/environment-variables.md
+- To give the app a database, create one with `npx prisma@next postgres create <name>` and set its connection string as an environment variable.
+- If the app needs config or secrets, scope them to the environment you are deploying: `npx prisma@next project env add KEY=value --role production` (or `--role preview`), then redeploy. Full scoping rules: https://www.prisma.io/docs/compute/environment-variables.md
 ```
 
 For example:
 
 ```text
-Build a Hono API with a /todos endpoint backed by an in-memory list and get it deployed to Prisma Compute using `npx @prisma/cli@next`.
+Build a Hono API with a /todos endpoint backed by an in-memory list and get it deployed to Prisma Compute using `npx prisma@next`.
 ```
 
 The notes travel with the prompt, so your agent checks sign-in state, verifies the live URL, and scopes environment variables correctly. For the full scoping rules in the docs, see [Environment variables](/compute/environment-variables).
diff --git a/apps/docs/content/docs/(index)/v8/add-to-existing-project/mongodb.mdx b/apps/docs/content/docs/(index)/v8/add-to-existing-project/mongodb.mdx
index ff569d2064..df81df353c 100644
--- a/apps/docs/content/docs/(index)/v8/add-to-existing-project/mongodb.mdx
+++ b/apps/docs/content/docs/(index)/v8/add-to-existing-project/mongodb.mdx
@@ -6,7 +6,7 @@ metaTitle: Add Prisma 8 to an existing MongoDB project
 metaDescription: Add Prisma 8 to an existing MongoDB project.
 ---
 
-This guide shows how to add Prisma 8 to a project that already uses MongoDB. You will run `orm init`, describe the collections you want to work with, emit the generated artifacts, and run a couple of queries.
+To add Prisma 8 to a project that already uses MongoDB, you will run `orm init`, describe the collections you want to work with, emit the generated artifacts, and run a couple of queries.
 
 Use this path when you already have an application and database. Make sure the app can already reach its MongoDB deployment and runs on Node.js 24 or newer. If you want Prisma 8 to create a new app for you, use the [MongoDB quickstart](/v8/quickstart/mongodb).
 
@@ -37,7 +37,7 @@ Later, `orm init` will also add the Node.js types it needs and make sure the gen
 From the root of your existing project, run:
 
 ```npm
-npx @prisma/cli@next orm init --target mongodb
+npx prisma@next orm init --target mongodb
 ```
 
 This is the existing-project path. It preselects MongoDB, adds Prisma 8 files and package scripts to the app you already have, and does not scaffold a new framework project.
@@ -95,7 +95,7 @@ Once the contract looks right, this step turns it into the generated files the r
 Run:
 
 ```npm
-npx @prisma/cli@next contract emit
+npx prisma@next contract emit
 ```
 
 This refreshes `prisma/contract.json` and `prisma/contract.d.ts` so the runtime and query APIs are aligned with the contract you just reviewed.
@@ -170,7 +170,7 @@ npx tsx script.ts
 When you change `prisma/contract.prisma`, emit the contract again:
 
 ```npm
-npx @prisma/cli@next contract emit
+npx prisma@next contract emit
 ```
 
 You do not need a migration just to read collections that already exist. Use [migration plan](/cli/v8/migration-plan) when you want Prisma 8 to own a schema change.
diff --git a/apps/docs/content/docs/(index)/v8/add-to-existing-project/postgresql.mdx b/apps/docs/content/docs/(index)/v8/add-to-existing-project/postgresql.mdx
index 3322dbc8d6..70bce04943 100644
--- a/apps/docs/content/docs/(index)/v8/add-to-existing-project/postgresql.mdx
+++ b/apps/docs/content/docs/(index)/v8/add-to-existing-project/postgresql.mdx
@@ -6,7 +6,7 @@ metaTitle: Add Prisma 8 to an existing PostgreSQL project
 metaDescription: Add Prisma 8 to an existing PostgreSQL project.
 ---
 
-This guide shows how to add Prisma 8 to a project that already uses PostgreSQL. You will run `orm init`, infer a contract from the live schema, sign the database, and run a couple of queries.
+To add Prisma 8 to a project that already uses PostgreSQL, you will run `orm init`, infer a contract from the live schema, sign the database, and run a couple of queries.
 
 Use this path when you already have an application and database. Make sure the app can already reach its PostgreSQL database and runs on Node.js 24 or newer. If you want Prisma 8 to create a new app for you, use the [PostgreSQL quickstart](/v8/quickstart/postgresql).
 
@@ -35,7 +35,7 @@ Later, `orm init` will also add the Node.js types it needs and make sure the gen
 From the root of your existing project, run:
 
 ```npm
-npx @prisma/cli@next orm init --target postgres
+npx prisma@next orm init --target postgres
 ```
 
 This is the existing-project path. It preselects PostgreSQL, adds Prisma 8 files and package scripts to the app you already have, and does not scaffold a new framework project.
@@ -62,10 +62,10 @@ This step gives you a starting contract by reading the schema that already exist
 Run:
 
 ```npm
-npx @prisma/cli@next contract infer --output ./prisma/contract.prisma
+npx prisma@next contract infer --output ./prisma/contract.prisma
 ```
 
-This reads the live PostgreSQL schema and writes a first draft of `prisma/contract.prisma`.
+The command writes a first draft of `prisma/contract.prisma`.
 
 Open that file and review it before you go on. This is the moment to clean up model names, keep only the tables you want Prisma 8 to know about first, and make the file easier to read.
 
@@ -76,7 +76,7 @@ Once the contract looks right, this step turns it into the generated files the r
 After you are happy with the contract, run:
 
 ```npm
-npx @prisma/cli@next contract emit
+npx prisma@next contract emit
 ```
 
 This refreshes `prisma/contract.json` and `prisma/contract.d.ts` so the runtime and query APIs are aligned with the contract you just reviewed.
@@ -86,7 +86,7 @@ This refreshes `prisma/contract.json` and `prisma/contract.d.ts` so the runtime
 Record that the live database matches the emitted contract:
 
 ```npm
-npx @prisma/cli@next db sign
+npx prisma@next db sign
 ```
 
 This step matters in two common cases:
@@ -170,7 +170,7 @@ npx tsx script.ts
 When you change `prisma/contract.prisma`, emit the contract again:
 
 ```npm
-npx @prisma/cli@next contract emit
+npx prisma@next contract emit
 ```
 
 Use [db update](/cli/v8/db-update) for a direct development update, or [migration plan](/cli/v8/migration-plan) when you want a checked-in migration.
diff --git a/apps/docs/content/docs/(index)/v8/getting-started.mdx b/apps/docs/content/docs/(index)/v8/getting-started.mdx
index cc27ea611f..03a9292740 100644
--- a/apps/docs/content/docs/(index)/v8/getting-started.mdx
+++ b/apps/docs/content/docs/(index)/v8/getting-started.mdx
@@ -36,7 +36,7 @@ If I have not told you which framework, stop and ask before scaffolding. Valid -
 
 1. Scaffold the app: `npx create-prisma@next create my-app --template [framework] --provider postgres --prisma-postgres --yes`. The `--prisma-postgres` flag provisions a Prisma Postgres database. If I give you a connection string, pass `--database-url "<url>"` instead of `--prisma-postgres`.
 2. From the project directory, apply the starter contract and seed: `npm run db:init`, then `npm run db:seed`. If seeding fails with `Cannot read properties of undefined (reading 'where')`, change `db.orm.User` to `db.orm.public.User` in `src/prisma/seed.ts`, `src/prisma/users.ts`, and any route files that query `db.orm`, then rerun.
-3. Edit the starter contract under `src/prisma/` into a small schema for my use case, then run `npm run contract:emit` and plan and apply the migration: `npx @prisma/cli@next migration plan`, then `npx @prisma/cli@next migrate --yes`. Migration planning diffs the emitted contract, so the emit step is required.
+3. Edit the starter contract under `src/prisma/` into a small schema for my use case, then run `npm run contract:emit` and plan and apply the migration: `npx prisma@next migration plan`, then `npx prisma@next migrate --yes`. Migration planning diffs the emitted contract, so the emit step is required.
 4. Update the seed script and the app routes to query the new schema, start `npm run dev` in the background, and verify with a request against the running app. For the `nest` template, if routes return 500s with `reading 'findAll'` in the logs, add explicit `@Inject()` tokens as shown in https://www.prisma.io/docs/guides/v8/frameworks/nestjs.md.
 
 Use the installed Prisma 8 skills and the current Prisma docs: https://www.prisma.io/docs/llms.txt (append `.md` to any docs URL for a markdown version).
@@ -47,7 +47,7 @@ Use the installed Prisma 8 skills and the current Prisma docs: https://www.prism
 ## Add to an existing project
 
 ```npm
-npx @prisma/cli@next orm init
+npx prisma@next orm init
 ```
 
 <Cards>
@@ -66,9 +66,9 @@ Add Prisma 8 to this existing project.
 
 This flow is for PostgreSQL. If the project uses MongoDB, follow https://www.prisma.io/docs/v8/add-to-existing-project/mongodb.md instead; for other databases, stop and tell me.
 
-1. Run `npx @prisma/cli@next orm init`. It writes `prisma-next.config.ts`, a starter contract and `db.ts` under `src/prisma/`, and installs Prisma 8 skills for you.
+1. Run `npx prisma@next orm init`. It writes `prisma.config.ts`, a starter contract and `db.ts` under `src/prisma/`, and installs Prisma 8 skills for you.
 2. Set `DATABASE_URL` in `.env` to my database. If I did not give you one, create a Prisma Postgres database with `npx create-db@latest`, put its connection string in `.env`, and show me the claim URL it prints so I can keep the database.
-3. If the database already has tables, infer the contract from it: `npx @prisma/cli@next contract infer`, then `npx @prisma/cli@next contract emit`, then sign it with `npx @prisma/cli@next db sign`. If the database is empty, keep the starter contract and run `npx @prisma/cli@next db init`.
+3. If the database already has tables, infer the contract from it: `npx prisma@next contract infer`, then `npx prisma@next contract emit`, then sign it with `npx prisma@next db sign`. If the database is empty, keep the starter contract and run `npx prisma@next db init`.
 4. Write one query with the generated `db` client in an existing code path, run it, and show me the returned rows.
 
 Follow https://www.prisma.io/docs/v8/add-to-existing-project/postgresql.md and the installed Prisma 8 skills.
diff --git a/apps/docs/content/docs/(index)/v8/index.mdx b/apps/docs/content/docs/(index)/v8/index.mdx
index 845f05f2ad..aa457c63e8 100644
--- a/apps/docs/content/docs/(index)/v8/index.mdx
+++ b/apps/docs/content/docs/(index)/v8/index.mdx
@@ -8,7 +8,7 @@ badge: release-candidate
 hideSidebar: true
 ---
 
-Prisma 8 is a ground-up rebuild of Prisma ORM, covering the runtime, query APIs, migration flow, and project setup.
+Prisma 8 is a ground-up rebuild of Prisma ORM, from the runtime and query APIs to the migration flow and project setup.
 
 :::note[The Prisma 8 Release Candidate is available]
 
@@ -18,7 +18,7 @@ If you want to stay on the current generally available version of Prisma ORM, yo
 
 :::
 
-Prisma 8 is the recommended starting point for new projects: the new developer experience today, on the path to general availability.
+Prisma 8 is the recommended starting point for new projects.
 
 ```npm
 npx create-prisma@next
@@ -48,7 +48,7 @@ If I have not told you which framework, stop and ask before scaffolding. Valid -
 
 1. Scaffold the app: `npx create-prisma@next create my-app --template [framework] --provider postgres --prisma-postgres --yes`. The `--prisma-postgres` flag provisions a Prisma Postgres database. If I give you a connection string, pass `--database-url "<url>"` instead of `--prisma-postgres`.
 2. From the project directory, apply the starter contract and seed: `npm run db:init`, then `npm run db:seed`. If seeding fails with `Cannot read properties of undefined (reading 'where')`, change `db.orm.User` to `db.orm.public.User` in `src/prisma/seed.ts`, `src/prisma/users.ts`, and any route files that query `db.orm`, then rerun.
-3. Edit the starter contract under `src/prisma/` into a small schema for my use case, then run `npm run contract:emit` and plan and apply the migration: `npx @prisma/cli@next migration plan`, then `npx @prisma/cli@next migrate --yes`. Migration planning diffs the emitted contract, so the emit step is required.
+3. Edit the starter contract under `src/prisma/` into a small schema for my use case, then run `npm run contract:emit` and plan and apply the migration: `npx prisma@next migration plan`, then `npx prisma@next migrate --yes`. Migration planning diffs the emitted contract, so the emit step is required.
 4. Update the seed script and the app routes to query the new schema, start `npm run dev` in the background, and verify with a request against the running app. For the `nest` template, if routes return 500s with `reading 'findAll'` in the logs, add explicit `@Inject()` tokens as shown in https://www.prisma.io/docs/guides/v8/frameworks/nestjs.md.
 5. Deploy with Prisma Compute. First apply the framework's deploy requirement from the guide at https://www.prisma.io/docs/guides/v8/frameworks/[guide].md, where [guide] is the template name except: template `next` → guide `nextjs`, `nest` → `nestjs`, `svelte` → `sveltekit`. The requirements: Next.js needs `output: "standalone"` in `next.config.ts` (without it the deployed app returns 504s), TanStack Start needs the nitro build plugin, Astro needs the `@astrojs/node` adapter plus `--env HOST=0.0.0.0`, and Elysia needs `--framework bun --entry src/index.ts` on the deploy command. If the template is `svelte`, skip this step; Compute does not support SvelteKit yet. Check `npx @prisma/cli@latest auth whoami`. If I am not signed in, stop and ask me to run `npx @prisma/cli@latest auth login`, because that step opens a browser. Then run `npx @prisma/cli@latest app deploy --create-project my-app --env .env` so DATABASE_URL reaches the deployment, and verify the deployed URL with curl.
 
diff --git a/apps/docs/content/docs/(index)/v8/prisma-postgres/from-the-cli.mdx b/apps/docs/content/docs/(index)/v8/prisma-postgres/from-the-cli.mdx
index 02520afc7f..8e73f10dea 100644
--- a/apps/docs/content/docs/(index)/v8/prisma-postgres/from-the-cli.mdx
+++ b/apps/docs/content/docs/(index)/v8/prisma-postgres/from-the-cli.mdx
@@ -44,10 +44,10 @@ npm run dev
 If the app already exists, run Prisma 8 from the project root:
 
 ```npm
-npx @prisma/cli@next orm init
+npx prisma@next orm init
 ```
 
-Choose PostgreSQL, set `DATABASE_URL` to your Prisma Postgres connection string, and let init add `prisma-next.md`, package scripts, and the Prisma 8 skills for your coding agent. Then follow the [PostgreSQL existing-project guide](/v8/add-to-existing-project/postgresql).
+Choose PostgreSQL and set `DATABASE_URL` to your Prisma Postgres connection string. Init adds `prisma-next.md`, package scripts, and the Prisma 8 skills for your coding agent. Then follow the [PostgreSQL existing-project guide](/v8/add-to-existing-project/postgresql).
 
 ## Import an existing database
 
diff --git a/apps/docs/content/docs/(index)/v8/prisma-postgres/import-from-existing-database-mysql.mdx b/apps/docs/content/docs/(index)/v8/prisma-postgres/import-from-existing-database-mysql.mdx
index 6445ab88c0..a00af0ccf4 100644
--- a/apps/docs/content/docs/(index)/v8/prisma-postgres/import-from-existing-database-mysql.mdx
+++ b/apps/docs/content/docs/(index)/v8/prisma-postgres/import-from-existing-database-mysql.mdx
@@ -20,7 +20,7 @@ You need:
 
 ## 1. Create a Prisma Postgres database
 
-Create a Prisma Postgres database from Console or with the CLI. Copy the direct connection string; you will use it for the import and for `DATABASE_URL`.
+Create a Prisma Postgres database from Console or with the CLI. Copy the direct connection string. You will use it for the import and for `DATABASE_URL`.
 
 ## 2. Create a pgloader config
 
@@ -53,15 +53,15 @@ pgloader config.load
 From your app root, initialize Prisma 8:
 
 ```npm
-npx @prisma/cli@next orm init
+npx prisma@next orm init
 ```
 
 Choose PostgreSQL, set `DATABASE_URL` to the Prisma Postgres connection string, then infer and emit the contract:
 
 ```npm
-npx @prisma/cli@next contract infer --output ./prisma/contract.prisma
-npx @prisma/cli@next contract emit
-npx @prisma/cli@next db sign
+npx prisma@next contract infer --output ./prisma/contract.prisma
+npx prisma@next contract emit
+npx prisma@next db sign
 ```
 
 ## Next steps
diff --git a/apps/docs/content/docs/(index)/v8/prisma-postgres/import-from-existing-database-postgresql.mdx b/apps/docs/content/docs/(index)/v8/prisma-postgres/import-from-existing-database-postgresql.mdx
index 9b51aa82a1..9a2e12cec5 100644
--- a/apps/docs/content/docs/(index)/v8/prisma-postgres/import-from-existing-database-postgresql.mdx
+++ b/apps/docs/content/docs/(index)/v8/prisma-postgres/import-from-existing-database-postgresql.mdx
@@ -20,7 +20,7 @@ You need:
 
 ## 1. Create a Prisma Postgres database
 
-Create a Prisma Postgres database from Console or with the CLI. Copy the direct connection string; you will use it for the restore and for `DATABASE_URL`.
+Create a Prisma Postgres database from Console or with the CLI. Copy the direct connection string. You will use it for the restore and for `DATABASE_URL`.
 
 ## 2. Export from PostgreSQL
 
@@ -43,15 +43,15 @@ pg_restore -d "postgres://USER:PASSWORD@db.prisma.io:5432/postgres?sslmode=requi
 From your app root, initialize Prisma 8:
 
 ```npm
-npx @prisma/cli@next orm init
+npx prisma@next orm init
 ```
 
 Choose PostgreSQL, set `DATABASE_URL` to the Prisma Postgres connection string, then infer and emit the contract:
 
 ```npm
-npx @prisma/cli@next contract infer --output ./prisma/contract.prisma
-npx @prisma/cli@next contract emit
-npx @prisma/cli@next db sign
+npx prisma@next contract infer --output ./prisma/contract.prisma
+npx prisma@next contract emit
+npx prisma@next db sign
 ```
 
 ## Next steps
diff --git a/apps/docs/content/docs/(index)/v8/quickstart/postgresql.mdx b/apps/docs/content/docs/(index)/v8/quickstart/postgresql.mdx
index 8dd53b6f7c..6bc5c847bc 100644
--- a/apps/docs/content/docs/(index)/v8/quickstart/postgresql.mdx
+++ b/apps/docs/content/docs/(index)/v8/quickstart/postgresql.mdx
@@ -46,6 +46,12 @@ From the generated project directory, run `db:init` to apply the starter schema
 npm run db:init
 ```
 
+:::warning[Known issue in the current RC scaffold]
+
+The current `create-prisma@next` release scaffolds some imports under an outdated package name. If `db:init` (or the setup's own emit step) fails with `PN-CLI-4999: Failed to load config`, change `@prisma/orm-postgres/config` to `@prisma-next/postgres/config` in `prisma-next.config.ts` and `@prisma/orm-postgres` to `@prisma-next/postgres` in `src/prisma/db.ts`, then rerun. If a query later fails with `Cannot read properties of undefined`, address models through their schema namespace: `db.orm.public.User` instead of `db.orm.User`.
+
+:::
+
 ## 3. Seed data
 
 `db:seed` inserts sample users so the first query has data to show.
diff --git a/apps/docs/content/docs/ai/tools/skills.mdx b/apps/docs/content/docs/ai/tools/skills.mdx
index 4a2a5db9ac..c6e2326d44 100644
--- a/apps/docs/content/docs/ai/tools/skills.mdx
+++ b/apps/docs/content/docs/ai/tools/skills.mdx
@@ -7,13 +7,21 @@ metaDescription: 'Give your AI coding agent up-to-date Prisma knowledge with ins
 
 ---
 
-AI coding agents often struggle with Prisma 7 -they generate outdated v6 patterns, hallucinate APIs, and miss breaking changes like ESM-only support and required driver adapters. **Prisma Skills** fix this by giving your agent accurate, version-specific knowledge it can reference automatically.
+AI coding agents often struggle with Prisma: they generate outdated v6 patterns, hallucinate APIs, and miss breaking changes like ESM-only support and required driver adapters. **Prisma Skills** fix this by giving your agent accurate, version-specific knowledge it can reference automatically.
 
-Skills are packaged instructions that follow the open [Agent Skills](https://agentskills.io/) format. Once installed, your agent uses them whenever it detects a relevant task -no prompting required.
+Skills are packaged instructions that follow the open [Agent Skills](https://agentskills.io/) format. Once installed, your agent uses them whenever it detects a relevant task, no prompting required.
+
+Prisma ships skills from three repositories, matched to what you are building:
+
+| You are working with | Skills repository | Install command |
+| --- | --- | --- |
+| Prisma ORM v7, Prisma Postgres, Prisma Compute | [prisma/skills](https://github.com/prisma/skills) | `npx skills add prisma/skills` |
+| [Prisma 8](/orm/v8) | [prisma/prisma](https://github.com/prisma/prisma) (`skills/`) | `npx skills add prisma/prisma/skills` |
+| [Prisma Composer](/composer) | [prisma/composer](https://github.com/prisma/composer) (`skills/`) | `npx skills add prisma/composer` |
 
 ## Install
 
-Add all Prisma skills to your project:
+Add all skills from the main registry to your project:
 
 ```npm
 npx skills add prisma/skills
@@ -25,9 +33,11 @@ Or install only the ones you need:
 npx skills add prisma/skills --skill prisma-client-api
 ```
 
+If you use the Prisma 8 CLI, [`prisma agent install`](/cli/v8/agent) wraps the same registry: with no flags it installs every `prisma/skills` skill for Claude Code and Codex, and `agent status` shows what is installed.
+
 :::note
 
-Skills are compatible with any agent that supports the [Agent Skills](https://agentskills.io/) format, including Claude Code, Cursor, and others.
+Skills are compatible with any agent that supports the [Agent Skills](https://agentskills.io/) format, including Claude Code, Cursor, Codex, Windsurf, and others.
 
 :::
 
@@ -89,7 +99,7 @@ Covers `SqlDriverAdapter`, `Transaction`, savepoint hooks, argument and result m
 
 ## Available skills for Prisma 8
 
-[Prisma 8](/orm/v8) ships its own skills, versioned with the product. Projects scaffolded with `create-prisma` or [`orm init`](/cli/v8/init) install them automatically; add them to an existing project with:
+[Prisma 8](/orm/v8) ships its own skills from the [prisma/prisma](https://github.com/prisma/prisma) repository, versioned with the product. Projects scaffolded with `create-prisma` or [`orm init`](/cli/v8/init) install them automatically for every agent runtime the installer supports (Claude Code, Cursor, Codex, Windsurf); skip that step with `orm init --skip-skills`. Add them to an existing project with:
 
 ```npm
 npx skills add prisma/prisma/skills
@@ -101,8 +111,20 @@ npx skills add prisma/prisma/skills
 | `prisma-next-upgrade` | Move a project between Prisma 8 releases |
 | `prisma-8-extension-upgrade` | Upgrade extension packs alongside the core |
 
+The `prisma-8` usage skill describes the exact CLI and runtime surface of one release, so pin it to your installed version when adding it by hand: `npx skills add prisma/prisma/skills#v<your-version> --skill prisma-8`. The two upgrade skills are intentionally unpinned; the latest revision covers every prior transition. `orm init` applies this pinning for you.
+
 The Prisma 8 docs reference the `prisma-8` skill in each page's "Prompt your coding agent" section, with prompts that map to the page you are reading.
 
+## Available skills for Prisma Composer
+
+[Prisma Composer](/composer) ships one skill, `prisma-composer`, from the [prisma/composer](https://github.com/prisma/composer) repository:
+
+```npm
+npx skills add prisma/composer
+```
+
+It covers the whole Composer story: the mental model (Modules, `compute()`, `service.load()`), RPC contracts, databases, the first-party Modules for scheduled jobs, object storage, and event streams, config params and secrets, testing, and deploying with stages. Install it before your agent writes Composer code so it works from the current authoring API instead of inventing one.
+
 ## Useful commands
 
 List available skills before installing:
diff --git a/apps/docs/content/docs/cli/index.mdx b/apps/docs/content/docs/cli/index.mdx
index 5a6fcf51e3..8c0f639ab0 100644
--- a/apps/docs/content/docs/cli/index.mdx
+++ b/apps/docs/content/docs/cli/index.mdx
@@ -24,7 +24,7 @@ npm install prisma --save-dev
 
 :::info
 
-This page covers the Prisma 7 CLI that ships in the `prisma` package. Prisma 8 introduces a new, unified Prisma CLI that also covers [Prisma Composer](/composer) and [Prisma Compute](/compute); until launch it is published as `@prisma/cli@next`. See the [Prisma 8 CLI reference](/cli/v8), the [Composer CLI reference](/composer/cli-reference), and the [Prisma Compute CLI reference](/compute/cli-reference).
+This page documents the Prisma 7 CLI that ships in the `prisma` package. Prisma 8 introduces a new, unified Prisma CLI that also includes commands for [Prisma Composer](/composer) and [Prisma Compute](/compute). The Prisma 8 RC publishes it as `prisma@next`. See the [Prisma 8 CLI reference](/cli/v8), the [Composer CLI reference](/composer/cli-reference), and the [Prisma Compute CLI reference](/compute/cli-reference).
 
 :::
 
diff --git a/apps/docs/content/docs/cli/v8/agent.mdx b/apps/docs/content/docs/cli/v8/agent.mdx
new file mode 100644
index 0000000000..7fd1dcbad2
--- /dev/null
+++ b/apps/docs/content/docs/cli/v8/agent.mdx
@@ -0,0 +1,49 @@
+---
+title: agent
+description: Install Prisma skills for AI coding agents.
+url: /cli/v8/agent
+metaTitle: agent | Prisma 8 CLI
+metaDescription: Learn how to install and inspect Prisma agent skills with the unified Prisma CLI.
+---
+
+Use `agent` commands to install and inspect [Prisma agent skills](/ai/tools/skills): packaged instructions that give AI coding agents accurate, current knowledge of Prisma commands and APIs. The commands wrap the [`skills`](https://npmjs.com/package/skills) CLI and install from the [prisma/skills](https://github.com/prisma/skills) registry, which covers the Prisma CLI, Prisma Client, Prisma Postgres, Prisma Compute, and upgrade guides.
+
+## Usage
+
+```npm
+npx prisma@next agent install
+```
+
+With no flags, `agent install` installs every skill in the registry into the current project, for Claude Code and Codex. Narrow it with `--skill` and `--agent`:
+
+```npm
+npx prisma@next agent install --skill prisma-compute --agent claude-code
+```
+
+## Commands
+
+| Command         | Description                                                          |
+| --------------- | ---------------------------------------------------------------------- |
+| `agent install` | Install Prisma skills for coding agents                                |
+| `agent update`  | Refresh installed Prisma skills                                        |
+| `agent status`  | Show installed Prisma skills (`--global` checks globally installed skills instead of project skills) |
+
+`agent install` and `agent update` take:
+
+| Option | What it does |
+| --- | --- |
+| `--skill <skill>` | Skill to install; repeat for multiple. Default: every skill in the registry. |
+| `--agent <agent>` | Agent runtime to install for (for example `claude-code`, `codex`, `cursor`); repeat for multiple. Default: `claude-code` and `codex`. |
+| `--all-agents` | Install for every agent runtime the `skills` CLI supports. |
+| `--global` | Install into the user directory instead of the project. |
+| `--copy` | Copy skill files instead of symlinking them (always on for Windows). |
+| `--dry-run` | Show the changes without writing files. |
+
+## Skills from other sources
+
+`agent install` covers the `prisma/skills` registry. Two skill sets live with their own products instead:
+
+- **Prisma 8 skills** ([prisma/prisma](https://github.com/prisma/prisma)): installed automatically by [`orm init`](/cli/v8/init), or by hand with `npx skills add prisma/prisma/skills`.
+- **The Composer skill** ([prisma/composer](https://github.com/prisma/composer)): installed with `npx skills add prisma/composer`.
+
+See [Agent Skills](/ai/tools/skills) for the full catalog of what each skill teaches your agent.
diff --git a/apps/docs/content/docs/cli/v8/auth.mdx b/apps/docs/content/docs/cli/v8/auth.mdx
new file mode 100644
index 0000000000..77d9055044
--- /dev/null
+++ b/apps/docs/content/docs/cli/v8/auth.mdx
@@ -0,0 +1,29 @@
+---
+title: auth
+description: Sign in to your Prisma account from the CLI, sign out, and manage workspace sessions.
+url: /cli/v8/auth
+metaTitle: auth | Prisma 8 CLI
+metaDescription: Learn how to authenticate the unified Prisma CLI with your Prisma account and manage workspace sessions.
+---
+
+Use `auth` commands to manage authentication for the platform commands. Signing in opens a browser flow and stores a session. Every platform command in that environment reuses that session.
+
+## Usage
+
+```npm
+npx prisma@next auth login
+npx prisma@next auth whoami
+```
+
+## Commands
+
+| Command                          | Description                                          |
+| -------------------------------- | ---------------------------------------------------- |
+| `auth login`                     | Log in to your Prisma platform account (browser flow) |
+| `auth logout`                    | Clear stored authentication credentials               |
+| `auth whoami`                    | Show the authenticated user and accessible workspace  |
+| `auth workspace list`            | List your workspace sessions                          |
+| `auth workspace use [id-or-name]`| Make one of your workspace sessions current           |
+| `auth workspace logout <id-or-name>` | End one workspace session                        |
+
+`auth login` signs you in through the browser. Afterward, anything running in that environment inherits the session, including coding agents. For CI, set [`PRISMA_SERVICE_TOKEN`](/cli/v8/configuration#platform-environment-variables) instead.
diff --git a/apps/docs/content/docs/cli/v8/branch.mdx b/apps/docs/content/docs/cli/v8/branch.mdx
new file mode 100644
index 0000000000..fe7fab209b
--- /dev/null
+++ b/apps/docs/content/docs/cli/v8/branch.mdx
@@ -0,0 +1,21 @@
+---
+title: branch
+description: List platform branches for a project.
+url: /cli/v8/branch
+metaTitle: branch | Prisma 8 CLI
+metaDescription: Learn how to inspect Prisma platform branches with the unified Prisma CLI.
+---
+
+Use `branch` commands to inspect the platform branches of a project. The commands do not create anything on the platform. See [Branching](/compute/branching) for how platform branches work.
+
+## Usage
+
+```npm
+npx prisma@next branch list
+```
+
+## Commands
+
+| Command       | Description                                      |
+| ------------- | ------------------------------------------------- |
+| `branch list` | List platform branches for the linked project    |
diff --git a/apps/docs/content/docs/cli/v8/bucket.mdx b/apps/docs/content/docs/cli/v8/bucket.mdx
new file mode 100644
index 0000000000..300d652012
--- /dev/null
+++ b/apps/docs/content/docs/cli/v8/bucket.mdx
@@ -0,0 +1,27 @@
+---
+title: bucket
+description: Create and manage object-store buckets.
+url: /cli/v8/bucket
+metaTitle: bucket | Prisma 8 CLI
+metaDescription: Learn how to create and manage object-store buckets and their access keys with the unified Prisma CLI.
+---
+
+Use `bucket` commands to manage object-store buckets in a project.
+
+## Usage
+
+```npm
+npx prisma@next bucket list
+npx prisma@next bucket create --name my-bucket
+```
+
+## Commands
+
+| Command                     | Description                                  |
+| --------------------------- | --------------------------------------------- |
+| `bucket list`               | List object-store buckets                      |
+| `bucket create`             | Create an object-store bucket (`--name <name>` sets the display name, auto-generated if omitted) |
+| `bucket delete <bucket-id>` | Delete a bucket and all its access keys        |
+| `bucket key list <bucket-id>` | List access keys for a bucket                |
+| `bucket key create <bucket-id>` | Create a bucket access key and print its one-time credentials |
+| `bucket key delete <bucket-id> <key-id>` | Revoke and delete a bucket access key |
diff --git a/apps/docs/content/docs/cli/v8/build.mdx b/apps/docs/content/docs/cli/v8/build.mdx
new file mode 100644
index 0000000000..647147380c
--- /dev/null
+++ b/apps/docs/content/docs/cli/v8/build.mdx
@@ -0,0 +1,23 @@
+---
+title: build
+description: Stream logs for builds created by a git push or the Console.
+url: /cli/v8/build
+metaTitle: build | Prisma 8 CLI
+metaDescription: Learn how to inspect Prisma Compute builds and stream build logs with the unified Prisma CLI.
+---
+
+Use `build` commands to inspect builds created by a Git push or the [Console](https://pris.ly/pdp).
+
+## Usage
+
+```npm
+npx prisma@next build logs <buildId> --follow
+```
+
+## Commands
+
+| Command                | Description                                                                  |
+| ---------------------- | ----------------------------------------------------------------------------- |
+| `build logs <buildId>` | Stream logs for a build. `--follow` keeps streaming while the build runs. `--cursor <cursor>` resumes from a cursor a previous run reported |
+
+Builds are started by a push to a connected repository or from the Console, not by a CLI command. See [`git`](/cli/v8/git) for connecting a repository, and [Deployments](/compute/deployments) for how builds become deployments.
diff --git a/apps/docs/content/docs/cli/v8/configuration.mdx b/apps/docs/content/docs/cli/v8/configuration.mdx
index d1c749d04d..ead0217364 100644
--- a/apps/docs/content/docs/cli/v8/configuration.mdx
+++ b/apps/docs/content/docs/cli/v8/configuration.mdx
@@ -1,46 +1,52 @@
 ---
 title: CLI configuration
-description: Configure Prisma 8 CLI commands with prisma-next.config.ts and global flags.
+description: Configure Prisma 8 CLI commands with prisma.config.ts and global flags.
 url: /cli/v8/configuration
 metaTitle: Prisma 8 CLI configuration
 metaDescription: Learn how Prisma 8 CLI commands find config, read database URLs, and format output.
 ---
 
-Prisma 8 CLI commands use `prisma-next.config.ts` as the project entrypoint for contract emission, database operations, and migrations.
+Prisma 8 CLI commands read `prisma.config.ts` in your project root. The file has one section per part of the CLI. The Prisma 8 data commands read the `orm` section.
 
 ## Config file
 
-Commands that need project context read the Prisma 8 config from your project. For PostgreSQL projects, use the Postgres config helper:
+The outer `defineConfig` comes from `@prisma/cli-engine` and marks the file as a Prisma 8 CLI config. A Prisma 7 `prisma.config.ts` without that marker is rejected rather than misread. The `orm` section uses the config helper for your database. For PostgreSQL:
 
-```typescript title="prisma-next.config.ts"
+```typescript title="prisma.config.ts"
 import "dotenv/config";
-import { defineConfig } from "@prisma/orm-postgres/config";
+import { defineConfig } from "@prisma/cli-engine";
+import { defineConfig as ormConfig } from "@prisma/orm-postgres/config";
 
 export default defineConfig({
-  contract: "./prisma/contract.prisma",
-  db: {
-    connection: process.env["DATABASE_URL"]!,
-  },
+  orm: ormConfig({
+    contract: "./prisma/contract.prisma",
+    db: {
+      connection: process.env["DATABASE_URL"]!,
+    },
+  }),
 });
 ```
 
-For MongoDB projects, import `defineConfig` from `@prisma/orm-mongo/config` instead.
+For MongoDB projects, import the section helper from `@prisma/orm-mongo/config` instead.
 
-Pass `--config` when your config file is not in the default project location:
+[`orm init`](/cli/v8/init) writes this file for you. Pass `--config` when your config file is not at `./prisma.config.ts`:
 
 ```npm
-npx @prisma/cli@next contract emit --config ./config/prisma-next.config.ts
+npx prisma@next contract emit --config ./config/prisma.config.ts
 ```
 
 ## Emit-only config
 
-`contract emit` does not connect to a database, so the config can omit `db.connection`:
+`contract emit` does not connect to a database, so the `orm` section can omit `db.connection`:
 
-```typescript title="prisma-next.config.ts"
-import { defineConfig } from "@prisma/orm-postgres/config";
+```typescript title="prisma.config.ts"
+import { defineConfig } from "@prisma/cli-engine";
+import { defineConfig as ormConfig } from "@prisma/orm-postgres/config";
 
 export default defineConfig({
-  contract: "./prisma/contract.prisma",
+  orm: ormConfig({
+    contract: "./prisma/contract.prisma",
+  }),
 });
 ```
 
@@ -48,18 +54,21 @@ Add `db.connection` before running commands such as `db verify`, `db sign`, `db
 
 ## Extension packs
 
-Add extension control descriptors to the config when your contract uses extension-provided types:
+Add extension control descriptors to the `orm` section when your contract uses extension-provided types:
 
-```typescript title="prisma-next.config.ts"
-import { defineConfig } from "@prisma/orm-postgres/config";
+```typescript title="prisma.config.ts"
+import { defineConfig } from "@prisma/cli-engine";
+import { defineConfig as ormConfig } from "@prisma/orm-postgres/config";
 import pgvector from "@prisma/orm-extension-pgvector/control";
 
 export default defineConfig({
-  contract: "./prisma/contract.prisma",
-  extensions: [pgvector],
-  db: {
-    connection: process.env["DATABASE_URL"]!,
-  },
+  orm: ormConfig({
+    contract: "./prisma/contract.prisma",
+    extensions: [pgvector],
+    db: {
+      connection: process.env["DATABASE_URL"]!,
+    },
+  }),
 });
 ```
 
@@ -67,10 +76,10 @@ Re-run `contract emit` after changing extension packs, then update the matching
 
 ## Database URLs
 
-Database commands accept `--db <url>`. If you omit it, Prisma 8 can use the database connection from `prisma-next.config.ts`.
+Database commands accept `--db <url>`. If you omit it, Prisma 8 uses the database connection from `prisma.config.ts`.
 
 ```npm
-npx @prisma/cli@next db verify --db "$DATABASE_URL"
+npx prisma@next db verify --db "$DATABASE_URL"
 ```
 
 ## Environment variables
@@ -80,12 +89,35 @@ npx @prisma/cli@next db verify --db "$DATABASE_URL"
 | `DATABASE_URL` | Common place to store the database connection string used by config files and scripts. |
 | `NO_COLOR=1` | Disables colored terminal output. |
 
+## Platform environment variables
+
+The [platform commands](/cli/v8#platform-commands) read these:
+
+| Variable               | Description                                                        |
+| ---------------------- | ------------------------------------------------------------------- |
+| `PRISMA_SERVICE_TOKEN` | Authenticate without a browser, for CI. Takes priority over any stored session |
+| `PRISMA_WORKSPACE_ID`  | Workspace to target when authenticating with a service token         |
+| `PRISMA_PROJECT_ID`    | Override the project stored in `.prisma/local.json` (useful in CI)   |
+| `PRISMA_SERVICE_ID`    | Override the service selected in `prisma.compute.ts` (useful in CI) |
+
 ## Output modes
 
 Use the default text output when running commands locally. Use `--json` in CI or automation:
 
 ```npm
-npx @prisma/cli@next db verify --db "$DATABASE_URL" --json
+npx prisma@next db verify --db "$DATABASE_URL" --json
 ```
 
-Use `--no-interactive` for scripts that must never pause for user input, and `--confirm <token>` to grant a consent prompt non-interactively (for example, [`db update`](/cli/v8/db-update) asks for the database name before a destructive change).
+Use `--no-interactive` for scripts that must never pause for user input. Use `--confirm <token>` to grant a consent prompt non-interactively. For example, [`db update`](/cli/v8/db-update) asks for the database name before a destructive change.
+
+## JSON output
+
+In `--json` mode, commands emit newline-delimited JSON events. Progress events have `kind: "step-finished"`. The final event has `kind: "result"` and carries the `envelope` object your script branches on:
+
+- `envelope.ok`: `true` or `false`.
+- `envelope.result`: the command's data, when `ok` is `true`.
+- `envelope.error.code`: a dotted `NAMESPACE.SUBCODE`, for example `PROJECT.NOT_FOUND` or `SERVICE.PROJECT_SETUP_REQUIRED`.
+- `envelope.error.summary` and `envelope.error.why`: what failed and why it was rejected.
+- `envelope.nextActions`: machine-readable follow-up commands, so agents can drive the CLI.
+
+Branch on `envelope.error.code`, not the message text: codes are a stable contract, while message wording can change between releases.
diff --git a/apps/docs/content/docs/cli/v8/contract-emit.mdx b/apps/docs/content/docs/cli/v8/contract-emit.mdx
index e5f5cb97e8..3e0d76db0b 100644
--- a/apps/docs/content/docs/cli/v8/contract-emit.mdx
+++ b/apps/docs/content/docs/cli/v8/contract-emit.mdx
@@ -13,7 +13,7 @@ The command is offline. It does not need a database connection.
 ## Usage
 
 ```npm
-npx @prisma/cli@next contract emit
+npx prisma@next contract emit
 ```
 
 ## Options
@@ -21,7 +21,7 @@ npx @prisma/cli@next contract emit
 | Option | What it does |
 | --- | --- |
 | `--output-path <dir>` | Writes `contract.json` and `contract.d.ts` into a specific directory. |
-| `--config <path>` | Reads a specific `prisma-next.config.ts` file. |
+| `--config <path>` | Read this config file instead of `./prisma.config.ts`. |
 | `--json` | Prints a machine-readable result. |
 
 ## What it creates
@@ -36,9 +36,9 @@ Do not edit these files by hand. Re-run `contract emit` after changing the contr
 ## Examples
 
 ```npm
-npx @prisma/cli@next contract emit
-npx @prisma/cli@next contract emit --output-path ./generated
-npx @prisma/cli@next contract emit --json
+npx prisma@next contract emit
+npx prisma@next contract emit --output-path ./generated
+npx prisma@next contract emit --json
 ```
 
 ## Next steps
diff --git a/apps/docs/content/docs/cli/v8/contract-infer.mdx b/apps/docs/content/docs/cli/v8/contract-infer.mdx
index 9ce6c55495..dfad83e0d4 100644
--- a/apps/docs/content/docs/cli/v8/contract-infer.mdx
+++ b/apps/docs/content/docs/cli/v8/contract-infer.mdx
@@ -13,7 +13,7 @@ Use it when you are adding Prisma 8 to an existing database and want an initial
 ## Usage
 
 ```npm
-npx @prisma/cli@next contract infer --db "$DATABASE_URL"
+npx prisma@next contract infer --db "$DATABASE_URL"
 ```
 
 ## Options
@@ -22,15 +22,15 @@ npx @prisma/cli@next contract infer --db "$DATABASE_URL"
 | --- | --- |
 | `--db <url>` | Connects to the database. |
 | `--output <path>` | Writes the inferred PSL contract to a specific path. |
-| `--config <path>` | Reads a specific `prisma-next.config.ts` file. |
+| `--config <path>` | Read this config file instead of `./prisma.config.ts`. |
 | `--json` | Prints a machine-readable result. |
 
 ## Examples
 
 ```npm
-npx @prisma/cli@next contract infer --db "$DATABASE_URL"
-npx @prisma/cli@next contract infer --db "$DATABASE_URL" --output ./prisma/contract.prisma
-npx @prisma/cli@next contract infer --db "$DATABASE_URL" --json
+npx prisma@next contract infer --db "$DATABASE_URL"
+npx prisma@next contract infer --db "$DATABASE_URL" --output ./prisma/contract.prisma
+npx prisma@next contract infer --db "$DATABASE_URL" --json
 ```
 
 ## What to review
@@ -43,12 +43,12 @@ Inference gives you a starting point, not a finished design. Review:
 - defaults, indexes, and constraints
 - extension-backed column types
 
-The command stops at `contract.prisma`; follow it with the emit and sign steps:
+The command stops at `contract.prisma`. Follow it with the emit and sign steps:
 
 ```npm
-npx @prisma/cli@next contract emit
-npx @prisma/cli@next db sign --db "$DATABASE_URL"
-npx @prisma/cli@next db verify --db "$DATABASE_URL"
+npx prisma@next contract emit
+npx prisma@next db sign --db "$DATABASE_URL"
+npx prisma@next db verify --db "$DATABASE_URL"
 ```
 
 `db sign` is the handoff point where you record that the existing database matches the reviewed contract.
diff --git a/apps/docs/content/docs/cli/v8/db-init.mdx b/apps/docs/content/docs/cli/v8/db-init.mdx
index c835126bfb..11f1538900 100644
--- a/apps/docs/content/docs/cli/v8/db-init.mdx
+++ b/apps/docs/content/docs/cli/v8/db-init.mdx
@@ -8,12 +8,12 @@ metaDescription: Learn how to create missing database structures from a Prisma 8
 
 `db init` bootstraps a database to match the current emitted contract and signs it.
 
-It creates everything the contract declares and the database does not have yet, using additive operations only. Structures already in place and compatible are left alone, and a conflict that would need a destructive change stops the run.
+It creates everything the contract declares and the database does not have yet, using additive operations only. Structures already in place and compatible are left alone. A conflict that would need a destructive change stops the run.
 
 ## Usage
 
 ```npm
-npx @prisma/cli@next db init --db "$DATABASE_URL"
+npx prisma@next db init --db "$DATABASE_URL"
 ```
 
 ## Options
@@ -23,7 +23,7 @@ npx @prisma/cli@next db init --db "$DATABASE_URL"
 | `--db <url>` | Connects to the database. |
 | `--dry-run` | Shows planned operations without applying them. |
 | `--advance-ref <name>` | Advances the named [ref](/cli/v8/migration-ref) to the post-command contract hash. |
-| `--config <path>` | Reads a specific `prisma-next.config.ts` file. |
+| `--config <path>` | Read this config file instead of `./prisma.config.ts`. |
 | `--json` | Prints a machine-readable result. |
 
 ## Behavior
@@ -33,19 +33,19 @@ npx @prisma/cli@next db init --db "$DATABASE_URL"
 Run a dry run first when you are not working with a disposable local database:
 
 ```npm
-npx @prisma/cli@next db init --db "$DATABASE_URL" --dry-run
+npx prisma@next db init --db "$DATABASE_URL" --dry-run
 ```
 
 ## Examples
 
 ```npm
-npx @prisma/cli@next contract emit
-npx @prisma/cli@next db init --db "$DATABASE_URL"
-npx @prisma/cli@next db verify --db "$DATABASE_URL"
+npx prisma@next contract emit
+npx prisma@next db init --db "$DATABASE_URL"
+npx prisma@next db verify --db "$DATABASE_URL"
 ```
 
 ```npm
-npx @prisma/cli@next db init --db "$DATABASE_URL" --dry-run --json
+npx prisma@next db init --db "$DATABASE_URL" --dry-run --json
 ```
 
 ## When to use db update instead
diff --git a/apps/docs/content/docs/cli/v8/db-schema.mdx b/apps/docs/content/docs/cli/v8/db-schema.mdx
index c68cb5ecd1..a731768743 100644
--- a/apps/docs/content/docs/cli/v8/db-schema.mdx
+++ b/apps/docs/content/docs/cli/v8/db-schema.mdx
@@ -13,7 +13,7 @@ Use it when you need to inspect what Prisma 8 sees in the database before inferr
 ## Usage
 
 ```npm
-npx @prisma/cli@next db schema --db "$DATABASE_URL"
+npx prisma@next db schema --db "$DATABASE_URL"
 ```
 
 ## Options
@@ -21,14 +21,14 @@ npx @prisma/cli@next db schema --db "$DATABASE_URL"
 | Option | What it does |
 | --- | --- |
 | `--db <url>` | Connects to the database. |
-| `--config <path>` | Reads a specific `prisma-next.config.ts` file. |
+| `--config <path>` | Read this config file instead of `./prisma.config.ts`. |
 | `--json` | Prints machine-readable schema output. |
 
 ## Examples
 
 ```npm
-npx @prisma/cli@next db schema --db "$DATABASE_URL"
-npx @prisma/cli@next db schema --db "$DATABASE_URL" --json > schema.json
+npx prisma@next db schema --db "$DATABASE_URL"
+npx prisma@next db schema --db "$DATABASE_URL" --json > schema.json
 ```
 
 ## Related commands
diff --git a/apps/docs/content/docs/cli/v8/db-sign.mdx b/apps/docs/content/docs/cli/v8/db-sign.mdx
index a239e5bb9b..fa97783617 100644
--- a/apps/docs/content/docs/cli/v8/db-sign.mdx
+++ b/apps/docs/content/docs/cli/v8/db-sign.mdx
@@ -13,7 +13,7 @@ It is idempotent and safe to run in CI or a deployment pipeline. Use it after im
 ## Usage
 
 ```npm
-npx @prisma/cli@next db sign --db "$DATABASE_URL"
+npx prisma@next db sign --db "$DATABASE_URL"
 ```
 
 ## Options
@@ -22,8 +22,8 @@ npx @prisma/cli@next db sign --db "$DATABASE_URL"
 | --- | --- |
 | `[contract]` | Signs against a specific contract reference (hash, prefix, ref name, or migration directory name) instead of the emitted contract. |
 | `--db <url>` | Connects to the database. |
-| `--contract <contract>` | Same as the positional argument, as a flag. |
-| `--config <path>` | Reads a specific `prisma-next.config.ts` file. |
+| `--contract <contract>` | The contract reference as a flag. Also accepts the `<dir>^` and `./path` forms that the positional argument does not. |
+| `--config <path>` | Read this config file instead of `./prisma.config.ts`. |
 | `--json` | Prints a machine-readable result. |
 
 ## Exit codes
@@ -37,9 +37,9 @@ npx @prisma/cli@next db sign --db "$DATABASE_URL"
 ## Example
 
 ```npm
-npx @prisma/cli@next contract emit
-npx @prisma/cli@next db sign --db "$DATABASE_URL"
-npx @prisma/cli@next db verify --db "$DATABASE_URL"
+npx prisma@next contract emit
+npx prisma@next db sign --db "$DATABASE_URL"
+npx prisma@next db verify --db "$DATABASE_URL"
 ```
 
 ## When to use it
diff --git a/apps/docs/content/docs/cli/v8/db-update.mdx b/apps/docs/content/docs/cli/v8/db-update.mdx
index 4361e1ea78..271ce3a264 100644
--- a/apps/docs/content/docs/cli/v8/db-update.mdx
+++ b/apps/docs/content/docs/cli/v8/db-update.mdx
@@ -13,7 +13,7 @@ Use it for direct reconciliation when you do not need a checked-in migration pac
 ## Usage
 
 ```npm
-npx @prisma/cli@next db update --db "$DATABASE_URL"
+npx prisma@next db update --db "$DATABASE_URL"
 ```
 
 ## Options
@@ -24,24 +24,24 @@ npx @prisma/cli@next db update --db "$DATABASE_URL"
 | `--dry-run` | Shows planned operations without applying them. |
 | `--to <contract>` | Updates to a specific contract (hash, prefix, ref name, migration directory name, or `./path`). |
 | `--advance-ref <name>` | Advances the named [ref](/cli/v8/migration-ref) to the post-command contract hash. |
-| `--config <path>` | Reads a specific `prisma-next.config.ts` file. |
+| `--config <path>` | Read this config file instead of `./prisma.config.ts`. |
 | `--json` | Prints a machine-readable result. |
 
 ## Destructive changes need consent
 
-An operation that would destroy data is applied only with your consent: the command asks you to type the database name. A run with nobody to ask, such as a CI job or a run with `--no-interactive`, takes the consent from `--confirm <database>` instead:
+An operation that would destroy data is applied only with your consent: the command asks you to type the database name. In a CI job or a run with `--no-interactive`, where the command cannot ask, pass the consent as `--confirm <database>` instead:
 
 ```npm
-npx @prisma/cli@next db update --db "$DATABASE_URL" --no-interactive --confirm appdb
+npx prisma@next db update --db "$DATABASE_URL" --no-interactive --confirm appdb
 ```
 
 ## Recommended flow
 
 ```npm
-npx @prisma/cli@next contract emit
-npx @prisma/cli@next db update --db "$DATABASE_URL" --dry-run
-npx @prisma/cli@next db update --db "$DATABASE_URL"
-npx @prisma/cli@next db verify --db "$DATABASE_URL"
+npx prisma@next contract emit
+npx prisma@next db update --db "$DATABASE_URL" --dry-run
+npx prisma@next db update --db "$DATABASE_URL"
+npx prisma@next db verify --db "$DATABASE_URL"
 ```
 
 Use `--dry-run` before applying changes in shared environments.
diff --git a/apps/docs/content/docs/cli/v8/db-verify.mdx b/apps/docs/content/docs/cli/v8/db-verify.mdx
index ed7e09cfe8..19c6ecab90 100644
--- a/apps/docs/content/docs/cli/v8/db-verify.mdx
+++ b/apps/docs/content/docs/cli/v8/db-verify.mdx
@@ -13,7 +13,7 @@ Use it in CI and deployment checks before application code that depends on a con
 ## Usage
 
 ```npm
-npx @prisma/cli@next db verify --db "$DATABASE_URL"
+npx prisma@next db verify --db "$DATABASE_URL"
 ```
 
 ## Options
@@ -24,7 +24,7 @@ npx @prisma/cli@next db verify --db "$DATABASE_URL"
 | `--marker-only` | Checks only the database marker. |
 | `--schema-only` | Checks only whether the live schema satisfies the contract. |
 | `--strict` | Fails if the database includes schema elements not present in the contract. |
-| `--config <path>` | Reads a specific `prisma-next.config.ts` file. |
+| `--config <path>` | Read this config file instead of `./prisma.config.ts`. |
 | `--json` | Prints machine-readable output. |
 
 ## Exit codes
@@ -38,16 +38,16 @@ npx @prisma/cli@next db verify --db "$DATABASE_URL"
 ## Examples
 
 ```npm
-npx @prisma/cli@next db verify --db "$DATABASE_URL"
-npx @prisma/cli@next db verify --db "$DATABASE_URL" --strict
-npx @prisma/cli@next db verify --db "$DATABASE_URL" --schema-only
-npx @prisma/cli@next db verify --db "$DATABASE_URL" --marker-only
+npx prisma@next db verify --db "$DATABASE_URL"
+npx prisma@next db verify --db "$DATABASE_URL" --strict
+npx prisma@next db verify --db "$DATABASE_URL" --schema-only
+npx prisma@next db verify --db "$DATABASE_URL" --marker-only
 ```
 
 Use JSON output in automation:
 
 ```npm
-npx @prisma/cli@next db verify --db "$DATABASE_URL" --json
+npx prisma@next db verify --db "$DATABASE_URL" --json
 ```
 
 ## What failures mean
diff --git a/apps/docs/content/docs/cli/v8/feedback.mdx b/apps/docs/content/docs/cli/v8/feedback.mdx
new file mode 100644
index 0000000000..8b10deeb7e
--- /dev/null
+++ b/apps/docs/content/docs/cli/v8/feedback.mdx
@@ -0,0 +1,17 @@
+---
+title: feedback
+description: Send feedback to the Prisma CLI team.
+url: /cli/v8/feedback
+metaTitle: feedback | Prisma 8 CLI
+metaDescription: Learn how to send feedback to the Prisma CLI team straight from the terminal.
+---
+
+`feedback` sends feedback to the Prisma CLI team, straight from the terminal.
+
+## Usage
+
+```npm
+npx prisma@next feedback "The service logs command saved my afternoon"
+```
+
+The message can be up to 4000 characters. Feedback is anonymous unless you add `--email <address>` so the team can reply.
diff --git a/apps/docs/content/docs/cli/v8/git.mdx b/apps/docs/content/docs/cli/v8/git.mdx
new file mode 100644
index 0000000000..736f011cbf
--- /dev/null
+++ b/apps/docs/content/docs/cli/v8/git.mdx
@@ -0,0 +1,22 @@
+---
+title: git
+description: Connect a GitHub repository for push-to-deploy.
+url: /cli/v8/git
+metaTitle: git | Prisma 8 CLI
+metaDescription: Learn how to connect and disconnect a GitHub repository for Prisma Compute push-to-deploy with the unified Prisma CLI.
+---
+
+Use `git` commands to manage the GitHub repository connection. See [GitHub integration](/compute/github).
+
+## Usage
+
+```npm
+npx prisma@next git connect
+```
+
+## Commands
+
+| Command                  | Description                                                      |
+| ------------------------ | ----------------------------------------------------------------- |
+| `git connect [git-url]`  | Connect the linked project to a GitHub repository. Starts the GitHub App install flow if needed |
+| `git disconnect`         | Stop push-triggered automation. Keeps the project and existing branches |
diff --git a/apps/docs/content/docs/cli/v8/index.mdx b/apps/docs/content/docs/cli/v8/index.mdx
index 6199731c6e..69c5f00207 100644
--- a/apps/docs/content/docs/cli/v8/index.mdx
+++ b/apps/docs/content/docs/cli/v8/index.mdx
@@ -7,7 +7,7 @@ metaDescription: Learn the Prisma 8 CLI commands for contracts, databases, migra
 badge: release-candidate
 ---
 
-Prisma 8 ships with a new, unified Prisma CLI. One binary covers the whole platform: the Prisma 8 data workflow (contracts, databases, migrations), [Prisma Composer](/composer), [Prisma Compute](/compute) deploys, and workspace management. This page covers the Prisma 8 data commands; see the [Composer CLI reference](/composer/cli-reference) and the [Compute CLI reference](/compute/cli-reference) for the rest.
+Prisma 8 ships with a new, unified Prisma CLI. One binary contains the commands for the whole platform: the Prisma 8 data workflow (contracts, databases, migrations), [Prisma Composer](/composer), [Prisma Compute](/compute), and workspace management. This page describes the Prisma 8 data commands and lists where the rest are documented.
 
 :::note[The Prisma 8 Release Candidate is available]
 
@@ -17,14 +17,14 @@ If you want to stay on the current generally available version of Prisma ORM, yo
 
 :::
 
-Until launch, the unified CLI is published as the `next` tag of the `@prisma/cli` package. Run it without installing:
+The Prisma 8 RC CLI is the `next` tag of the `prisma` package. Run it without installing:
 
 ```npm
-npx @prisma/cli@next help
-npx @prisma/cli@next contract emit
+npx prisma@next --help
+npx prisma@next contract emit
 ```
 
-At launch these commands move to the `prisma` package, and the invocations become `prisma contract emit` and so on.
+At general availability these commands become plain `prisma contract emit` and so on.
 
 For a full app scaffold, use a [Prisma 8 quickstart](/v8/quickstart/postgresql). That path creates the project files and package scripts for you. This CLI reference is for the lower-level commands those scripts call.
 
@@ -33,31 +33,31 @@ For a full app scaffold, use a [Prisma 8 quickstart](/v8/quickstart/postgresql).
 Start in an existing project:
 
 ```npm
-npx @prisma/cli@next orm init --target postgres --authoring psl
-npx @prisma/cli@next contract emit
-npx @prisma/cli@next db init --db "$DATABASE_URL"
+npx prisma@next orm init --target postgres --authoring psl
+npx prisma@next contract emit
+npx prisma@next db init --db "$DATABASE_URL"
 ```
 
 Adopt an existing database:
 
 ```npm
-npx @prisma/cli@next contract infer --db "$DATABASE_URL" --output ./prisma/contract.prisma
-npx @prisma/cli@next contract emit
-npx @prisma/cli@next db sign --db "$DATABASE_URL"
-npx @prisma/cli@next db verify --db "$DATABASE_URL"
+npx prisma@next contract infer --db "$DATABASE_URL" --output ./prisma/contract.prisma
+npx prisma@next contract emit
+npx prisma@next db sign --db "$DATABASE_URL"
+npx prisma@next db verify --db "$DATABASE_URL"
 ```
 
 Use checked-in migrations:
 
 ```npm
-npx @prisma/cli@next contract emit
-npx @prisma/cli@next migration plan --name add-users
-npx @prisma/cli@next migration status --db "$DATABASE_URL"
-npx @prisma/cli@next migrate --db "$DATABASE_URL"
-npx @prisma/cli@next db verify --db "$DATABASE_URL"
+npx prisma@next contract emit
+npx prisma@next migration plan --name add-users
+npx prisma@next migration status --db "$DATABASE_URL"
+npx prisma@next migrate --db "$DATABASE_URL"
+npx prisma@next db verify --db "$DATABASE_URL"
 ```
 
-## Command groups
+## Data commands
 
 | Command | Purpose |
 | --- | --- |
@@ -78,7 +78,27 @@ npx @prisma/cli@next db verify --db "$DATABASE_URL"
 | `format` | Format your PSL contract source in place. |
 | `lsp` | Start the Prisma 8 language server (spawned by editors, not run interactively). |
 
-The `migration` group also has read-only inspection commands without dedicated pages yet: `migration list` (on-disk migrations per contract space), `migration log` (executed history from the database ledger), `migration graph` (graph topology, with `--dot` for Graphviz output), and `migration check` (artifact and graph integrity). Run any of them with `--help` for the details.
+The `migration` group also has read-only inspection commands without dedicated pages yet: `migration list` (on-disk migrations per contract space; `--space`, `--ascii`, `--legend`), `migration log` (executed history from the database ledger; `--db`, `--utc`, `--ascii`), `migration graph` (graph topology; `--space`, `--dot` for Graphviz output, `--ascii`, `--legend`), and `migration check [target]` (artifact and graph integrity; `--space`). Run any of them with `--help` for the details.
+
+## Platform commands
+
+The same binary carries the platform command groups. Each group has its own page in this section, except `composer`, which is documented on the [Composer CLI reference](/composer/cli-reference):
+
+| Command group | Purpose |
+| --- | --- |
+| [`auth`](/cli/v8/auth) | Sign in to your Prisma account from the CLI, sign out, and check who you are signed in as. |
+| [`init`](/cli/v8/platform-init) | Write a committed compute config for the app in the current directory. |
+| [`project`](/cli/v8/project) | Create, link, and inspect projects, and manage project environment variables. |
+| [`service`](/cli/v8/service) | Manage Compute services, their deployments, logs, and custom domains. |
+| [`build`](/cli/v8/build) | Stream logs for builds created by a git push or the Console. |
+| [`git`](/cli/v8/git) | Connect a GitHub repository for push-to-deploy. |
+| [`branch`](/cli/v8/branch) | List platform branches for a project. |
+| [`postgres`](/cli/v8/postgres) | Create and manage Prisma Postgres databases. |
+| [`bucket`](/cli/v8/bucket) | Create and manage object-store buckets. |
+| [`composer`](/composer/cli-reference) | Run and deploy applications composed from Prisma modules. |
+| [`agent`](/cli/v8/agent) | Install Prisma skills for AI coding agents. |
+| [`telemetry`](/cli/v8/telemetry) | Show, enable, or disable anonymous CLI telemetry. |
+| [`feedback`](/cli/v8/feedback) | Send feedback to the Prisma CLI team. |
 
 ## Global flags
 
@@ -95,6 +115,8 @@ All commands accept these flags.
 | `--interactive` / `--no-interactive` | Force prompts on or off. |
 | `-y`, `--yes` | Accept prompt defaults without asking. |
 | `--confirm <token>` | Grant a consent prompt non-interactively by typing its token (repeatable). |
-| `--config <path>` | Read a specific config file. |
+| `--config <path>` | Read this config file instead of `./prisma.config.ts`. |
+| `-h`, `--help` | Print help for a command. |
+| `--version` | Print the CLI version and exit. |
 
-Use `npx @prisma/cli@next <command> --help` when you need the exact command help from the installed version.
+Use `npx prisma@next <command> --help` when you need the exact command help from the installed version.
diff --git a/apps/docs/content/docs/cli/v8/init.mdx b/apps/docs/content/docs/cli/v8/init.mdx
index 0fdcd32f7e..08f6a3cbe7 100644
--- a/apps/docs/content/docs/cli/v8/init.mdx
+++ b/apps/docs/content/docs/cli/v8/init.mdx
@@ -15,13 +15,13 @@ Use a [Prisma 8 quickstart](/v8/quickstart/postgresql) when you want a complete
 Run it interactively for a guided setup:
 
 ```npm
-npx @prisma/cli@next orm init
+npx prisma@next orm init
 ```
 
 Or supply `--target` and `--authoring` for a fully scriptable run (CI, AI coding agents, automation):
 
 ```npm
-npx @prisma/cli@next orm init --yes --target postgres --authoring psl
+npx prisma@next orm init --yes --target postgres --authoring psl
 ```
 
 ## Options
@@ -35,25 +35,27 @@ npx @prisma/cli@next orm init --yes --target postgres --authoring psl
 | `--probe-db` | Connects to `DATABASE_URL` once and checks the server version. |
 | `--strict-probe` | Treats a failed database probe as fatal. |
 | `--skip-install` | Skips dependency installation and contract emission. |
-| `--skip-skills` | Skips the Prisma 8 agent-skill install. |
+| `--skip-skills` | Skips installing the [Prisma 8 agent skills](/ai/tools/skills) (the version-pinned `prisma-8` usage skill plus the upgrade skills). |
 | `--keep-previous-facade` | Keeps the previous target package in `package.json` when switching targets. |
 
 ## What it creates
 
 The exact files depend on the target and authoring style, but a Postgres PSL setup normally includes:
 
-- `prisma-next.config.ts`
-- a starter contract file such as `prisma/contract.prisma`
+- `prisma.config.ts`
+- a starter contract file such as `src/prisma/contract.prisma`
 - emitted contract artifacts after installation runs
-- a runtime client file that imports `contract.json`
-- package scripts for contract emission and database commands
+- a runtime client file (`src/prisma/db.ts`) that imports `contract.json`
+- `.env.example`, `tsconfig.json`, and updated `package.json`
+
+The runtime files are ES modules. If your `package.json` declares `"type": "commonjs"`, `orm init` keeps it and prints a warning. Set `"type": "module"` so the scaffolded `db.ts` loads.
 
 ## Examples
 
 ```npm
-npx @prisma/cli@next orm init --yes --target postgres --authoring psl
-npx @prisma/cli@next orm init --yes --target mongodb --authoring typescript --json
-npx @prisma/cli@next orm init --skip-install
+npx prisma@next orm init --yes --target postgres --authoring psl
+npx prisma@next orm init --yes --target mongodb --authoring typescript --json
+npx prisma@next orm init --skip-install
 ```
 
 ## After initialization
@@ -61,12 +63,14 @@ npx @prisma/cli@next orm init --skip-install
 Review the generated files, set `DATABASE_URL`, and emit the contract when you change the schema:
 
 ```npm
-npx @prisma/cli@next contract emit
+npx prisma@next contract emit
 ```
 
 Then initialize or verify the database:
 
 ```npm
-npx @prisma/cli@next db init --db "$DATABASE_URL"
-npx @prisma/cli@next db verify --db "$DATABASE_URL"
+npx prisma@next db init --db "$DATABASE_URL"
+npx prisma@next db verify --db "$DATABASE_URL"
 ```
+
+The scaffolded `db.ts` reads `DATABASE_URL` from the process environment at runtime. The CLI loads `.env` through the config file, but your own scripts do not. Run them with the variable set, for example `node --env-file=.env src/index.ts`.
diff --git a/apps/docs/content/docs/cli/v8/meta.json b/apps/docs/content/docs/cli/v8/meta.json
index 45954c42b9..dd68a6dfdc 100644
--- a/apps/docs/content/docs/cli/v8/meta.json
+++ b/apps/docs/content/docs/cli/v8/meta.json
@@ -27,6 +27,21 @@
     "migration-apply",
     "migration-status",
     "migration-show",
-    "migration-ref"
+    "migration-ref",
+
+    "---Platform commands---",
+    "auth",
+    "platform-init",
+    "project",
+    "service",
+    "build",
+    "git",
+    "branch",
+    "postgres",
+    "bucket",
+    "[composer](/composer/cli-reference)",
+    "agent",
+    "telemetry",
+    "feedback"
   ]
 }
diff --git a/apps/docs/content/docs/cli/v8/migration-apply.mdx b/apps/docs/content/docs/cli/v8/migration-apply.mdx
index f280e6a4dc..4ea8b82531 100644
--- a/apps/docs/content/docs/cli/v8/migration-apply.mdx
+++ b/apps/docs/content/docs/cli/v8/migration-apply.mdx
@@ -6,14 +6,14 @@ metaTitle: migrate | Prisma 8 CLI
 metaDescription: Learn how to apply pending Prisma 8 on-disk migrations with the migrate command.
 ---
 
-`migrate` applies pending on-disk migrations to advance the database. It walks every contract space (app and extensions) and applies migrations in canonical order: extensions alphabetically, then the app. It replays the on-disk migration graph and never invents an edge.
+`migrate` applies pending on-disk migrations to advance the database. It walks every contract space (app and extensions) and applies migrations in canonical order: extensions alphabetically, then the app. It applies only the migrations that exist on disk and never generates new operations.
 
 Use it from a controlled deployment step after reviewing migration packages.
 
 ## Usage
 
 ```npm
-npx @prisma/cli@next migrate --db "$DATABASE_URL"
+npx prisma@next migrate --db "$DATABASE_URL"
 ```
 
 ## Options
@@ -24,17 +24,17 @@ npx @prisma/cli@next migrate --db "$DATABASE_URL"
 | `--to <contract>` | Applies migrations up to a target contract (hash, prefix, ref name, migration directory name, `<dir>^`, or `./path`). |
 | `--advance-ref <name>` | Advances the named [ref](/cli/v8/migration-ref) to the post-apply marker after success. |
 | `--show` | Previews the migration route without applying (read-only). |
-| `--from <contract>` | Sets the from-state for the `--show` preview. |
-| `--config <path>` | Reads a specific `prisma-next.config.ts` file. |
+| `--from <contract>` | Sets the from-state for the `--show` preview: `@contract` (the emitted contract), `@db` (the database's current marker), a hash, a ref name, or a migration directory. |
+| `--config <path>` | Read this config file instead of `./prisma.config.ts`. |
 | `--json` | Prints a machine-readable result. |
 
 ## Recommended flow
 
 ```npm
-npx @prisma/cli@next migration status --db "$DATABASE_URL"
-npx @prisma/cli@next migrate --db "$DATABASE_URL"
-npx @prisma/cli@next migration status --db "$DATABASE_URL"
-npx @prisma/cli@next db verify --db "$DATABASE_URL"
+npx prisma@next migration status --db "$DATABASE_URL"
+npx prisma@next migrate --db "$DATABASE_URL"
+npx prisma@next migration status --db "$DATABASE_URL"
+npx prisma@next db verify --db "$DATABASE_URL"
 ```
 
 Run `migration status` before and after applying migrations to see what changed.
@@ -44,8 +44,8 @@ Run `migration status` before and after applying migrations to see what changed.
 `--show` prints the route `migrate` would take without touching the database:
 
 ```npm
-npx @prisma/cli@next migrate --show
-npx @prisma/cli@next migrate --show --from @contract --to production
+npx prisma@next migrate --show
+npx prisma@next migrate --show --from @contract --to production
 ```
 
 ## Applying to a target
@@ -53,7 +53,7 @@ npx @prisma/cli@next migrate --show --from @contract --to production
 If your project uses named [refs](/cli/v8/migration-ref), apply up to a target ref:
 
 ```npm
-npx @prisma/cli@next migrate --db "$DATABASE_URL" --to production
+npx prisma@next migrate --db "$DATABASE_URL" --to production
 ```
 
 Manage refs with [`ref`](/cli/v8/migration-ref).
diff --git a/apps/docs/content/docs/cli/v8/migration-new.mdx b/apps/docs/content/docs/cli/v8/migration-new.mdx
index 086ac86b87..e9579408a6 100644
--- a/apps/docs/content/docs/cli/v8/migration-new.mdx
+++ b/apps/docs/content/docs/cli/v8/migration-new.mdx
@@ -8,12 +8,12 @@ metaDescription: Learn how to scaffold a manual Prisma 8 migration package.
 
 `migration new` creates a migration package with a `migration.ts` file for manual authoring.
 
-Use it when the generated plan is not enough and you want to write the migration operations yourself. The command is offline; it does not consult the database.
+Use it when the generated plan is not enough and you want to write the migration operations yourself. The command is offline. It does not consult the database.
 
 ## Usage
 
 ```npm
-npx @prisma/cli@next migration new --name split-name
+npx prisma@next migration new --name split-name
 ```
 
 ## Options
@@ -22,19 +22,19 @@ npx @prisma/cli@next migration new --name split-name
 | --- | --- |
 | `--name <slug>` | Sets the migration directory name suffix. |
 | `--from <hash>` | Sets the starting contract hash. Defaults to the latest migration target. |
-| `--config <path>` | Reads a specific `prisma-next.config.ts` file. |
+| `--config <path>` | Read this config file instead of `./prisma.config.ts`. |
 | `--json` | Prints a machine-readable result. |
 
 ## Examples
 
 ```npm
-npx @prisma/cli@next migration new --name split-name
-npx @prisma/cli@next migration new --name custom-fk --from abc123
+npx prisma@next migration new --name split-name
+npx prisma@next migration new --name custom-fk --from abc123
 ```
 
 ## After scaffolding
 
-Write the migration body in `migration.ts`, then run the file with Node to self-emit `ops.json` and attest the package:
+Write the migration body in `migration.ts`, then run the file with Node so it emits `ops.json` and attests the package:
 
 ```bash
 node migration.ts
@@ -43,13 +43,13 @@ node migration.ts
 Inspect the result:
 
 ```npm
-npx @prisma/cli@next migration show <migration-dir>
+npx prisma@next migration show <migration-dir>
 ```
 
 Apply the migration only after review:
 
 ```npm
-npx @prisma/cli@next migrate --db "$DATABASE_URL"
+npx prisma@next migrate --db "$DATABASE_URL"
 ```
 
 Manual migrations should still end at a contract state that matches the emitted contract.
diff --git a/apps/docs/content/docs/cli/v8/migration-plan.mdx b/apps/docs/content/docs/cli/v8/migration-plan.mdx
index 77c53591da..00b08a0299 100644
--- a/apps/docs/content/docs/cli/v8/migration-plan.mdx
+++ b/apps/docs/content/docs/cli/v8/migration-plan.mdx
@@ -13,7 +13,7 @@ The command is offline. It does not need a database connection.
 ## Usage
 
 ```npm
-npx @prisma/cli@next migration plan --name add-users-table
+npx prisma@next migration plan --name add-users-table
 ```
 
 ## Options
@@ -23,15 +23,15 @@ npx @prisma/cli@next migration plan --name add-users-table
 | `--name <slug>` | Sets the migration directory name suffix. |
 | `--from <contract>` | Uses a specific starting contract reference (hash, prefix, ref name, migration directory name, `<dir>^`, or `./path`) instead of the latest migration target. |
 | `--to <contract>` | Sets the destination contract reference. Defaults to the emitted contract. Same grammar as `--from`. |
-| `--config <path>` | Reads a specific `prisma-next.config.ts` file. |
+| `--config <path>` | Read this config file instead of `./prisma.config.ts`. |
 | `--json` | Prints a machine-readable result. |
 
 ## Recommended flow
 
 ```npm
-npx @prisma/cli@next contract emit
-npx @prisma/cli@next migration plan --name add-users-table
-npx @prisma/cli@next migration show <migration-dir>
+npx prisma@next contract emit
+npx prisma@next migration plan --name add-users-table
+npx prisma@next migration show <migration-dir>
 ```
 
 Review the generated migration package before applying it with [`migrate`](/cli/v8/migration-apply).
@@ -41,7 +41,7 @@ Review the generated migration package before applying it with [`migrate`](/cli/
 Because `--to` accepts `<dir>^` (the source contract of a migration), you can plan a migration that walks back a change:
 
 ```npm
-npx @prisma/cli@next migration plan --to <migration-dir>^ --name rollback
+npx prisma@next migration plan --to <migration-dir>^ --name rollback
 ```
 
 ## When to use migration plan
diff --git a/apps/docs/content/docs/cli/v8/migration-ref.mdx b/apps/docs/content/docs/cli/v8/migration-ref.mdx
index 0e2b966560..4bda79198a 100644
--- a/apps/docs/content/docs/cli/v8/migration-ref.mdx
+++ b/apps/docs/content/docs/cli/v8/migration-ref.mdx
@@ -6,16 +6,16 @@ metaTitle: ref | Prisma 8 CLI
 metaDescription: Learn how to set, list, and delete named Prisma 8 contract refs.
 ---
 
-`ref` manages named refs stored with your migration history. A ref lets a logical environment name, such as `staging` or `production`, resolve to a contract hash, so commands can target it by name: [`migrate --to production`](/cli/v8/migration-apply), [`db update --to production`](/cli/v8/db-update), or [`db sign production`](/cli/v8/db-sign).
+Use `ref` commands to manage named refs stored with your migration history. A ref maps a logical environment name, such as `staging` or `production`, to a contract hash. Other commands can then target that environment by name: [`migrate --to production`](/cli/v8/migration-apply), [`db update --to production`](/cli/v8/db-update), or [`db sign production`](/cli/v8/db-sign).
 
-Refs live on disk as `migrations/app/refs/<name>.json`, so they are versioned with your migrations. The commands are offline; the contract a ref points at must already be a node of the on-disk migration graph.
+Refs live on disk as `migrations/app/refs/<name>.json`, so they are versioned with your migrations. The commands are offline. The contract a ref points at must already be part of the on-disk migration graph.
 
 ## Usage
 
 ```npm
-npx @prisma/cli@next ref set production 4cb4256
-npx @prisma/cli@next ref list
-npx @prisma/cli@next ref delete production
+npx prisma@next ref set production 4cb4256
+npx prisma@next ref list
+npx prisma@next ref delete production
 ```
 
 ## Subcommands
@@ -24,14 +24,14 @@ npx @prisma/cli@next ref delete production
 | --- | --- |
 | `set <name> <contract>` | Points a ref at a contract. The contract is a hash or prefix, another ref name, a migration directory name, or `<dir>^` for that migration's source contract. |
 | `list` | Lists every ref with the contract hash it points at and the invariants recorded against it. |
-| `delete <name>` | Deletes a ref. The contract it pointed at is untouched; a ref is a pointer. |
+| `delete <name>` | Deletes a ref. The contract it pointed at is untouched. |
 
 ## Example workflow
 
 ```npm
-npx @prisma/cli@next ref set production 20260101T1000_add_user
-npx @prisma/cli@next migration status --db "$DATABASE_URL" --to production
-npx @prisma/cli@next migrate --db "$DATABASE_URL" --to production
+npx prisma@next ref set production 20260101T1000_add_user
+npx prisma@next migration status --db "$DATABASE_URL" --to production
+npx prisma@next migrate --db "$DATABASE_URL" --to production
 ```
 
-Use refs when environments need named targets instead of always applying to the latest migration on disk. Several commands can also move a ref forward for you after they succeed, via `--advance-ref <name>`.
+Use refs when environments need named targets instead of always applying to the latest migration on disk. Several commands can also move a ref forward for you after they succeed when you pass `--advance-ref <name>`.
diff --git a/apps/docs/content/docs/cli/v8/migration-show.mdx b/apps/docs/content/docs/cli/v8/migration-show.mdx
index e666a39a7f..1a7558377d 100644
--- a/apps/docs/content/docs/cli/v8/migration-show.mdx
+++ b/apps/docs/content/docs/cli/v8/migration-show.mdx
@@ -8,12 +8,12 @@ metaDescription: Learn how to inspect Prisma 8 migration operations, statements,
 
 `migration show` displays the operations, statement preview, and metadata for one migration package.
 
-Use this command during review before applying a migration package. The command is offline; it does not consult the database.
+Use this command during review before applying a migration package. The command is offline. It does not consult the database.
 
 ## Usage
 
 ```npm
-npx @prisma/cli@next migration show <target>
+npx prisma@next migration show <target>
 ```
 
 ## Options
@@ -21,16 +21,16 @@ npx @prisma/cli@next migration show <target>
 | Argument or option | What it does |
 | --- | --- |
 | `<target>` | The migration to inspect: a directory name, a hash or hash prefix, a ref, or a path. |
-| `--config <path>` | Reads a specific `prisma-next.config.ts` file. |
+| `--config <path>` | Read this config file instead of `./prisma.config.ts`. |
 | `--json` | Prints a machine-readable result. |
 
 ## Examples
 
 ```npm
-npx @prisma/cli@next migration show 20260101_100000_add_user
-npx @prisma/cli@next migration show a1b2c3
-npx @prisma/cli@next migration show migrations/app/20260101_100000_add_user
-npx @prisma/cli@next migration show 20260101_100000_add_user --json
+npx prisma@next migration show 20260101_100000_add_user
+npx prisma@next migration show a1b2c3
+npx prisma@next migration show migrations/app/20260101_100000_add_user
+npx prisma@next migration show 20260101_100000_add_user --json
 ```
 
 ## What to check
@@ -40,4 +40,4 @@ Before applying, review:
 - the source and destination contract hashes
 - the planned operations
 - generated SQL statements or operation payloads
-- any extension-space migrations included with the application migration
+- the migration's metadata
diff --git a/apps/docs/content/docs/cli/v8/migration-status.mdx b/apps/docs/content/docs/cli/v8/migration-status.mdx
index ebf0dd340d..c98f5d7d7a 100644
--- a/apps/docs/content/docs/cli/v8/migration-status.mdx
+++ b/apps/docs/content/docs/cli/v8/migration-status.mdx
@@ -13,7 +13,7 @@ Use it before and after [`migrate`](/cli/v8/migration-apply), and when debugging
 ## Usage
 
 ```npm
-npx @prisma/cli@next migration status --db "$DATABASE_URL"
+npx prisma@next migration status --db "$DATABASE_URL"
 ```
 
 ## Options
@@ -23,19 +23,19 @@ npx @prisma/cli@next migration status --db "$DATABASE_URL"
 | `--db <url>` | Connects to the database. |
 | `--space <id>` | Narrows output to a single contract space. |
 | `--to <contract>` | Sets the target contract reference (hash, prefix, ref name, migration directory name, `<dir>^`, or `./path`). |
-| `--from <contract>` | Sets the origin contract reference. Supplying it switches to offline path computation, with no database needed. |
+| `--from <contract>` | Sets the origin contract reference. With `--from`, the command computes the path offline and does not need a database. |
 | `--legend` | Prints a key for the tree glyphs and lane colors. |
 | `--ascii` | Uses ASCII glyphs (pipe-friendly). |
-| `--config <path>` | Reads a specific `prisma-next.config.ts` file. |
+| `--config <path>` | Read this config file instead of `./prisma.config.ts`. |
 | `--json` | Prints a machine-readable result. |
 
 ## Examples
 
 ```npm
-npx @prisma/cli@next migration status --db "$DATABASE_URL"
-npx @prisma/cli@next migration status --to production
-npx @prisma/cli@next migration status --from abc123 --to production
-npx @prisma/cli@next migration status --ascii
+npx prisma@next migration status --db "$DATABASE_URL"
+npx prisma@next migration status --to production
+npx prisma@next migration status --from abc123 --to production
+npx prisma@next migration status --ascii
 ```
 
 ## Reading the result
diff --git a/apps/docs/content/docs/cli/v8/platform-init.mdx b/apps/docs/content/docs/cli/v8/platform-init.mdx
new file mode 100644
index 0000000000..9fa066b5d6
--- /dev/null
+++ b/apps/docs/content/docs/cli/v8/platform-init.mdx
@@ -0,0 +1,33 @@
+---
+title: init
+description: Write a committed compute config for the app in the current directory.
+url: /cli/v8/platform-init
+metaTitle: init | Prisma 8 CLI
+metaDescription: Learn how the init command writes the committed Prisma Compute config for an app in the unified Prisma CLI.
+---
+
+`init` writes the committed compute config for the current directory. It detects your framework and writes `prisma.compute.ts` (or, with `--config-format json`, a dependency-free `prisma.compute.json`). The [`service` commands](/cli/v8/service) read this file for service targets, framework, entry point, HTTP port, and region.
+
+To add Prisma 8 ORM files to a project instead, use [`orm init`](/cli/v8/init).
+
+## Usage
+
+```npm
+npx prisma@next init
+```
+
+## Options
+
+| Flag                         | Description                                                          |
+| ---------------------------- | --------------------------------------------------------------------- |
+| `--framework <framework>`    | Framework to use. Detected when omitted (`nextjs`, `nuxt`, `astro`, `hono`, `nestjs`, `tanstack-start`, `custom`, `bun`) |
+| `--entry <path>`             | Source entrypoint for entrypoint frameworks (Bun, Hono)                |
+| `--http-port <port>`         | HTTP port the app listens on                                           |
+| `--region <region>`          | Region used when a deploy creates the service (`us-east-1`, `us-west-1`, `eu-west-3`, `eu-central-1`, `ap-northeast-1`, `ap-southeast-1`) |
+| `--name <app-name>`          | App name                                                               |
+| `--link` / `--no-link`       | Link this directory to a project, or skip that step                    |
+| `--project <id-or-name>`     | Project to link this directory to                                      |
+| `--install` / `--no-install` | Install `@prisma/compute-sdk` for config types, or skip that step      |
+| `--config-format <ts\|json>` | `ts` (default) writes `prisma.compute.ts`. `json` writes `prisma.compute.json` |
+
+For what goes in the config file and how builds read it, see [Compute configuration](/compute/configuration).
diff --git a/apps/docs/content/docs/cli/v8/postgres.mdx b/apps/docs/content/docs/cli/v8/postgres.mdx
new file mode 100644
index 0000000000..fab9e13a5e
--- /dev/null
+++ b/apps/docs/content/docs/cli/v8/postgres.mdx
@@ -0,0 +1,32 @@
+---
+title: postgres
+description: Create and manage Prisma Postgres databases.
+url: /cli/v8/postgres
+metaTitle: postgres | Prisma 8 CLI
+metaDescription: Learn how to create and manage Prisma Postgres databases, connections, and backups with the unified Prisma CLI.
+---
+
+Use `postgres` commands to manage [Prisma Postgres](/postgres) databases in a project. Most commands let you target a specific project with `--project <id-or-name>` and a branch with `--branch <git-name>`.
+
+## Usage
+
+```npm
+npx prisma@next postgres list
+npx prisma@next postgres create mydb
+```
+
+## Commands
+
+| Command                                    | Description                                                    |
+| ------------------------------------------ | --------------------------------------------------------------- |
+| `postgres list`                            | List databases                                                   |
+| `postgres show <database>`                 | Show database metadata without secret values                     |
+| `postgres create <name>`                   | Create a database and print its one-time connection URL. `--region` sets the Prisma Postgres region |
+| `postgres usage <database>`                | Show usage metrics for a database                                |
+| `postgres restore <database>`              | Restore from a backup, after exact id confirmation               |
+| `postgres remove <database>`               | Remove a database, after exact id confirmation                   |
+| `postgres backup list <database>`          | List platform-created backups for a database                     |
+| `postgres connection list <database>`      | List a database's connections                                    |
+| `postgres connection create <database>`    | Create a database connection and print its one-time connection URL |
+| `postgres connection rotate <connection-id>` | Rotate connection credentials and print the new one-time connection URL |
+| `postgres connection remove <connection-id>` | Remove a database connection, after exact id confirmation      |
diff --git a/apps/docs/content/docs/cli/v8/project.mdx b/apps/docs/content/docs/cli/v8/project.mdx
new file mode 100644
index 0000000000..84a95cc89e
--- /dev/null
+++ b/apps/docs/content/docs/cli/v8/project.mdx
@@ -0,0 +1,47 @@
+---
+title: project
+description: Create, link, and inspect projects; manage project environment variables.
+url: /cli/v8/project
+metaTitle: project | Prisma 8 CLI
+metaDescription: Learn how to manage Prisma platform projects, directory bindings, and project environment variables with the unified Prisma CLI.
+---
+
+Use `project` commands to create, link, and inspect projects, and to manage project environment variables.
+
+## Usage
+
+```npm
+npx prisma@next project list
+npx prisma@next project show
+```
+
+## Commands
+
+| Command                        | Description                                                  |
+| ------------------------------ | ------------------------------------------------------------- |
+| `project list`                 | List all projects in your workspace                            |
+| `project show`                 | Show the project this directory is linked to                   |
+| `project create <name>`        | Create a project and link the directory to it (`--region <region>` sets the Prisma Compute region) |
+| `project link [id-or-name]`    | Link the directory to an existing project                      |
+| `project rename <name>`        | Rename the linked project                                      |
+| `project remove <id-or-name>`  | Remove a project permanently, after exact id confirmation      |
+| `project transfer <id-or-name>`| Transfer a project to another workspace, after exact id confirmation |
+
+When you link a project, Prisma writes the selected workspace and project to `.prisma/local.json`. This file is gitignored and only stores your local link, so it should not be treated as committed configuration.
+
+Committed configuration lives in `prisma.compute.ts` or `prisma.compute.json`. The [`init`](/cli/v8/platform-init) command creates this configuration, and the [`service` commands](/cli/v8/service) use it.
+
+## project env
+
+Use `project env` commands to manage environment variables for the linked project. Every write requires an explicit scope: pass exactly one of `--role <production|preview>` or `--branch <git-name>`. A write without a scope fails with `PROJECT.USAGE_ERROR`, so a write targets production only when you ask for it. See [Environment variables](/compute/environment-variables).
+
+| Command                               | Description                                                |
+| ------------------------------------- | ----------------------------------------------------------- |
+| `project env add [KEY=value\|KEY]`    | Create a variable. Pass just `KEY` to read the value from your environment, or omit the assignment and pass `--file` |
+| `project env update [KEY=value\|KEY]` | Replace an existing variable's value. A bare `KEY` also reads from your environment |
+| `project env list`                    | List variable names and metadata for a scope, never values   |
+| `project env remove <key>`            | Remove a variable from a scope                               |
+
+`add` and `update` also accept `--file <path>` to read `KEY=VALUE` assignments from a dotenv file, and every `project env` command takes `--project <id-or-name>`.
+
+Values are write-only: they are encrypted at rest and cannot be read back. A deployment picks up the values at deploy time. Redeploy to apply changes.
diff --git a/apps/docs/content/docs/cli/v8/service.mdx b/apps/docs/content/docs/cli/v8/service.mdx
new file mode 100644
index 0000000000..d371479eb5
--- /dev/null
+++ b/apps/docs/content/docs/cli/v8/service.mdx
@@ -0,0 +1,59 @@
+---
+title: service
+description: Manage Compute services, their deployments, logs, and custom domains.
+url: /cli/v8/service
+metaTitle: service | Prisma 8 CLI
+metaDescription: Learn how to manage Prisma Compute services, deployments, and custom domains with the unified Prisma CLI.
+---
+
+Use `service` commands to manage the services in a project.
+
+If your `prisma.compute.ts` defines multiple services, most commands let you select a service with the optional `[service]` positional argument or the `--service <name>` option. You can also target a specific project with `--project <id-or-name>`.
+
+Deployments are created through a Git push, the [Console](https://pris.ly/pdp), or [Composer](/composer). There is no standalone `deploy` command for deploying an individual service. The commands below let you manage services and their deployments.
+
+## Usage
+
+```npm
+npx prisma@next service list
+npx prisma@next service show
+```
+
+## Commands
+
+| Command                  | Description                                       |
+| ------------------------ | -------------------------------------------------- |
+| `service list`           | List the services in a project (`--branch` scopes it) |
+| `service create <name>`  | Create a service (`--region`, `--branch`)          |
+| `service show [service]` | Show the service and its current deployment        |
+| `service open [service]` | Open the service's live URL                        |
+| `service logs [service]` | Read logs for a deployment of the service. Defaults to the live deployment (`--deployment <id>` selects another). `--tail <n>` sets the line count (default 100), `--from-start` reads from the beginning, and `--follow` keeps polling |
+| `service remove [service]` | Remove the service from the branch you target    |
+
+## service deployment
+
+Use `service deployment` commands to manage the deployments of a service. Deployments are created through a Git push, the Console, or Composer. These commands operate on the deployments that already exist.
+
+| Command                                    | Description                                                        |
+| ------------------------------------------ | ------------------------------------------------------------------- |
+| `service deployment list [service]`        | List deployments for the service                                    |
+| `service deployment show <deployment> [service]` | Show a deployment in detail                                   |
+| `service deployment promote <deployment> [service]` | Promote a deployment to production by rebuilding with production env vars |
+| `service deployment rollback [service]`    | Roll back production to a previous deployment (`--to <deployment>`; defaults to the one before the live deployment) |
+| `service deployment start <deployment> [service]` | Start a stopped deployment                                   |
+| `service deployment stop <deployment> [service]`  | Stop a running deployment                                    |
+| `service deployment delete <deployment> [service]` | Delete a deployment and the artifact it holds               |
+
+Promotion rebuilds the deployment with production environment variables, so configuration changes take effect on promote. Rollback switches production back to an existing deployment. See [Deployments](/compute/deployments).
+
+## service domain
+
+Use `service domain` commands to manage custom domains for a service. All commands take a `<hostname>` argument plus the usual service and project selectors and a `--branch <name>` scope. Domains target the production branch by default. See [Domains](/compute/domains) for details.
+
+| Command                           | Description                                                    |
+| --------------------------------- | --------------------------------------------------------------- |
+| `service domain add <hostname>`   | Register a custom domain on the service's production branch      |
+| `service domain show <hostname>`  | Show custom domain status and certificate details                |
+| `service domain wait <hostname>`  | Wait until a custom domain is active or failed (`--timeout <duration>`, default 15m) |
+| `service domain retry <hostname>` | Retry custom domain DNS verification and TLS provisioning         |
+| `service domain remove <hostname>`| Detach a custom domain from the service                           |
diff --git a/apps/docs/content/docs/cli/v8/telemetry.mdx b/apps/docs/content/docs/cli/v8/telemetry.mdx
new file mode 100644
index 0000000000..15ac5a35a8
--- /dev/null
+++ b/apps/docs/content/docs/cli/v8/telemetry.mdx
@@ -0,0 +1,23 @@
+---
+title: telemetry
+description: Show, enable, or disable anonymous CLI telemetry.
+url: /cli/v8/telemetry
+metaTitle: telemetry | Prisma 8 CLI
+metaDescription: Learn how to inspect and change anonymous CLI telemetry in the unified Prisma CLI.
+---
+
+Use `telemetry` commands to inspect and change anonymous CLI telemetry. Telemetry is on by default.
+
+## Usage
+
+```npm
+npx prisma@next telemetry status
+```
+
+## Commands
+
+| Command             | Description                                            |
+| ------------------- | ------------------------------------------------------ |
+| `telemetry status`  | Show whether anonymous CLI telemetry is enabled and why |
+| `telemetry enable`  | Enable anonymous CLI telemetry                          |
+| `telemetry disable` | Disable anonymous CLI telemetry                         |
diff --git a/apps/docs/content/docs/composer/cli-reference.mdx b/apps/docs/content/docs/composer/cli-reference.mdx
index 480331695e..a2da67d50d 100644
--- a/apps/docs/content/docs/composer/cli-reference.mdx
+++ b/apps/docs/content/docs/composer/cli-reference.mdx
@@ -6,13 +6,13 @@ metaTitle: CLI reference | Prisma Composer
 metaDescription: Complete reference for the prisma composer command group, including deploy, destroy, dev, and log, their flags, credentials, and the in-process control API.
 ---
 
-Composer ships as the `composer` command group of the Prisma CLI. Until the unified `prisma` CLI ships, run it through the `@prisma/cli` package's `next` tag:
+Composer ships as the `composer` command group of the unified Prisma CLI, published as `prisma@next` during the Prisma 8 RC:
 
 ```npm
-npx @prisma/cli@next composer <command>
+npx prisma@next composer <command>
 ```
 
-Every command takes an `<entry>` argument: the module whose default export is the application root, typically `module.ts`. All four commands hand the terminal to the underlying pipeline and do not support `--json`.
+Every command takes an `<entry>` argument: the module whose default export is the application root, typically `module.ts`. All four commands stream the underlying pipeline's own output to the terminal.
 
 | Command | Description |
 | --- | --- |
@@ -23,16 +23,22 @@ Every command takes an `<entry>` argument: the module whose default export is th
 
 ## `composer deploy`
 
-Deploys the application whose root node is `<entry>`'s default export. Requires `PRISMA_SERVICE_TOKEN` and `PRISMA_WORKSPACE_ID` in the environment; see [Deploying](/composer/deploying#credentials). Deploy does not build your code first; run your build before it.
+Deploys the application exported as the default export from `<entry>`.
+
+By default, the command uses the credentials from your existing `auth login` session. In CI or other headless environments, set `PRISMA_SERVICE_TOKEN` and `PRISMA_WORKSPACE_ID` instead. See [Deploying](/composer/deploying#credentials) for details.
+
+The `deploy` command does not build your application. Run your build command before deploying.
 
 | Flag | Description |
 | --- | --- |
-| `--name <name>` | Override the root node's name, which is the deploy's application name |
+| `--name <name>` | Override the application name for this deploy. It defaults to the name of the exported application |
 | `--stage <stage>` | Deploy scope to target; omit for production |
+| `--report <path>` | Write the deploy's outcome as JSON to this path: resources, preview URLs, and the failure cause. Also settable as `PRISMA_COMPOSER_REPORT_FILE` |
+| `--build-id <id>` | Join the deploy record your CI already created rather than letting the target create one |
 
 ```npm
-npx @prisma/cli@next composer deploy module.ts
-npx @prisma/cli@next composer deploy module.ts --stage feat-auth
+npx prisma@next composer deploy module.ts
+npx prisma@next composer deploy module.ts --stage feat-auth
 ```
 
 ## `composer destroy`
@@ -41,56 +47,57 @@ Tears down the application's deployed resources. Requires an explicit target: `-
 
 | Flag | Description |
 | --- | --- |
-| `--name <name>` | Override the root node's name, the application name to tear down |
+| `--name <name>` | Override the application name to tear down |
 | `--stage <stage>` | Tear down this branch environment |
 | `--production` | Tear down the project-level production environment |
 
 ```npm
-npx @prisma/cli@next composer destroy module.ts --stage feat-auth
-npx @prisma/cli@next composer destroy module.ts --production
+npx prisma@next composer destroy module.ts --stage feat-auth
+npx prisma@next composer destroy module.ts --production
 ```
 
 ## `composer dev`
 
-Brings the application up entirely on this machine. Runs credential-free against local emulators, watches the built output, and restarts a service when its build changes. Logs are a separate command; run `composer log <entry>` to tail them. See [Local development](/composer/local-development).
+Brings the application up entirely on this machine. Runs credential-free against local emulators, watches the built output, and restarts a service when its build changes. Logs are a separate command. Run `composer log <entry>` to tail them. See [Local development](/composer/local-development).
 
 | Flag | Description |
 | --- | --- |
-| `--name <name>` | Override the root node's name, the dev instance's application name |
+| `--name <name>` | Override the application name for the local dev instance |
 | `--fresh` | Destroy the dev stack and wipe the dev state directory before starting |
 
 ```npm
-npx @prisma/cli@next composer dev module.ts
-npx @prisma/cli@next composer dev module.ts --fresh
+npx prisma@next composer dev module.ts
+npx prisma@next composer dev module.ts --fresh
 ```
 
 ## `composer log`
 
-Tails the merged logs of the locally running application. It only reads; it never builds, provisions, starts, or stops anything.
+Tails the merged logs of the locally running application. The command only reads. It never builds, provisions, starts, or stops anything.
 
 | Argument or flag | Description |
 | --- | --- |
 | `[address]` | Only this service's lines, by its dotted address (for example `catalog.service`); every service when absent |
-| `--name <name>` | Override the root node's name, the dev instance's application name |
+| `--name <name>` | Override the application name for the local dev instance |
 | `--tail <lines>` | How many trailing history lines to show before live output (default 20; `0` for live-only) |
 
 ```npm
-npx @prisma/cli@next composer log module.ts
-npx @prisma/cli@next composer log module.ts catalog.service
+npx prisma@next composer log module.ts
+npx prisma@next composer log module.ts catalog.service
 ```
 
 ## Global flags
 
-The Prisma CLI's global flags also apply: `--format`, `--json`, `--log-level`, `--verbose`, `--quiet`, `--yes`, `--confirm`, `--interactive`, `--color`, and `--config`. The four Composer commands stream the pipeline's own output and ignore `--json`.
+The Prisma CLI's global flags also apply: `--format`, `--json`, `--log-level`, `--verbose`, `--quiet`, `--yes`, `--confirm`, `--interactive`, `--color`, and `--config`.
 
 ## Environment variables
 
 | Variable | Used by | Description |
 | --- | --- | --- |
-| `PRISMA_SERVICE_TOKEN` | `deploy`, `destroy` | A workspace service token from the [Prisma Console](https://console.prisma.io) |
-| `PRISMA_WORKSPACE_ID` | `deploy`, `destroy` | The workspace ID from the workspace's settings |
+| `PRISMA_SERVICE_TOKEN` | `deploy`, `destroy` | A workspace service token from the [Prisma Console](https://console.prisma.io), for CI and other headless environments. When unset, the commands use your stored `auth login` session |
+| `PRISMA_WORKSPACE_ID` | `deploy`, `destroy` | The workspace ID from the workspace's settings; pair it with the service token |
+| `PRISMA_COMPOSER_REPORT_FILE` | `deploy` | Path to write the deploy's JSON outcome report; the `--report` flag wins when both are set |
 
-`dev` and `log` need neither; local runs never talk to the platform.
+`dev` and `log` need none of these; local runs never talk to the platform.
 
 ## The control API
 
diff --git a/apps/docs/content/docs/composer/databases.mdx b/apps/docs/content/docs/composer/databases.mdx
index ccc5d638b2..df8e82e294 100644
--- a/apps/docs/content/docs/composer/databases.mdx
+++ b/apps/docs/content/docs/composer/databases.mdx
@@ -8,9 +8,15 @@ metaDescription: Add Prisma Postgres to a Composer service with postgres() for a
 
 There are two ways for a service to get a [Prisma Postgres](/postgres) database, depending on how much you want the framework to do. Both are dependencies: the service declares the need, the module provisions the resource, and your code receives the result from `service.load()`.
 
+:::note[Two kinds of contract]
+
+Composer's [service contracts](/composer/services-and-contracts) describe an RPC API between services. A Prisma 8 **data contract** describes a database schema. This page uses both: `pnPostgres()` ties a database dependency to a Prisma 8 data contract.
+
+:::
+
 ## `postgres()`: bring your own client
 
-The dependency delivers connection config, `{ url }`, and nothing else. You build the client you already know (`pg`, Bun's `SQL`, an ORM) in your server entry:
+Declare `postgres()` when you want to build the client yourself. The dependency delivers connection config, `{ url }`, and nothing else. In your server entry, build the client you already know (`pg`, Bun's `SQL`, an ORM):
 
 ```ts title="src/auth/service.ts"
 import { compute, postgres } from '@prisma/composer-prisma-cloud';
@@ -29,7 +35,7 @@ const { db } = service.load();
 const sql = new SQL({ url: db.url, max: 1, idleTimeout: 10 });
 ```
 
-Those pool settings are not decorative. Prisma Compute scales to zero and closes idle connections, so keep the pool small and reconnect-friendly; see [Deploying](/composer/deploying#production-behavior).
+Those pool settings matter. Prisma Compute scales to zero and closes idle connections, so keep the pool small and reconnect-friendly. See [Deploying](/composer/deploying#production-behavior).
 
 The module that owns the database provisions it:
 
@@ -40,16 +46,16 @@ provision(authService, { deps: { db } });
 
 ## `pnPostgres()`: a Prisma 8-typed database
 
-If you want typed queries and managed migrations, make the database a [Prisma 8](/v8) one. `load()` then returns `{ url, client }`: the raw connection string, plus a client generated from your data contract, so queries like `db.client.orm.public.Product.where({ id }).first()` are compile-time checked, with no SQL strings and no row mapping. The client is constructed on first access, so a service that brings its own Postgres client can still read `db.url` and keep contract-checked wiring and deploy-time migrations.
+If you want typed queries and managed migrations, make the database a [Prisma 8](/v8) one. `load()` then returns `{ url, client }`: the raw connection string, plus a client generated from your data contract. Queries like `db.client.orm.public.Product.where({ id }).first()` are compile-time checked, with no SQL strings and no row mapping. The client is constructed only on first access, so a service that brings its own Postgres client can still read `db.url` and keep contract-checked wiring and deploy-time migrations.
 
 The schema workflow runs once per schema change, using the [Prisma 8 CLI commands](/cli/v8):
 
 1. Edit `contract.prisma`, your schema.
 2. Run `contract emit` to regenerate `contract.json` and `contract.d.ts` from it.
 3. Run `migration plan` to author the migration into `migrations/`.
-4. Deploy. The deploy applies `migrations/` before the service starts; there is no `CREATE TABLE IF NOT EXISTS` anywhere in app code.
+4. Deploy. The deploy applies `migrations/` before the service starts. There is no `CREATE TABLE IF NOT EXISTS` anywhere in app code.
 
-In your app, the emitted contract is wrapped once, and that one value is referenced by both the resource and every service that queries it:
+In your app, wrap the emitted contract once. Both the resource and every service that queries it reference that one value:
 
 ```ts title="src/data.ts"
 import { pnContract } from '@prisma/composer-prisma-cloud/prisma-next';
@@ -59,13 +65,13 @@ import contractJson from '../contract.json' with { type: 'json' };
 export const catalogData = pnContract<Contract>(contractJson);
 ```
 
-`pnPostgres` is both ends of the edge, told apart by what you pass it. The contract alone is the dependency end, the service declaring what it queries:
+You call `pnPostgres()` on both sides of the wiring, and what you pass it tells the two apart. Passing the contract alone declares the dependency, the service saying what it queries:
 
 ```ts
 deps: { db: pnPostgres(catalogData) }
 ```
 
-An options object is the resource end. The module that owns the database provisions it, naming the `prisma-next.config.ts` path (relative to the module file) so the deploy can find `migrations/`:
+Passing an options object declares the resource. The module that owns the database provisions it, naming the `prisma-next.config.ts` path (relative to the module file) so the deploy can find `migrations/`:
 
 ```ts
 const db = provision(
diff --git a/apps/docs/content/docs/composer/deploying.mdx b/apps/docs/content/docs/composer/deploying.mdx
index 6773688c99..7867abd20f 100644
--- a/apps/docs/content/docs/composer/deploying.mdx
+++ b/apps/docs/content/docs/composer/deploying.mdx
@@ -6,24 +6,30 @@ metaTitle: Deploying | Prisma Composer
 metaDescription: Deploy Prisma Composer apps to Prisma Compute with composer deploy, use stages for isolated environments and per-PR previews, wire CI, and destroy environments safely.
 ---
 
-One CLI, two commands. `composer deploy` takes your entry file (the one whose default export is the root module) and stands the whole app up on [Prisma Compute](/compute) and [Prisma Postgres](/postgres); `composer destroy` tears an environment down. Which environment you are touching, production or an isolated **stage**, is always a command-line choice, never something in your code.
+`composer deploy` takes your entry file (the one whose default export is the root module) and stands the whole app up on [Prisma Compute](/compute) and [Prisma Postgres](/postgres). `composer destroy` tears an environment down. You choose the target environment, production or an isolated **stage**, on the command line rather than in your code.
 
 | You want to... | Run |
 | --- | --- |
-| Deploy to production | `npx @prisma/cli@next composer deploy module.ts` |
-| Deploy an isolated environment | `npx @prisma/cli@next composer deploy module.ts --stage <name>` |
-| Deploy under a different app name | `npx @prisma/cli@next composer deploy module.ts --name demo-42` |
-| Tear down an isolated environment | `npx @prisma/cli@next composer destroy module.ts --stage <name>` |
-| Tear down production's resources | `npx @prisma/cli@next composer destroy module.ts --production` |
+| Deploy to production | `npx prisma@next composer deploy module.ts` |
+| Deploy an isolated environment | `npx prisma@next composer deploy module.ts --stage <name>` |
+| Deploy under a different app name | `npx prisma@next composer deploy module.ts --name demo-42` |
+| Tear down an isolated environment | `npx prisma@next composer destroy module.ts --stage <name>` |
+| Tear down production's resources | `npx prisma@next composer destroy module.ts --production` |
 
 ## Credentials
 
-Two environment variables, nothing else:
+On your machine, `composer deploy` uses the session stored by `auth login`, the same sign-in every other CLI command uses:
+
+```npm
+npx prisma@next auth login
+```
+
+In CI or any headless environment, use a service token instead. Set two environment variables:
 
 - `PRISMA_SERVICE_TOKEN`: create a service token for your workspace in the [Prisma Console](https://console.prisma.io).
 - `PRISMA_WORKSPACE_ID`: in the workspace's settings.
 
-A fresh checkout with just those two set deploys successfully; the CLI finds or creates everything else. Keep the values out of the repo (an `.env` you source at deploy time, or CI secrets). There is no interactive login for deploys; the token is the only authentication.
+A fresh checkout with just those two variables set deploys successfully. The CLI finds or creates everything else. Keep the values out of the repo (an `.env` you source at deploy time, or CI secrets). When `PRISMA_SERVICE_TOKEN` is set it takes priority over any stored session.
 
 ## Build first
 
@@ -31,24 +37,24 @@ A fresh checkout with just those two set deploys successfully; the CLI finds or
 
 ```npm
 npm run build
-npx @prisma/cli@next composer deploy module.ts
+npx prisma@next composer deploy module.ts
 ```
 
-Deploy state (what is already provisioned, so re-deploys diff instead of recreate) is stored with the environment it describes, not on your machine. The platform hosts each environment's state behind its API, scoped to that environment's branch inside the app's project. Everyone deploying the app shares it, your laptop and CI see the same world, and two concurrent deploys of the same environment lock each other out instead of corrupting it: while one holds the deploy lease, the second fails immediately with a message naming the holder. If a deploy crashes, its lease expires after about a minute and the next deploy takes over.
+Deploy state records what is already provisioned, so a re-deploy applies the difference instead of recreating everything. The platform stores this state with the environment it describes, scoped to that environment's branch inside the app's project. It is not stored on your machine, so your laptop and CI see the same state. Concurrent deploys of the same environment take turns through a lease on that state. While one deploy holds the lease, a second deploy fails immediately with a message naming the holder. If a deploy crashes, its lease expires after about a minute, and the next deploy takes over.
 
 ## Production and stages
 
 Deploying with no `--stage` targets **production**. In platform terms, the app is a project (named after your root module), and production lives at the project level.
 
-`--stage <name>` deploys a complete, isolated copy of the app, every service, every database, its own configuration, as a branch of that same project. Nothing is shared with production except the code:
+`--stage <name>` deploys a complete, isolated copy of the app as a [preview branch](/compute/branching) of that same project: its own services, its own databases, its own configuration. The only thing a stage shares with production is the code. Composer's *stage* and Compute's *preview branch* are the same object seen from two tools, which is why the stage's variables are the branch's [environment variables](/compute/environment-variables):
 
 ```npm
-npx @prisma/cli@next composer deploy module.ts                  # production
-npx @prisma/cli@next composer deploy module.ts --stage staging  # a persistent staging environment
-npx @prisma/cli@next composer deploy module.ts --stage pr-42    # one environment per PR
+npx prisma@next composer deploy module.ts                  # production
+npx prisma@next composer deploy module.ts --stage staging  # a persistent staging environment
+npx prisma@next composer deploy module.ts --stage pr-42    # one environment per PR
 ```
 
-Re-deploying any environment is idempotent; it updates the resources in place. A stage name must be a valid git ref name; an invalid name is a hard error, never a silent rename.
+Re-deploying any environment is idempotent: it updates the resources in place. A stage name must be a valid git ref name. An invalid name fails the deploy rather than being renamed.
 
 ## What a deploy prints
 
@@ -66,29 +72,29 @@ storefront-auth
 
 The tree is your module structure: `auth.api` is the `api` service inside the `auth` Module. Under each name is the platform resource it became and its ID, the thing to search for in the Console when you need it.
 
-A URL appears only where the address is genuinely public. A Compute service prints one because its endpoint is reachable. A database never does: it has a connection string, not a public endpoint. Nothing secret is reported here at all; a node whose whole product is a keypair prints no resource line. A node that deployed but published nothing reportable is still listed, marked `(no entities reported)`, so a node is never silently missing from the tree.
+URLs appear for publicly reachable endpoints. That is why a Compute service prints one and a database does not: a database has a connection string, not a public endpoint. Secrets are left out entirely, so a node whose only output is a keypair prints no resource line. A node that deployed but published nothing reportable still appears in the tree, marked `(no entities reported)`.
 
 ## Destroying
 
-`destroy` refuses to guess. A bare `composer destroy` is an error; name the target:
+`destroy` requires an explicit target; a bare `composer destroy` is an error:
 
 ```npm
-npx @prisma/cli@next composer destroy module.ts --stage staging  # staging only; production untouched
-npx @prisma/cli@next composer destroy module.ts --production     # production's resources
+npx prisma@next composer destroy module.ts --stage staging  # staging only; production untouched
+npx prisma@next composer destroy module.ts --production     # production's resources
 ```
 
-`--stage` and `--production` together is an error too. Destroying a stage removes its resources, then deletes its branch, which takes the stage's deploy state with it. Destroying production removes the resources and also deletes the app's project once nothing is left in it, so hand-run stacks do not pile up as empty projects in your workspace; a project still holding another stage's resources is left in place. Destroy never creates: tearing down a stage that was never deployed fails with "nothing deployed" rather than provisioning one first.
+`--stage` and `--production` together is an error too. Destroying a stage removes its resources, then deletes its branch along with the stage's deploy state. Destroying production removes the resources and, if the project is empty afterwards, deletes the project too, so empty projects do not pile up in your workspace. A project still holding another stage's resources stays in place. Tearing down a stage that was never deployed fails with "nothing deployed". It does not provision one first.
 
 ## CI
 
-Nothing is CI-specific. Set the two credential variables as CI secrets, build, and run the same commands. The per-PR environment pattern:
+CI runs the same commands as your machine: set the two credential variables as CI secrets, build, and deploy. The per-PR environment pattern:
 
 ```bash
-npx @prisma/cli@next composer deploy module.ts --stage "pr-$PR_NUMBER"    # on push
-npx @prisma/cli@next composer destroy module.ts --stage "pr-$PR_NUMBER"   # on close
+npx prisma@next composer deploy module.ts --stage "pr-$PR_NUMBER"    # on push
+npx prisma@next composer destroy module.ts --stage "pr-$PR_NUMBER"   # on close
 ```
 
-One extra: if your app binds input fields with `envSecret` or `envParam` (see [Service input](/composer/service-input)), each stage keeps its own copy of those platform variables, and the platform copy is the store; the deploying shell only seeds it. A fresh stage (a new `pr-42`) has none of them yet, so CI must export the values alongside the two credentials; preflight copies missing ones up on that first deploy. A name absent from both the platform and the shell fails the deploy early, naming the missing variable.
+One extra step applies if your app binds input fields with `envSecret` or `envParam` (see [Service input](/composer/service-input)). Each stage stores its own copy of those platform variables. The deploying shell only seeds them. A fresh stage, such as a new `pr-42`, starts with none of them, so CI must export the values alongside the two credential variables. The first deploy then copies any missing values from the shell up to the stage. If a name is absent from both the platform and the shell, the deploy fails early and names the missing variable.
 
 ## When a deploy stops on an effect version conflict
 
@@ -110,11 +116,11 @@ Connection input "auth.db" declares param "url", but its producer "db" did not
 supply it — the producer's outputs carry [host].
 ```
 
-Fix it at whichever end is wrong: add the name to the outputs the producer returns, or mark the param `optional` on the connection if absent is genuinely legal (the consumer then reads `undefined`). Do not make the param optional just to route around the error; that reinstates a silent `undefined`. You will only meet this if you authored the connection or an extension on one side of the wire; every block that ships with the framework supplies what it declares.
+Fix it at whichever end is wrong: add the name to the outputs the producer returns, or mark the param `optional` on the connection if absent is a valid value (the consumer then reads `undefined`). Do not make the param optional just to route around the error: that reinstates a silent `undefined`. You will only meet this error if you authored the connection or an extension on one side of the wire. Every block that ships with the framework supplies what it declares.
 
 ## Production behavior
 
-What deployed apps actually run into, and what to do about it:
+Behavior you will run into once the app is deployed, and what to do about it:
 
 - **Compute scales to zero, and idle database connections get closed.** A long-lived client that treats a dropped connection as fatal will crash-loop through 502s. Keep the pool small and reconnect-friendly, and do not let an async error kill the process:
 
@@ -127,13 +133,13 @@ What deployed apps actually run into, and what to do about it:
 - **Bind `0.0.0.0`, not loopback.** Compute routes external HTTP to the VM; a `localhost` listener is unreachable from outside.
 - **A deployed `/rpc/<method>` returns `401` to you.** Calls are [authenticated for you](/composer/services-and-contracts#calls-are-authenticated-for-you), and your `curl` is not one of the services the app connected. Reach it through a consumer instead.
 - **Calls into a sleeping service can get `ECONNRESET`** while it cold-starts. Retry them; the generated RPC client already does.
-- **The `COMPOSER_*` variables in your project belong to the deploy.** Config, secret pointers, and service keys all land there, and every deploy rewrites them; editing one by hand does not survive.
+- **The `COMPOSER_*` variables in your project belong to the deploy.** Config, secret pointers, and service keys all land there, and every deploy rewrites them. An edit made by hand does not survive the next deploy.
 - **Streaming responses do not stream.** The platform's HTTP front door buffers a response until it completes, so an open SSE tail delivers nothing and times out at 60 seconds. Do not build on streamed HTTP responses.
 - **Next.js pages that call `service.load()` need `export const dynamic = 'force-dynamic'`.** The runtime environment does not exist at build time, and Next.js will not re-read it for prerendered routes.
 
 ## Driving deploys from code
 
-Everything the CLI does is also callable in-process, from `@prisma/composer/control`: typed `deploy`, `destroy`, `dev`, and `log` operations that return structured results instead of printing and exiting. The CLI commands are thin renderers over these same operations, so the two surfaces cannot drift:
+Everything the CLI does is also callable in-process, from `@prisma/composer/control`: typed `deploy`, `destroy`, `dev`, and `log` operations that return structured results instead of printing and exiting. The CLI commands are thin renderers over these same operations, so both surfaces behave the same:
 
 ```ts
 import { deploy } from '@prisma/composer/control';
@@ -142,7 +148,7 @@ const result = await deploy({ entry: 'module.ts', stage: 'pr-42' });
 if (!result.ok) console.error(result.failure.message);
 ```
 
-Failures come back as structured errors with a dotted `failure.code` and the same fix-naming `message` the CLI renders. `destroy` takes an explicit target, `{ kind: 'production' }` or `{ kind: 'stage', stage }`, so nothing defaults to production. The deploy engine's live output still streams to your process's stdio; the operations do not capture it.
+Failures come back as structured errors with a dotted `failure.code` and the same fix-naming `message` the CLI renders. `destroy` takes an explicit target, `{ kind: 'production' }` or `{ kind: 'stage', stage }`. There is no default. The deploy engine's live output still streams to your process's stdio; the operations do not capture it.
 
 ## Next steps
 
diff --git a/apps/docs/content/docs/composer/getting-started.mdx b/apps/docs/content/docs/composer/getting-started.mdx
index 616ac9331e..dc656e24c8 100644
--- a/apps/docs/content/docs/composer/getting-started.mdx
+++ b/apps/docs/content/docs/composer/getting-started.mdx
@@ -6,9 +6,9 @@ metaTitle: Get started with Prisma Composer
 metaDescription: Build a two-service Prisma Composer app from scratch, wire the services with a typed contract, and run the whole app locally with one command.
 ---
 
-By the end of this page you will have a working Prisma App: a `quotes` API and a public `gateway` that calls it, wired together by a typed contract and running on your machine with one command. It meets every core Composer idea once: a contract, a service, a root module, a build, and a local run.
+By the end of this page you will have a working Prisma App: a `quotes` API and a public `gateway` that calls it. A typed contract wires the two together, and one command runs them on your machine. Along the way you will meet every core Composer idea once: a contract, a service, a root module, a build, and a local run.
 
-The app is deliberately tiny, with no database, so you can see the whole shape at once. Adding a Postgres is the natural next step, and [Databases](/composer/databases) covers it.
+The app is deliberately tiny, with no database, so you can see the whole shape at once. Adding a Postgres is the natural next step. See [Databases](/composer/databases) when you are ready.
 
 :::note[Working with a coding agent?]
 
@@ -22,11 +22,11 @@ npx skills add prisma/composer
 
 ## Prerequisites
 
-- **Node.js 22.18 or newer.** Check with `node --version`. Composer hands your TypeScript entry file straight to Node, and Node runs `.ts` files directly only from 22.18.0, the release that turns type stripping on by default. On anything older, Composer commands stop at `ERR_UNKNOWN_FILE_EXTENSION` naming your own entry file; 22.17 is not close enough.
-- **[Bun](https://bun.sh).** Prisma Compute runs Bun, so that is what the server code targets (`Bun.serve`), and `bun build` is the fastest way to produce the built output.
+- **Node.js 22.18 or newer.** Check with `node --version`. Composer hands your TypeScript entry file straight to Node. Node runs `.ts` files directly only from 22.18.0, the release that turns type stripping on by default. On any older version, including 22.17, Composer commands stop at `ERR_UNKNOWN_FILE_EXTENSION` naming your own entry file.
+- **[Bun](https://bun.sh).** Prisma Compute runs Bun, so the server code targets it (`Bun.serve`). `bun build` is also the fastest way to produce the built output.
 - **npm or pnpm.**
 
-You do not need a Prisma account for this page. Local runs never talk to the platform; you only need credentials when you [deploy](/composer/deploying).
+You do not need a Prisma account for this page. Local runs never talk to the platform. You only need credentials when you [deploy](/composer/deploying).
 
 ## 1. Set up the project
 
@@ -34,27 +34,48 @@ Create a directory and install the two Composer packages, plus [arktype](https:/
 
 ```npm
 npm init -y
+npm pkg set type=module
 npm install @prisma/composer @prisma/composer-prisma-cloud arktype
 npm install -D typescript @types/bun
 ```
 
-Then pin the `effect` family in your `package.json`. This works around an upstream bug in Composer's deploy engine, whose own version ranges float past the versions its code supports; without the pins, a fresh install ends up with two conflicting copies of `effect` and every Composer command refuses to run. Match the version to the one your installed `@prisma/composer` pins (check `dependencies.effect` in `node_modules/@prisma/composer/package.json`; for `@prisma/composer` 0.6.0 it is `4.0.0-beta.93`):
+`"type": "module"` matters: Composer loads your entry file as an ES module, and without it every Composer command stops at `COMPOSE.ENTRY_UNLOADABLE` ("Cannot use import statement outside a module").
 
-```json title="package.json"
+Then pin the `effect` family in your `package.json`. This works around an upstream bug in Composer's deploy engine, whose own version ranges float past the versions its code supports. Without the pins, a fresh install ends up with two conflicting copies of `effect`, and every Composer command refuses to run. Match the version to the one your installed `@prisma/composer` pins: check `dependencies.effect` in `node_modules/@prisma/composer/package.json`. For `@prisma/composer` 0.8.0 it is `4.0.0-beta.103`:
+
+```json title="package.json (npm)"
 {
   "overrides": {
-    "effect": "4.0.0-beta.93",
-    "@effect/sql-d1": "4.0.0-beta.93",
-    "@effect/sql-pg": "4.0.0-beta.93",
-    "@effect/vitest": "4.0.0-beta.93",
-    "@effect/platform-bun": "4.0.0-beta.93",
-    "@effect/platform-node": "4.0.0-beta.93",
-    "@effect/platform-node-shared": "4.0.0-beta.93"
+    "effect": "4.0.0-beta.103",
+    "@effect/sql-d1": "4.0.0-beta.103",
+    "@effect/sql-pg": "4.0.0-beta.103",
+    "@effect/vitest": "4.0.0-beta.103",
+    "@effect/platform-bun": "4.0.0-beta.103",
+    "@effect/platform-node": "4.0.0-beta.103",
+    "@effect/platform-node-shared": "4.0.0-beta.103"
+  }
+}
+```
+
+With pnpm, the same map goes under `"pnpm"` instead:
+
+```json title="package.json (pnpm)"
+{
+  "pnpm": {
+    "overrides": {
+      "effect": "4.0.0-beta.103",
+      "@effect/sql-d1": "4.0.0-beta.103",
+      "@effect/sql-pg": "4.0.0-beta.103",
+      "@effect/vitest": "4.0.0-beta.103",
+      "@effect/platform-bun": "4.0.0-beta.103",
+      "@effect/platform-node": "4.0.0-beta.103",
+      "@effect/platform-node-shared": "4.0.0-beta.103"
+    }
   }
 }
 ```
 
-npm reads `overrides`, yarn calls it `resolutions`, and pnpm nests it under `"pnpm"`. Run your install again after adding the block.
+Run your install again after adding the block. (Yarn users: the equivalent field is `"resolutions"`, but this guide is tested with npm and pnpm only.)
 
 Add a `tsconfig.json` so the compiler checks your wiring the same way the deploy will:
 
@@ -118,7 +139,7 @@ export default compute({
 });
 ```
 
-Third, the **server**: the code your build turns into `dist/quotes/server.mjs` and the platform boots. `serve()` generates the HTTP handler from the contract; if you forget a handler or return the wrong shape, it does not compile:
+Third, the **server**: the code your build turns into `dist/quotes/server.mjs` and the platform boots. `serve()` generates the HTTP handler from the contract. If you forget a handler or return the wrong shape, the code does not compile:
 
 ```ts title="src/quotes/server.ts"
 import { serve } from '@prisma/composer/service-rpc';
@@ -143,11 +164,11 @@ export default handler;
 Bun.serve({ port, hostname: '0.0.0.0', fetch: handler });
 ```
 
-Notice what is missing: no URL of anything and no `process.env`. Every service gets a port for free, read through `service.port()`; dependencies arrive through `service.load()`; and any configuration of your own arrives through `service.input()` (see [Service input](/composer/service-input)). Those three typed accessors are the whole framework contract with your code.
+Notice what is missing: no URL of anything and no `process.env`. Every service gets a port for free, read through `service.port()`. Dependencies arrive through `service.load()`. Any configuration of your own arrives through `service.input()` (see [Service input](/composer/service-input)). Those three typed accessors are the whole framework contract with your code.
 
 ## 3. Create the gateway service
 
-The gateway depends on the quotes contract. Note the asymmetry with step 2: the quotes service *exposed* the bare contract (its offer), while the gateway wraps it in `rpc()` (its need, "a client of this contract"). Declaring `deps: { quotes: rpc(quotesContract) }` means `service.load()` hands the server a ready-made typed client:
+The gateway depends on the quotes contract. Note the asymmetry with step 2: the quotes service *exposed* the bare contract (what it provides), while the gateway wraps it in `rpc()` (what it needs: a client of this contract). Declaring `deps: { quotes: rpc(quotesContract) }` means `service.load()` hands the server a ready-made typed client:
 
 ```ts title="src/gateway/service.ts"
 import node from '@prisma/composer/node';
@@ -210,7 +231,7 @@ export default defineConfig({
 
 ## 5. Build
 
-You own the build; the framework only assembles what you built. It asks one thing: each entry must be a single self-contained file, with everything inlined except the runtime's own built-ins (`bun`, `bun:*`, `node:*`). Any bundler that produces such a file works; this guide uses Bun. Two services means two separate builds, not one multi-entry build, which would split the shared contract code into a chunk neither output contains:
+You own the build. The framework only assembles what you built, and it has one requirement: each entry must be a single self-contained file, with everything inlined except the runtime's own built-ins (`bun`, `bun:*`, `node:*`). Any bundler that produces such a file works. This guide uses Bun. Build the two services separately, because a multi-entry build would split the shared contract code into a chunk neither output contains:
 
 ```json title="package.json"
 {
@@ -235,7 +256,7 @@ npx tsc --noEmit
 One command brings the whole app up on your machine, both services wired together, with no cloud credentials:
 
 ```npm
-npx @prisma/cli@next composer dev module.ts
+npx prisma@next composer dev module.ts
 ```
 
 It runs the same pipeline a deploy runs, against local stand-ins for Prisma Compute and Prisma Postgres, and prints each service's local URL:
@@ -258,7 +279,7 @@ Make it work, make it right, make it fast.
 
 That response traveled over one typed RPC hop: the gateway received your request, called `quotes.random({})` through its injected client, and returned the result.
 
-`dev` keeps running, watches your built output, and restarts a service when its build changes (run `npm run build` in another terminal and the affected service restarts). `Ctrl-C` stops it; your local data stays, so the next start is warm. See [Local development](/composer/local-development) for logs, `--fresh`, and what persists.
+`dev` keeps running, watches your built output, and restarts a service when its build changes (run `npm run build` in another terminal and the affected service restarts). `Ctrl-C` stops it. Your local data stays, so the next start is warm. See [Local development](/composer/local-development) for logs, `--fresh`, and what persists.
 
 Now try the quotes service directly:
 
@@ -270,24 +291,22 @@ You get `401 Unauthorized`. That is deliberate: Composer mints a **service key**
 
 ## 7. Deploy it (optional)
 
-Local dev needed no account. Deploying the same app to [Prisma Compute](/compute) needs exactly two environment variables: a service token and your workspace ID, both from the [Prisma Console](https://console.prisma.io):
-
-```bash
-export PRISMA_SERVICE_TOKEN=<your service token>
-export PRISMA_WORKSPACE_ID=<your workspace id>
-```
+Local dev needed no account. Deploying the same app to [Prisma Compute](/compute) needs a signed-in session:
 
 ```npm
-npx @prisma/cli@next composer deploy module.ts
+npx prisma@next auth login
+npx prisma@next composer deploy module.ts
 ```
 
+(In CI, where the browser sign-in is not an option, set `PRISMA_SERVICE_TOKEN` and `PRISMA_WORKSPACE_ID` from the [Prisma Console](https://console.prisma.io) instead; see [Deploying](/composer/deploying#credentials).)
+
 The CLI creates a project named `my-app` in your workspace, provisions both services on Prisma Compute, points the gateway's `quotes` dependency at the deployed quotes service, and starts everything. The deploy finishes by printing what it made: your module names, the platform resource each became, and the public URLs. Open the gateway's URL and you get a quote.
 
 Re-deploying is idempotent. For an isolated copy of the whole app, deploy a stage and tear it down when you are done:
 
 ```npm
-npx @prisma/cli@next composer deploy module.ts --stage demo
-npx @prisma/cli@next composer destroy module.ts --stage demo
+npx prisma@next composer deploy module.ts --stage demo
+npx prisma@next composer destroy module.ts --stage demo
 ```
 
 See [Deploying](/composer/deploying) for stages, CI, and teardown in full.
diff --git a/apps/docs/content/docs/composer/index.mdx b/apps/docs/content/docs/composer/index.mdx
index ecc84e16d4..41b8c0351d 100644
--- a/apps/docs/content/docs/composer/index.mdx
+++ b/apps/docs/content/docs/composer/index.mdx
@@ -1,93 +1,112 @@
 ---
 title: Prisma Composer
-description: "Build apps made of multiple services in TypeScript, then deploy services, databases, and the wiring between them with one command."
+description: "A TypeScript framework for defining applications composed of multiple services and resources, and deploying them to Prisma Compute and Prisma Postgres."
 url: /composer
 badge: early-access
-metaTitle: Prisma Composer | Compose and deploy multi-service TypeScript apps
-metaDescription: Learn how Prisma Composer lets you declare services, databases, and their connections in TypeScript, and deploy the whole app to Prisma Compute and Prisma Postgres with one command.
+metaTitle: Prisma Composer | Define and deploy multi-service TypeScript apps
+metaDescription: Prisma Composer lets you declare services, their contracts, and their databases in TypeScript, then provisions and connects them on Prisma Compute and Prisma Postgres.
 ---
 
-Prisma Composer is a TypeScript framework for apps made of more than one piece. You declare each service and what it depends on, such as other services, databases, schedules, and secrets, compose them into a **Prisma App**, and deploy the whole thing to [Prisma Compute](/compute) and [Prisma Postgres](/postgres) with one command. There is no infrastructure configuration to write or maintain.
+With Prisma Composer, you describe your whole application in TypeScript: each service, plus whatever it depends on, such as other services, [Prisma Postgres](/postgres) databases, scheduled jobs, object storage, and secrets. One deploy command then provisions the services on [Prisma Compute](/compute), the databases on Prisma Postgres, and the authenticated connections between them.
+
+You do not need Composer to deploy to Prisma Compute. If your application is a single service, you can deploy it to Compute directly. See [Deployments](/compute/deployments) for those paths.
 
 :::info[Early Access]
 
-Prisma Composer is in [Early Access](/console/more/feature-maturity#early-access). APIs and commands can change between releases. Until the unified `prisma` CLI ships, run Composer commands with `npx @prisma/cli@next composer <command>`.
+Prisma Composer is in [Early Access](/console/more/feature-maturity#early-access). APIs and commands can change between releases. The Composer commands ship inside the [Prisma CLI](/composer/cli-reference): run them with `npx prisma@next composer <command>`.
 
 :::
 
-## Get started
-
-The fastest way to understand Composer is to build a small app with it. The quickstart takes you from an empty directory to two services calling each other over a typed contract, running on your machine.
-
-<Cards>
-  <Card href="/composer/getting-started" title="Build your first Prisma App" icon={<Rocket className="text-primary" />}>
-    Two services, one typed contract, one command to run them together.
-  </Card>
-  <Card href="/composer/porting-an-app" title="Port an app you already have" icon={<Milestone className="text-primary" />}>
-    Keep your server code and add the declarations around it.
-  </Card>
-</Cards>
-
-## Built for agents
-
-Composer is designed to be driven by an AI coding agent. Before you or your agent write any code, add the Composer skill:
+## What a Composer application is
 
-```npm
-npx skills add prisma/composer
-```
-
-Your agent now knows the whole API, including the ready-made Modules for scheduled jobs, blob storage, and event streams. Describe what you want, for example "a Next.js storefront calling an orders API with its own Postgres", and review TypeScript instead of infrastructure config.
-
-Three properties make this reliable rather than plausible:
-
-- **Modules snap together.** A capability arrives as a [Module](/composer/apps-and-modules) that owns its internals and exposes a typed port. Adding scheduled jobs or a blob store is a couple of lines of composition, not an integration your agent has to invent.
-- **The compiler checks the wiring.** A dependency wired to the wrong producer, a missing RPC handler, or a config value of the wrong shape does not compile. Mistakes fail `tsc` in seconds, not a deploy ten minutes later.
-- **Deploys are deterministic.** One command, no infrastructure config, and re-running it converges instead of drifting.
+A Composer application is a tree of services and resources. Each service declares the resources it needs, such as a database. Services call each other through typed contracts. Step through how the pieces relate:
 
-## Two rules shape everything
+<ConceptAnimation name="composer-app-graph" />
 
-- **Your code never reaches for its environment.** No `process.env`, no URLs. Every dependency arrives typed through one call, `service.load()`, which is why any environment (production, a staging copy, a test) is just a different set of injected values.
-- **The framework never bundles or transforms your code.** You build with the bundler you already use; the deploy assembles what you built.
+## A minimal example
 
-## What it looks like
+You declare a service as data instead of writing deployment scripts. The declaration below says the `storefront` service calls the `catalog` service's API and is built as a Next.js app:
 
-A service declares its dependencies as data; app code receives them from `service.load()`:
+```ts title="src/storefront/service.ts"
+import nextjs from '@prisma/composer/nextjs';
+import { rpc } from '@prisma/composer/service-rpc';
+import { compute } from '@prisma/composer-prisma-cloud';
+import { catalogContract } from '../catalog/contract.ts';
 
-```ts
-// service.ts, the declaration: pure data
 export default compute({
   name: 'storefront',
-  deps: { catalog: rpc(catalogContract) },   // "I call catalog's API"
+  deps: { catalog: rpc(catalogContract) },
   build: nextjs({ module: import.meta.url, appDir: '..' }),
 });
 ```
 
-```ts
-// app code: load() returns a client typed by that contract
+At runtime, the service receives a typed client for each declared dependency from `service.load()`. The contract determines which methods that client exposes and their TypeScript types, and calling one is an ordinary async function call:
+
+```ts title="src/storefront/data.ts"
+import service from './service.ts';
+
 const { catalog } = service.load();
 const { products } = await catalog.listProducts({});
 ```
 
-The root module is the app. It provisions the pieces and wires the typed ports:
+The root module ties the application together, wiring each declared dependency to the service or resource that provides it:
+
+```ts title="module.ts"
+import { module } from '@prisma/composer';
+import catalogModule from './src/catalog/module.ts';
+import ordersModule from './src/orders/module.ts';
+import storefrontService from './src/storefront/service.ts';
 
-```ts
-// module.ts
 export default module('store', ({ provision }) => {
-  const catalog = provision(catalogModule);      // owns its own Postgres
+  const catalog = provision(catalogModule);
   const orders = provision(ordersModule, { deps: { catalog: catalog.rpc } });
   provision(storefrontService, { deps: { catalog: catalog.rpc, orders: orders.rpc } });
 });
 ```
 
-Running `npx @prisma/cli@next composer deploy module.ts` provisions all of it: the services on Prisma Compute, the databases on Prisma Postgres, and the authenticated connections between them.
+TypeScript checks the wiring: a dependency bound to a producer with a different contract, a missing RPC handler, or a config value of the wrong shape is a compile error, not a failed deploy.
+
+## From declaration to deployment
+
+`npx prisma@next composer deploy module.ts` loads the root module, compares it with the deploy state stored for that environment, and creates or updates the services on Prisma Compute and the databases on Prisma Postgres. Re-running a deploy applies only the difference:
+
+<ConceptAnimation name="composer-deploy-flow" />
+
+## Core concepts
+
+- **App**: the complete deployable application, defined by the root module. Deployed as one Prisma [project](/compute#the-model).
+- **Service**: a running application component, declared with `compute()`. Deployed as one Prisma Compute service.
+- **Resource**: something a service depends on that is not a service: a Prisma Postgres database, a bucket, or a secret.
+- **Contract**: the typed interface through which services communicate, written as [Standard Schema](https://standardschema.dev) definitions.
+- **Module**: a reusable unit that provisions services and resources behind a typed boundary, such as a service packaged with its own database.
+
+[Apps and Modules](/composer/apps-and-modules) covers each in depth.
+
+## Design principles
+
+Two choices shape the rest of the framework. First, application code does not read `process.env` or hardcode URLs. Dependencies arrive typed through `service.load()`, so production, an isolated stage, and a test all run the same code with different injected values. Second, Composer does not bundle or transform your code. You build with your own bundler, and the deploy assembles what you built.
+
+## Get started
+
+<Cards>
+  <Card href="/composer/getting-started" title="Getting started" icon={<Rocket className="text-primary" />}>
+    Build and run a two-service application locally, then deploy it.
+  </Card>
+  <Card href="/composer/porting-an-app" title="Port an existing app" icon={<Milestone className="text-primary" />}>
+    Keep your server code and add the declarations around it.
+  </Card>
+</Cards>
+
+## Use Composer with an AI coding agent
+
+Composer's declaration-based API works well with coding agents because mistakes fail the TypeScript compile instead of a deploy. Before your agent writes Composer code, install the Composer skill, which gives it the current authoring API to work from:
+
+```npm
+npx skills add prisma/composer
+```
+
+The `prisma-composer` skill documents the full authoring API, the CLI commands, and the first-party Modules for scheduled jobs, object storage, and event streams. It is one of several [Prisma agent skills](/ai/tools/skills). Review the generated declarations like any other TypeScript: `npx tsc --noEmit` checks the wiring before you deploy.
 
 ## What to read next
 
-- [Getting started](/composer/getting-started): build and run a two-service app from scratch.
-- [Apps and Modules](/composer/apps-and-modules): how services, resources, and Modules compose into an app.
-- [Services and contracts](/composer/services-and-contracts): typed RPC between services, with authentication and retries handled for you.
-- [Databases](/composer/databases): give a service a Postgres database, plain or typed by a Prisma 8 contract.
-- [Local development](/composer/local-development): run the whole app on your machine with no cloud credentials.
-- [Deploying](/composer/deploying): production, isolated stages, CI, and teardown.
-- [CLI reference](/composer/cli-reference): every Composer command and flag.
-- [Limitations](/composer/limitations): what Composer does not do yet.
+Start with [Apps and Modules](/composer/apps-and-modules) for how services, resources, and Modules compose into an app, then [Services and contracts](/composer/services-and-contracts) for the typed RPC between them. When you're ready to run something, [Local development](/composer/local-development) works with no cloud credentials, and [Deploying](/composer/deploying) covers production, stages, and CI. Check [Limitations](/composer/limitations) before committing to a design.
diff --git a/apps/docs/content/docs/composer/local-development.mdx b/apps/docs/content/docs/composer/local-development.mdx
index 195e9a9618..f1260bf111 100644
--- a/apps/docs/content/docs/composer/local-development.mdx
+++ b/apps/docs/content/docs/composer/local-development.mdx
@@ -10,13 +10,13 @@ One command brings your whole app up on your machine, every service, its databas
 
 | You want to... | Run |
 | --- | --- |
-| Bring the app up locally | `npx @prisma/cli@next composer dev module.ts` |
-| Start clean (wipe local data first) | `npx @prisma/cli@next composer dev module.ts --fresh` |
-| Watch every service's logs | `npx @prisma/cli@next composer log module.ts` |
-| Watch one service | `npx @prisma/cli@next composer log module.ts catalog.service` |
-| Show more history first | `npx @prisma/cli@next composer log module.ts --tail 200` |
+| Bring the app up locally | `npx prisma@next composer dev module.ts` |
+| Start clean (wipe local data first) | `npx prisma@next composer dev module.ts --fresh` |
+| Watch every service's logs | `npx prisma@next composer log module.ts` |
+| Watch one service | `npx prisma@next composer log module.ts catalog.service` |
+| Show more history first | `npx prisma@next composer log module.ts --tail 200` |
 
-`module.ts` is your entry file, the one whose default export is the root module, the same file you pass to `deploy`. No `PRISMA_*` variables are needed; local dev never talks to the platform.
+`module.ts` is your entry file, the one whose default export is the root module, the same file you pass to `deploy`. No `PRISMA_*` variables are needed. Local dev never talks to the platform.
 
 ## Bring it up
 
@@ -24,10 +24,10 @@ Like deploy, `dev` runs your *built* output, so build first:
 
 ```npm
 npm run build
-npx @prisma/cli@next composer dev module.ts
+npx prisma@next composer dev module.ts
 ```
 
-It stands the app up and prints the front door, every service's local URL:
+It stands the app up and prints each service's local URL:
 
 ```text no-copy
 dev: ready
@@ -39,12 +39,12 @@ From here `dev` keeps running: it watches your built output and, when a service'
 
 `Ctrl-C` stops your app's service processes and exits. The local databases, buckets, and their data stay up, so the next `dev` is a warm start: same ports, same data. `--fresh` wipes this app's local instances and data before starting.
 
-`dev` does not print service logs. With several services running, streaming them all inline would bury the front door and the restart notices, so logs are their own command.
+`dev` does not print service logs. With several services running, streaming them all inline would bury the URL list and the restart notices, so logs are their own command.
 
 ## Logs
 
 ```npm
-npx @prisma/cli@next composer log module.ts
+npx prisma@next composer log module.ts
 ```
 
 This tails the merged logs of the already-running app: one stream, each line prefixed with the service it came from:
@@ -54,9 +54,9 @@ This tails the merged logs of the already-running app: one stream, each line pre
 [quotes] serving a quote
 ```
 
-It follows live, like `tail -f`; `Ctrl-C` stops watching. It only reads the running app. It never builds, provisions, starts, or stops anything, so you can open and close it freely alongside a running `dev`.
+It follows live, like `tail -f`. `Ctrl-C` stops watching. It only reads the running app. It never builds, provisions, starts, or stops anything, so you can open and close it freely alongside a running `dev`.
 
-- **One service:** pass its address, for example `composer log module.ts cron.runner`. A nested Module's service address is dotted, exactly as the front door prints it.
+- **One service:** pass its address, for example `composer log module.ts cron.runner`. A nested Module's service address is dotted, exactly as the startup output prints it.
 - **How much history:** `--tail <n>` sets how many recent lines to show before going live (default 20; `--tail 0` for live-only). Each service's log is cleared when it starts fresh, so you are never scrolling back through past sessions.
 - **Nothing running yet?** If you have not run `dev` (or you stopped it), `log` says so and points you at `dev`.
 
@@ -65,8 +65,8 @@ It follows live, like `tail -f`; `Ctrl-C` stops watching. It only reads the runn
 Everything above the cloud boundary is real: your actual service code, real databases you can migrate and query, real object storage, and the same wiring a deploy creates, including [service keys](/composer/services-and-contracts#calls-are-authenticated-for-you). What is swapped are the providers underneath: local emulators stand in for Prisma Compute and Prisma Postgres, so no token, workspace, or network is involved. Three consequences worth knowing:
 
 - **Direct RPC probes get `401` here too.** `dev` runs the deploy pipeline, so providers only accept their wired consumers, exactly as in production. Exercise a provider through a consumer, or in [tests](/composer/testing), where nothing is provisioned and every call passes through.
-- **Unset secrets do not stop the app.** A secret you have not set in your shell gets a local placeholder and a one-line warning; the app boots and serves, and only the code path that actually spends that secret fails, at the real external service it calls. Set the secret in your shell to exercise that path.
-- **The emulators outlive a session.** They are shared, machine-wide daemons, so your data survives `Ctrl-C` and even a reboot until you pass `--fresh`. That is what makes restarts warm.
+- **Unset secrets do not stop the app.** A secret you have not set in your shell gets a local placeholder and a one-line warning. The app boots and serves. Only the code path that actually uses that secret fails, at the real external service it calls. Set the secret in your shell to exercise that path.
+- **The emulators outlive a session.** They are shared, machine-wide daemons, so your data survives `Ctrl-C` and even a reboot until you pass `--fresh`. That is what makes restarts warm. If a previous session died uncleanly and `dev` stops with `postgres emulator failed to start database ... is already running`, start once with `--fresh` to clear the stale instance.
 
 Windows is not supported yet; see [Limitations](/composer/limitations).
 
diff --git a/apps/docs/content/docs/composer/porting-an-app.mdx b/apps/docs/content/docs/composer/porting-an-app.mdx
index 0909e703b0..8732c1e64e 100644
--- a/apps/docs/content/docs/composer/porting-an-app.mdx
+++ b/apps/docs/content/docs/composer/porting-an-app.mdx
@@ -6,7 +6,7 @@ metaTitle: Port an existing app | Prisma Composer
 metaDescription: Port an existing Node.js, Bun, or Next.js app to Prisma Composer by adding service declarations around the server code you already have.
 ---
 
-You do not rewrite an app to put it on Composer; you declare it. The server code you already have stays the server, and you add the declaration around it. This page covers the three common cases.
+Bringing an existing app to Composer does not mean rewriting it. The server code you already have stays the server, and you add a service declaration around it. This page covers the three common cases.
 
 ## A Node.js or Bun service
 
@@ -18,15 +18,15 @@ Add a `service.ts` with `compute({ name, deps, build: node({ module, entry }) })
    Bun.serve({ port: service.port(), hostname: '0.0.0.0', fetch: handler });
    ```
 
-2. **Replace every other `process.env` read** with what it really is: a field of the service's [input schema](/composer/service-input) for config and credentials, or a [dependency](/composer/services-and-contracts) for anything another service provides. If a value differs per stage (an app origin, an external URL), bind it with `envParam`; a credential, with `envSecret`.
+2. **Replace every other `process.env` read.** Config and credentials become fields of the service's [input schema](/composer/service-input). Anything another service provides becomes a [dependency](/composer/services-and-contracts). If a value differs per stage (an app origin, an external URL), bind it with `envParam`. Bind a credential with `envSecret`.
 
 3. **If it talks to Postgres**: declare `deps: { db: postgres() }` and build your existing client (`pg`, Bun's `SQL`, whatever you use today) from the injected `db.url` instead of a connection-string env var. See [Databases](/composer/databases).
 
-Your build must produce a self-contained entry file, with everything inlined except runtime built-ins. Keep your own build if it already does; otherwise a one-line `bun build --target=bun` gets you there (see [Getting started](/composer/getting-started#5-build)).
+Your build must produce a self-contained entry file, with everything inlined except runtime built-ins. Keep your own build if it already does this. Otherwise, a one-line `bun build --target=bun` produces one. See [Getting started](/composer/getting-started#5-build).
 
 ## A Next.js app
 
-Use the `nextjs` build adapter instead of `node`; `next build` with `output: 'standalone'` is the whole build:
+Use the `nextjs` build adapter instead of `node`. With `output: 'standalone'` set, `next build` is the whole build:
 
 ```ts title="src/service.ts"
 import nextjs from '@prisma/composer/nextjs';
@@ -59,13 +59,13 @@ export default defineConfig({
 });
 ```
 
-Any page or server action that calls `service.load()` needs `export const dynamic = 'force-dynamic'`, because the runtime environment does not exist at build time and Next.js will not re-read it for prerendered routes.
+Add `export const dynamic = 'force-dynamic'` to any page or server action that calls `service.load()`. The runtime environment does not exist at build time, and Next.js will not re-read it for prerendered routes.
 
-[`examples/storefront-auth`](https://github.com/prisma/composer/tree/main/examples/storefront-auth) in the Composer repository is a complete ported-shaped app: a Next.js frontend calling a Bun API service that owns a Postgres.
+[`examples/storefront-auth`](https://github.com/prisma/composer/tree/main/examples/storefront-auth) in the Composer repository is a complete example of a ported app: a Next.js frontend calling a Bun API service that owns a Postgres.
 
 ## More than one service
 
-Port them into one `module.ts` and replace the URLs they used to reach each other with [contracts](/composer/services-and-contracts). That is the payoff: the edges become typed, and every environment (production, stages, tests) gets the wiring for free.
+Port them into one `module.ts` and replace the URLs they used to reach each other with [contracts](/composer/services-and-contracts). That is the payoff: the calls between services become typed, and every environment (production, stages, tests) gets the wiring for free.
 
 ## Verify the port
 
@@ -73,10 +73,10 @@ Build, then run the app locally before you deploy:
 
 ```npm
 npm run build
-npx @prisma/cli@next composer dev module.ts
+npx prisma@next composer dev module.ts
 ```
 
-Every service should appear in the front-door list with a local URL. If a service fails at boot with a module-resolution error, its build left something un-inlined; check that the entry file is self-contained.
+Every service should appear in the startup output with a local URL. If a service fails at boot with a module-resolution error, its build left something un-inlined. Check that the entry file is self-contained.
 
 ## Next steps
 
diff --git a/apps/docs/content/docs/compute/branching.mdx b/apps/docs/content/docs/compute/branching.mdx
index 456b473282..2a138db7f1 100644
--- a/apps/docs/content/docs/compute/branching.mdx
+++ b/apps/docs/content/docs/compute/branching.mdx
@@ -6,9 +6,9 @@ metaTitle: Branching | Prisma Compute
 metaDescription: How production and preview branches work in Prisma Compute, how the CLI picks a branch, and how branches are created and cleaned up.
 ---
 
-A branch is an isolated environment for one line of work. Every branch in a project gets its own apps, databases, and deployments, so work on a preview never touches production.
+A branch is an isolated environment for one line of work. Every branch in a project owns its own services, deployments, and any databases created on it, so preview deploys never share Compute resources with production. One caveat: a database your app reaches through a `DATABASE_URL` environment variable is only as isolated as that variable's value. Give previews their own preview-scoped `DATABASE_URL`. See [Environment variables](/compute/environment-variables) for details.
 
-A platform branch usually matches a Git branch name, but in Prisma it is a real resource that owns its own apps and databases:
+A platform branch usually matches a Git branch name, but in Prisma it is a real resource that owns its own services and databases:
 
 <ConceptAnimation name="compute-model" />
 
@@ -32,25 +32,25 @@ Commands that take a branch resolve it in this order:
 Inside a Git repo, running `service list` from `feature/search` targets the `feature/search` branch automatically. To target a branch explicitly:
 
 ```npm
-npx @prisma/cli@next service list --branch feature/search
+npx prisma@next service list --branch feature/search
 ```
 
 Inspect platform branches:
 
 ```npm
-npx @prisma/cli@next branch list
+npx prisma@next branch list
 ```
 
 Listing branches doesn't expand the services and databases inside them. Use the `service` and `postgres` commands to inspect those.
 
 ## Creating branches
 
-You rarely create branches manually. They appear when work needs them:
+You rarely create branches manually. They are created automatically:
 
 - **From GitHub**: when a repo is connected, branch and push events create or update the matching platform branch automatically. To set this up, see the [GitHub integration docs](/compute/github).
 - **From the CLI**: commands that target a branch that doesn't exist yet, such as `service create --branch feature/search` or a [Composer stage deploy](/composer/deploying), create it.
 
-Connecting GitHub doesn't create branches retroactively; it aligns your default branch with the repo's default branch and wires up automation for future events.
+Connecting GitHub doesn't create branches retroactively. It aligns your default branch with the repo's default branch and wires up automation for future events.
 
 ## Cleaning up
 
diff --git a/apps/docs/content/docs/compute/cli-reference.mdx b/apps/docs/content/docs/compute/cli-reference.mdx
index b75b04b151..8996c07bf4 100644
--- a/apps/docs/content/docs/compute/cli-reference.mdx
+++ b/apps/docs/content/docs/compute/cli-reference.mdx
@@ -1,222 +1,45 @@
 ---
 title: CLI reference
-description: Every Prisma Compute command, flag, and environment variable in the unified Prisma CLI.
+description: Where the Prisma Compute commands in the unified Prisma CLI are documented.
 url: /compute/cli-reference
 metaTitle: CLI reference | Prisma Compute
-metaDescription: Complete reference for the Prisma Compute commands in the unified Prisma CLI, including service, deployment, domain, project, env, git, branch, postgres, and bucket commands.
+metaDescription: Find the reference pages for the Prisma Compute commands in the unified Prisma CLI, including service, deployment, domain, project, env, git, branch, postgres, and bucket commands.
 ---
 
-This page is the complete reference for the Prisma Compute commands in the unified Prisma CLI. For a guided start, see [Getting started](/compute/getting-started).
+The Prisma Compute commands ship in the unified Prisma CLI, and each command group is documented in the [Prisma 8 CLI reference](/cli/v8). For a guided start, see [Getting started](/compute/getting-started).
 
-Until launch, the unified CLI is published as the `next` tag of the `@prisma/cli` package. Run it without installing:
+The unified CLI is the Prisma 8 RC CLI, published as `prisma@next`. Run it without installing:
 
 ```npm
-npx @prisma/cli@next <command>
+npx prisma@next <command>
 ```
 
-The platform command groups are `auth`, `init`, `project`, `project env`, `service`, `service deployment`, `service domain`, `build`, `git`, `branch`, `postgres`, `bucket`, and `agent`. The same binary also carries the [Prisma 8 data commands](/cli/v8) and the [Composer commands](/composer/cli-reference).
+Deployments are created by a git push, the [Console](https://pris.ly/pdp), or [Composer](/composer). There is no standalone `deploy` command for a single service. Use the command groups below to manage the projects, services, and deployments those flows create.
 
-Deployments are created by a git push, the [Console](https://pris.ly/pdp), or [Composer](/composer); there is no standalone `deploy` command for a single service. The commands below manage everything around those deployments.
+## Command groups
 
-## `auth`
+| Command group | Purpose |
+| --- | --- |
+| [`auth`](/cli/v8/auth) | Sign in to your Prisma account, sign out, and manage workspace sessions. |
+| [`init`](/cli/v8/platform-init) | Write a committed compute config for the app in the current directory. |
+| [`project`](/cli/v8/project) | Create, link, and inspect projects, and manage project environment variables. |
+| [`service`](/cli/v8/service) | Manage services, their deployments, logs, and custom domains. |
+| [`build`](/cli/v8/build) | Stream logs for builds created by a git push or the Console. |
+| [`git`](/cli/v8/git) | Connect a GitHub repository for push-to-deploy. |
+| [`branch`](/cli/v8/branch) | List platform branches for a project. |
+| [`postgres`](/cli/v8/postgres) | Create and manage Prisma Postgres databases. |
+| [`bucket`](/cli/v8/bucket) | Create and manage object-store buckets. |
+| [`agent`](/cli/v8/agent) | Install Prisma skills for AI coding agents. |
+| [`telemetry`](/cli/v8/telemetry) | Show, enable, or disable anonymous CLI telemetry. |
+| [`feedback`](/cli/v8/feedback) | Send feedback to the Prisma CLI team. |
 
-Manage authentication.
+The same binary also carries the [Prisma 8 data commands](/cli/v8#data-commands) and the [Composer commands](/composer/cli-reference).
 
-| Command          | Description                                          |
-| ---------------- | ---------------------------------------------------- |
-| `auth login`     | Log in to your Prisma platform account (browser flow) |
-| `auth logout`    | Clear stored authentication credentials               |
-| `auth whoami`    | Show the authenticated user and accessible workspace  |
-| `auth workspace` | Manage local workspace sessions                       |
-
-The browser step in `auth login` needs a human. Afterwards, anything running in that environment inherits the session, including coding agents. For CI, set [`PRISMA_SERVICE_TOKEN`](#environment-variables) instead.
-
-## `init`
-
-Write the committed compute config for the current directory. `init` detects your framework and writes `prisma.compute.ts` (or, with `--config-format json`, a dependency-free `prisma.compute.json`). The `service` commands read this file for service targets, framework, entry point, HTTP port, and region.
-
-| Flag                         | Description                                                          |
-| ---------------------------- | --------------------------------------------------------------------- |
-| `--framework <framework>`    | Framework override; detected when omitted (`nextjs`, `nuxt`, `astro`, `hono`, `nestjs`, `tanstack-start`, `custom`, `bun`) |
-| `--entry <path>`             | Source entrypoint for entrypoint frameworks (Bun, Hono)                |
-| `--http-port <port>`         | HTTP port the app listens on                                           |
-| `--region <region>`          | Region used when a deploy creates the service (`us-east-1`, `us-west-1`, `eu-west-3`, `eu-central-1`, `ap-northeast-1`, `ap-southeast-1`) |
-| `--name <app-name>`          | App name                                                               |
-| `--link` / `--no-link`       | Link this directory to a project, or skip that step                    |
-| `--project <id-or-name>`     | Project to link this directory to                                      |
-| `--install` / `--no-install` | Install `@prisma/compute-sdk` for config types, or skip that step      |
-| `--config-format <ts\|json>` | `ts` (default) writes `prisma.compute.ts`; `json` writes `prisma.compute.json` |
-
-## `service`
-
-Manage services for a project. Most commands take an optional `[service]` positional to pick a target from `prisma.compute.ts` when the config defines multiple services, plus `--service <name>` and `--project <id-or-name>`.
-
-| Command                  | Description                                       |
-| ------------------------ | -------------------------------------------------- |
-| `service list`           | List the services in a project (`--branch` scopes it) |
-| `service create <name>`  | Create a service (`--region`, `--branch`)          |
-| `service show [service]` | Show the service and its current deployment        |
-| `service open [service]` | Open the service's live URL                        |
-| `service remove [service]` | Remove the service from the resolved branch      |
-
-## `service deployment`
-
-Manage deployments for a service. Deployments are created by a git push, the Console, or Composer; these commands operate on the ones that exist.
-
-| Command                                    | Description                                                        |
-| ------------------------------------------ | ------------------------------------------------------------------- |
-| `service deployment list [service]`        | List deployments for the service                                    |
-| `service deployment show <deployment>`     | Show a deployment in detail                                         |
-| `service deployment promote <deployment>`  | Promote a deployment to production by rebuilding with production env vars |
-| `service deployment rollback`              | Roll back production to a previous deployment (`--to <deployment>`; defaults to the one before the live deployment) |
-| `service deployment start <deployment>`    | Start a stopped deployment                                          |
-| `service deployment stop <deployment>`     | Stop a running deployment                                           |
-| `service deployment delete <deployment>`   | Delete a deployment and the artifact it holds                       |
-
-Promotion rebuilds the deployment with production environment variables, so config changes take effect on promote. Rollback switches production back to an existing deployment. See [Deployments](/compute/deployments).
-
-## `service domain`
-
-Manage custom domains for a service. All commands take a `<hostname>` argument plus the usual service and project selectors. Domains target the production branch; see [Domains](/compute/domains).
-
-| Command                           | Description                                                    |
-| --------------------------------- | --------------------------------------------------------------- |
-| `service domain add <hostname>`   | Register a custom domain on the service's production branch      |
-| `service domain show <hostname>`  | Show custom domain status and certificate details                |
-| `service domain wait <hostname>`  | Wait until a custom domain is active or failed                    |
-| `service domain retry <hostname>` | Retry custom domain DNS verification and TLS provisioning         |
-| `service domain remove <hostname>`| Detach a custom domain from the service                           |
-
-## `build`
-
-Inspect builds created by a git push or the Console.
-
-| Command                | Description                                                                  |
-| ---------------------- | ----------------------------------------------------------------------------- |
-| `build logs <buildId>` | Stream logs for a build; `--follow` keeps streaming while the build runs, `--cursor <cursor>` resumes from a cursor a previous run reported |
-
-## `project`
-
-Manage projects and directory bindings.
-
-| Command                        | Description                                                  |
-| ------------------------------ | ------------------------------------------------------------- |
-| `project list`                 | List all projects in your workspace                            |
-| `project show`                 | Show this directory's project binding                          |
-| `project create <name>`        | Create a project and link the directory to it                  |
-| `project link [id-or-name]`    | Link the directory to an existing project                      |
-| `project rename <name>`        | Rename the resolved project                                    |
-| `project remove <id-or-name>`  | Remove a project permanently, after exact id confirmation      |
-| `project transfer <id-or-name>`| Transfer a project to another workspace, after exact id confirmation |
-
-Linking writes `.prisma/local.json`, a gitignored local pin of the workspace and project. It is a cache, not committed config. Committed configuration lives in `prisma.compute.ts` (or `prisma.compute.json`), which [`init`](#init) writes and the `service` commands read.
-
-## `project env`
-
-Manage environment variables for the active project. Writes require an explicit scope: exactly one of `--role <production|preview>` or `--branch <git-name>` (running without one fails with `PROJECT.USAGE_ERROR`, so a write never silently targets production). See [Environment variables](/compute/environment-variables).
-
-| Command                               | Description                                                |
-| ------------------------------------- | ----------------------------------------------------------- |
-| `project env add <KEY=value\|KEY>`    | Create a variable; pass just `KEY` to read the value from your environment |
-| `project env update <KEY=value\|KEY>` | Replace an existing variable's value; a bare `KEY` also reads from your environment |
-| `project env list`                    | List variable names and metadata for a scope, never values   |
-| `project env remove <key>`            | Remove a variable from a scope                               |
-
-`add` and `update` also accept `--file <path>` to read `KEY=VALUE` assignments from a dotenv file, and every `project env` command takes `--project <id-or-name>`.
-
-Values are write-only: encrypted at rest and never returned by any surface. They resolve at deploy time; redeploy to apply changes.
-
-## `branch`
-
-Inspect platform branches for the resolved project without creating remote state. See [Branching](/compute/branching).
-
-| Command       | Description                                      |
-| ------------- | ------------------------------------------------- |
-| `branch list` | List platform branches for the resolved project    |
-
-## `postgres`
-
-Manage Prisma Postgres databases for the resolved project. Most commands take `--project <id-or-name>` and `--branch <git-name>`.
-
-| Command                                    | Description                                                    |
-| ------------------------------------------ | --------------------------------------------------------------- |
-| `postgres list`                            | List databases                                                   |
-| `postgres show <database>`                 | Show database metadata without secret values                     |
-| `postgres create <name>`                   | Create a database and print its one-time connection URL; `--region` sets the Prisma Postgres region |
-| `postgres usage <database>`                | Show usage metrics for a database                                |
-| `postgres restore <database>`              | Restore from a backup, after exact id confirmation               |
-| `postgres remove <database>`               | Remove a database, after exact id confirmation                   |
-| `postgres backup`                          | Inspect platform-created database backups                        |
-| `postgres connection`                      | Manage one-time-view database connection strings                 |
-
-## `bucket`
-
-Manage object-store buckets for the resolved project.
-
-| Command                     | Description                                  |
-| --------------------------- | --------------------------------------------- |
-| `bucket list`               | List object-store buckets                      |
-| `bucket create`             | Create an object-store bucket                  |
-| `bucket delete <bucket-id>` | Delete a bucket and all its access keys        |
-| `bucket key`                | Manage access keys for an object-store bucket  |
-
-## `git`
-
-Manage the GitHub repository connection. See [GitHub integration](/compute/github).
-
-| Command                  | Description                                                      |
-| ------------------------ | ----------------------------------------------------------------- |
-| `git connect [git-url]`  | Connect the resolved project to a GitHub repository; starts the GitHub App install flow if needed |
-| `git disconnect`         | Stop push-triggered automation; keeps the project and existing branches |
-
-## `agent`
-
-Install and inspect Prisma agent skills.
-
-| Command         | Description                                                          |
-| --------------- | ---------------------------------------------------------------------- |
-| `agent install` | Install Prisma skills for coding agents                                |
-| `agent update`  | Refresh installed Prisma skills                                        |
-| `agent status`  | Show installed Prisma skills                                           |
-
-`agent install` and `agent update` take `--agent <agent>` (repeatable), `--all-agents`, `--skill <skill>` (repeatable), `--global`, `--copy`, and `--dry-run`. For example, `agent install --skill prisma-compute` installs the Compute deploy skill.
-
-## Global flags
-
-| Flag                                | Description                                        |
-| ----------------------------------- | --------------------------------------------------- |
-| `--format <human\|json>`            | Output format                                        |
-| `--json`                            | Shorthand for `--format json`                        |
-| `--log-level <level>`               | Commentary verbosity: `error`, `warn`, `info`, `verbose` |
-| `-q`, `--quiet` / `-v`, `--verbose` | Shorthands for `--log-level error` / `verbose`       |
-| `-y`, `--yes`                       | Accept prompt defaults without asking                |
-| `--confirm <token>`                 | Grant a consent prompt non-interactively by typing its token (repeatable) |
-| `--interactive` / `--no-interactive`| Force prompts on or off; non-interactive fails instead of asking |
-| `--color` / `--no-color`            | Control colored output                               |
-| `--config <path>`                   | Read a specific config file                          |
-
-## JSON output
-
-In `--json` mode, every command emits an envelope you can branch on:
-
-- `envelope.ok`: `true` or `false`.
-- `envelope.result`: the command's data, when `ok` is `true`.
-- `envelope.error.code`: a dotted `NAMESPACE.SUBCODE`, for example `SERVICE.PROJECT_SETUP_REQUIRED` or `PROJECT.USAGE_ERROR`.
-- `envelope.error.summary` and `error.why`: what failed and why it is rejected.
-- `nextActions`: concrete follow-up commands, machine-readable, which is what makes the CLI drivable by agents.
-
-Branch on `error.code`, not the message text: codes are a stable contract, while message wording can change between releases.
-
-## Environment variables
-
-| Variable               | Description                                                        |
-| ---------------------- | ------------------------------------------------------------------- |
-| `PRISMA_SERVICE_TOKEN` | Authenticate without a browser (CI); takes priority over any stored session |
-| `PRISMA_WORKSPACE_ID`  | Workspace to target when authenticating with a service token         |
+Global flags, the JSON output envelope, and the platform environment variables (`PRISMA_SERVICE_TOKEN`, `PRISMA_WORKSPACE_ID`, `PRISMA_PROJECT_ID`, `PRISMA_SERVICE_ID`) are documented on [CLI configuration](/cli/v8/configuration).
 
 ## Related
 
 - [Getting started](/compute/getting-started)
+- [Prisma 8 CLI reference](/cli/v8) for every command and flag
 - [Prisma Composer CLI reference](/composer/cli-reference) for CLI-driven multi-service deploys
-- [Prisma 8 CLI reference](/cli/v8) for the contract, database, and migration commands
 - [Known limitations](/compute/limitations)
diff --git a/apps/docs/content/docs/compute/configuration.mdx b/apps/docs/content/docs/compute/configuration.mdx
index 33028d5cdf..0eab7f0b2f 100644
--- a/apps/docs/content/docs/compute/configuration.mdx
+++ b/apps/docs/content/docs/compute/configuration.mdx
@@ -12,11 +12,11 @@ metaDescription: "Reference for the prisma.compute.ts file: declare your app's f
 - **A monorepo.** Declare several apps in one repository and deploy them together, or one at a time.
 - **Type safety.** Catch a typo'd field or an invalid framework in your editor, before you deploy.
 
-The file is read by platform builds and the [`service` commands](/compute/cli-reference#service). It never selects your project, branch, or production; those stay explicit. It also does not configure a database; see [Environment variables](/compute/environment-variables) for the connection string.
+Platform builds and the [`service` commands](/cli/v8/service) read the file. It never selects your project, branch, or production target. You select those explicitly. It also does not configure a database. See [Environment variables](/compute/environment-variables) for the connection string.
 
 ## A minimal config
 
-Export a single `app` with `defineComputeConfig`:
+Export a single `app` with `defineComputeConfig`. The config keys are named `app` and `apps`. Each entry describes what the rest of the docs and the CLI call a **service**:
 
 ```ts title="prisma.compute.ts"
 import { defineComputeConfig } from "@prisma/compute-sdk/config";
@@ -30,17 +30,17 @@ export default defineComputeConfig({
 });
 ```
 
-Every field is optional. An empty `app: {}` is valid and defers entirely to detection. The values you do set become the defaults for builds and the `service` commands; explicit flags still win over them.
+Every field is optional. An empty `app: {}` is valid and defers entirely to detection. The values you do set become the defaults for builds and the `service` commands. Explicit flags still win over them.
 
 :::info
 
-`defineComputeConfig` is an identity helper that gives the file full type checking. The CLI resolves the import when it reads your config, so the file works without a local install. To get editor types, add the package as a dev dependency:
+The `defineComputeConfig` helper gives the file full type checking without changing the config at runtime. The CLI resolves the import when it reads your config, so the file works without a local install. To get editor types, add the package as a dev dependency:
 
 ```npm
 npm install -D @prisma/compute-sdk
 ```
 
-JavaScript configs work too: a plain `export default { app: { ... } }` from `prisma.compute.js`/`.mjs`/`.cjs` is valid, just without the type checking. So is a static `prisma.compute.json` with the same shape; it may include a `$schema` field for editor tooling, which is ignored at load time.
+JavaScript configs work too: a plain `export default { app: { ... } }` from `prisma.compute.js`/`.mjs`/`.cjs` is valid, just without the type checking. A static `prisma.compute.json` with the same shape is also valid. It may include a `$schema` field for editor tooling, which the CLI ignores at load time.
 
 :::
 
@@ -128,7 +128,7 @@ export default defineComputeConfig({
 
 - Every field is optional. A field you set overrides the framework default; a field you omit is inferred.
 - `command: null` skips the build step entirely.
-- `entrypoint` names the built artifact's entry file, relative to `outputDirectory` when one is set (otherwise to the app root). For `hono` and `bun` apps it's required whenever you set `outputDirectory`, and setting both `entry` and a differing `build.entrypoint` is a configuration error.
+- `entrypoint` names the built artifact's entry file, relative to `outputDirectory` when one is set (otherwise to the app root). For `hono` and `bun` apps it's required whenever you set `outputDirectory`. Setting both `entry` and a differing `build.entrypoint` is a configuration error.
 - A `build` block works with every framework. With the `custom` framework it's required, and must set both `outputDirectory` and `entrypoint`.
 
 Without a `build` block, the CLI infers everything (running your `package.json` build script when there is one, otherwise the framework default) and shows you what it chose during the deploy.
@@ -139,7 +139,7 @@ The CLI reads the **nearest** config file, searching from your current directory
 
 Per directory, exactly one of `prisma.compute.ts`, `prisma.compute.mts`, `prisma.compute.js`, `prisma.compute.mjs`, `prisma.compute.cjs`, or `prisma.compute.json` may exist.
 
-The config file's directory is treated as the project directory: the [`.prisma/local.json`](/compute/getting-started#create-or-link-a-project) project pin lives there, and paths in the config (`root`, `env.file`) resolve from there. That means the config means the same thing no matter which subdirectory you run the command from.
+The config file's directory is treated as the project directory: the [`.prisma/local.json`](/compute/getting-started#create-or-link-a-project) project pin lives there, and paths in the config (`root`, `env.file`) resolve from there. That means the config behaves the same no matter which subdirectory you run the command from.
 
 ## Monorepos
 
@@ -173,7 +173,7 @@ The config never sets your project, branch, or production target; those are alwa
 
 ## What's next
 
-- [CLI reference](/compute/cli-reference): every command and flag.
+- [CLI reference](/cli/v8): every command and flag.
 - [Deploy your first app](/prisma-compute/deploy): the end-to-end quickstart.
 - [Environment variables](/compute/environment-variables): scoped configuration, secrets, and your database connection string.
 - [GitHub integration](/compute/github): deploy-on-push, including monorepos.
diff --git a/apps/docs/content/docs/compute/deployments.mdx b/apps/docs/content/docs/compute/deployments.mdx
index 42f1d4411e..3a546fe871 100644
--- a/apps/docs/content/docs/compute/deployments.mdx
+++ b/apps/docs/content/docs/compute/deployments.mdx
@@ -14,17 +14,17 @@ Deployments are created three ways:
 
 - **A git push.** After you [connect a GitHub repository](/compute/github), pushing a branch builds and deploys it: the default Git branch deploys to production, and every other branch gets an isolated preview.
 - **The [Console](https://pris.ly/pdp).** Trigger a build and deployment from the browser.
-- **[Prisma Composer](/composer).** `composer deploy` builds nothing but assembles your built services and provisions them, which is the CLI-driven path for multi-service apps.
+- **[Prisma Composer](/composer).** `composer deploy` does not build your services; it assembles the services you have already built and provisions them. This is the CLI-driven path for multi-service apps.
 
-The unified CLI does not have a standalone `deploy` command for a single service; it manages the deployments those flows create.
+The unified CLI does not have a standalone `deploy` command for a single service. Use its `service` commands to manage the deployments those flows create. During the beta, the earlier CLI (`@prisma/cli@latest`) still offers an `app deploy` command that builds and deploys a single service from your terminal in one step. The same commands below manage the deployments it creates.
 
 ## Inspect deployments
 
 ```npm
-npx @prisma/cli@next service show --service web
-npx @prisma/cli@next service open --service web
-npx @prisma/cli@next service deployment list --service web
-npx @prisma/cli@next service deployment show dep_123
+npx prisma@next service show --service web
+npx prisma@next service open --service web
+npx prisma@next service deployment list --service web
+npx prisma@next service deployment show dep_123
 ```
 
 `service show` describes the service and its current deployment, `service open` opens its URL, `deployment list` lists the deployment history, and `deployment show` shows one deployment in detail.
@@ -34,7 +34,7 @@ npx @prisma/cli@next service deployment show dep_123
 Each deployment starts as a build. Stream a build's logs, live or after the fact:
 
 ```npm
-npx @prisma/cli@next build logs bld_123 --follow
+npx prisma@next build logs bld_123 --follow
 ```
 
 `--follow` keeps the connection open while the build runs; `--cursor <cursor>` resumes from a cursor a previous run reported. Build ids appear in `service show`, `service deployment show`, and the Console.
@@ -44,16 +44,16 @@ npx @prisma/cli@next build logs bld_123 --follow
 Promote a preview deployment to production:
 
 ```npm
-npx @prisma/cli@next service deployment promote dep_123 --service web
+npx prisma@next service deployment promote dep_123 --service web
 ```
 
-Promotion rebuilds the deployment with **production** environment variables and makes the result live behind the service's endpoint. The rebuild is what lets a deployment built for a preview branch pick up production config on its way to production.
+Promotion rebuilds the deployment with **production** environment variables and makes the result live behind the service's endpoint. The rebuild is what lets a deployment built for a preview branch pick up production environment variables on its way to production.
 
 Roll back production to a previous deployment. Rollback reuses an existing build, so there is no rebuild step between you and a known-good state:
 
 ```npm
-npx @prisma/cli@next service deployment rollback --service web
-npx @prisma/cli@next service deployment rollback --service web --to dep_123
+npx prisma@next service deployment rollback --service web
+npx prisma@next service deployment rollback --service web --to dep_123
 ```
 
 Without `--to`, rollback targets the deployment before the live one.
@@ -61,9 +61,9 @@ Without `--to`, rollback targets the deployment before the live one.
 ## Start, stop, delete
 
 ```npm
-npx @prisma/cli@next service deployment stop dep_123
-npx @prisma/cli@next service deployment start dep_123
-npx @prisma/cli@next service deployment delete dep_123
+npx prisma@next service deployment stop dep_123
+npx prisma@next service deployment start dep_123
+npx prisma@next service deployment delete dep_123
 ```
 
 Stopping a deployment takes it out of service without deleting its artifact; starting it brings it back. Deleting a deployment removes it and the artifact it holds, after confirmation.
@@ -71,10 +71,10 @@ Stopping a deployment takes it out of service without deleting its artifact; sta
 ## Remove a service
 
 ```npm
-npx @prisma/cli@next service remove --service web
+npx prisma@next service remove --service web
 ```
 
-This removes the service from the resolved branch. Pass `--yes` to skip the confirmation prompt.
+This removes the service from the selected branch (your active Git branch, unless you pass `--branch`). Pass `--yes` to skip the confirmation prompt.
 
 ## Next steps
 
diff --git a/apps/docs/content/docs/compute/domains.mdx b/apps/docs/content/docs/compute/domains.mdx
index b4837ea023..5af29aee48 100644
--- a/apps/docs/content/docs/compute/domains.mdx
+++ b/apps/docs/content/docs/compute/domains.mdx
@@ -23,7 +23,7 @@ Domain commands target the [production branch](/compute/branching). Pointing the
 ### 1. Add a domain
 
 ```npm
-npx @prisma/cli@next service domain add shop.acme.com --service web
+npx prisma@next service domain add shop.acme.com --service web
 ```
 
 Registration verifies DNS up front. If the **CNAME** record isn't visible yet, the command fails with a `DOMAIN_DNS_NOT_CONFIGURED` error and prints the record name and value for you to create. Re-running `add` for a hostname that's already attached is safe: it shows the existing domain instead of failing.
@@ -41,7 +41,7 @@ The CLI prints the record name as the full hostname. If your DNS provider expect
 
 :::note[What is switchboard?]
 
-Switchboard is the routing layer that sits in front of your Compute app. Switchboard verifies the domain, provisions and terminates TLS, then forwards traffic to your app: one domain, one CNAME, one Compute app.
+Switchboard is the routing layer that sits in front of your Compute app. Switchboard verifies the domain, provisions and terminates TLS, then forwards traffic to your app.
 
 :::
 
@@ -50,13 +50,13 @@ Switchboard is the routing layer that sits in front of your Compute app. Switchb
 Once the CNAME record has propagated, re-run `service domain add`. This time registration succeeds and TLS provisioning starts. Track it with:
 
 ```npm
-npx @prisma/cli@next service domain wait shop.acme.com --service web
+npx prisma@next service domain wait shop.acme.com --service web
 ```
 
 `wait` polls until the domain is active, up to 15 minutes. For a single status check, use `--timeout 0`:
 
 ```npm
-npx @prisma/cli@next service domain wait shop.acme.com --service web --timeout 0 --json
+npx prisma@next service domain wait shop.acme.com --service web --timeout 0 --json
 ```
 
 A single check exits non-zero with `DOMAIN_VERIFICATION_TIMEOUT` while the domain is still provisioning, so automation should read the status event rather than the exit code. In `--json` mode, `wait` streams newline-delimited status events, so an agent can track provisioning as it progresses.
@@ -64,10 +64,10 @@ A single check exits non-zero with `DOMAIN_VERIFICATION_TIMEOUT` while the domai
 ## Remove a domain
 
 ```npm
-npx @prisma/cli@next service domain remove shop.acme.com --service web
+npx prisma@next service domain remove shop.acme.com --service web
 ```
 
-Removing detaches the domain from the app; pass `--yes` to skip the confirmation prompt. Prisma can't touch your DNS, so the CNAME record stays behind: delete it at your provider once you no longer need it.
+Removing detaches the domain from the app. Pass `--yes` to skip the confirmation prompt. Prisma can't touch your DNS, so the CNAME record stays behind. Delete it at your provider once you no longer need it.
 
 ## States
 
@@ -85,20 +85,20 @@ A domain moves through these states:
 - Custom domains are only available on production apps.
 - DNS uses CNAME records only. Apex domains need a DNS provider that supports CNAME-like records (ALIAS, ANAME, or CNAME flattening) at the apex.
 - Wildcard hostnames such as `*.acme.com` are rejected.
-- Up to 3 custom domains per app; more returns `DOMAIN_QUOTA_EXCEEDED`.
+- Up to 3 custom domains per app. Adding more returns `DOMAIN_QUOTA_EXCEEDED`.
 - There's no workspace-wide domain list in the CLI.
 
 ## Troubleshooting
 
 ```npm
-npx @prisma/cli@next service domain show shop.acme.com --service web
-npx @prisma/cli@next service domain retry shop.acme.com --service web
+npx prisma@next service domain show shop.acme.com --service web
+npx prisma@next service domain retry shop.acme.com --service web
 ```
 
-`show` gives you the exact state, certificate details, and any DNS hints. `retry` restarts stuck provisioning; if a domain isn't in a retryable state, it returns `DOMAIN_RETRY_NOT_ELIGIBLE`.
+`show` prints the exact state, certificate details, and any DNS hints. `retry` restarts stuck provisioning. If a domain isn't in a retryable state, it returns `DOMAIN_RETRY_NOT_ELIGIBLE`.
 
 ## Next steps
 
 - [Deployments](/compute/deployments): promote a deployment to production first.
 - [Known limitations](/compute/limitations): what the beta can and can't do.
-- [`service domain` reference](/compute/cli-reference#service-domain): every domain subcommand and flag.
+- [`service domain` reference](/cli/v8/service#service-domain): every domain subcommand and flag.
diff --git a/apps/docs/content/docs/compute/environment-variables.mdx b/apps/docs/content/docs/compute/environment-variables.mdx
index 5b9fa7b09d..ad301d9cd1 100644
--- a/apps/docs/content/docs/compute/environment-variables.mdx
+++ b/apps/docs/content/docs/compute/environment-variables.mdx
@@ -3,7 +3,7 @@ title: Environment variables
 description: Project configuration that gets injected into your deployments, scoped to production, preview, or a single branch.
 url: /compute/environment-variables
 metaTitle: Environment variables | Prisma Compute
-metaDescription: Set, update, and remove environment variables for Prisma Compute apps, with production, preview, and per-branch scopes.
+metaDescription: Set, update, and remove environment variables for Prisma Compute services, with production, preview, and per-branch scopes.
 ---
 
 Environment variables are project configuration that gets injected into your deployments. You scope each one to production, to preview, or to a single preview branch. This is also how you connect your app to a database: set its connection string as a variable like `DATABASE_URL`.
@@ -20,28 +20,28 @@ There are three layers:
 
 A preview deploy gets the preview variables, with any branch overrides layered on top. Overrides help when one branch needs a different API key, database URL, or feature flag than the rest.
 
-Values are resolved at deploy time and baked into the deployment. Changing a variable doesn't touch deployments that already exist and doesn't trigger a redeploy; the new value applies the next time you deploy.
+Values are resolved at deploy time and baked into the deployment. Changing a variable doesn't touch deployments that already exist and doesn't trigger a redeploy. The new value applies the next time you deploy.
 
 ## Set a variable
 
 Pass `KEY=value` and a role or branch:
 
 ```npm
-npx @prisma/cli@next project env add DATABASE_URL=postgresql://example --role production
-npx @prisma/cli@next project env add DATABASE_URL=postgresql://preview --role preview
-npx @prisma/cli@next project env add FEATURE_FLAG=enabled --branch feature/search
+npx prisma@next project env add DATABASE_URL=postgresql://example --role production
+npx prisma@next project env add DATABASE_URL=postgresql://preview --role preview
+npx prisma@next project env add FEATURE_FLAG=enabled --branch feature/search
 ```
 
 To keep a secret out of your shell history, pass just the key and let the CLI read it from your environment:
 
 ```bash
-DATABASE_URL=postgresql://example npx @prisma/cli@next project env add DATABASE_URL --role production
+DATABASE_URL=postgresql://example npx prisma@next project env add DATABASE_URL --role production
 ```
 
 To import many variables at once, pass a dotenv file with `--file` instead of a `KEY=value` argument (one or the other, not both). It works for `add` and `update`:
 
 ```npm
-npx @prisma/cli@next project env add --file .env.production --role production
+npx prisma@next project env add --file .env.production --role production
 ```
 
 ## Connect a database
@@ -57,19 +57,19 @@ Don't assume production data is copied into preview branches, and don't assume m
 ## List, update, remove
 
 ```npm
-npx @prisma/cli@next project env list --role production
-npx @prisma/cli@next project env list --branch feature/search
-npx @prisma/cli@next project env update DATABASE_URL=postgresql://new --role production
-npx @prisma/cli@next project env remove DATABASE_URL --role preview
+npx prisma@next project env list --role production
+npx prisma@next project env list --branch feature/search
+npx prisma@next project env update DATABASE_URL=postgresql://new --role production
+npx prisma@next project env remove DATABASE_URL --role preview
 ```
 
-`list --role` shows names and metadata, never values. `list --branch` shows the resolved view for one branch. `rm` works as an alias for `remove`.
+`list --role` shows names and metadata, never values. `list --branch` shows the variables a deploy of that branch would receive. `rm` works as an alias for `remove`.
 
 `add` never overwrites: it fails if the key already exists in that scope, so use `update` to change a value. Every `project env` subcommand also accepts `--project <id-or-name>` to target a project other than the linked one.
 
 ## Values are write-only
 
-Once you save a variable, the platform never gives it back. Values are encrypted at rest and never returned: not by the CLI, the API, or the Console. In practice:
+Once you save a variable, its value is encrypted at rest and never returned: not by the CLI, the API, or the Console. In practice:
 
 - `project env list` shows keys and metadata, not values.
 - There's no command to pull values into a local `.env`.
@@ -86,13 +86,13 @@ Keep your own copy of every value in a secret manager. Treat Prisma as the place
 
 ## In CI and agents
 
-Add `--json` so the output is machine-readable, and `--no-interactive` so the CLI fails with an error code instead of waiting on a prompt nothing will answer:
+Add `--json` so the output is machine-readable, and `--no-interactive` so the CLI fails with an error code instead of waiting on a prompt:
 
 ```npm
-npx @prisma/cli@next project env list --role preview --json --no-interactive
+npx prisma@next project env list --role preview --json --no-interactive
 ```
 
-Don't build anything that depends on reading a value back. Pass the source value in from your own secret store, and let Prisma handle injection at deploy time.
+Don't build anything that depends on reading a value back. Pass the source value in from your own secret store, and let Prisma inject it at deploy time.
 
 ## Next steps
 
diff --git a/apps/docs/content/docs/compute/faq.mdx b/apps/docs/content/docs/compute/faq.mdx
index 0b8fcf5c29..b89a1ad2b2 100644
--- a/apps/docs/content/docs/compute/faq.mdx
+++ b/apps/docs/content/docs/compute/faq.mdx
@@ -8,15 +8,15 @@ metaDescription: Answers to common questions about Prisma Compute, the unified P
 
 ## Which package do I install?
 
-Compute is part of the unified Prisma CLI. Until launch it is published as the `next` tag of the `@prisma/cli` package; the quickest way to run it without installing anything is:
+Compute is part of the unified Prisma CLI, published as `prisma@next` during the Prisma 8 RC. The quickest way to run it without installing anything is:
 
 ```npm
-npx @prisma/cli@next service show
+npx prisma@next service show
 ```
 
 ## How do I deploy?
 
-Deployments come from a git push, the [Console](https://pris.ly/pdp), or [Prisma Composer](/composer); the CLI has no standalone `deploy` command for a single service. [Connect a GitHub repository](/compute/github) and push, or use [`composer deploy`](/composer/deploying) for CLI-driven deploys of multi-service apps.
+Deployments come from a git push, the [Console](https://pris.ly/pdp), or [Prisma Composer](/composer). The unified CLI has no standalone `deploy` command for a single service. [Connect a GitHub repository](/compute/github) and push, or use [`composer deploy`](/composer/deploying) for CLI-driven deploys of multi-service apps. During the beta, the earlier CLI (`@prisma/cli@latest`) still offers a one-shot `app deploy` for a single service.
 
 ## What's the difference between a project and an app?
 
@@ -30,7 +30,7 @@ A branch is an isolated environment for one line of work. It usually matches a G
 
 ## Does `git connect` deploy my app?
 
-No, it links a project to a GitHub repository and turns on automation for future branch and push events. It does not deploy anything by itself; push a commit to trigger the first build. To set the connection up, see the [GitHub integration docs](/compute/github).
+No, it links a project to a GitHub repository and turns on automation for future branch and push events. It does not deploy anything by itself. Push a commit to trigger the first build. To set the connection up, see the [GitHub integration docs](/compute/github).
 
 ## What does a GitHub push do?
 
@@ -42,10 +42,10 @@ In beta, variable values are encrypted and never returned by any surface. `proje
 
 ## How do I rotate a secret?
 
-Update it, then redeploy production (push to your default branch, or promote a deployment, which rebuilds with production environment variables):
+Update the value, then redeploy production. To redeploy, push to your default branch, or promote a deployment, which rebuilds with production environment variables:
 
 ```npm
-npx @prisma/cli@next project env update DATABASE_URL=postgresql://new --role production
+npx prisma@next project env update DATABASE_URL=postgresql://new --role production
 ```
 
 ## Does changing a variable redeploy my app?
@@ -57,14 +57,14 @@ No. Variables resolve at deploy time, so you need to redeploy for the app to pic
 Use a service token and explicit targets:
 
 ```bash
-PRISMA_SERVICE_TOKEN=... npx @prisma/cli@next service show \
+PRISMA_SERVICE_TOKEN=... npx prisma@next service show \
   --project my-app \
   --service web \
   --json \
   --no-interactive
 ```
 
-Passing every target explicitly keeps the run self-contained; `--json` makes the result parseable, and `--no-interactive` turns any would-be prompt into a structured error.
+Passing every target explicitly keeps the run self-contained. `--json` makes the result parseable, and `--no-interactive` turns any prompt into a structured error.
 
 ## Why `SERVICE.PROJECT_SETUP_REQUIRED`?
 
@@ -75,8 +75,8 @@ The current directory isn't linked to a project, and the CLI won't guess one fro
 Once the service has a running production deployment:
 
 ```npm
-npx @prisma/cli@next service domain add shop.acme.com --service web
-npx @prisma/cli@next service domain wait shop.acme.com --service web
+npx prisma@next service domain add shop.acme.com --service web
+npx prisma@next service domain wait shop.acme.com --service web
 ```
 
 Add the CNAME record the command returns at your DNS provider. To learn more, see the [Domains docs](/compute/domains).
@@ -95,7 +95,7 @@ No. Your app connects to a database through a connection string you set as an en
 
 ## Can I use the Console instead?
 
-Yes. Use it to inspect projects, branches, apps, deployments, integrations, env var names, and domain status.
+Yes. Use it to inspect projects, branches, services, deployments, integrations, environment variable names, and domain status.
 
 ## Is Prisma Compute free?
 
@@ -103,7 +103,7 @@ Yes, Compute is free during public beta. We've published the rates we expect to
 
 ## What does Public Beta mean for Compute?
 
-The core model and documented happy paths are stable enough for evaluation, staging, internal tools, and low-risk apps; details like limits, pricing, and some CLI, API, and Console behavior can still change before general availability. See [Public Beta](/console/more/feature-maturity#public-beta) on the feature maturity page.
+The core model and documented happy paths are stable enough for evaluation, staging, internal tools, and low-risk apps. Details like limits, pricing, and some CLI, API, and Console behavior can still change before general availability. See [Public Beta](/console/more/feature-maturity#public-beta) on the feature maturity page.
 
 ## What are the current limits?
 
diff --git a/apps/docs/content/docs/compute/getting-started.mdx b/apps/docs/content/docs/compute/getting-started.mdx
index 52fc55a17e..ccf3bf6a92 100644
--- a/apps/docs/content/docs/compute/getting-started.mdx
+++ b/apps/docs/content/docs/compute/getting-started.mdx
@@ -6,43 +6,43 @@ metaTitle: Get started with Prisma Compute
 metaDescription: Sign in with the unified Prisma CLI, write a compute config, connect a GitHub repository, and deploy an app to Prisma Compute.
 ---
 
-Get an app live on [Prisma Compute](/compute) with the unified Prisma CLI: sign in, describe your app in a committed config, connect GitHub, and push. This guide takes you from your code to a live URL, then covers environment variables, CI, and agents. For every command and flag, see the [CLI reference](/compute/cli-reference).
+Get an app live on [Prisma Compute](/compute) with the unified Prisma CLI: sign in, describe your app in a committed config, connect GitHub, and push. This guide takes you from your code to a live URL, then covers environment variables, CI, and agents. For every command and flag, see the [CLI reference](/cli/v8).
 
 :::info
 
-Until launch, the unified Prisma CLI is published as the `next` tag of the `@prisma/cli` package; run it as `npx @prisma/cli@next <command>`. It replaces the earlier `@prisma/cli` beta and its `app deploy` loop: deployments now come from a git push, the [Console](https://pris.ly/pdp), or [Prisma Composer](/composer), and the CLI manages everything around them.
+This guide uses the Prisma 8 RC CLI, run as `npx prisma@next <command>`. Deployments come from a git push, the [Console](https://pris.ly/pdp), or [Prisma Composer](/composer). The CLI creates the project, writes the configuration, connects GitHub, and inspects the results.
 
 :::
 
 ## Prerequisites
 
-- A JavaScript runtime. The commands below run with `npx` or `pnpm` on Node.js 22 or newer, or with `bunx` (Bun).
+- A JavaScript runtime. The commands below run with `npx` or `pnpm` on Node.js 22.18 or newer, or with `bunx` (Bun).
 - A [Prisma Data Platform account](https://pris.ly/pdp).
 - An app in a GitHub repository you can connect.
 
 ## Sign in
 
-Authenticate first; everything else needs a session:
+Authenticate first. Every other command needs a session:
 
 ```npm
-npx @prisma/cli@next auth login
+npx prisma@next auth login
 ```
 
-This opens a browser to sign you in, then stores a session that every later command inherits, including any coding agent working in your directory. The browser step needs a human; in CI or other headless environments, use a [service token](#automation-and-ci) instead. To check who you are signed in as, run `auth whoami`.
+This opens a browser to sign you in, then stores a session that every later command inherits. Because the browser step is interactive, CI and other headless environments use a [service token](#automation-and-ci) instead. To check who you are signed in as, run `auth whoami`.
 
 ## Describe your app
 
 From your app directory, write the committed compute config:
 
 ```npm
-npx @prisma/cli@next init
+npx prisma@next init
 ```
 
-`init` detects your framework and writes `prisma.compute.ts` (or, with `--config-format json`, a dependency-free `prisma.compute.json`). The service commands read this file for the service name, framework, entry point, HTTP port, and region. Today there is first-class support for **Next.js**, **Nuxt**, **Astro**, **Hono**, **NestJS**, and **TanStack Start**, plus `bun` and `custom` entry points:
+`init` detects your framework and writes `prisma.compute.ts` (or, with `--config-format json`, a dependency-free `prisma.compute.json`). The service commands read this file for the service name, framework, entry point, HTTP port, and region. [Configuration](/compute/configuration) documents every field. A simple single-service repository can skip the file, since builds detect the framework without it. Committing one makes deploys reproducible. Monorepos require it. Today there is first-class support for **Next.js**, **Nuxt**, **Astro**, **Hono**, **NestJS**, and **TanStack Start**, plus `bun` and `custom` entry points:
 
 ```npm
-npx @prisma/cli@next init --framework hono --entry src/index.ts
-npx @prisma/cli@next init --name api --http-port 8080
+npx prisma@next init --framework hono --entry src/index.ts
+npx prisma@next init --name api --http-port 8080
 ```
 
 :::note
@@ -60,43 +60,43 @@ export default { output: "standalone" };
 A project groups your services, branches, and databases. Create one and link this directory to it:
 
 ```npm
-npx @prisma/cli@next project create my-app
+npx prisma@next project create my-app
 ```
 
 If your team already has one, link to it instead:
 
 ```npm
-npx @prisma/cli@next project link my-app
+npx prisma@next project link my-app
 ```
 
-Either path writes `.prisma/local.json`, a gitignored file that pins this directory to a project. It is a local cache, not committed config. Two commands to check your wiring:
+Either path writes the selected project to `.prisma/local.json`. This file is gitignored and only stores your local link, so it should not be treated as committed configuration. To verify the link, run:
 
 ```npm
-npx @prisma/cli@next project show
-npx @prisma/cli@next project list
+npx prisma@next project show
+npx prisma@next project list
 ```
 
-`project show` tells you what this directory is linked to; `project list` shows the projects you can see.
+`project show` tells you what this directory is linked to. `project list` shows the projects you can see.
 
 ## Connect GitHub and deploy
 
 Connect the project to your repository:
 
 ```npm
-npx @prisma/cli@next git connect
+npx prisma@next git connect
 ```
 
 This starts the GitHub App install flow if needed and links the repository. From then on, pushing a branch builds and deploys it: the default Git branch deploys to production, and every other branch gets its own isolated preview. Push, then watch and open the result:
 
 ```npm
-npx @prisma/cli@next service show
-npx @prisma/cli@next service open
+npx prisma@next service show
+npx prisma@next service open
 ```
 
-`service show` prints the service and its current deployment, including the build id; stream a build's logs with:
+`service show` prints the service and its current deployment, including the build id. Stream a build's logs with:
 
 ```npm
-npx @prisma/cli@next build logs <buildId> --follow
+npx prisma@next build logs <buildId> --follow
 ```
 
 To learn how deployments are promoted, rolled back, started, and stopped, see [Deployments](/compute/deployments).
@@ -107,29 +107,29 @@ For an app made of several services and databases that you want to deploy direct
 
 ## Environment variables
 
-Give your app configuration per scope, production or preview, before the deploy that should use it:
+Set environment variables per scope, production or preview, before the deploy that should use them. To connect a database, create a [Prisma Postgres](/postgres) database in the project (`npx prisma@next postgres create my-db` prints its connection string once) and store the URL as an environment variable:
 
 ```npm
-npx @prisma/cli@next project env add DATABASE_URL=postgres://... --role production
-npx @prisma/cli@next project env add DATABASE_URL=postgres://... --role preview
+npx prisma@next project env add DATABASE_URL=postgres://... --role production
+npx prisma@next project env add DATABASE_URL=postgres://... --role preview
 ```
 
-Values are write-only and resolve at deploy time; see [Environment variables](/compute/environment-variables).
+Values are write-only and resolve at deploy time. See [Environment variables](/compute/environment-variables) for details.
 
 ## Automation and CI
 
-The CLI is built for agents and CI, not just terminals.
+The same commands run unattended in CI or under a coding agent.
 
 If you have signed in with `auth login`, anything running in that environment inherits your session, including an agent working in your directory. Check the session:
 
 ```npm
-npx @prisma/cli@next auth whoami
+npx prisma@next auth whoami
 ```
 
-For CI, or any environment where the browser sign-in is not an option, authenticate with a **service token** instead. Set `PRISMA_SERVICE_TOKEN` and the CLI uses it before any stored session. Pass targets explicitly so nothing depends on a prompt, `--json` for structured output, and `--no-interactive` so the CLI fails instead of asking:
+For CI, or any environment where the browser sign-in is not an option, authenticate with a **service token** instead. Set `PRISMA_SERVICE_TOKEN` and the CLI uses it before any stored session. Pass targets explicitly so nothing depends on a prompt. Add `--json` for structured output, and `--no-interactive` so the CLI fails instead of asking:
 
 ```bash
-PRISMA_SERVICE_TOKEN=... npx @prisma/cli@next service show \
+PRISMA_SERVICE_TOKEN=... npx prisma@next service show \
   --project my-app \
   --service web \
   --json \
@@ -141,24 +141,21 @@ PRISMA_SERVICE_TOKEN=... npx @prisma/cli@next service show \
 If a coding agent does your deploying, install the Prisma Compute agent skill into your repo:
 
 ```npm
-npx @prisma/cli@next agent install --skill prisma-compute
+npx prisma@next agent install --skill prisma-compute
 ```
 
-The `prisma-compute` skill teaches your agent the Compute workflow (auth, config, deploys, logs, and domains), so it follows the right steps. Supported agents pick it up automatically. Run `agent install` with no flags for an interactive picker, or `agent status` to see what is installed.
+The `prisma-compute` skill teaches your agent the Compute workflow (auth, config, deploys, logs, and domains), so it follows the right steps. Supported agents pick it up automatically. Run `agent install` with no flags to install [every Prisma skill](/ai/tools/skills) instead of just this one, and `agent status` to see what is installed. `prisma init` also offers this install once per project, so you may already have it.
 
 ### Structured output
 
-In `--json` mode, every command emits an envelope with an `ok` flag. On failure, `error.code` is a dotted `NAMESPACE.SUBCODE` (for example `SERVICE.PROJECT_SETUP_REQUIRED`), `error.summary` and `error.why` explain the problem, and `nextActions` lists concrete follow-up commands, which is what makes the CLI drivable by agents. Branch on the code, not the message: codes are a stable contract, while wording can change between releases.
+In `--json` mode, every command emits an envelope with an `ok` flag. On failure, `error.code` is a dotted `NAMESPACE.SUBCODE` (for example `SERVICE.PROJECT_SETUP_REQUIRED`), `error.summary` and `error.why` explain the problem, and `nextActions` lists concrete follow-up commands. Scripts and agents should branch on the code rather than the message: codes are a stable contract, while wording can change between releases.
 
 ## Console
 
-To view your resources instead of running commands, use the [Console](https://pris.ly/pdp) for projects, branches, services, deployments, integrations, and domains. It shows them in a visual way and lets you manage them with buttons instead of commands.
+To browse and manage the same resources without the CLI, open the [Console](https://pris.ly/pdp). It shows projects, branches, services, deployments, integrations, and domains.
 
 ## Next steps
 
-- [CLI reference](/compute/cli-reference): every command and flag.
 - [Deployments](/compute/deployments): inspect, promote, roll back, start, stop.
 - [Environment variables](/compute/environment-variables): production, preview, and per-branch overrides.
 - [Branching](/compute/branching): how branches isolate work and map to Git.
-- [GitHub integration](/compute/github): the push-to-deploy flow in detail.
-- [Prisma Composer](/composer): CLI-driven deploys of multi-service apps.
diff --git a/apps/docs/content/docs/compute/github.mdx b/apps/docs/content/docs/compute/github.mdx
index b8b5325bfe..005ed8be3b 100644
--- a/apps/docs/content/docs/compute/github.mdx
+++ b/apps/docs/content/docs/compute/github.mdx
@@ -23,25 +23,25 @@ In beta, a project connects to one repository.
 From a linked project directory, connect your Git origin:
 
 ```npm
-npx @prisma/cli@next git connect
+npx prisma@next git connect
 ```
 
 To name the repository explicitly:
 
 ```npm
-npx @prisma/cli@next git connect https://github.com/acme/shop
+npx prisma@next git connect https://github.com/acme/shop
 ```
 
-If the GitHub App isn't installed yet, the CLI starts the install flow. In `--json` / `--no-interactive` mode it doesn't block: it gives you the install URL to finish in the browser, so automation can hand the install off:
+If the GitHub App isn't installed yet, the CLI starts the install flow. In `--json` / `--no-interactive` mode it doesn't block: it prints the install URL to finish in the browser, so automation can hand the install off:
 
 ```npm
-npx @prisma/cli@next git connect https://github.com/acme/shop --json --no-interactive
+npx prisma@next git connect https://github.com/acme/shop --json --no-interactive
 ```
 
 Disconnect when you're done:
 
 ```npm
-npx @prisma/cli@next git disconnect
+npx prisma@next git disconnect
 ```
 
 Disconnecting stops future automation. It doesn't delete the project or tear down existing branches.
@@ -54,14 +54,14 @@ Once a project is connected:
 - **Push** → creates or resolves the matching branch and builds the pushed commit.
 - **Branch deleted** → tears down the matching branch, unless it's the production or default branch.
 
-Connecting doesn't deploy anything on its own; it wires up automation for *future* events. Push a commit to trigger the first build.
+Connecting doesn't deploy anything on its own. It wires up automation for *future* events. Push a commit to trigger the first build.
 
 ## CI and monorepos
 
-Auto-deploy handles monorepos that declare their apps in `prisma.compute.ts`: one pushed commit fans out into a targeted build per app. Watch a build from CI or a terminal with a service token and explicit targets:
+When a monorepo declares several services in `prisma.compute.ts`, one pushed commit fans out into a targeted build per service. Watch a build from CI or a terminal with a service token and explicit targets:
 
 ```bash
-PRISMA_SERVICE_TOKEN=... npx @prisma/cli@next service show \
+PRISMA_SERVICE_TOKEN=... npx prisma@next service show \
   --project my-app \
   --service web \
   --json \
@@ -72,7 +72,7 @@ For pipelines that need a CLI-driven deploy rather than the push automation, use
 
 ## What's not in beta
 
-GitHub is the only supported provider; others return `REPO_PROVIDER_UNSUPPORTED`. The webhook path is branch- and push-driven. Each webhook deployment posts a "Prisma Compute Deploy" check run on the commit — success or failure, with the deploy URL — on a best-effort basis. Pull-request comments and preview comments aren't part of the beta surface.
+GitHub is the only supported provider; others return `REPO_PROVIDER_UNSUPPORTED`. The webhook path is branch- and push-driven. Each webhook deployment posts a "Prisma Compute Deploy" check run on the commit (success or failure, with the deploy URL) on a best-effort basis. Pull-request comments and preview comments aren't part of the beta surface.
 
 ## Next steps
 
diff --git a/apps/docs/content/docs/compute/image-transformations.mdx b/apps/docs/content/docs/compute/image-transformations.mdx
index 7a7c58e6fd..91af6935ba 100644
--- a/apps/docs/content/docs/compute/image-transformations.mdx
+++ b/apps/docs/content/docs/compute/image-transformations.mdx
@@ -8,7 +8,7 @@ metaDescription: Learn how to build image transformation routes on Prisma Comput
 
 [Prisma Compute](/compute) apps run on Bun, and Bun ships [`Bun.Image`](https://bun.com/docs/runtime/image): a native pipeline for decoding, resizing, rotating, flipping, adjusting, and re-encoding images. So you build image transformations as part of your app, not as a separate image service.
 
-A transformation route is an ordinary [Compute deployment](/compute/deployments). It handles a request, uses CPU and memory, and returns bytes, and it is billed and operated like every other route in your app.
+A transformation route is an ordinary [Compute deployment](/compute/deployments). It receives a request, uses CPU and memory, and returns bytes. It is billed and operated like every other route in your app.
 
 ## What Bun handles natively
 
@@ -153,7 +153,7 @@ export default app;
 Deploy it:
 
 ```bash title="Deploy"
-bunx @prisma/cli@next init --framework hono --entry src/index.ts
+bunx prisma@next init --framework hono --entry src/index.ts
 ```
 
 Request variants:
diff --git a/apps/docs/content/docs/compute/index.mdx b/apps/docs/content/docs/compute/index.mdx
index 2f1a91aec6..738fad14e7 100644
--- a/apps/docs/content/docs/compute/index.mdx
+++ b/apps/docs/content/docs/compute/index.mdx
@@ -1,53 +1,46 @@
 ---
 title: Prisma Compute
-description: "Deploy TypeScript apps alongside Prisma Postgres, with hosting, database branches, and previews managed together."
+description: "Deploy TypeScript services alongside Prisma Postgres, with hosting, database branches, and previews managed together."
 url: /compute
 badge: beta
 metaTitle: Prisma Compute | TypeScript app hosting for Prisma Postgres
 metaDescription: Learn how Prisma Compute deploys TypeScript apps alongside Prisma Postgres, with isolated branch previews, database branches, and CLI-first workflows.
 ---
 
-Prisma Compute is TypeScript app hosting built to run alongside [Prisma Postgres](/postgres). It is the last step of the [recommended Prisma stack](/): you model your data with [Prisma 8](/v8) or [Prisma ORM](/orm), store it in Prisma Postgres, and deploy your app with Prisma Compute, so your schema, database, hosting, and branch previews work together in one Prisma project.
+Prisma Compute is a hosting platform for TypeScript services. It runs your application next to [Prisma Postgres](/postgres) and gives every Git branch an isolated environment: its own service, environment variables, and optionally its own database.
+
+Compute works with any supported TypeScript framework. It pairs with [Prisma 8](/v8) and [Prisma ORM](/orm) for data access, but neither is required.
 
 :::info[Public Beta]
 
-Prisma Compute is in [Public Beta](/console/more/feature-maturity#public-beta). You manage it with the unified [Prisma CLI](/compute/getting-started) (published as `@prisma/cli@next` until launch), and deployments come from a git push, the [Console](https://pris.ly/pdp), or [Prisma Composer](/composer).
+Prisma Compute is in [Public Beta](/console/more/feature-maturity#public-beta). These docs use the Prisma 8 RC CLI, run as `npx prisma@next`. Deployments come from a git push, the [Console](https://pris.ly/pdp), or [Prisma Composer](/composer). See [Deployments](/compute/deployments) for details.
 
 :::
 
 ## Get started
 
-The best way to understand Compute is to deploy an app. The quickstart takes a TypeScript app to a live URL in a few minutes, then connects GitHub so every push can deploy automatically.
-
 <Cards>
-  <Card href="/prisma-compute/deploy" title="Deploy your first app" icon={<Rocket className="text-primary" />}>
-    The quickstart: sign in, deploy, verify, and connect GitHub.
+  <Card href="/compute/getting-started" title="Deploy your first service" icon={<Rocket className="text-primary" />}>
+    Sign in, write the compute config, connect GitHub, and deploy on push.
   </Card>
-  <Card href="/" title="Start from the beginning" icon={<Milestone className="text-primary" />}>
-    No app yet? Scaffold one with Prisma 8 and Prisma Postgres first.
+  <Card href="/prisma-compute/deploy" title="Deploy quickstart" icon={<Milestone className="text-primary" />}>
+    The short path: scaffold or bring an app, connect GitHub, push, verify.
   </Card>
 </Cards>
 
-Working with a coding agent? The deploy quickstart ends with a ready-to-copy prompt in [Hand it to your agent](/prisma-compute/deploy#hand-it-to-your-agent).
-
-To learn how Compute works, [the model](#the-model) below shows how each branch gets isolated app and database resources, so preview work never touches production.
+Building an application with several services that depend on each other or on databases? Use [Prisma Composer](/composer) to declare them in TypeScript and deploy them together.
 
 ## The model
 
 Compute organizes everything into a few resources:
 
 - A **project** groups one product or codebase.
-- A **branch** maps to a Git branch in the linked repository, and gets its own isolated app, environment variables, and deployments.
-- An **app** is an HTTP service, such as a frontend or backend, and can have multiple **deployments**.
-
-The branch is the concept that ties Compute together. Each branch owns its own app, URL, and environment variables, and can have its own database. When you deploy to a new branch, Compute provisions isolated resources for that branch, so you can test changes in preview without affecting production.
-
-- **Production**: the default Git branch (e.g., `main`) is your production branch, with its own resources and environment variables.
-- **Preview**: every other branch is a preview branch, with its own isolated resources and environment variables scoped to **preview**.
+- A **branch** maps to a Git branch in the linked repository. Each branch is an isolated environment with its own services, environment variables, and deployments, and can have its own database.
+- A **service** is an HTTP application, such as a frontend or backend. Each deploy of a service creates a **deployment**. One deployment is live at a time.
 
-After you [connect a GitHub repository](/compute/github), pushing to a Git branch builds and deploys its preview automatically.
+The default Git branch (usually `main`) is the **production** branch. Every other branch is a **preview** branch with its own Compute resources: services, deployments, and environment variables. Data isolation is yours to configure. A preview deploy reads the preview-scoped variables. If preview work must not touch production data, point the preview `DATABASE_URL` at a non-production database. See [Environment variables](/compute/environment-variables) for details. After you [connect a GitHub repository](/compute/github), pushing to a branch builds and deploys that branch automatically.
 
-The animation below shows how a project, its branches, and their infrastructure fit together, and how each branch's variables resolve by scope. Step through it, or let it play:
+The animation below shows how a project, its branches, and their infrastructure fit together, and how each branch's variables resolve by scope:
 
 <ConceptAnimation name="compute-model" />
 
@@ -57,17 +50,8 @@ For the full picture, see [Branching](/compute/branching).
 
 Use the **CLI** for anything you want to repeat: local development, CI, and agent workflows. Every command supports a `--json` flag that switches its output to machine-readable JSON, so scripts and agents can parse results instead of scraping terminal text.
 
-Use the **[Console](https://pris.ly/pdp)** if you prefer to view your resources instead of running a command. The Console shows your projects, branches, apps, and deployments in a visual way, and lets you manage them with buttons instead of commands.
+Use the **[Console](https://pris.ly/pdp)** to view and manage projects, branches, services, and deployments in a browser instead of running commands.
 
 ## What to read next
 
-- [Getting started](/compute/getting-started): sign in, write the compute config, connect GitHub, and deploy.
-- [Branching](/compute/branching): how branches isolate work and map to Git.
-- [Deployments](/compute/deployments): build, deploy, logs, promote, roll back.
-- [Image Transformations](/compute/image-transformations): resize, encode, cache, and serve images from a Compute app with Bun.
-- [Environment variables](/compute/environment-variables): production, preview, and per-branch overrides.
-- [GitHub integration](/compute/github): connect a repo and deploy on push.
-- [CLI reference](/compute/cli-reference): every command and flag.
-- [Domains](/compute/domains): point a custom domain at production.
-- [Known limitations](/compute/limitations): what the beta can and can't do.
-- [FAQ](/compute/faq): quick answers to common questions.
+Once you have deployed something, read [Deployments](/compute/deployments) for logs, promoting, and rolling back, and [Environment variables](/compute/environment-variables) for configuration per scope. [Configuration](/compute/configuration) documents every field of `prisma.compute.ts`, and the [CLI reference](/cli/v8) documents every command and flag. Before relying on the beta in production, read the [known limitations](/compute/limitations).
diff --git a/apps/docs/content/docs/compute/limitations.mdx b/apps/docs/content/docs/compute/limitations.mdx
index c3cc1c1354..ebd92cfbcf 100644
--- a/apps/docs/content/docs/compute/limitations.mdx
+++ b/apps/docs/content/docs/compute/limitations.mdx
@@ -10,9 +10,10 @@ Prisma Compute is in [Public Beta](/console/more/feature-maturity#public-beta).
 
 ## CLI
 
-- The package is `@prisma/cli`; the executable is `prisma-cli`. The quickest way to run it is `npx @prisma/cli@next <command>` (or `bunx`/`pnpm dlx`), with Node.js 22.12 or newer for `npx` and `pnpm`.
-- The command groups are `version`, `init`, `agent`, `auth`, `project` (including `project env`), `git`, `branch`, `build`, `database`, and `app`. There is no `schema` or `migrate` command, and no product-branded `compute` namespace.
-- Committed configuration lives in [`prisma.compute.ts`](/compute/configuration) (or `prisma.compute.json`). `.prisma/local.json` is a gitignored local pin of the workspace and project, and `PRISMA_PROJECT_ID` / `PRISMA_APP_ID` override it for CI.
+- The quickest way to run the CLI is `npx prisma@next <command>` (or `bunx`/`pnpm dlx`), with Node.js 22.18 or newer.
+- The platform command groups are `init`, `auth`, `project` (including `project env`), `postgres`, `bucket`, `branch`, `git`, `service` (including `service deployment` and `service domain`), `build`, and `agent`. The same binary also carries the [Prisma 8 data commands](/cli/v8) (`contract`, `db`, `migration`, `migrate`, `ref`) and the [`composer` commands](/composer/cli-reference). There is no `compute` namespace: Compute is managed through the resource groups above.
+- There is no standalone `deploy`, `build`, or `run` verb in the unified CLI. Deployments come from a git push, the Console, or Composer; see [Deployments](/compute/deployments).
+- Committed configuration lives in [`prisma.compute.ts`](/compute/configuration) or `prisma.compute.json`. `.prisma/local.json` is gitignored and only stores your local link to the workspace and project. In CI, set `PRISMA_PROJECT_ID` / `PRISMA_SERVICE_ID` to override the linked project and service.
 
 ## Projects and branches
 
@@ -24,7 +25,7 @@ Prisma Compute is in [Public Beta](/console/more/feature-maturity#public-beta).
 ## Frameworks and runtimes
 
 - `init --framework` (and the `framework` field in `prisma.compute.ts`) accepts `nextjs`, `nuxt`, `astro`, `hono`, `nestjs`, `tanstack-start`, `custom`, and `bun`.
-- Use `--entry` for Bun, or whenever detection needs a hand.
+- Use `--entry` for Bun, or whenever detection needs help.
 
 ## Environment variables
 
@@ -37,13 +38,13 @@ Prisma Compute is in [Public Beta](/console/more/feature-maturity#public-beta).
 ## GitHub
 
 - GitHub is the only supported provider, and a project connects to one repository.
-- Auto-deploy supports multiple apps declared in `prisma.compute.ts`: one push build fans out into a targeted build per app. CI with a service token remains available when you need full control.
+- Auto-deploy supports multiple services declared in `prisma.compute.ts`: one push fans out into a targeted build per service. CI with a service token remains available when you need full control.
 - The webhook path is branch- and push-driven. There are no PR comments or PR status automation.
 
 ## Domains
 
-- Custom domains are production-only and CNAME-based: they attach to the default (production) branch, and the app needs a promoted deployment first.
-- Up to 3 custom domains per app.
+- Custom domains are production-only and CNAME-based: they attach to the default (production) branch, and the service needs a promoted deployment first.
+- Up to 3 custom domains per service.
 - There is no workspace-wide domain list in the CLI.
 
 ## Logs
@@ -54,7 +55,7 @@ Prisma Compute is in [Public Beta](/console/more/feature-maturity#public-beta).
 
 ## Runtime
 
-- This release focuses on HTTP apps. Background work between requests is supported through the `@prisma/compute` keep-awake primitives; see [Keeping instances awake](/compute/keeping-instances-awake). Cron scheduling, a persistent filesystem, and edge runtimes are not part of it.
+- This release focuses on HTTP services. Background work between requests is supported through the `@prisma/compute` keep-awake primitives; see [Keeping instances awake](/compute/keeping-instances-awake). Cron scheduling, a persistent filesystem, and edge runtimes are not part of it.
 - WebSocket servers are not currently a supported Public Beta capability. `waitUntil` and `KeepAwakeGuard` only prevent an instance from scaling to zero; they do not change connection-lifetime limits or guarantee continuity through restarts or deployments.
 - No multi-region deployments. Each service lives in one region, chosen at creation (`init --region` or `service create --region`): `us-east-1` (the default), `us-west-1`, `eu-west-3`, `eu-central-1`, `ap-northeast-1`, or `ap-southeast-1`.
 - Not yet recommended for mission-critical or heavy production workloads.
@@ -62,7 +63,7 @@ Prisma Compute is in [Public Beta](/console/more/feature-maturity#public-beta).
 
 ## Databases and migrations
 
-- These docs cover deployment and runtime config only: not schema migrations or data cloning. Databases are managed with the [`postgres` commands](/compute/cli-reference#postgres).
+- These docs cover deployment and runtime config only: not schema migrations or data cloning. Databases are managed with the [`postgres` commands](/cli/v8/postgres).
 - Don't assume production data is copied into preview branches.
 - Don't assume production migrations run automatically on deploy.
 - Pass database URLs and other runtime config through [environment variables](/compute/environment-variables).
@@ -70,4 +71,4 @@ Prisma Compute is in [Public Beta](/console/more/feature-maturity#public-beta).
 ## Next steps
 
 - [FAQ](/compute/faq): quick answers to common questions.
-- [Get started with `@prisma/cli`](/compute/getting-started): your first deploy.
+- [Get started with the Prisma CLI](/compute/getting-started): your first deploy.
diff --git a/apps/docs/content/docs/compute/pricing.mdx b/apps/docs/content/docs/compute/pricing.mdx
index 6a26568565..991029644c 100644
--- a/apps/docs/content/docs/compute/pricing.mdx
+++ b/apps/docs/content/docs/compute/pricing.mdx
@@ -10,7 +10,7 @@ Compute is free during public beta. The rates below are what we expect to charge
 
 :::info[Public Beta]
 
-Prisma Compute is in [Public Beta](/console/more/feature-maturity#public-beta), so rates, limits, and included usage may change before billing begins. If something has to change, we will change it and say so clearly.
+Prisma Compute is in [Public Beta](/console/more/feature-maturity#public-beta), so rates, limits, and included usage may change before billing begins. If something has to change, we will say so clearly.
 
 This pricing isn't final, and your feedback shapes it. If a rate or meter doesn't fit how your app runs, tell us in the `prisma-compute` channel on our [Discord](https://pris.ly/discord).
 
@@ -47,7 +47,7 @@ Assume the preview gets `10,000` requests, stays running for `3,000s` at `1 GB`,
 | Outbound bandwidth | `0.25 GB * $0.025 = $0.0063`                             |
 | Total              | `$0.0320`, about `$0.03`                                 |
 
-The usage is the bill, not the deploys or the [preview branch](/compute/branching).
+Only the usage is billed; the deploys and the [preview branch](/compute/branching) itself are not.
 
 ### Agent workflow
 
@@ -107,7 +107,7 @@ A preview branch only costs money when it does work, such as serving traffic or
 
 ## Usage data for humans and agents
 
-Database usage is available from the [CLI](/compute/cli-reference) (`database usage`) and API, including as JSON, and an agent can read it to estimate a cost, explain a change, or suggest a fix. Equivalent Compute usage surfaces are still taking shape during the beta.
+Database usage is available from the [CLI](/cli/v8/postgres) (`postgres usage`) and API, including as JSON, and an agent can read it to estimate a cost, explain a change, or suggest a fix. Equivalent usage reporting for Compute is still being built during the beta.
 
 ## Beta and bandwidth
 
@@ -117,12 +117,12 @@ Outbound bandwidth is the data your app sends from Compute to the public interne
 
 ## Share your pricing feedback
 
-This pricing is still taking shape during the beta, and your input shapes where it lands. If a rate, meter, or included amount doesn't match how your app actually runs, tell us in the `prisma-compute` channel on our [Discord](https://pris.ly/discord). That feedback is exactly what we are measuring against before billing turns on.
+If a rate, meter, or included amount doesn't match how your app actually runs, tell us in the `prisma-compute` channel on our [Discord](https://pris.ly/discord). That feedback is exactly what we are measuring against before billing turns on.
 
 ## What to read next
 
 - [Prisma Compute vs Vercel pricing](https://www.prisma.io/blog/prisma-compute-vs-vercel-pricing?utm_source=docs): the same monthly workload priced line by line on both platforms.
-- [Get started](/compute/getting-started): the quickstart, deploy your first app to a live URL in two commands.
+- [Get started](/compute/getting-started): the quickstart that takes your first app to a live URL in two commands.
 - [Known limitations](/compute/limitations): what the beta can and can't do.
 - [FAQ](/compute/faq): quick answers to common questions.
 - [Branching](/compute/branching): how preview branches isolate work and when they cost money.
diff --git a/apps/docs/content/docs/guides/v8/runtimes/deno.mdx b/apps/docs/content/docs/guides/v8/runtimes/deno.mdx
index 20e7b75120..3b3d3ac030 100644
--- a/apps/docs/content/docs/guides/v8/runtimes/deno.mdx
+++ b/apps/docs/content/docs/guides/v8/runtimes/deno.mdx
@@ -8,7 +8,7 @@ metaDescription: Set up a Prisma 8 project on Deno with Prisma Postgres, from sc
 
 ## Introduction
 
-In this guide, you scaffold a Prisma 8 project for Deno, initialize and seed a PostgreSQL database, and run your first typed query. Deno runs TypeScript natively and installs npm packages on demand, so the flow is close to the [Bun guide](/guides/v8/runtimes/bun) with two Deno-specific differences this guide calls out: explicit import extensions and permission flags.
+In this guide, you scaffold a Prisma 8 project for Deno, initialize and seed a PostgreSQL database, and run your first typed query. Deno runs TypeScript natively and installs npm packages on demand, so the flow is close to the [Bun guide](/guides/v8/runtimes/bun). Two Deno-specific differences come up along the way: explicit import extensions and permission flags.
 
 Every command and code sample below was run end to end against a live Prisma Postgres database.
 
@@ -27,7 +27,7 @@ Prefer to delegate this guide? Copy the prompt and hand it to your coding agent:
 Create a new Prisma 8 project on Deno, seed it, and run a first typed query.
 
 1. Scaffold: `deno run -A npm:create-prisma@next create my-deno-app --template minimal --provider postgres --package-manager deno --prisma-postgres --yes` (or pass `--database-url "<url>"` instead of `--prisma-postgres` if I give you a connection string).
-2. In `my-deno-app`, run `deno install`, then `deno run -A --env-file=.env npm:@prisma/cli@next contract emit` and `deno run -A --env-file=.env npm:@prisma/cli@next db init`.
+2. In `my-deno-app`, run `deno install`, then `deno run -A --env-file=.env npm:prisma@next contract emit` and `deno run -A --env-file=.env npm:prisma@next db init`.
 3. Run `deno task db:seed`. If seeding fails with `Cannot read properties of undefined (reading 'where')`, change `db.orm.User` to `db.orm.public.User` in `src/prisma/seed.ts`, `src/prisma/users.ts`, and `src/index.ts`, then rerun.
 4. Replace `src/index.ts` with a script that creates a user and reads all users back, following https://www.prisma.io/docs/guides/v8/runtimes/deno.md. Keep the `.ts` extension on relative imports. Verify `deno task dev` prints the created user and the user count.
 5. Do not deploy to Prisma Compute; it does not support Deno yet.
@@ -55,11 +55,11 @@ deno install
 ## 2. Emit the contract and initialize the database
 
 ```bash
-deno run -A --env-file=.env npm:@prisma/cli@next contract emit
-deno run -A --env-file=.env npm:@prisma/cli@next db init
+deno run -A --env-file=.env npm:prisma@next contract emit
+deno run -A --env-file=.env npm:prisma@next db init
 ```
 
-The first command compiles `src/prisma/contract.prisma` into the contract your queries are type-checked against and prints a JSON summary with `"ok": true` and the emitted file paths. The second creates the tables and signs the database; it exits quietly on success.
+The first command compiles `src/prisma/contract.prisma` into the contract your queries are type-checked against and prints a JSON summary with `"ok": true` and the emitted file paths. The second creates the tables and signs the database. It exits quietly on success.
 
 The `-A` flag grants the permissions the CLI needs (network for the database, filesystem for the generated files). To scope permissions tighter, start from `--allow-net --allow-read --allow-write --allow-env` and adjust to your setup.
 
@@ -116,7 +116,7 @@ there are now 4 users
 
 The count is the three seeded users plus the one this script created.
 
-[Prisma Compute](/compute) does not support Deno deployments yet; see [Deploy your first app](/prisma-compute/deploy) for what is currently supported. In the meantime, the app deploys to Deno's usual hosts, such as Deno Deploy or any server that runs the Deno CLI.
+[Prisma Compute](/compute) does not support Deno deployments yet. See [Deploy your first app](/prisma-compute/deploy) for what is currently supported. In the meantime, the app deploys to Deno's usual hosts, such as Deno Deploy or any server that runs the Deno CLI.
 
 ## Common gotchas
 
@@ -137,4 +137,4 @@ The scaffold installs [Prisma 8 skills](/ai/tools/skills#available-skills-for-pr
 
 - [Learn the fundamentals](/orm/v8/fundamentals/reading-data): filtering, sorting, pagination, and writes.
 - [Read the Prisma 8 overview](/orm/v8) for the concepts behind contracts and typed queries.
-- [Use the Bun guide](/guides/v8/runtimes/bun) if you also target Bun; the flow is the same apart from the runtime differences above.
+- [Use the Bun guide](/guides/v8/runtimes/bun) if you also target Bun. The flow is the same apart from the runtime differences above.
diff --git a/apps/docs/content/docs/guides/v8/upgrade-prisma-orm/meta.json b/apps/docs/content/docs/guides/v8/upgrade-prisma-orm/meta.json
index 1a20c32cbf..4290efa555 100644
--- a/apps/docs/content/docs/guides/v8/upgrade-prisma-orm/meta.json
+++ b/apps/docs/content/docs/guides/v8/upgrade-prisma-orm/meta.json
@@ -1,4 +1,7 @@
 {
   "title": "Upgrade Prisma ORM",
-  "pages": ["mongodb"]
+  "pages": [
+    "postgresql",
+    "mongodb"
+  ]
 }
diff --git a/apps/docs/content/docs/guides/v8/upgrade-prisma-orm/mongodb.mdx b/apps/docs/content/docs/guides/v8/upgrade-prisma-orm/mongodb.mdx
index ad1d52b80a..b1379b29d9 100644
--- a/apps/docs/content/docs/guides/v8/upgrade-prisma-orm/mongodb.mdx
+++ b/apps/docs/content/docs/guides/v8/upgrade-prisma-orm/mongodb.mdx
@@ -39,21 +39,24 @@ The `mongodb@^7` driver no longer accepts AWS credentials embedded in the connec
 Scaffold the project:
 
 ```bash
-npx @prisma/cli@next orm init --yes --target mongodb --authoring psl
+npx prisma@next orm init --yes --target mongodb --authoring psl
 ```
 
-`init` writes a `prisma-next.config.ts` at the repo root. MongoDB is selected by importing the `@prisma/orm-mongo` facade, not by a `provider` string in the schema. Point the connection at the **same database** your v6 app uses.
+`init` writes a `prisma.config.ts` at the repo root. You select MongoDB by importing the `@prisma/orm-mongo` facade instead of setting a `provider` string in the schema. Point the connection at the **same database** your v6 app uses.
 
 ```typescript tab="After"
-// prisma-next.config.ts
+// prisma.config.ts
 import 'dotenv/config';
-import { defineConfig } from '@prisma/orm-mongo/config';
+import { defineConfig } from '@prisma/cli-engine';
+import { defineConfig as ormConfig } from '@prisma/orm-mongo/config';
 
 export default defineConfig({
-  contract: './src/prisma/contract.prisma',
-  db: {
-    connection: process.env['DATABASE_URL']!,
-  },
+  orm: ormConfig({
+    contract: './src/prisma/contract.prisma',
+    db: {
+      connection: process.env['DATABASE_URL']!,
+    },
+  }),
 });
 ```
 
@@ -69,11 +72,11 @@ datasource db {
 
 ### Generate the contract
 
-Run `npx @prisma/cli@next contract emit` to generate `contract.json` from your `.prisma` contract file. Re-run this whenever you change the contract.
+Run `npx prisma@next contract emit` to generate `contract.json` from your `.prisma` contract file. Re-run this whenever you change the contract.
 
 ### Import the client
 
-The way to instantiate the Prisma client now is from the emitted contract. Replace `my-app-db` with the database name your v6 connection string uses; if the connection URL already carries the database name in its path, omit `dbName` and the client reads it from the URL:
+Instantiate the Prisma client from the emitted contract. Replace `my-app-db` with the database name your v6 connection string uses. If the connection URL already carries the database name in its path, omit `dbName` and the client reads it from the URL:
 
 ```typescript tab="After"
 // src/prisma/db.ts
@@ -107,7 +110,7 @@ Prisma 8 addresses collections by **storage name**, not model name: `db.orm.user
 
 :::
 
-The v6 `schema.prisma` is not consumed as-is; it becomes a **contract**, authored in PSL (shown here) or TypeScript. The syntax is close to v6, with a few differences.
+Prisma 8 does not consume the v6 `schema.prisma` as-is. You port it to a **contract**, authored in PSL (shown here) or TypeScript. The syntax is close to v6, with a few differences.
 
 In the table below, the left column is how you wrote it in v6 and the right column is the Prisma 8 equivalent:
 
@@ -119,7 +122,7 @@ You can use the [prisma-mongodb-upgrade](https://github.com/prisma/skills/tree/m
 
 | Concept | v6 (`schema.prisma`) | Prisma 8 (`contract.prisma`) |
 |---------|----------------------|---------------------------------|
-| Datasource | `datasource db { provider = "mongodb" }` | no `provider` (configured in `prisma-next.config.ts`) |
+| Datasource | `datasource db { provider = "mongodb" }` | no `provider` (configured in `prisma.config.ts`) |
 | Id field | `id String @id @default(auto()) @map("_id") @db.ObjectId` | `id ObjectId @id @map("_id")` |
 | Embedded document | `type Address { ... }` | `type Address { ... }` (unchanged) |
 | Index | `@@index(...)`, synced by `db push` | `@@index(...)` / `@@unique(...)`, applied by migrations |
@@ -173,7 +176,7 @@ When you use `@@discriminator`, declare a variant for every value the field take
 
 ## 3. Port client calls
 
-Names look similar but parity does not hold. This section breaks down each category of operation.
+Many method names look similar, but they do not behave the same way. This section breaks down each category of operation.
 
 ### 3a. Basic CRUD
 
@@ -389,8 +392,8 @@ For raw reads and writes scoped to a single collection (anything the typed build
 | `aggregate` / `groupBy` | `db.query.from(...).group(...).build()` → `db.execute(plan)` |
 | `findRaw` / `aggregateRaw` | `db.raw.collection(...).aggregate(...).build()` → `db.execute(plan)`, or `db.query.rawCommand(...)` |
 | `$runCommandRaw` | share a `MongoClient` with the binding, then `mongoClient.db(...).command(...)` (see 3e) |
-| `$transaction(...)` | no wrapper yet; driver sessions on a replica set (see 3d) |
-| `$connect` / `$disconnect` | lazy connect on first use; `db.close()` to disconnect |
+| `$transaction(...)` | no wrapper yet. Use driver sessions on a replica set (see 3d) |
+| `$connect` / `$disconnect` | connects lazily on first use. Call `db.close()` to disconnect |
 
 ## 4. Adopt the migration lifecycle
 
@@ -398,12 +401,12 @@ v6 MongoDB had no Prisma Migrate, only `db push` (ephemeral, no history). Prisma
 
 ### Bring the v6 database under management
 
-Your database already has collections and data, so bootstrap it with `db update`: it diffs the live database against your contract, applies the delta (the strict validators, plus any indexes the contract declares that v6 never created), and signs the database so Prisma 8 recognizes it from then on. The `--advance-ref db` flag records the resulting contract state as the [`db` ref](/orm/v8/migrations/the-migration-graph#name-important-states-with-refs), the starting point later migration plans diff from.
+Your database already has collections and data, so bootstrap it with `db update`. The command diffs the live database against your contract, applies the delta (the strict validators, plus any indexes the contract declares that v6 never created), and signs the database so Prisma 8 recognizes it from then on. The `--advance-ref db` flag records the resulting contract state as the [`db` ref](/orm/v8/migrations/the-migration-graph#name-important-states-with-refs), the starting point later migration plans diff from.
 
 ```bash
-npx @prisma/cli@next contract emit
-npx @prisma/cli@next db update --db "$DATABASE_URL" --dry-run   # preview the delta first
-npx @prisma/cli@next db update --db "$DATABASE_URL" --advance-ref db
+npx prisma@next contract emit
+npx prisma@next db update --db "$DATABASE_URL" --dry-run   # preview the delta first
+npx prisma@next db update --db "$DATABASE_URL" --advance-ref db
 ```
 
 Don't reach for `db init` here. It bootstraps only additively, and on a populated database it refuses the validator changes this migration needs, because adding a validator to a collection with existing documents is classed destructive. `db update` applies them after a confirmation prompt.
@@ -413,15 +416,16 @@ Don't reach for `db init` here. It bootstraps only additively, and on a populate
 Use `db update` for local experiments (the `db push` analogue, no history kept) and the migration workflow for shared branches and production:
 
 ```bash
-npx @prisma/cli@next migration plan --name add_posts_indexes   # plans from the db ref
-npx @prisma/cli@next migrate --db "$DATABASE_URL" --advance-ref db
-npx @prisma/cli@next db verify --db "$DATABASE_URL"   # check the DB matches the contract
+npx prisma@next contract emit                             # planning diffs the emitted contract
+npx prisma@next migration plan --name add_posts_indexes   # plans from the db ref
+npx prisma@next migrate --db "$DATABASE_URL" --advance-ref db
+npx prisma@next db verify --db "$DATABASE_URL"   # check the DB matches the contract
 ```
 
 **Good to know:**
 
 - You never hand-write migration steps: declare indexes and validators in the contract (step 2) and `migration plan` derives the changes.
-- Interrupted `migrate` runs are resumable; just rerun. After fixing anything by hand, run `db sign` so the signature matches the database again.
+- If a `migrate` run is interrupted, rerun it to resume. After fixing anything by hand, run `db sign` so the signature matches the database again.
 - Prisma 8 adds strict `$jsonSchema` validators by default. Make sure existing documents pass them before running in production: once the validators are live, writes to documents that don't match the contract fail with `Document failed validation`.
 
 ## 5. Pre-flight checklist (before production cutover)
@@ -449,4 +453,4 @@ Once you've cut over, this is the day-to-day workflow:
 - **Troubleshooting.** `db verify` checks the database against your contract, and `db sign` records any fixes you make by hand.
 - **Performance.** Your aggregations now compile to native MongoDB pipelines, so it's worth benchmarking them against your old v6 raw calls.
 
-See the [Prisma 8 docs](/orm/v8) for [pipeline builder patterns](/orm/v8/reference/pipeline-builder), [relation loading strategies](/orm/v8/reference/orm-client), and [advanced contract features](/orm/v8/contract-authoring/psl-syntax). This guide gets you across the bridge; Prisma 8's docs are the source of truth from here on.
+See the [Prisma 8 docs](/orm/v8) for [pipeline builder patterns](/orm/v8/reference/pipeline-builder), [relation loading strategies](/orm/v8/reference/orm-client), and [advanced contract features](/orm/v8/contract-authoring/psl-syntax). This guide gets you across the bridge. From here on, Prisma 8's docs are the source of truth.
diff --git a/apps/docs/content/docs/guides/v8/upgrade-prisma-orm/postgresql.mdx b/apps/docs/content/docs/guides/v8/upgrade-prisma-orm/postgresql.mdx
new file mode 100644
index 0000000000..de142187c9
--- /dev/null
+++ b/apps/docs/content/docs/guides/v8/upgrade-prisma-orm/postgresql.mdx
@@ -0,0 +1,549 @@
+---
+title: Migrate from Prisma 7 to Prisma 8
+description: Migrate a PostgreSQL project from Prisma 7 to Prisma 8 incrementally, with both versions running side by side
+url: /guides/v8/upgrade-prisma-orm/postgresql
+metaTitle: How to migrate a PostgreSQL project from Prisma 7 to Prisma 8
+metaDescription: Step-by-step guide to migrating a Prisma 7 PostgreSQL project to Prisma 8 incrementally. Run both clients side by side, migrate routes one at a time, then move migrations to Prisma 8.
+---
+
+This guide is for teams running a Prisma 7 application on PostgreSQL who want to move to **Prisma 8** without a rewrite. You will install Prisma 8 next to Prisma 7 in the same application, move routes over one at a time, hand migration ownership to Prisma 8, and remove Prisma 7 once nothing depends on it.
+
+Both versions run against the same PostgreSQL database the whole time. The database, its data, and its connection string do not change; only application code and tooling do. Because each route stays on Prisma 7 until you deliberately move it, the application remains shippable at every point in the migration.
+
+The guide covers **PostgreSQL only**. Guidance for other databases will follow. If you are coming from v6 on MongoDB, see the [MongoDB guide](/guides/v8/upgrade-prisma-orm/mongodb).
+
+:::info
+
+Prisma 8 is a Release Candidate and evolves quickly. Every command and code example in this guide was validated against `prisma@8.0.0-rc.6`, `@prisma/orm-postgres@8.0.0-rc.4`, `@prisma/cli-engine@0.2.0`, and `@prisma/prisma7@7.10.0-dev.58`, with a Prisma 7 baseline on `7.9.1`.
+
+:::
+
+## How the incremental migration works
+
+The migration runs in five phases. The application works at the end of each one.
+
+1. **Prepare Prisma 7 for side-by-side operation.** Move Prisma 7 onto its own package name, binary, and config file. No behavior changes.
+2. **Add Prisma 8.** Install the Prisma 8 CLI and runtime with their own config, schema contract, and generated client. No application code uses them yet.
+3. **Migrate one route.** One route runs on Prisma 8 while the rest stay on Prisma 7, all against the same database.
+4. **Transfer migration ownership.** Prisma 8 takes over planning and applying schema changes.
+5. **Remove Prisma 7** once nothing imports it.
+
+The ownership timeline matters more than the code timeline. Prisma 7 owns schema migrations through phases 1 to 3, and routes move to Prisma 8 independently of that. Prisma 8 takes over migrations only in phase 4, after a baseline migration, a database signature, and a ref are in place. You can pause between phases for as long as you need.
+
+The [prisma8-and-7-example](https://github.com/prisma/prisma8-and-7-example) repository shows the finished result of each phase (tags `step-0` through `step-3`).
+
+## Prerequisites
+
+- **Node.js 22.18+** (required by `@prisma/orm-postgres`)
+- A working **Prisma 7** application on PostgreSQL: `prisma.config.ts`, the `prisma-client` generator, and a driver adapter
+- **TypeScript 5.3+** with `"strict": true` and a `module` setting that supports import attributes, such as `"nodenext"`
+
+## 1. Prepare Prisma 7 for side-by-side operation
+
+Prisma 8 expects the `prisma` package name, the `prisma` binary, and the `prisma.config.ts` file name. In this phase you move Prisma 7 off those three names so Prisma 8 can take them without ambiguity. Nothing migrates yet.
+
+### 1.1. Confirm the application works
+
+The guide follows a small Hono API with two routes. Map the file names to your own project. The Prisma 7 pieces that matter:
+
+```json title="package.json (excerpt)"
+{
+  "scripts": {
+    "prisma:generate": "prisma generate",
+    "db:migrate": "prisma migrate dev"
+  },
+  "dependencies": {
+    "@prisma/adapter-pg": "^7.9.1",
+    "@prisma/client": "^7.9.1"
+  },
+  "devDependencies": {
+    "prisma": "^7.9.1"
+  }
+}
+```
+
+```prisma title="prisma/schema.prisma"
+generator client {
+  provider = "prisma-client"
+  output   = "../generated/prisma"
+}
+
+datasource db {
+  provider = "postgresql"
+}
+
+model User {
+  id    Int     @id @default(autoincrement())
+  email String  @unique
+  name  String?
+  posts Post[]
+}
+
+model Post {
+  id        Int     @id @default(autoincrement())
+  title     String
+  published Boolean @default(false)
+  authorId  Int
+  author    User    @relation(fields: [authorId], references: [id], onDelete: Cascade)
+
+  @@index([authorId])
+}
+```
+
+```typescript title="prisma.config.ts"
+import "dotenv/config";
+import { defineConfig } from "prisma/config";
+
+export default defineConfig({
+  schema: "prisma/schema.prisma",
+  migrations: {
+    path: "prisma/migrations",
+  },
+  datasource: {
+    url: process.env["DATABASE_URL"],
+  },
+});
+```
+
+```typescript title="src/db.ts"
+import "dotenv/config";
+import { PrismaPg } from "@prisma/adapter-pg";
+import { PrismaClient } from "../generated/prisma/client.js";
+
+const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL! });
+
+export const prisma = new PrismaClient({ adapter });
+```
+
+Two routes read and write through this client, `/users` and `/posts`:
+
+```typescript title="src/routes/users.ts"
+import { Hono } from "hono";
+import { prisma } from "../db.js";
+
+export const users = new Hono();
+
+users.get("/", async (c) => {
+  const result = await prisma.user.findMany({
+    include: { posts: true },
+    orderBy: { id: "asc" },
+  });
+  return c.json(result);
+});
+
+users.post("/", async (c) => {
+  const body = await c.req.json<{ email: string; name?: string }>();
+  const user = await prisma.user.create({ data: body });
+  return c.json(user, 201);
+});
+```
+
+`src/routes/posts.ts` follows the same pattern for `Post`.
+
+Start the app and run a read and a write:
+
+```npm
+npm run dev
+```
+
+```bash
+curl -X POST localhost:3000/users -H 'content-type: application/json' \
+  -d '{"email":"alice@prisma.io","name":"Alice"}'
+curl localhost:3000/users
+```
+
+Do not continue until both requests succeed. That confirms the Prisma 7 application works before you change its configuration.
+
+### 1.2. Replace the `prisma` package with `@prisma/prisma7`
+
+```npm
+npm uninstall prisma
+npm install --save-dev @prisma/prisma7@7.10.0-dev.58
+```
+
+`@prisma/prisma7` is the same Prisma 7 CLI under a version-specific name. It exposes a `prisma7` binary and keeps `prisma` 7 as a transitive dependency. Your `@prisma/client` and `@prisma/adapter-pg` dependencies stay untouched.
+
+### 1.3. Rename the Prisma 7 config
+
+```bash
+mv prisma.config.ts prisma7.config.ts
+```
+
+```typescript title="prisma7.config.ts"
+import "dotenv/config";
+import { defineConfig } from "prisma/config"; // [!code --]
+import { defineConfig } from "@prisma/prisma7/config"; // [!code ++]
+
+export default defineConfig({
+  schema: "prisma/schema.prisma",
+  migrations: {
+    path: "prisma/migrations",
+  },
+  datasource: {
+    url: process.env["DATABASE_URL"],
+  },
+});
+```
+
+The `prisma7` CLI discovers `prisma7.config.ts` automatically, so no `--config` flag is needed. Renaming frees the `prisma.config.ts` name for Prisma 8, which only accepts its own config format under that name.
+
+### 1.4. Point scripts at the `prisma7` binary
+
+```json title="package.json (excerpt)"
+{
+  "scripts": {
+    "prisma:generate": "prisma generate", // [!code --]
+    "db:migrate": "prisma migrate dev" // [!code --]
+    "prisma7:generate": "prisma7 generate", // [!code ++]
+    "prisma7:migrate": "prisma7 migrate dev" // [!code ++]
+  }
+}
+```
+
+After Prisma 8 is installed, the `prisma` binary runs the Prisma 8 CLI. Update every script, CI job, and deployment command that must continue using Prisma 7 to call `prisma7` instead.
+
+### 1.5. Check that Prisma 7 still works
+
+```npm
+npx prisma7 generate
+npx prisma7 migrate status
+```
+
+**Expected result:** `generate` writes the client to `generated/prisma` as before, and `migrate status` reports that the database schema is up to date. Start the app and query each route; behavior should be identical to step 1.1.
+
+## 2. Add Prisma 8
+
+### 2.1. Install the Prisma 8 packages
+
+```npm
+npm install --save-dev prisma@next @prisma/cli-engine@0.2.0
+npm install @prisma/orm-postgres
+```
+
+`prisma@next` is the Prisma 8 CLI. `@prisma/orm-postgres` is the PostgreSQL ORM runtime your application code will import. `@prisma/cli-engine` provides `defineConfig` for the Prisma 8 config file. Install it directly so the import resolves under every package manager.
+
+After this install, `npx prisma <command>` runs the Prisma 8 CLI and `npx prisma7 <command>` runs Prisma 7:
+
+```npm
+npx prisma --version
+```
+
+**Expected result:** `8.0.0-rc.6` (or newer).
+
+### 2.2. Create the Prisma 8 config
+
+```typescript title="prisma.config.ts"
+import "dotenv/config";
+import { defineConfig } from "@prisma/cli-engine";
+import { defineConfig as definePostgresConfig } from "@prisma/orm-postgres/config";
+
+export default defineConfig({
+  orm: definePostgresConfig({
+    contract: "prisma8/contract.prisma",
+    output: "generated/prisma8",
+    db: {
+      connection: process.env["DATABASE_URL"],
+    },
+  }),
+});
+```
+
+Both configs point at the **same** `DATABASE_URL`. Everything else is separate:
+
+| | Prisma 7 | Prisma 8 |
+|---|---|---|
+| CLI | `prisma7` | `prisma` |
+| Config | `prisma7.config.ts` | `prisma.config.ts` |
+| Schema | `prisma/schema.prisma` | `prisma8/contract.prisma` |
+| Generated client | `generated/prisma` | `generated/prisma8` |
+
+Because the config carries the connection, the Prisma 8 CLI commands below don't need a `--db` flag.
+
+### 2.3. Infer the contract from the live database
+
+Prisma 8 describes your schema as a [contract](/orm/v8/contract-authoring/the-data-contract). Generate it from the database Prisma 7 built:
+
+```npm
+npx prisma contract infer --output prisma8/contract.prisma
+```
+
+### 2.4. Edit the inferred contract
+
+The inferred contract needs two edits before it is correct:
+
+1. **Delete the `PrismaMigrations` model.** `contract infer` picks up Prisma 7's `_prisma_migrations` ledger table. Prisma 8 must not manage it, and extra tables in the database are fine. Remove the whole model.
+2. **Add `@@map` to every model.** Prisma 8 addresses tables by storage name and lowercases unmapped model names, so without `@@map("User")` it would query `public.user`. The table Prisma 7 created is `"User"`, so queries fail with `relation "public.user" does not exist`.
+
+The finished contract:
+
+```prisma title="prisma8/contract.prisma"
+model User {
+  id    Int     @id(map: "User_pkey") @default(autoincrement())
+  email String
+  name  String?
+  posts Post[]
+
+  @@index([email], map: "User_email_key", unique: true)
+  @@map("User")
+}
+
+model Post {
+  id        Int     @id(map: "Post_pkey") @default(autoincrement())
+  title     String
+  published Boolean @default(false)
+  authorId  Int
+  author    User    @relation(fields: [authorId], references: [id], onDelete: Cascade, onUpdate: Cascade, map: "Post_authorId_fkey")
+
+  @@index([authorId], map: "Post_authorId_idx")
+  @@map("Post")
+}
+```
+
+### 2.5. Emit the contract artifacts
+
+```npm
+npx prisma contract emit
+```
+
+`contract emit` writes `contract.json` and `contract.d.ts` to `generated/prisma8`, the runtime and type inputs for the Prisma 8 client. Re-run it after every contract change.
+
+### 2.6. Include the generated types
+
+The Prisma 8 client imports `contract.json` with the `with { type: "json" }` import attribute. This syntax requires TypeScript 5.3 or later and a `module` setting that supports import attributes. The example project uses `"module": "nodenext"`, which supports them. `"esnext"` with `"moduleResolution": "bundler"` also works.
+
+Enable `resolveJsonModule` so TypeScript types the imported JSON, and include the generated declarations in the program:
+
+```json title="tsconfig.json (excerpt)"
+{
+  "compilerOptions": {
+    "module": "nodenext",
+    "resolveJsonModule": true // [!code ++]
+  },
+  "include": [
+    "src/**/*.ts",
+    "generated/prisma/**/*.ts",
+    "generated/prisma8/**/*.d.ts" // [!code ++]
+  ]
+}
+```
+
+**Check:** `npx tsc --noEmit` passes. Prisma 8 is now installed and configured, but no application code uses it yet.
+
+## 3. Migrate one route
+
+Pick one small route and move only that code. The rest of the application stays on Prisma 7.
+
+### 3.1. Instantiate both clients
+
+```typescript title="src/db.ts"
+import "dotenv/config";
+import { PrismaPg } from "@prisma/adapter-pg";
+import postgres from "@prisma/orm-postgres/runtime"; // [!code ++]
+import type { Contract } from "../generated/prisma8/contract.js"; // [!code ++]
+import contractJson from "../generated/prisma8/contract.json" with { type: "json" }; // [!code ++]
+import { PrismaClient } from "../generated/prisma/client.js";
+
+const connectionString = process.env.DATABASE_URL!;
+
+const adapter = new PrismaPg({ connectionString });
+
+export const prisma = new PrismaClient({ adapter });
+
+export const db = postgres<Contract>({ url: connectionString, contractJson }); // [!code ++]
+```
+
+`prisma` is the Prisma 7 client and `db` is the Prisma 8 client, both connected to the same database.
+
+### 3.2. Rewrite the route
+
+Move the users route to the Prisma 8 [ORM client](/orm/v8/reference/orm-client). Queries start from `db.orm.<schema>.<Model>` (`public` here) and chain instead of taking one options object:
+
+```typescript title="src/routes/users.ts" tab="After"
+import { Hono } from "hono";
+import { db } from "../db.js";
+
+export const users = new Hono();
+
+users.get("/", async (c) => {
+  const result = await db.orm.public.User.include("posts", (posts) =>
+    posts.orderBy((post) => post.id.asc()),
+  )
+    .orderBy((user) => user.id.asc())
+    .all();
+  return c.json(result);
+});
+
+users.post("/", async (c) => {
+  const body = await c.req.json<{ email: string; name?: string }>();
+  const user = await db.orm.public.User.create(body);
+  return c.json(user, 201);
+});
+```
+
+```typescript title="src/routes/users.ts" tab="Before"
+import { Hono } from "hono";
+import { prisma } from "../db.js";
+
+export const users = new Hono();
+
+users.get("/", async (c) => {
+  const result = await prisma.user.findMany({
+    include: { posts: true },
+    orderBy: { id: "asc" },
+  });
+  return c.json(result);
+});
+
+users.post("/", async (c) => {
+  const body = await c.req.json<{ email: string; name?: string }>();
+  const user = await prisma.user.create({ data: body });
+  return c.json(user, 201);
+});
+```
+
+`src/routes/posts.ts` stays unchanged, on Prisma 7.
+
+### 3.3. Exercise both code paths
+
+Start the app and hit both routes:
+
+```bash
+curl localhost:3000/users
+curl -X POST localhost:3000/posts -H 'content-type: application/json' \
+  -d '{"title":"Written by Prisma 7","authorId":1}'
+curl localhost:3000/users
+```
+
+**Expected result:** the first request runs through Prisma 8. The second writes through Prisma 7. The third, through Prisma 8 again, includes the post Prisma 7 just wrote.
+
+Remaining routes can move over the same way, one at a time, on any schedule. Prisma 7 still owns schema migrations in this phase. If the schema changes, run `prisma7 migrate dev`, then re-run `contract infer` and `contract emit` so the Prisma 8 contract stays current.
+
+## 4. Transfer migration ownership
+
+So far every schema change has gone through `prisma7 migrate dev`. In this phase Prisma 8 takes over planning and applying schema changes, and `prisma/schema.prisma` is frozen.
+
+Treat the switch as a decision, not a routine step. After it, your team and your pipelines must stop using the Prisma 7 migration workflow, even though routes still on the Prisma 7 client keep working. See [how migrations work](/orm/v8/migrations/how-migrations-work) for the full picture.
+
+Prisma 8 tracks schema state with four pieces, and the handoff creates each one exactly once:
+
+- A **contract hash** identifies one version of the emitted contract.
+- A **migration** is an on-disk package recording how to get from one contract hash to another. `migrate` only replays recorded migrations; it never invents one.
+- The **marker** is Prisma 8's record, stored in the database, of which contract hash the database currently satisfies.
+- A **ref** is a named pointer at a contract hash. `migration plan` uses the `db` ref as its starting point.
+
+Steps 4.1 to 4.3 create the baseline migration, set the marker, and set the ref.
+
+### 4.1. Create a baseline migration
+
+```npm
+npx prisma migration plan --name baseline
+```
+
+The command writes a migration package under `migrations/app/<timestamp>_baseline/` plus a contract snapshot under `migrations/snapshots/`. It captures the full schema Prisma 7 built, but you will not run it against your database.
+
+### 4.2. Sign the existing database
+
+Your database already has these tables, so adopt it instead of replaying the baseline:
+
+```npm
+npx prisma db sign
+```
+
+`db sign` verifies the live schema matches the emitted contract and writes Prisma 8's marker at that contract version.
+
+**Expected result:** `Database signed (marker created)`. Then confirm nothing is pending:
+
+```npm
+npx prisma migration status
+```
+
+The current and target contract hashes should match, with the baseline migration listed as already satisfied.
+
+### 4.3. Set the `db` ref
+
+Point a [ref](/orm/v8/migrations/the-migration-graph#name-important-states-with-refs) named `db` at the baseline, using the directory name from step 4.1:
+
+```npm
+npx prisma ref set db <timestamp>_baseline
+```
+
+Without a ref, the next `migration plan` starts from scratch and plans `CREATE TABLE` operations all over again. With it, plans chain from the baseline and contain only your actual changes.
+
+### 4.4. Retire the Prisma 7 migration scripts
+
+Remove `prisma7 migrate` from your scripts so nobody runs it by accident. Keep `prisma7 generate`, because the legacy routes still need their client:
+
+```json title="package.json (excerpt)"
+{
+  "scripts": {
+    "prisma7:generate": "prisma7 generate",
+    "prisma7:migrate": "prisma7 migrate dev", // [!code --]
+    "prisma8:migrate": "prisma migrate --advance-ref db" // [!code ++]
+  }
+}
+```
+
+### 4.5. Verify the handoff with a schema change
+
+Verify the migration handoff with a small additive schema change. Add a field to the contract:
+
+```prisma title="prisma8/contract.prisma (excerpt)"
+model User {
+  id    Int     @id(map: "User_pkey") @default(autoincrement())
+  email String
+  name  String?
+  bio   String? // [!code ++]
+  ...
+}
+```
+
+Emit, plan, and apply:
+
+```npm
+npx prisma contract emit
+npx prisma migration plan --name add_user_bio
+npx prisma migrate --advance-ref db
+npx prisma db verify
+```
+
+**Expected result:** `migration plan` contains a single operation, `Add column "bio" to "User"`. If you see `CREATE TABLE` operations instead, the `db` ref from step 4.3 is missing. `migrate` applies the migration, `--advance-ref db` moves the ref so the next plan chains correctly, and `db verify` reports that marker and schema match the contract.
+
+Restart the app: the Prisma 8 route returns users with `bio`, and the Prisma 7 route keeps working untouched, because its client doesn't know about the new column. Additive changes like nullable columns are safe next to legacy Prisma 7 code. Be careful with renames or drops of columns that Prisma 7 routes still read.
+
+## 5. Remove Prisma 7
+
+Migrate the remaining routes as in phase 3. For `posts` here, that means swapping `prisma.post.findMany(...)` for `db.orm.public.Post.include("author").all()` and `prisma.post.create({ data })` for `db.orm.public.Post.create(data)`.
+
+When nothing imports `generated/prisma` anymore, remove Prisma 7:
+
+```npm
+npm uninstall @prisma/prisma7 @prisma/client @prisma/adapter-pg
+```
+
+```bash
+rm prisma7.config.ts
+rm -r prisma generated/prisma
+```
+
+Then delete the `prisma7:*` scripts from `package.json` and drop `generated/prisma/**/*.ts` from the `include` array in `tsconfig.json`.
+
+Verify the end state:
+
+```npm
+npx tsc --noEmit
+npx prisma db verify
+```
+
+Start the app and run a query against every route. The application now runs entirely on Prisma 8, with schema changes managed by `prisma migrate`.
+
+:::note
+
+Prisma 7's `_prisma_migrations` table remains in the database. It is inert (Prisma 8 ignores it) and you can drop it whenever you like.
+
+:::
+
+## Next steps
+
+- [How migrations work in Prisma 8](/orm/v8/migrations/how-migrations-work): the day-to-day `contract emit` → `migration plan` → `migrate` loop for schema changes
+- [Contract authoring](/orm/v8/contract-authoring/psl-syntax): the full PSL syntax for evolving `contract.prisma`
+- [Prisma 8 CLI reference](/cli/v8): every command used in this guide
diff --git a/apps/docs/content/docs/orm/v8/contract-authoring/capabilities.mdx b/apps/docs/content/docs/orm/v8/contract-authoring/capabilities.mdx
index f0f82757cd..0b09c21f20 100644
--- a/apps/docs/content/docs/orm/v8/contract-authoring/capabilities.mdx
+++ b/apps/docs/content/docs/orm/v8/contract-authoring/capabilities.mdx
@@ -9,7 +9,7 @@ badge: release-candidate
 
 Not every database stack supports every feature. One setup can run lateral joins, `RETURNING` clauses, and vector distance operations; another cannot.
 
-Capabilities are how the [data contract](/orm/v8/contract-authoring/the-data-contract) records what yours supports. Prisma 8 checks them before using a gated feature, so an unsupported feature fails early, with an error that names the missing capability, instead of surfacing as a database error mid-query.
+Capabilities are how the [data contract](/orm/v8/contract-authoring/the-data-contract) records what yours supports. Prisma 8 checks them before using a gated feature. An unsupported feature fails early with an error that names the missing capability, instead of surfacing as a database error mid-query.
 
 ## Where capabilities come from
 
@@ -38,20 +38,20 @@ You do not write capabilities yourself. When [`contract emit`](/cli/v8/contract-
 }
 ```
 
-The `sql` namespace holds keys shared across SQL databases; the `postgres` namespace holds PostgreSQL-specific keys. Extension packs contribute keys of their own: composing the pgvector pack is what adds `pgvector.cosine` above. Because the packs declare the keys, adding or removing an extension in `prisma-next.config.ts` and re-running `contract emit` changes the capability set with no further work.
+The `sql` namespace holds keys shared across SQL databases; the `postgres` namespace holds PostgreSQL-specific keys. Extension packs contribute keys of their own: composing the pgvector pack is what adds `pgvector.cosine` above. Because the packs declare the keys, adding or removing an extension in `prisma.config.ts` and re-running `contract emit` changes the capability set with no further work.
 
 ## What capabilities gate
 
 Capabilities are checked at two points, both before any SQL reaches the database.
 
-**When the contract is built.** A schema feature the target cannot store fails emission with a diagnostic. For example, SQLite does not report the `scalarList` capability, so a scalar list field in a contract targeting SQLite fails to emit:
+**When the contract is built.** If the schema uses a feature the target cannot store, `contract emit` fails with a diagnostic. For example, SQLite does not report the `scalarList` capability, so a scalar list field in a contract targeting SQLite fails to emit:
 
 ```text
 Field "User.tags" is a scalar list, but target "sqlite" does not support
 scalar lists (the adapter does not report the "scalarList" capability).
 ```
 
-**When a query is built.** Query-builder methods that depend on a capability check the contract's matrix and throw if the key is missing, naming the method and the capability:
+**When a query is built.** Query-builder methods that depend on a capability check the contract's `capabilities` section and throw if the key is missing, naming the method and the capability:
 
 ```text
 distinctOn() requires capability postgres.distinctOn
@@ -75,19 +75,19 @@ A few of the keys the built-in components declare, to give a sense of the granul
 | `postgres.jsonAgg` | JSON aggregation for nested reads |
 | `postgres.pgvector.cosine` | Cosine distance operations, contributed by the pgvector pack |
 
-This is an illustration, not the full registry; each target, adapter, and pack ships its own declarations. The emitted `contract.json` of your own project is the authoritative list of what your stack supports.
+This table is a sample, not the full registry. Each target, adapter, and pack ships its own declarations. Your project's emitted `contract.json` is the authoritative list of what your stack supports.
 
 MongoDB currently declares no capability keys: the capability system mostly differentiates SQL targets and their extensions, and the MongoDB pipeline does not yet gate features this way.
 
 ## Capabilities and verification
 
-Capabilities describe what the composed software stack supports, as declared by the target, adapter, and packs. They are recorded in the contract at emit time rather than probed from the live database, so the same contract behaves identically in every environment. Database-side verification is the separate hash-and-marker mechanism described in [the contract artifact](/orm/v8/contract-authoring/the-contract-artifact#the-content-hashes): [`db verify`](/cli/v8/db-verify) checks that the database matches the contract's schema and profile.
+Capabilities describe what the composed software stack supports, as declared by the target, adapter, and packs. They are recorded in the contract at emit time rather than probed from the live database, so the same contract behaves identically in every environment. Database-side verification is separate: [`db verify`](/cli/v8/db-verify) checks that the database matches the contract's schema and profile, using the hashes described in [the contract artifact](/orm/v8/contract-authoring/the-contract-artifact#the-content-hashes).
 
-Extensions are the main source of capabilities beyond the core; [Using extensions](/orm/v8/extensions/using-extensions) shows the full install-to-query flow.
+Extensions are the main source of capabilities beyond the core. [Using extensions](/orm/v8/extensions/using-extensions) shows the full flow from install to first query.
 
 ## Prompt your coding agent
 
-Projects scaffolded with `create-prisma@next` install [Prisma 8 skills](/ai/tools/skills#available-skills-for-prisma-8) for your coding agent; the `prisma-8` skill covers this page. Ask your agent to:
+Projects scaffolded with `create-prisma@next` install [Prisma 8 skills](/ai/tools/skills#available-skills-for-prisma-8) for your coding agent. The `prisma-8` skill covers this page. Ask your agent to:
 
 - "Which capabilities does our contract currently require, and which package provides each?"
 - "Add pgvector to the project and confirm the capability shows up in the emitted contract."
diff --git a/apps/docs/content/docs/orm/v8/contract-authoring/psl-syntax.mdx b/apps/docs/content/docs/orm/v8/contract-authoring/psl-syntax.mdx
index 058be08413..b4bda11b0c 100644
--- a/apps/docs/content/docs/orm/v8/contract-authoring/psl-syntax.mdx
+++ b/apps/docs/content/docs/orm/v8/contract-authoring/psl-syntax.mdx
@@ -100,25 +100,31 @@ model Post {
 }
 ```
 
-Run `npx @prisma/cli@next contract emit` after any change to refresh the artifacts.
+Run `npx prisma@next contract emit` after any change to refresh the artifacts.
 
 ## Point the config at the schema
 
 The config's `contract` path names the source of truth. A `.prisma` extension selects PSL authoring:
 
-```typescript title="prisma-next.config.ts" tab="PostgreSQL"
-import { defineConfig } from "@prisma/orm-postgres/config";
+```typescript title="prisma.config.ts" tab="PostgreSQL"
+import { defineConfig } from "@prisma/cli-engine";
+import { defineConfig as ormConfig } from "@prisma/orm-postgres/config";
 
 export default defineConfig({
-  contract: "./prisma/contract.prisma",
+  orm: ormConfig({
+    contract: "./prisma/contract.prisma",
+  }),
 });
 ```
 
-```typescript title="prisma-next.config.ts" tab="MongoDB"
-import { defineConfig } from "@prisma/orm-mongo/config";
+```typescript title="prisma.config.ts" tab="MongoDB"
+import { defineConfig } from "@prisma/cli-engine";
+import { defineConfig as ormConfig } from "@prisma/orm-mongo/config";
 
 export default defineConfig({
-  contract: "./prisma/contract.prisma",
+  orm: ormConfig({
+    contract: "./prisma/contract.prisma",
+  }),
 });
 ```
 
@@ -130,7 +136,7 @@ Models declare fields with a type, an optional `?` marker, and attributes:
 
 - `@id` marks the primary key; `@@id([a, b])` declares a composite key.
 - `@unique` adds a unique constraint; `@@index([...])` declares a secondary index.
-- `@default(...)` sets a default. Database function defaults such as `@default(now())` become column defaults in the database. Generated defaults such as `@default(uuid())` are applied by Prisma 8 before each write instead, so they work the same on every database and appear in the contract's `execution` section rather than as DDL.
+- `@default(...)` sets a default. Database function defaults such as `@default(now())` become column defaults in the database. Generated defaults such as `@default(uuid())` are applied by Prisma 8 before each write instead, so they work the same on every database. They appear in the contract's `execution` section rather than as DDL.
 - `@map("column_name")` sets a field's physical name; `@@map("table_name")` sets the table or collection name when it differs from the model name.
 
 How IDs map differs by database:
@@ -188,7 +194,7 @@ enum Priority {
 }
 ```
 
-`@@type("pg/text@1")` stores the values as `text` on PostgreSQL. When a member has no explicit value, the member name itself is stored. In the database, the emitted contract enforces the allowed values with a `CHECK` constraint on each column that uses the enum.
+`@@type("pg/text@1")` stores the values as `text` on PostgreSQL. When a member has no explicit value, the member name itself is stored. In the database, Prisma 8 enforces the allowed values with a `CHECK` constraint on each column that uses the enum.
 
 ## Value objects
 
@@ -208,7 +214,7 @@ model User {
 }
 ```
 
-Storage follows the database's nature: on PostgreSQL a value object field lives in a single `jsonb` column, and on MongoDB it is an embedded document. Either way, `contract.d.ts` types it as a structured object rather than untyped JSON. On MongoDB, whether to embed or reference is the central modeling decision; [MongoDB data modeling](/orm/v8/data-modeling/mongodb#embed-or-reference) covers it.
+Storage differs by database: on PostgreSQL a value object field lives in a single `jsonb` column, and on MongoDB it is an embedded document. Either way, `contract.d.ts` types it as a structured object rather than untyped JSON. On MongoDB, whether to embed or reference is the central modeling decision; [MongoDB data modeling](/orm/v8/data-modeling/mongodb#embed-or-reference) covers it.
 
 ## Relations
 
@@ -273,19 +279,22 @@ model Bug {
 }
 ```
 
-Rows with `type = "bug"` are `Bug` records. On PostgreSQL, the variant's `@@map` picks its storage layout: with its own `@@map`, as here, the variant's fields live in their own table sharing the base model's primary key; without one, they live in the base table as nullable columns. [Relational data modeling](/orm/v8/data-modeling/relational-databases#polymorphic-relations) covers choosing between the two. On MongoDB, variants add their fields to documents in the base model's collection, so a variant declares `@@base` but no `@@map` of its own.
+Rows with `type = "bug"` are `Bug` records. On PostgreSQL, the variant's `@@map` picks its storage layout: with its own `@@map`, as here, the variant's fields live in their own table sharing the base model's primary key. Without one, they live in the base table as nullable columns. [Relational data modeling](/orm/v8/data-modeling/relational-databases#polymorphic-relations) covers choosing between the two. On MongoDB, variants add their fields to documents in the base model's collection, so a variant declares `@@base` but no `@@map` of its own.
 
 ## Extension types
 
 Extension packs contribute types through constructor expressions in the `types` block. Compose the pack in the config, then use its types:
 
-```typescript title="prisma-next.config.ts"
+```typescript title="prisma.config.ts"
+import { defineConfig } from "@prisma/cli-engine";
 import pgvector from "@prisma/orm-extension-pgvector/control";
-import { defineConfig } from "@prisma/orm-postgres/config";
+import { defineConfig as ormConfig } from "@prisma/orm-postgres/config";
 
 export default defineConfig({
-  contract: "./prisma/contract.prisma",
-  extensions: [pgvector],
+  orm: ormConfig({
+    contract: "./prisma/contract.prisma",
+    extensions: [pgvector],
+  }),
 });
 ```
 
@@ -300,17 +309,17 @@ model Post {
 }
 ```
 
-Emission validates extension types against the composed packs: a type from a pack that is not listed in the config fails the emit with a diagnostic. Re-run `contract emit` after changing the extension list.
+`contract emit` validates extension types against the packs composed in the config: a type from a pack that is not listed fails the emit with a diagnostic. Re-run `contract emit` after changing the extension list.
 
 ## Starting from an existing database
 
 If the database already exists, don't write the schema by hand. [`contract infer`](/cli/v8/contract-infer) reads the live schema and writes a starter `contract.prisma` for you to review and edit.
 
-The syntax above declares relations; for which shape to choose and which side owns the foreign key, see [relational data modeling](/orm/v8/data-modeling/relational-databases) and [MongoDB data modeling](/orm/v8/data-modeling/mongodb).
+The syntax above declares relations. For which shape to choose and which side owns the foreign key, see [relational data modeling](/orm/v8/data-modeling/relational-databases) and [MongoDB data modeling](/orm/v8/data-modeling/mongodb).
 
 ## Prompt your coding agent
 
-Projects scaffolded with `create-prisma@next` install [Prisma 8 skills](/ai/tools/skills#available-skills-for-prisma-8) for your coding agent; the `prisma-8` skill covers this page. Ask your agent to:
+Projects scaffolded with `create-prisma@next` install [Prisma 8 skills](/ai/tools/skills#available-skills-for-prisma-8) for your coding agent. The `prisma-8` skill covers this page. Ask your agent to:
 
 - "Using the prisma-8 skill, add a Status enum stored as text and use it on the Order model."
 - "Add a one-to-many between User and Post with the foreign key on Post."
diff --git a/apps/docs/content/docs/orm/v8/contract-authoring/the-data-contract.mdx b/apps/docs/content/docs/orm/v8/contract-authoring/the-data-contract.mdx
index d13c4bc762..3639e8b3ec 100644
--- a/apps/docs/content/docs/orm/v8/contract-authoring/the-data-contract.mdx
+++ b/apps/docs/content/docs/orm/v8/contract-authoring/the-data-contract.mdx
@@ -27,7 +27,7 @@ model Post {
 }
 ```
 
-Prisma 8 compiles this into a machine-readable artifact, and everything else checks itself against it: queries are type-checked against the contract, migrations are planned as changes to it, and the database is verified against it before your code runs.
+Prisma 8 compiles this into a machine-readable artifact, and the rest of the toolchain works against it: queries are type-checked against the contract, migrations are planned as changes to it, and the database is verified against it before your code runs.
 
 Think of it as a `package-lock.json` for your data: an exact, versioned record of what your application expects from its database.
 
@@ -43,17 +43,20 @@ Prisma ORM's current architecture compiles your schema into generated client cod
 
 Prisma 8 keeps the schema knowledge in the open. Your contract source compiles to two plain files: `contract.json`, a canonical JSON description of models, storage, and capabilities, and `contract.d.ts`, the TypeScript types derived from it. Both are deterministic: the same source always produces byte-identical output, so the artifacts can be diffed in code review, hashed for verification, and read directly by tools and AI agents.
 
-The contract also carries identity. Emission computes hashes over the contract's content, and [`db sign`](/cli/v8/db-sign) records them in a small marker inside the database. Before executing queries, Prisma 8 compares the contract it was built against with the marker in the database it is talking to. A mismatch, such as a deploy against an unmigrated database, fails verification instead of failing at query time.
+The contract also identifies the exact schema version it describes. When you emit the contract, Prisma 8 computes hashes over its content, and [`db sign`](/cli/v8/db-sign) records them in a small marker inside the database. Before executing queries, Prisma 8 compares the contract it was built against with the marker in the database it is talking to. If they do not match, for example after a deploy against an unmigrated database, verification fails before any query runs.
 
 ## How it works
 
-A Prisma 8 project declares one contract source in `prisma-next.config.ts`:
+A Prisma 8 project declares one contract source in `prisma.config.ts`:
 
-```typescript title="prisma-next.config.ts"
-import { defineConfig } from "@prisma/orm-postgres/config";
+```typescript title="prisma.config.ts"
+import { defineConfig } from "@prisma/cli-engine";
+import { defineConfig as ormConfig } from "@prisma/orm-postgres/config";
 
 export default defineConfig({
-  contract: "./prisma/contract.prisma",
+  orm: ormConfig({
+    contract: "./prisma/contract.prisma",
+  }),
 });
 ```
 
@@ -61,8 +64,8 @@ The source is either a Prisma schema file (`contract.prisma`) or a TypeScript fi
 
 Emitting turns the source into the artifacts:
 
-```bash
-npx @prisma/cli@next contract emit
+```npm
+npx prisma@next contract emit
 ```
 
 This writes `contract.json` and `contract.d.ts` next to the source. From there, the rest of the toolchain takes over:
@@ -73,11 +76,11 @@ This writes `contract.json` and `contract.d.ts` next to the source. From there,
 
 ## Two authoring modes, one artifact
 
-**[PSL](/orm/v8/contract-authoring/psl-syntax)** is the preferred authoring surface: a compact language purpose-built for describing data. It is what `create-prisma` scaffolds, what [`contract infer`](/cli/v8/contract-infer) writes when you start from an existing database, and what the examples throughout these docs use.
+**[PSL](/orm/v8/contract-authoring/psl-syntax)** is the preferred way to author the contract: a compact language purpose-built for describing data. It is what `create-prisma` scaffolds, what [`contract infer`](/cli/v8/contract-infer) writes when you start from an existing database, and what the examples throughout these docs use.
 
-For the cases PSL does not cover, defining models with a **[TypeScript builder](/orm/v8/contract-authoring/typescript-schema-builder)** exists as an escape hatch: reach for it when model definitions must be composed, generated, or shared as ordinary TypeScript modules.
+For the cases PSL does not cover, define models with the **[TypeScript builder](/orm/v8/contract-authoring/typescript-schema-builder)** instead. Reach for it when model definitions must be composed, generated, or shared as ordinary TypeScript modules.
 
-Both modes are front ends to the same contract. For an equivalent schema they emit the same `contract.json`, so nothing downstream, including migrations, verification, and the query APIs, cares which one you write, and you give up nothing by staying with PSL. A project declares exactly one source of truth: the file named by `contract` in the config. Keep the other form out of the project, or treat it as a generated reference, so the two can never disagree.
+Both modes produce the same contract. For an equivalent schema they emit the same `contract.json`, so migrations, verification, and the query APIs behave the same no matter which mode you write. You give up nothing by staying with PSL. A project declares exactly one source of truth: the file named by `contract` in the config. Keep the other form out of the project, or treat it as a generated reference, so the two can never disagree.
 
 ## What the contract contains
 
@@ -93,7 +96,7 @@ It contains no rows, no credentials, and no connection details, so committing th
 
 ## Prompt your coding agent
 
-Projects scaffolded with `create-prisma@next` install [Prisma 8 skills](/ai/tools/skills#available-skills-for-prisma-8) for your coding agent; the `prisma-8` skill covers this page. Ask your agent to:
+Projects scaffolded with `create-prisma@next` install [Prisma 8 skills](/ai/tools/skills#available-skills-for-prisma-8) for your coding agent. The `prisma-8` skill covers this page. Ask your agent to:
 
 - "Using the prisma-8 skill, explain what our contract.json currently declares."
 - "Add an Invoice model to the contract and emit it."
diff --git a/apps/docs/content/docs/orm/v8/contract-authoring/typescript-schema-builder.mdx b/apps/docs/content/docs/orm/v8/contract-authoring/typescript-schema-builder.mdx
index ed73225acb..655b1ec8cd 100644
--- a/apps/docs/content/docs/orm/v8/contract-authoring/typescript-schema-builder.mdx
+++ b/apps/docs/content/docs/orm/v8/contract-authoring/typescript-schema-builder.mdx
@@ -7,11 +7,11 @@ metaDescription: Learn how to define a Prisma 8 contract in TypeScript with defi
 badge: release-candidate
 ---
 
-TypeScript authoring defines the Prisma 8 [data contract](/orm/v8/contract-authoring/the-data-contract) in code. Instead of a `.prisma` file, you write `prisma/contract.ts` with the `defineContract` builder, and [`contract emit`](/cli/v8/contract-emit) produces exactly the same `contract.json` and `contract.d.ts` a PSL schema would.
+With TypeScript authoring, you define the Prisma 8 [data contract](/orm/v8/contract-authoring/the-data-contract) in code. Instead of a `.prisma` file, you write `prisma/contract.ts` with the `defineContract` builder, and [`contract emit`](/cli/v8/contract-emit) produces exactly the same `contract.json` and `contract.d.ts` a PSL schema would.
 
 ## When to choose TypeScript over PSL
 
-[PSL](/orm/v8/contract-authoring/psl-syntax) is the preferred authoring surface, and since both modes emit identical artifacts, you give up nothing by staying with it. The TypeScript builder is an escape hatch for the cases PSL does not cover. Reach for it when:
+[PSL](/orm/v8/contract-authoring/psl-syntax) is the preferred way to author the contract. Both modes emit identical artifacts, so you give up nothing by staying with PSL. The TypeScript builder is an escape hatch for the cases PSL does not cover. Reach for it when:
 
 - model definitions must be split, composed, or reused across ordinary TypeScript modules or packages
 - parts of the schema are assembled programmatically from other static definitions (the [purity rules](#keep-the-contract-file-pure) still apply)
@@ -22,19 +22,25 @@ If neither applies, write PSL: it is more compact, and it is what `create-prisma
 
 The config's `contract` path names the source of truth. A `.ts` extension selects TypeScript authoring:
 
-```typescript title="prisma-next.config.ts" tab="PostgreSQL"
-import { defineConfig } from "@prisma/orm-postgres/config";
+```typescript title="prisma.config.ts" tab="PostgreSQL"
+import { defineConfig } from "@prisma/cli-engine";
+import { defineConfig as ormConfig } from "@prisma/orm-postgres/config";
 
 export default defineConfig({
-  contract: "./prisma/contract.ts",
+  orm: ormConfig({
+    contract: "./prisma/contract.ts",
+  }),
 });
 ```
 
-```typescript title="prisma-next.config.ts" tab="MongoDB"
-import { defineConfig } from "@prisma/orm-mongo/config";
+```typescript title="prisma.config.ts" tab="MongoDB"
+import { defineConfig } from "@prisma/cli-engine";
+import { defineConfig as ormConfig } from "@prisma/orm-mongo/config";
 
 export default defineConfig({
-  contract: "./prisma/contract.ts",
+  orm: ormConfig({
+    contract: "./prisma/contract.ts",
+  }),
 });
 ```
 
@@ -149,9 +155,9 @@ export const contract = defineContract({
 });
 ```
 
-Run `npx @prisma/cli@next contract emit` after any change to refresh the artifacts.
+Run `npx prisma@next contract emit` after any change to refresh the artifacts.
 
-The two builders share the same shape but differ where the databases do. On PostgreSQL, fields pick column types and models chain `.sql({ table })` to map storage; on MongoDB, the ID is a `field.objectId()` named `_id`, scalar helpers are `field.string()`, `field.int32()`, `field.double()`, `field.bool()`, and `field.date()`, and the collection is an inline `collection` option on the model rather than a chained call.
+The two builders share the same shape but differ where the databases do. On PostgreSQL, fields pick column types and models chain `.sql({ table })` to map storage. On MongoDB, the ID is a `field.objectId()` named `_id`, and the scalar helpers are `field.string()`, `field.int32()`, `field.double()`, `field.bool()`, and `field.date()`. The collection is an inline `collection` option on the model rather than a chained call.
 
 ## How `defineContract` works
 
@@ -159,7 +165,7 @@ The two builders share the same shape but differ where the databases do. On Post
 
 The options object declares what the contract is built from, most importantly `extensionPacks`. The target and database family are already bound by the import: `@prisma/orm-postgres/contract-builder` produces PostgreSQL contracts, so you never name them yourself.
 
-The factory receives authoring helpers composed from the target and every extension pack you declared: `field` for field definitions, `model` for models, and `type` for pack-provided types (which is why `type.pgvector` exists in the example, and only when `pgvector` is in `extensionPacks`). The factory returns the contract's content: `models`, plus optional `enums` and `types`.
+The factory receives authoring helpers composed from the target and every extension pack you declared: `field` for field definitions, `model` for models, and `type` for pack-provided types. `type.pgvector` in the example exists only because `pgvector` is listed in `extensionPacks`. The factory returns the contract's content: `models`, plus optional `enums` and `types`.
 
 The MongoDB builder is simpler: it exports `field`, `model`, and `rel` directly, and its `defineContract` takes a single definition object with the `models`, as in the MongoDB tab above. The sections below use the PostgreSQL builder.
 
@@ -208,7 +214,7 @@ Post.relations({
 });
 ```
 
-`rel.hasMany(Model, { by })` names the foreign key field on the other model; `rel.belongsTo(Model, { from, to })` maps the local foreign key field to the referenced field. `rel.hasOne` and `rel.manyToMany` cover the remaining shapes. A typo in a relation target is a compile error either way: the PostgreSQL builder takes model objects, and the MongoDB builder takes model names that are type-checked against the declared models.
+`rel.hasMany(Model, { by })` names the foreign key field on the other model. `rel.belongsTo(Model, { from, to })` maps the local foreign key field to the referenced field. `rel.hasOne` and `rel.manyToMany` cover the remaining shapes. A typo in a relation target is a compile error either way: the PostgreSQL builder takes model objects, and the MongoDB builder takes model names that are type-checked against the declared models.
 
 ## Storage mapping
 
@@ -248,25 +254,25 @@ export const contract = defineContract(
 );
 ```
 
-The same pack must also be composed in `prisma-next.config.ts` (as `extensions: [pgvector]`, using the pack's `/control` export) so the CLI and runtime agree with the contract.
+The same pack must also be composed in `prisma.config.ts` (as `extensions: [pgvector]`, using the pack's `/control` export) so the CLI and runtime agree with the contract.
 
 ## Keep the contract file pure
 
-The contract file describes structure; emission canonicalizes it to JSON and hashes it, and the same source must always produce the same bytes. That works only if the file is pure data:
+The contract file describes structure. When you emit it, Prisma 8 canonicalizes it to JSON and hashes it, and the same source must always produce the same bytes. That works only if the file is pure data:
 
 - Do not read `process.env`, the current time, or random values into the contract. A contract that changes per machine or per run breaks hashing and verification.
 - Keep field values plain: strings, numbers, booleans, and the builder's own objects. Functions, class instances, and `Date` objects do not serialize.
 - Keep the file free of side effects. Emission evaluates it to obtain the contract object and nothing else.
 
-Configuration that legitimately varies per environment, such as the database URL, belongs in `prisma-next.config.ts`, not in the contract.
+Configuration that legitimately varies per environment, such as the database URL, belongs in `prisma.config.ts`, not in the contract.
 
 ## Parity with PSL
 
-TypeScript and [PSL](/orm/v8/contract-authoring/psl-syntax) authoring emit the same canonical artifact for an equivalent schema. You can move between the modes without any downstream change, but a project declares exactly one source of truth: the file named in the config. Keep the other form out of the project so the two can never disagree.
+TypeScript and [PSL](/orm/v8/contract-authoring/psl-syntax) authoring emit the same canonical artifact for an equivalent schema. You can move between the modes without any downstream change. A project still declares exactly one source of truth: the file named in the config. Keep the other form out of the project so the two can never disagree.
 
 ## Prompt your coding agent
 
-Projects scaffolded with `create-prisma@next` install [Prisma 8 skills](/ai/tools/skills#available-skills-for-prisma-8) for your coding agent; the `prisma-8` skill covers this page. Ask your agent to:
+Projects scaffolded with `create-prisma@next` install [Prisma 8 skills](/ai/tools/skills#available-skills-for-prisma-8) for your coding agent. The `prisma-8` skill covers this page. Ask your agent to:
 
 - "Convert this contract.prisma to the TypeScript schema builder."
 - "Using the prisma-8 skill, add a unique index to the email field in our TypeScript schema."
diff --git a/apps/docs/content/docs/orm/v8/extensions/using-extensions.mdx b/apps/docs/content/docs/orm/v8/extensions/using-extensions.mdx
index 8038c06ac9..3c1549d3b0 100644
--- a/apps/docs/content/docs/orm/v8/extensions/using-extensions.mdx
+++ b/apps/docs/content/docs/orm/v8/extensions/using-extensions.mdx
@@ -7,11 +7,11 @@ metaDescription: Add an extension to a Prisma 8 project, from install to first q
 badge: release-candidate
 ---
 
-An extension is a package that teaches Prisma 8 a database capability it does not have out of the box: new column types, query operations, and index types, along with the migrations that install the underlying database feature. Vector search, geospatial data, full-text search, typed JSON, and provider-specific integrations all arrive this way.
+An extension is a package that adds a database capability Prisma 8 does not have out of the box: new column types, query operations, and index types, along with the migrations that install the underlying database feature. Vector search, geospatial data, full-text search, typed JSON, and provider-specific integrations are all added through extensions.
 
 Use an extension when you want the database to do something powerful and still keep the Prisma 8 experience: typed schema declarations, generated TypeScript, migration support, and query helpers that feel native to your app.
 
-Adding an extension takes one install and two registrations. The steps below use pgvector, the vector search extension, as the example.
+To add an extension, install its package and register it in two places: the config and the client. The steps below use pgvector, the vector search extension, as the example.
 
 ## 1. Install the package
 
@@ -21,24 +21,27 @@ npm install @prisma/orm-extension-pgvector
 
 ## 2. Register it in the config
 
-This side is used when Prisma 8 emits your contract and plans migrations:
+Prisma 8 uses this registration when it emits your contract and plans migrations:
 
-```ts title="prisma-next.config.ts"
+```ts title="prisma.config.ts"
+import { defineConfig } from '@prisma/cli-engine';
 import pgvector from '@prisma/orm-extension-pgvector/control';
-import { defineConfig } from '@prisma/orm-postgres/config';
+import { defineConfig as ormConfig } from '@prisma/orm-postgres/config';
 
 export default defineConfig({
-  contract: './src/prisma/contract.prisma',
-  extensions: [pgvector],
-  db: {
-    connection: process.env['DATABASE_URL']!,
-  },
+  orm: ormConfig({
+    contract: './src/prisma/contract.prisma',
+    extensions: [pgvector],
+    db: {
+      connection: process.env['DATABASE_URL']!,
+    },
+  }),
 });
 ```
 
 ## 3. Register it on the client
 
-This side is used when your app runs queries: it adds the extension's query operations and value types:
+Prisma 8 uses this registration when your app runs queries: it adds the extension's query operations and value types:
 
 ```ts title="src/prisma/db.ts"
 import pgvector from '@prisma/orm-extension-pgvector/runtime';
@@ -71,7 +74,7 @@ model Post {
 
 ## 5. Apply and query
 
-Run `npx @prisma/cli@next db init` (or `db update` on an existing database). The extension ships its own migration, so this step runs `CREATE EXTENSION IF NOT EXISTS vector` for you. If `db init` reports a contract-space layout violation instead, run `npx @prisma/cli@next migration plan` once: it materializes the extension's baseline migration under `migrations/<extension>/`, and `db init` then proceeds. Then query with the operations the extension adds:
+Run `npx prisma@next db init` (or `db update` on an existing database). The extension ships its own migration, so this step runs `CREATE EXTENSION IF NOT EXISTS vector` for you. If `db init` reports a contract-space layout violation instead, run `npx prisma@next migration plan` once: it writes the extension's baseline migration under `migrations/<extension>/`, and `db init` then proceeds. Then query with the operations the extension adds:
 
 ```ts title="src/prisma/similarity-search.ts"
 const plan = db.sql.public.post
@@ -92,16 +95,16 @@ One package, two registrations, one database:
 
 ## Capabilities
 
-Each extension names what it adds under a key like `pgvector.cosine`. You never write these keys by hand. Registering the extension in the config records them in your contract; registering it in `db.ts` provides them at runtime.
+Each extension names what it adds under a key like `pgvector.cosine`. You never write these keys by hand. Registering the extension in the config records them in your contract. Registering it in `db.ts` provides them at runtime.
 
-The point of this bookkeeping is failing early:
+The point of this bookkeeping is to fail early:
 
-- If your contract needs an extension that `db.ts` does not register, creating the client fails immediately. A query never runs against half an extension.
+- If your contract needs an extension that `db.ts` does not register, creating the client fails immediately. A query never runs with the extension only partially registered.
 - If the database itself cannot install the extension, `db init` or `db update` reports it before your app takes traffic.
 
 ## Available extensions
 
-You can build an extension that does not exist yet. The catalog is first-party today and built for community authors, extension packs are versioned npm packages with a documented layout, and the [call for extension authors](https://www.prisma.io/blog/prisma-next-call-for-extension-authors) explains how to write and publish one.
+You can build an extension that does not exist yet. The catalog is first-party today, but it is built for community authors: extension packs are versioned npm packages with a documented layout. The [call for extension authors](https://www.prisma.io/blog/prisma-next-call-for-extension-authors) explains how to write and publish one.
 
 | Extension | Adds | Package |
 | --- | --- | --- |
@@ -111,7 +114,7 @@ You can build an extension that does not exist yet. The catalog is first-party t
 | [Supabase](https://github.com/prisma/prisma/tree/main/packages/3-extensions/supabase#readme) | Supabase auth and storage tables, role-bound clients | `@prisma/orm-extension-supabase` |
 | [arktype-json](https://github.com/prisma/prisma/tree/main/packages/3-extensions/arktype-json#readme) | JSON columns validated by an arktype schema | `@prisma/orm-extension-arktype-json` |
 
-All target PostgreSQL. ParadeDB and Supabase are experimental (ParadeDB covers the `key_field` index option only so far); the rest are part of the Release Candidate. Extension names link to each package's README on GitHub.
+All target PostgreSQL. ParadeDB and Supabase are experimental (ParadeDB supports the `key_field` index option only so far). The rest are part of the Release Candidate. Extension names link to each package's README on GitHub.
 
 For a working project per extension, see the runnable examples: [pgvector](https://github.com/prisma/prisma-next/tree/main/examples/prisma-next-demo), [PostGIS](https://github.com/prisma/prisma-next/tree/main/examples/prisma-next-postgis-demo), [ParadeDB](https://github.com/prisma/prisma-next/tree/main/examples/paradedb-demo), and [Supabase](https://github.com/prisma/prisma-next/tree/main/examples/supabase).
 
diff --git a/apps/docs/content/docs/orm/v8/index.mdx b/apps/docs/content/docs/orm/v8/index.mdx
index 438f9358f8..97b991a53c 100644
--- a/apps/docs/content/docs/orm/v8/index.mdx
+++ b/apps/docs/content/docs/orm/v8/index.mdx
@@ -1,40 +1,42 @@
 ---
 title: Prisma 8
-description: A look at Prisma 8, a ground-up rethink of Prisma that improves queries, extensibility, migrations, and AI-friendly workflows while keeping Prisma’s schema-first approach.
+description: Prisma 8 is the next major version of Prisma ORM, with a TypeScript runtime, contract-based data models, a new query API, and a revised migration workflow.
 url: /orm/v8
 metaTitle: What is Prisma 8?
-metaDescription: Prisma 8 is a ground-up rethink of Prisma ORM with better queries, extensibility, migrations, and AI-friendly workflows, keeping the schema-first approach.
+metaDescription: Prisma 8 is the next major version of Prisma ORM. It introduces a TypeScript runtime, contract-based data models, a new query API, and a revised migration workflow.
 badge: release-candidate
 ---
 
-Prisma 8 is a full TypeScript rewrite of Prisma ORM. It keeps the schema-first workflow and model-first queries you already know, and rebuilds everything underneath to be **extensible**, **composable**, and **AI-agent friendly** by default.
-
-Instead of compiling your schema into a heavy generated client, Prisma 8 treats your schema as a versioned **contract**: open, inspectable artifacts that your code, your tools, and AI agents can all rely on.
+Prisma 8 rewrites Prisma ORM in TypeScript. The schema-first workflow and model-first queries from earlier versions stay. What changes is what your schema produces and how queries run. This page gives you the mental model, and the [quickstart](/v8/quickstart/postgresql) gets you to a running query.
 
 :::note[The Prisma 8 Release Candidate is available]
 
-Prisma 8 is the next major version of Prisma ORM, now available as a Release Candidate. It’s the cutting-edge version of Prisma ORM and will become the future of Prisma, so we’d love for you to try it, explore what’s new, and [share your feedback in Discord](https://pris.ly/discord).
-
-If you want to stay on the current generally available version of Prisma ORM, you can continue with [Prisma 7](/getting-started).
+Prisma 8 is available as a Release Candidate through `prisma@next`. Try it, explore what's new, and [share your feedback in Discord](https://pris.ly/discord). To stay on the current generally available version, continue with [Prisma 7](/getting-started).
 
 :::
 
-## Why Prisma 8
+## The central change: your schema becomes a contract
+
+You still author models in a Prisma schema file (or in TypeScript), but instead of generating a client package, Prisma 8 emits the schema as a **contract**: a JSON document plus TypeScript types that your application, the migration tools, and coding agents all read. The contract is a plain artifact you can inspect and diff.
+
+The workflow has three steps:
+
+1. **Author your schema**: define your models in a Prisma schema (`.prisma`) or directly in TypeScript.
+2. **Emit the contract**: a lightweight build step turns the schema into a deterministic JSON contract plus TypeScript types.
+3. **Query with a composable DSL**: write queries inline against the typed contract. Each query compiles to a verifiable plan at runtime, with no hidden client methods.
 
-Prisma's current architecture tightly couples three layers: the schema language, the generated client, and runtime execution. That coupling makes Prisma harder to extend, slower to rebuild, and opaque to the tools that read your code. Prisma 8 rebuilds the data layer around a contract-first model with a small, extensible core:
+## What changed for developers
 
-- **Better queries**: a cleaner API with simpler nested queries, custom collection methods on your models, and streaming results, plus a low-level, type-safe SQL query builder for the cases that need raw control.
+- **Better queries**: simpler nested queries, custom collection methods on your models, streaming results, and a low-level type-safe SQL builder when you need raw control.
 - **Extensible by design**: a minimal core exposed through a public SPI. Everything around it, including Postgres support itself, is an extension, so you can add databases, query builders, data types, and middleware.
 - **Rethought migrations**: [graph-based migrations](/orm/v8/migrations/the-migration-graph) that resolve branch conflicts automatically and make partial failures safe to retry, with both schema and data migrations written in TypeScript and validated against your contract.
-- **AI-agent friendly**: your schema compiles to a machine-readable contract, every query produces a structured, inspectable plan, and middleware adds compile-time guardrails. The installers also register agent skills so your editor's AI assistant can drive Prisma 8 changes safely.
+- **AI-agent friendly**: the contract is machine-readable and each query produces an inspectable plan, which gives coding agents something concrete to check their work against. The installers also register agent skills for your editor's AI assistant.
 
-## How it works
+### Supported databases
 
-Prisma 8 is contract-first:
+Prisma 8 ships first-class support for **PostgreSQL** (the primary target, on track for general availability) and **MongoDB**. **SQLite** support is planned next, then **MySQL**.
 
-1. **Author your schema**: define your models in a Prisma schema (`.prisma`) or directly in TypeScript.
-2. **Emit the contract**: a lightweight build step turns the schema into a deterministic JSON contract plus TypeScript types, artifacts you can read and diff.
-3. **Query with a composable DSL**: write queries inline against the typed contract, and each one compiles to a verifiable plan at runtime with no hidden client methods.
+## Get started
 
 Scaffold a new project in one command:
 
@@ -42,10 +44,8 @@ Scaffold a new project in one command:
 npx create-prisma@next
 ```
 
-## Get started
-
 <Cards>
-  <Card href="/v8/quickstart/postgresql" title="Quickstart" icon={<Rocket className="text-primary" />}>
+  <Card href="/v8/quickstart/postgresql" title="Quickstart with PostgreSQL" icon={<Rocket className="text-primary" />}>
     Scaffold a Prisma 8 app with PostgreSQL, seed it, and run your first query.
   </Card>
   <Card href="/v8/add-to-existing-project/postgresql" title="Add to an existing project" icon={<FolderPlus className="text-primary" />}>
@@ -56,40 +56,9 @@ npx create-prisma@next
   </Card>
 </Cards>
 
-### Supported databases
-
-Prisma 8 ships first-class support for **PostgreSQL** (the primary target, on track for general availability) and **MongoDB**. **SQLite** is the next SQL target on deck, with **MySQL** to follow.
-
-## The Prisma 8 blog series
-
-Prisma 8 is being built in the open. The full story spans this nine-part series:
-
-1. **[The Next Evolution of Prisma ORM](https://www.prisma.io/blog/the-next-evolution-of-prisma-orm)**. The announcement that explains why Prisma is being rebuilt and tours the new query API, extensibility model, migrations, and AI-friendly design.
-2. **[Prisma 8 Roadmap](https://www.prisma.io/blog/prisma-next-roadmap)**. What is already built and the phased plan that runs through early access to general availability.
-3. **[Rethinking Database Migrations](https://www.prisma.io/blog/rethinking-database-migrations)**. How graph-based migrations replace timestamp ordering with schema state hashes, keeping branches reconcilable and migrations explicit and verifiable.
-4. **[TypeScript Migrations in Prisma 8](https://www.prisma.io/blog/typescript-migrations-in-prisma-next)**. Writing schema migrations in TypeScript that are checked against your contract at compile time.
-5. **[Data Migrations in Prisma 8](https://www.prisma.io/blog/data-migrations-in-prisma-next)**. Running type-safe data transformations alongside schema changes with the same query builder you use in your app.
-6. **[Prisma 8: A Call for Extension Authors](https://www.prisma.io/blog/prisma-next-call-for-extension-authors)**. An invitation for the community to build databases, extensions, and integrations on the new extension API.
-7. **[Prisma 8: April Milestone Complete, the Extension API Is Open](https://www.prisma.io/blog/prisma-next-roadmap-april-milestone)**. The extension API opens with its first community extensions (pgvector, arktype-json, ParadeDB, and CipherStash), plus progress across migrations, transactions, and MongoDB.
-8. **[Prisma 8 Early Access: Write Your Contract, Prompt Your Agent, Ship Your App](https://www.prisma.io/blog/prisma-next-early-access-write-your-contract-prompt-your-agent-ship-your-app)**. The early access launch and the agent-driven workflow it enables.
-9. **[Prisma 8 Is ~90% As Fast as Raw PG](https://www.prisma.io/blog/prisma-next-performance-benchmark)**. Benchmarks showing Prisma 8 reaching roughly 90% of the raw PostgreSQL driver's throughput at a fraction of the bundle size.
-
-:::note[More Prisma 8 docs are coming soon]
-
-Prisma 8 is in active development, and full conceptual and reference documentation is on the way. Follow along on the [Prisma blog](https://www.prisma.io/blog) and explore the source on [GitHub](https://github.com/prisma/prisma-next).
-
-:::
-
-## Next steps
+## Go deeper
 
 <Cards>
-  <Card
-    href="/v8/getting-started"
-    title="Get started"
-    icon={<Rocket className="text-primary" />}
-  >
-    Scaffold a new Prisma 8 app or add it to an existing project.
-  </Card>
   <Card
     href="/orm/v8/fundamentals/reading-data"
     title="Learn the fundamentals"
@@ -98,14 +67,6 @@ Prisma 8 is in active development, and full conceptual and reference documentati
     Read, write, and relate data with the ORM, run transactions, and reach for
     advanced queries when you need them.
   </Card>
-  <Card
-    href="/v8/quickstart/postgresql"
-    title="Quickstart with PostgreSQL"
-    icon={<Database className="text-primary" />}
-  >
-    Create a Prisma 8 app, initialize the database, seed data, and run your
-    first query.
-  </Card>
   <Card
     href="/orm/v8/contract-authoring/the-data-contract"
     title="The data contract"
@@ -114,6 +75,13 @@ Prisma 8 is in active development, and full conceptual and reference documentati
     Learn how your schema becomes a verifiable contract, authored in PSL or
     TypeScript.
   </Card>
+  <Card
+    href="/cli/v8"
+    title="CLI reference"
+    icon={<Database className="text-primary" />}
+  >
+    The contract, database, and migration commands in the Prisma 8 CLI.
+  </Card>
   <Card
     href="/studio/prisma-next"
     title="See your migrations in Studio"
@@ -122,4 +90,22 @@ Prisma 8 is in active development, and full conceptual and reference documentati
     Read your applied migration history in Prisma Studio: a visual diff, the
     executed SQL, and a schema diff per migration.
   </Card>
+  <Card
+    href="/prisma-compute/deploy"
+    title="Deploy the application"
+    icon={<Cpu className="text-primary" />}
+  >
+    Ready to ship? Deploy your Prisma 8 app to Prisma Compute, next to your
+    Prisma Postgres database.
+  </Card>
 </Cards>
+
+## Learn more about the design of Prisma 8
+
+The thinking behind Prisma 8 is documented on the [Prisma blog](https://www.prisma.io/blog). Start with these:
+
+- **[The Next Evolution of Prisma ORM](https://www.prisma.io/blog/the-next-evolution-of-prisma-orm)**: why Prisma is being rebuilt, with a tour of the new query API, extensibility model, migrations, and AI-friendly design.
+- **[Rethinking Database Migrations](https://www.prisma.io/blog/rethinking-database-migrations)**: how graph-based migrations replace timestamp ordering with schema state hashes.
+- **[Prisma 8 Is ~90% As Fast as Raw PG](https://www.prisma.io/blog/prisma-next-performance-benchmark)**: benchmarks against the raw PostgreSQL driver.
+
+The full series also covers [TypeScript migrations](https://www.prisma.io/blog/typescript-migrations-in-prisma-next), [data migrations](https://www.prisma.io/blog/data-migrations-in-prisma-next), [the extension API](https://www.prisma.io/blog/prisma-next-call-for-extension-authors), the [roadmap](https://www.prisma.io/blog/prisma-next-roadmap), and the [early-access launch](https://www.prisma.io/blog/prisma-next-early-access-write-your-contract-prompt-your-agent-ship-your-app). The source lives on [GitHub](https://github.com/prisma/prisma).
diff --git a/apps/docs/content/docs/orm/v8/migrations/applying-a-migration.mdx b/apps/docs/content/docs/orm/v8/migrations/applying-a-migration.mdx
index d39ab111b3..ec3994dd0f 100644
--- a/apps/docs/content/docs/orm/v8/migrations/applying-a-migration.mdx
+++ b/apps/docs/content/docs/orm/v8/migrations/applying-a-migration.mdx
@@ -9,16 +9,16 @@ badge: release-candidate
 
 Applying is the one step that touches a database, and it has one command:
 
-```bash
-npx @prisma/cli@next migrate
+```npm
+npx prisma@next migrate
 ```
 
 Note the verb: it's `migrate`, not `migration apply`. The `migration ...` subcommands manage files on disk; `migrate` moves a database. It reads where the database currently is (its **marker**), finds a path through the [migration graph](/orm/v8/migrations/the-migration-graph) to the target, and applies each migration along the path, running every operation's precheck, execute, and postcheck as it goes.
 
-The connection comes from `db.connection` in `prisma-next.config.ts`, or `--db` to override:
+By default, the connection comes from `db.connection` in `prisma.config.ts`. Pass `--db` to override it:
 
-```bash
-npx @prisma/cli@next migrate --db $DATABASE_URL
+```npm
+npx prisma@next migrate --db $DATABASE_URL
 ```
 
 A successful run reports every operation it performed and the marker it left behind:
@@ -32,24 +32,26 @@ App space
   └─ Set NOT NULL on "user"."displayName" (destructive)
   marker: sha256:e6b5c2849eca8d24ff1e8e88ab2a4234db8e74c497c035cb7ce42e814f31cd63
 
-Next: prisma-next migration status
+Next: prisma-cli migration status
 ```
 
-`App space` is your application's migration lane, one of the run's *contract spaces*; projects that use database extensions gain additional spaces, covered in [Extension spaces](#extension-spaces) below.
+The `prisma-cli` in that hint is the binary's own name for itself. When you invoke it as `npx prisma@next`, run the suggested subcommand the same way (`npx prisma@next migration status`).
+
+`App space` is your application's migration lane, one of the run's *contract spaces*. Projects that use database extensions gain additional spaces, covered in [Extension spaces](#extension-spaces) below.
 
 ## Check before, preview, then apply
 
 The habit worth building, especially against shared databases, is a three-step rhythm:
 
-```bash
+```npm
 # 1. Where is the database, what's pending?
-npx @prisma/cli@next migration status --db $DATABASE_URL
+npx prisma@next migration status --db $DATABASE_URL
 
 # 2. What exactly would run?
-npx @prisma/cli@next migrate --show --db $DATABASE_URL
+npx prisma@next migrate --show --db $DATABASE_URL
 
 # 3. Run it.
-npx @prisma/cli@next migrate --db $DATABASE_URL
+npx prisma@next migrate --db $DATABASE_URL
 ```
 
 `migration status` draws the path between the database's marker and the target, flagging each migration as applied or pending:
@@ -61,7 +63,7 @@ npx @prisma/cli@next migrate --db $DATABASE_URL
 |^  20260707T1005_init                  - -> 705b1a6  2 ops  + applied
 *   -
 
-1 pending — run `prisma-next migrate --to 925198f3cc27`
+1 pending — run `prisma-cli migrate --to 925198f3cc27`
 ```
 
 Read the markers on the right: `@db` is where the database is, `@contract` is where your emitted contract is, and `(db)` is the [ref](/orm/v8/migrations/the-migration-graph#name-important-states-with-refs) of that name pointing at the same node.
@@ -92,18 +94,18 @@ After applying, `migration log` shows the database's own record of what ran: an
 
 With no `--to`, `migrate` advances toward your emitted contract. To aim somewhere specific, `--to` accepts the same reference grammar as everywhere else: a ref name, a contract hash or prefix, a migration directory name, or `<dir>^` for the state before a migration:
 
-```bash
-npx @prisma/cli@next migrate --to prod --db $DATABASE_URL          # a ref
-npx @prisma/cli@next migrate --to sha256:e6b5c28 --db $DATABASE_URL # a hash prefix
-npx @prisma/cli@next migrate --to 20260707T1005_init --db $DATABASE_URL
+```npm
+npx prisma@next migrate --to prod --db $DATABASE_URL          # a ref
+npx prisma@next migrate --to sha256:e6b5c28 --db $DATABASE_URL # a hash prefix
+npx prisma@next migrate --to 20260707T1005_init --db $DATABASE_URL
 ```
 
-If the graph has branched and more than one tip is reachable, `migrate` refuses to guess and asks for an explicit `--to`. That's the graph protecting you: two feature branches may both be valid futures, and picking one is a human decision.
+If the graph has branched and more than one tip is reachable, `migrate` stops and asks for an explicit `--to`. That's the graph protecting you: two feature branches may both be valid futures, and picking one is a human decision.
 
 `--advance-ref` moves a named ref to the post-apply state in the same step. Advancing one called `db` is what keeps [`migration plan`](/orm/v8/migrations/generating-a-migration#the-db-ref-skipping---from) incremental:
 
-```bash
-npx @prisma/cli@next migrate --advance-ref db
+```npm
+npx prisma@next migrate --advance-ref db
 ```
 
 ## When something goes wrong
@@ -113,42 +115,42 @@ The runner stops at the first failing operation and tells you which one, why, an
 ```text
 ✖ Operation pgvector.install-vector-extension failed during execution: create extension "vector" (PN-RUN-3000)
   Why: extension "vector" is not available
-  Fix: Fix the issue and re-run `prisma-next migrate --to <contract>` — previously applied migrations are preserved.
+  Fix: Fix the issue and re-run `prisma-cli migrate --to <contract>` — previously applied migrations are preserved.
 ```
 
 Three properties make failure boring instead of terrifying:
 
-- **On PostgreSQL, a failed run leaves nothing behind.** The entire `migrate` run executes inside one transaction, so when an operation fails, everything from that run rolls back and the database is exactly where it was before you started. Migrations applied in *earlier* runs are untouched; that's what "previously applied migrations are preserved" means.
+- **On PostgreSQL, a failed run leaves nothing behind.** The entire `migrate` run executes inside one transaction, so when an operation fails, everything from that run rolls back and the database is exactly where it was before you started. Migrations applied in *earlier* runs are untouched. That's what "previously applied migrations are preserved" means.
 - **The error is specific.** It names the operation, the phase (precheck, execute, or postcheck), and the check that failed, which is enough to fix the cause without spelunking.
-- **Re-running is safe.** Operations are idempotent: before running one, the runner evaluates its postcheck and skips it if the database already satisfies it. A change that snuck in out-of-band doesn't break the run; it becomes a skip. On MongoDB, where cross-collection transactions don't exist, this same mechanism is what makes a partially-applied run converge on retry. See [Rollbacks and recovery](/orm/v8/migrations/rollbacks-and-recovery) for the full failure playbook.
+- **Re-running is safe.** Operations are idempotent: before running one, the runner evaluates its postcheck and skips it if the database already satisfies it. A change made outside of migrations doesn't break the run. The runner skips the operation instead. On MongoDB, where cross-collection transactions don't exist, this same mechanism is what makes a partially-applied run converge on retry. See [Rollbacks and recovery](/orm/v8/migrations/rollbacks-and-recovery) for the full failure playbook.
 
 Before running any DDL, `migrate` also verifies the database's marker is a state the graph knows. A database that was changed outside of migrations fails fast with a marker mismatch instead of getting SQL applied on top of unknown drift.
 
 ## Development vs. production
 
-The commands are the same everywhere; what changes is where the files come from and who runs them.
+The commands are the same everywhere. What changes is where the files come from and who runs them.
 
 **In development**, you're the one planning and editing, and you apply immediately:
 
-```bash
-npx @prisma/cli@next migration plan --name my_change && npx @prisma/cli@next migrate --advance-ref db
+```npm
+npx prisma@next migration plan --name my_change && npx prisma@next migrate --advance-ref db
 ```
 
-**In CI and production**, migrations arrive via your repo, already planned, reviewed, and merged. That's why the [editing rule](/orm/v8/migrations/editing-a-migration) matters: commit `migration.ts` and `ops.json` together, and let `migration check` (exit codes `0`/`2`/`4`, see [Generating a migration](/orm/v8/migrations/generating-a-migration#reviewing-what-you-planned)) catch a stale recompile before deploy. The deploy step is:
+**In CI and production**, migrations arrive via your repo, already planned, reviewed, and merged. That's why the [editing rule](/orm/v8/migrations/editing-a-migration) matters: commit `migration.ts` and `ops.json` together, and run `migration check` to catch a stale recompile before deploy. See [Generating a migration](/orm/v8/migrations/generating-a-migration#reviewing-what-you-planned) for its exit codes. The deploy step is:
 
-```bash
-npx @prisma/cli@next migration check          # files intact, graph well-formed (offline)
-npx @prisma/cli@next migrate --show --db $DATABASE_URL   # log what's about to run
-npx @prisma/cli@next migrate --db $DATABASE_URL
+```npm
+npx prisma@next migration check          # files intact, graph well-formed (offline)
+npx prisma@next migrate --show --db $DATABASE_URL   # log what's about to run
+npx prisma@next migrate --db $DATABASE_URL
 ```
 
 A production nicety that falls out of the design: the runner executes only `ops.json`, plain data. Your `migration.ts` files, and any TypeScript they import, are never executed with production credentials.
 
-Concurrent deploys are safe: on PostgreSQL the whole apply runs inside a transaction guarded by an advisory lock, so two `migrate` runs serialize instead of interleaving. On MongoDB, where cross-collection DDL transactions don't exist, each migration advances the marker with compare-and-swap and the runner verifies the resulting schema before committing the marker, so a re-run converges rather than double-applying.
+Concurrent deploys are safe: on PostgreSQL the whole apply runs inside a transaction guarded by an advisory lock, so two `migrate` runs serialize instead of interleaving. On MongoDB, cross-collection DDL transactions don't exist. Instead, each migration advances the marker with compare-and-swap, and the runner verifies the resulting schema before committing the marker, so a re-run converges rather than double-applying.
 
 ## Extension spaces
 
-If your project uses [database extensions](/orm/v8/extensions/using-extensions) (say pgvector), you'll see more than one *contract space* in the output: extensions ship their own migrations (for example `CREATE EXTENSION vector`), tracked in `migrations/<extension>/` next to your app's. One `migrate` run walks them all (extensions first, then your app) and reports each space separately:
+If your project uses [database extensions](/orm/v8/extensions/using-extensions) (say pgvector), you'll see more than one *contract space* in the output. Extensions ship their own migrations (for example `CREATE EXTENSION vector`), tracked in `migrations/<extension>/` next to your app's. One `migrate` run walks them all (extensions first, then your app) and reports each space separately:
 
 ```text
 ✔ Applied 2 migration(s) (20 operation(s)) across 2 contract space(s)
@@ -163,7 +165,7 @@ App space
 
 :::note[What's early]
 
-Apply, targeting, preview, refs, the ledger, and multi-space runs all work today. Not built yet: a shadow-database rehearsal (`migrate` runs against the real target; use `--show` and a staging database), and an apply-time check that `ops.json` still matches `migration.ts` (today that's `migration check`'s job; run it in CI).
+Apply, targeting, preview, refs, the ledger, and multi-space runs all work today. Not built yet: a shadow-database rehearsal, and an apply-time check that `ops.json` still matches `migration.ts`. Until then, `migrate` runs against the real target, so rehearse with `--show` and a staging database, and run `migration check` in CI to catch a stale `ops.json`.
 
 :::
 
diff --git a/apps/docs/content/docs/orm/v8/migrations/editing-a-migration.mdx b/apps/docs/content/docs/orm/v8/migrations/editing-a-migration.mdx
index 2e99f5d54e..f2aadf4850 100644
--- a/apps/docs/content/docs/orm/v8/migrations/editing-a-migration.mdx
+++ b/apps/docs/content/docs/orm/v8/migrations/editing-a-migration.mdx
@@ -7,7 +7,7 @@ metaDescription: How to edit a Prisma 8 migration.ts by filling placeholder data
 badge: release-candidate
 ---
 
-The planner writes a good first draft, but plenty of real migrations need a human (or agent) decision: what to put in existing rows when a column becomes required, which order two steps must run in, one statement the planner has no factory for. In Prisma 8 you make those changes by editing `migration.ts`, ordinary TypeScript with autocomplete and type checking, and recompiling it. You never hand-edit SQL files, and you never hand-edit `ops.json`.
+The planner writes a good first draft, but plenty of real migrations need a human (or agent) decision: what to put in existing rows when a column becomes required, which order two steps must run in, one statement the planner has no factory for. In Prisma 8 you make those changes by editing `migration.ts`, ordinary TypeScript with autocomplete and type checking, and recompiling it. You never hand-edit SQL files or `ops.json`.
 
 The rule that makes this safe:
 
@@ -29,8 +29,8 @@ The recompile also **re-attests** the migration: `migration.json` gets a fresh `
 
 This is the classic case. `User` gets a required `displayName`, but the table already has rows, and those rows have no `displayName`. Plan it:
 
-```bash
-npx @prisma/cli@next migration plan --name add_display_name
+```npm
+npx prisma@next migration plan --name add_display_name
 ```
 
 ```text
@@ -58,7 +58,7 @@ override get operations() {
 }
 ```
 
-A `dataTransform` takes two closures. `check` asks "are there rows that still need this?" It must be a row-returning query where *any row* means work remains; the conventional shape is `select('id').where(<violation>).limit(1)`. `run` performs the change. Fill them with the typed SQL query builder, wired to the contract snapshot sitting next to the migration:
+A `dataTransform` takes two closures. `check` asks "are there rows that still need this?" It must be a row-returning query where *any row* means work remains. The conventional shape is `select('id').where(<violation>).limit(1)`. `run` performs the change. Fill them with the typed SQL query builder, wired to the contract snapshot sitting next to the migration:
 
 ```ts title="migration.ts (filled in)"
 import type { Contract as End } from './end-contract';
@@ -115,7 +115,7 @@ Two details worth pausing on:
 - **The types come from the migration's own contract snapshot** (`./end-contract`), not your live app contract. You're type-checking against the schema *as it will exist when this step runs*. That's why the builder happily references `displayName` even though the column doesn't exist yet, and why a migration written months ago keeps compiling after your contract moves on.
 - **The query is real application-grade TypeScript.** You can import shared constants, and typos in column names fail the type check instead of failing in production.
 
-The wiring block at the top (deserializing the contract, building the `db` handle) is the current Release Candidate shape; expect it to shrink to a one-liner. It's the price of a query builder that's typed against this migration's snapshot instead of your live app client.
+The wiring block at the top (deserializing the contract, building the `db` handle) is the current Release Candidate shape. Expect it to shrink to a one-liner. It's the price of a query builder that's typed against this migration's snapshot instead of your live app client.
 
 Recompile with `node migration.ts` and inspect what the backfill became:
 
@@ -148,7 +148,7 @@ Recompile with `node migration.ts` and inspect what the backfill became:
 }
 ```
 
-Your `check` closure became both the precheck (`EXISTS`: is there work?) and the postcheck (`NOT EXISTS`: is it done?). Your `run` became a parameterized `UPDATE`; note that `"Anonymous"` travels in `params`, through the driver's parameter binder, never spliced into SQL text. The reviewer reading your PR sees intent in `migration.ts` and the exact statements in `ops.json`, side by side.
+Your `check` closure became both the precheck (`EXISTS`: is there work?) and the postcheck (`NOT EXISTS`: is it done?). Your `run` became a parameterized `UPDATE`. Note that `"Anonymous"` travels in `params`, through the driver's parameter binder, and is never spliced into SQL text. The reviewer reading your PR sees intent in `migration.ts` and the exact statements in `ops.json`, side by side.
 
 ## Escape hatch: raw SQL
 
@@ -170,7 +170,7 @@ rawSql({
 }),
 ```
 
-The prechecks and postchecks are optional, but they're what makes a failed run resumable and a mistake diagnosable, so skipping them trades away most of what this system gives you. If you write the same `rawSql` twice, lift it into a function; the built-in factories are plain functions doing exactly this.
+The prechecks and postchecks are optional, but they're what makes a failed run resumable and a mistake diagnosable, so skipping them trades away most of what this system gives you. If you write the same `rawSql` twice, lift it into a function. The built-in factories are plain functions doing exactly this.
 
 ## The same pattern on MongoDB
 
@@ -201,8 +201,8 @@ The full working migration, including the two query-plan helpers, is in the Pris
 
 Sometimes there's no contract change at all: you want a data-only migration, or you'd rather write the whole thing by hand. `migration new` scaffolds an empty migration directory (already attested, like everything the CLI writes):
 
-```bash
-npx @prisma/cli@next migration new --name backfill_scores
+```npm
+npx prisma@next migration new --name backfill_scores
 ```
 
 Write your operations in the generated `migration.ts`, then compile it the same way: `node migration.ts`.
@@ -212,7 +212,7 @@ Write your operations in the generated `migration.ts`, then compile it the same
 1. Edit `migration.ts`, never `ops.json`.
 2. Recompile: `node <migration-dir>/migration.ts`.
 3. Review the diff of `ops.json`; that's what will run.
-4. Verify: `npx @prisma/cli@next migration check`.
+4. Verify: `npx prisma@next migration check`.
 5. Commit `migration.ts`, `ops.json`, and `migration.json` together.
 
 :::note[What's early]
diff --git a/apps/docs/content/docs/orm/v8/migrations/generating-a-migration.mdx b/apps/docs/content/docs/orm/v8/migrations/generating-a-migration.mdx
index 2417b47c37..3c040398f3 100644
--- a/apps/docs/content/docs/orm/v8/migrations/generating-a-migration.mdx
+++ b/apps/docs/content/docs/orm/v8/migrations/generating-a-migration.mdx
@@ -7,9 +7,9 @@ metaDescription: A step-by-step tutorial for the migration plan command, from co
 badge: release-candidate
 ---
 
-This tutorial takes a contract change from your editor to a planned migration on disk. Planning is **fully offline**: `migration plan` reads your emitted contract and your existing migrations; it never connects to a database, so you can plan on a plane, in CI, or in a sandbox with no credentials.
+This tutorial takes a contract change from your editor to a planned migration on disk. Planning is **fully offline**. `migration plan` reads your emitted contract and your existing migrations, and it never connects to a database. That means you can plan on a plane, in CI, or in a sandbox with no credentials.
 
-Start from a minimal project; `npx create-prisma@next` scaffolds one.
+Start from a minimal project. `npx create-prisma@next` scaffolds one.
 
 ## Your first migration
 
@@ -27,14 +27,14 @@ model User {
 
 First, emit the contract. This compiles the schema into the `contract.json` artifact that every other command reads:
 
-```bash
-npx @prisma/cli@next contract emit
+```npm
+npx prisma@next contract emit
 ```
 
-Now plan. `--name` sets the human-readable part of the directory name; without it the directory is called `migration`:
+Now plan. `--name` sets the human-readable part of the directory name. If you omit it, the directory is called `migration`:
 
-```bash
-npx @prisma/cli@next migration plan --name init
+```npm
+npx prisma@next migration plan --name init
 ```
 
 ```text
@@ -48,7 +48,7 @@ from:   null
 to:     sha256:705b1a62f26f0913caa4bfe3f8b7cb491a1b94bd47fc43471d8711bc480bcbb5
 App space → migrations/app/20260707T1005_init
 
-Next: review migrations/app/20260707T1005_init if needed, then run prisma-next migrate.
+Next: review migrations/app/20260707T1005_init if needed, then run prisma-cli migrate.
 
 DDL preview
 
@@ -61,12 +61,14 @@ CREATE TABLE "public"."user" (
 );
 ```
 
+(The `prisma-cli` in the hint is the binary's own name for itself. When invoking it as `npx prisma@next`, run the suggested subcommand the same way: `npx prisma@next migrate`.)
+
 Four things to notice:
 
 - **The DDL preview is right there.** You see the exact SQL before anything exists but files.
-- **`from: null`** means this migration starts from an empty database; it's the root of your [migration graph](/orm/v8/migrations/the-migration-graph).
+- **`from: null`** means this migration starts from an empty database. It's the root of your [migration graph](/orm/v8/migrations/the-migration-graph).
 - **`to:` is your contract's hash.** The migration promises to deliver a database matching exactly the contract you just emitted.
-- **`App space`** is your application's migration lane. Database extensions bring their own lanes; see [extension spaces](/orm/v8/migrations/applying-a-migration#extension-spaces).
+- **`App space`** is your application's migration lane. Database extensions bring their own lanes. See [extension spaces](/orm/v8/migrations/applying-a-migration#extension-spaces).
 
 The planned migration directory contains the TypeScript source, the compiled operations, and the contract snapshots:
 
@@ -108,9 +110,9 @@ export default class M extends Migration<never, End> {
 MigrationCLI.run(import.meta.url, M);
 ```
 
-Two notes on reading it: the `col(...)` calls mirror your contract fields, and you never write `codecRef` by hand. The planner fills it in to pin how values convert between TypeScript and Postgres; treat it as noise when reviewing.
+Two notes on reading it: the `col(...)` calls mirror your contract fields, and you never write `codecRef` by hand. The planner fills it in to pin how values convert between TypeScript and Postgres. Treat it as noise when reviewing.
 
-For a simple change you don't need to touch this file. When you do (to add a data backfill, reorder operations, or drop in raw SQL), that's [Editing a migration](/orm/v8/migrations/editing-a-migration).
+For a simple change you don't need to touch this file. When you do (to add a data backfill, reorder operations, or drop in raw SQL), see [Editing a migration](/orm/v8/migrations/editing-a-migration).
 
 ## The second migration: planning a delta
 
@@ -129,9 +131,9 @@ model User {
 
 Emit and plan again. This time, tell the planner where to start from, so it plans the *delta* rather than the whole schema:
 
-```bash
-npx @prisma/cli@next contract emit
-npx @prisma/cli@next migration plan --name add_user_phone --from 20260707T1005_init
+```npm
+npx prisma@next contract emit
+npx prisma@next migration plan --name add_user_phone --from 20260707T1005_init
 ```
 
 ```text
@@ -153,11 +155,11 @@ ALTER TABLE "public"."user" ADD COLUMN "phone" text;
 
 ### The db ref: skipping --from
 
-Passing `--from` every time gets old. The planner's default is smarter: if a [ref](/orm/v8/migrations/the-migration-graph#name-important-states-with-refs) named **`db`** exists, planning starts from whatever it points at. Keep it advanced as part of applying:
+You don't have to pass `--from` every time. If a [ref](/orm/v8/migrations/the-migration-graph#name-important-states-with-refs) named **`db`** exists, planning starts from whatever it points at by default. Move the ref forward each time you apply:
 
-```bash
-npx @prisma/cli@next migrate --advance-ref db
-npx @prisma/cli@next migration plan --name next_change   # starts from the db ref automatically
+```npm
+npx prisma@next migrate --advance-ref db
+npx prisma@next migration plan --name next_change   # starts from the db ref automatically
 ```
 
 :::warning[Without `--from` or a `db` ref, plans start from empty]
@@ -183,22 +185,22 @@ The generated migration sandwiches a `dataTransform` between the schema steps, w
 
 Three offline commands close the loop before anything runs:
 
-```bash
+```npm
 # One migration in detail: operations, metadata, DDL preview
-npx @prisma/cli@next migration show 20260707T1006_add_user_phone
+npx prisma@next migration show 20260707T1006_add_user_phone
 
 # The whole graph, with your new edge in place
-npx @prisma/cli@next migration graph
+npx prisma@next migration graph
 
 # Integrity check: hashes match, files complete, graph well-formed; exits non-zero on failure
-npx @prisma/cli@next migration check
+npx prisma@next migration check
 ```
 
 `migration check` is designed for CI: exit code `0` means clean, `2` means it couldn't resolve what you asked for, `4` means an integrity failure, for example someone hand-edited `ops.json` without re-running `migration.ts`.
 
 :::note[What's early]
 
-Planning covers tables, columns, indexes, constraints, and the backfill scaffold shown above. Rename inference is not built yet: renaming a field plans as **drop column + add column**, flagged destructive with a data-loss warning. For a true rename, edit the migration and replace the pair with a `rawSql` `ALTER TABLE ... RENAME COLUMN`. There is also no interactive mode; the planner writes its best answer and leaves refinement to you in `migration.ts`.
+Planning covers tables, columns, indexes, constraints, and the backfill scaffold shown above. Rename inference is not built yet: renaming a field plans as **drop column + add column**, flagged destructive with a data-loss warning. For a true rename, edit the migration and replace the pair with a `rawSql` `ALTER TABLE ... RENAME COLUMN`. There is also no interactive mode. The planner writes its best answer and leaves refinement to you in `migration.ts`.
 
 :::
 
diff --git a/apps/docs/content/docs/orm/v8/migrations/how-migrations-work.mdx b/apps/docs/content/docs/orm/v8/migrations/how-migrations-work.mdx
index 66f46bf6a0..d0c3a37200 100644
--- a/apps/docs/content/docs/orm/v8/migrations/how-migrations-work.mdx
+++ b/apps/docs/content/docs/orm/v8/migrations/how-migrations-work.mdx
@@ -7,7 +7,7 @@ metaDescription: What a Prisma 8 migration is, the plan-review-apply loop, the f
 badge: release-candidate
 ---
 
-A migration is how Prisma 8 changes your database when your contract changes. The **contract** is the schema description you author (a `.prisma` file or TypeScript) plus the `contract.json` artifact it compiles to; the **schema** is the database's actual structure, and migrations are what move it. You add a field to a model, and something has to run `ALTER TABLE` against every database that serves your app: your laptop, staging, production. Migrations are that something, recorded as files in your repo so the change is reviewable, repeatable, and versioned with your code.
+A migration is how Prisma 8 changes your database when your contract changes. The **contract** is the schema description you author (a `.prisma` file or TypeScript) plus the `contract.json` artifact it compiles to. The **schema** is the database's actual structure, and migrations are what move it. You add a field to a model, and something has to run `ALTER TABLE` against every database that serves your app: your laptop, staging, production. Migrations are that something, recorded as files in your repo so the change is reviewable, repeatable, and versioned with your code.
 
 The workflow is a loop you will run many times a day in development:
 
@@ -20,10 +20,10 @@ The workflow is a loop you will run many times a day in development:
 
 In a project with a database connection configured (the [quickstart](/v8/quickstart/postgresql) gives you one), the whole loop is three commands. Add an optional `phone String?` field to a model in your `.prisma` file, then:
 
-```bash
-npx @prisma/cli@next contract emit
-npx @prisma/cli@next migration plan --name add_user_phone
-npx @prisma/cli@next migrate
+```npm
+npx prisma@next contract emit
+npx prisma@next migration plan --name add_user_phone
+npx prisma@next migrate
 ```
 
 `migration plan` prepares the SQL for the migration, but doesn't run it:
@@ -45,7 +45,7 @@ and `migrate` applies the migration to your database and confirms what it applie
 ✔ Applied 1 migration(s) (1 operation(s)) across 1 contract space(s)
 ```
 
-The contract-space count only matters once you add database extensions; ignore it for now. If you see the `✔ Applied` line, you've already run the entire workflow. The rest of this page covers additional detail: what a migration is, and why it looks the way it does.
+The contract-space count only matters once you add database extensions. You can ignore it for now. If you see the `✔ Applied` line, you've already run the entire workflow. The rest of this page covers additional detail: what a migration is, and why it looks the way it does.
 
 ## What a migration contains
 
@@ -87,7 +87,7 @@ Use this file when you want to review or change what the migration does. See [Ed
 
 ### ops.json: the file Prisma runs
 
-`ops.json` is the compiled form of the migration. When `migration.ts` runs (the planner does this for you; after an edit, re-run it with `node migration.ts`), Prisma turns the TypeScript steps into JSON operations. The migration runner reads only this file.
+`ops.json` is the compiled form of the migration. When `migration.ts` runs, Prisma turns the TypeScript steps into JSON operations. The planner runs it for you. After an edit, re-run it yourself with `node migration.ts`. The migration runner reads only this file.
 
 That means production never executes your TypeScript. It reads the compiled operations, so no application code runs with production credentials.
 
@@ -181,13 +181,13 @@ Each operation also carries a class, which drives the `(destructive)` flags and
 
 This structure is what makes Prisma 8 migrations safe in the situations where classic SQL migrations hurt:
 
-- **A migration fails.** On PostgreSQL the whole run is one transaction, so a failure rolls everything back: the database returns to exactly where it was while you fix the cause and re-run. And because the runner skips any operation whose postcheck already holds, re-running never double-applies work that's already true in the database. No commenting out statements, no hand-editing the database.
+- **A migration fails.** On PostgreSQL the whole run is one transaction, so a failure rolls everything back and the database returns to exactly where it was. Fix the cause and re-run. Because the runner skips any operation whose postcheck already holds, re-running never double-applies work that's already true in the database. No commenting out statements, no hand-editing the database.
 - **The database isn't in the state you assumed.** The precheck catches it before the change runs, and the error names the exact operation and the exact check that failed, not a generic SQL error halfway through.
 - **Someone (or some agent) wrote the migration for you.** The intent (`migration.ts`), the exact SQL (`ops.json`), and the verification for every step are all in the diff, so review is straightforward.
 
 ## The commands
 
-Everything lives under the [Prisma 8 CLI](/cli/v8); run them with `npx @prisma/cli@next <command>`. Planning and inspection are offline; they read files, not your database:
+These commands live under the [Prisma 8 CLI](/cli/v8). Run them with `npx prisma@next <command>`. The planning and inspection commands work offline. They read files, not your database:
 
 | Command                   | What it does                                                            |
 | ------------------------- | ----------------------------------------------------------------------- |
diff --git a/apps/docs/content/docs/orm/v8/migrations/rollbacks-and-recovery.mdx b/apps/docs/content/docs/orm/v8/migrations/rollbacks-and-recovery.mdx
index ec36c607b8..fe9020a172 100644
--- a/apps/docs/content/docs/orm/v8/migrations/rollbacks-and-recovery.mdx
+++ b/apps/docs/content/docs/orm/v8/migrations/rollbacks-and-recovery.mdx
@@ -14,14 +14,14 @@ Two different situations get called "rollback", and Prisma 8 treats them differe
 
 ## Rollback: a migration like any other
 
-There is no `migrate down` command, and no separate "down migration" files. In the [graph model](/orm/v8/migrations/the-migration-graph), the state you want to return to is a node you've already visited, so rolling back means planning a new edge that points at it. If you know git, this is `git revert`, not `git reset`: history only ever grows, and the ledger (the applied-history record every database keeps) retains the full round trip.
+There is no `migrate down` command, and no separate "down migration" files. In the [graph model](/orm/v8/migrations/the-migration-graph), the state you want to return to is a node you've already visited, so rolling back means planning a new edge that points at it. If you know git, this is `git revert`, not `git reset`. History only ever grows, and the ledger (the applied-history record every database keeps) retains the full round trip.
 
 <ConceptAnimation name="migration-rollback" />
 
-Suppose `20260707T1008_add_display_name` shipped and needs to come back out. Plan the reverse edge; `<dir>^` means "the state before that migration":
+Suppose `20260707T1008_add_display_name` shipped and needs to come back out. Plan the reverse edge. `<dir>^` means "the state before that migration":
 
-```bash
-npx @prisma/cli@next migration plan \
+```npm
+npx prisma@next migration plan \
   --from 20260707T1008_add_display_name \
   --to 20260707T1008_add_display_name^ \
   --name rollback_display_name
@@ -45,11 +45,11 @@ ALTER TABLE "public"."user" DROP COLUMN "displayName";
 
 The planner diffs the two contract states and writes the operations that undo the change, flagged **destructive** because they are. This is a real migration: review it, edit it (for example, to archive the column's data into another table before the `DROP`), commit it. Then apply it like any other migration:
 
-```bash
-npx @prisma/cli@next migrate --to 20260707T1008_add_display_name^
+```npm
+npx prisma@next migrate --to 20260707T1008_add_display_name^
 ```
 
-A rollback also leaves a cycle in the graph, so the next `migration plan` cannot pick its starting point automatically. It fails with `MIGRATION.NO_TARGET` and lists the reachable states; plan with an explicit `--from <state>` until history moves forward again.
+A rollback also leaves a cycle in the graph, so the next `migration plan` cannot pick its starting point automatically. It fails with `MIGRATION.NO_TARGET` and lists the reachable states. Plan with an explicit `--from <state>` until history moves forward again.
 
 One loose end remains after the database moves back: your contract source still contains the change, so `db verify` reports a hash mismatch until you revert the schema and re-run `contract emit`. Roll back the contract in the same commit as the rollback migration and the two stay in step.
 
@@ -68,12 +68,12 @@ The database's marker (its record of which graph node it currently matches) is b
 
 Two things to be clear-eyed about:
 
-- **A rollback does not resurrect data.** Dropping the column discards whatever the forward migration and the app wrote into it. If that data matters, edit the rollback migration to save it somewhere first; that's exactly why the rollback is an editable migration and not an automatic mechanism.
+- **A rollback does not resurrect data.** Dropping the column discards whatever the forward migration and the app wrote into it. If that data matters, edit the rollback migration to save it somewhere first. That's exactly why the rollback is an editable migration rather than an automatic mechanism.
 - **You don't have to retrace every step.** An edge can jump from the current state directly to any earlier node, skipping intermediate states: one planned migration, one apply, even if you're rolling back three changes.
 
 ### One planning caveat after a rollback
 
-A rollback edge creates a cycle in the graph (`A → B → A`), and with a cycle the planner can no longer infer "the latest state" on its own. The next time you run `migration plan`, pass `--from` explicitly (a migration directory name or hash); the error you'd otherwise get, `MIGRATION.NO_TARGET`, says exactly this.
+A rollback edge creates a cycle in the graph (`A → B → A`), and with a cycle the planner can no longer infer "the latest state" on its own. The next time you run `migration plan`, pass `--from` explicitly (a migration directory name or hash). The error you'd otherwise get, `MIGRATION.NO_TARGET`, says exactly this.
 
 ## Recovery: when a migration fails partway
 
@@ -83,7 +83,7 @@ A failed `migrate` run stops at the failing operation and reports it precisely:
 ✖ Operation alterNullability.setNotNull.user.nickname failed during precheck:
   ensure no NULL values in "nickname" (PN-RUN-3000)
   Why: Migration runner failed
-  Fix: Fix the issue and re-run `prisma-next migrate --to <contract>` — previously applied migrations are preserved.
+  Fix: Fix the issue and re-run `prisma-cli migrate --to <contract>` — previously applied migrations are preserved.
 ```
 
 The playbook:
@@ -92,19 +92,19 @@ The playbook:
 2. **Nothing to clean up.** On PostgreSQL the whole run was one transaction, so the failure rolled it back completely: the database is exactly where it was before the run, and migrations applied in earlier runs are untouched. There is no "half-applied migration" to untangle by hand.
 3. **Fix the cause, then re-run `migrate`.** Sometimes the cause is the environment (extension missing, permissions). Sometimes it's the migration itself; here you'd [edit the migration](/orm/v8/migrations/editing-a-migration) to add a backfill before the `setNotNull`, recompile with `node migration.ts`, and apply again. Re-running is safe, for the reasons covered in [the failure model](/orm/v8/migrations/applying-a-migration#when-something-goes-wrong).
 
-The precheck is also what protects you against the works-in-dev-breaks-in-prod trap. Your dev database had no `NULL`s, production does; the precheck halts production *before* the destructive `ALTER` touches anything, with an error pointing at the exact rows-with-NULLs condition, not a generic constraint violation mid-statement.
+The precheck also protects you when a migration works in development but would fail in production. Your dev database had no `NULL`s, but production does. The precheck halts production *before* the destructive `ALTER` touches anything, with an error pointing at the exact rows-with-NULLs condition instead of a generic constraint violation mid-statement.
 
 ### Drift: when the database isn't where migrations left it
 
 If someone changed the database outside of migrations (a hand-run `ALTER`, a restore from an old backup), the marker or the live schema won't match any state the graph knows, and `migrate` refuses to run rather than pile changes onto drift. Your options, in order of preference:
 
 - **`db verify`** checks whether the database still matches your contract, and fails with a precise error when it doesn't.
-- **In development**, `db update` reconciles the database directly to your contract without walking the graph: quick, but off the record, so treat it as a dev-only reset.
+- **In development**, `db update` reconciles the database directly to your contract without walking the graph. It's quick, but it leaves no record in the migration history, so treat it as a dev-only reset.
 - **For a database with no history at all** (a fresh environment, or adopting Prisma 8 on an existing schema), `db init` bootstraps it to the current contract and signs the marker.
 
 :::note[What's early]
 
-Reverse planning (`--to <dir>^`), destructive-operation warnings, resumable re-runs, and the ledger all work today, as shown above. Honest gaps: there's no rehearsal mode that executes a migration against a shadow copy first, recovery from drift beyond the `db verify`/`db update`/`db init` trio is manual, and the planning caveat after cycles (explicit `--from`) is a real papercut we expect to smooth out. For deep or unusual situations, `#prisma-next` on [Discord](https://pris.ly/discord) is the fastest route.
+Reverse planning (`--to <dir>^`), destructive-operation warnings, resumable re-runs, and the ledger all work today, as shown above. Some gaps remain. There's no rehearsal mode that executes a migration against a shadow copy first. Recovery from drift beyond the `db verify`/`db update`/`db init` trio is manual. The planning caveat after cycles (explicit `--from`) is a real papercut we expect to smooth out. For deep or unusual situations, `#prisma-next` on [Discord](https://pris.ly/discord) is the fastest route.
 
 :::
 
diff --git a/apps/docs/content/docs/orm/v8/migrations/the-migration-graph.mdx b/apps/docs/content/docs/orm/v8/migrations/the-migration-graph.mdx
index a9836cb3c7..892a956f2a 100644
--- a/apps/docs/content/docs/orm/v8/migrations/the-migration-graph.mdx
+++ b/apps/docs/content/docs/orm/v8/migrations/the-migration-graph.mdx
@@ -58,8 +58,8 @@ A database always sits at exactly one node. Its **marker**, a record Prisma 8 ke
 
 Here is the Alice-and-Bob situation as an actual graph. Alice adds `phone`, Bob adds `avatarUrl`, and both branches merge:
 
-```bash
-npx @prisma/cli@next migration graph
+```npm
+npx prisma@next migration graph
 ```
 
 ```text
@@ -118,7 +118,7 @@ The Prisma 8 repo ships example graphs (a diamond, a wide fan-out, converging br
 git clone https://github.com/prisma/prisma-next
 cd prisma-next && pnpm install && pnpm -w build && pnpm install
 cd examples/prisma-next-demo
-npx @prisma/cli@next migration graph --config fixtures/showcase/prisma-next.config.ts --legend
+npx prisma@next migration graph --config fixtures/showcase/prisma.config.ts --legend
 ```
 
 Swap `showcase` for `diamond`, `wide-fan`, `converging-branches`, `multi-branch`, `long-spine`, or `skip-rollback` to explore each shape.
@@ -127,13 +127,13 @@ Swap `showcase` for `diamond`, `wide-fan`, `converging-branches`, `multi-branch`
 
 Raw hashes are awkward to type and impossible to remember, so name the states that matter. A **ref** is a human-readable pointer to a node, stored as a small file in `migrations/app/refs/` and committed to your repo:
 
-```bash
-npx @prisma/cli@next ref set prod sha256:f9a41d7...
-npx @prisma/cli@next ref list
-npx @prisma/cli@next migrate --to prod
+```npm
+npx prisma@next ref set prod sha256:f9a41d7...
+npx prisma@next ref list
+npx prisma@next migrate --to prod
 ```
 
-Because refs are committed, "where production should be" is a reviewable fact in a pull request, not tribal knowledge in someone's terminal history.
+Because refs are committed, "where production should be" is a reviewable fact in a pull request instead of tribal knowledge in someone's terminal history.
 
 One ref name is special. A ref called `db` is the default starting point `migration plan` uses when you do not pass `--from`. Keep it current with `migrate --advance-ref db` and planning stays incremental on its own.
 
@@ -150,7 +150,7 @@ Alice and Bob each planned a migration from `705b1a6` on their own branches. In
 
 ### History you can trust
 
-Because each edge declares its `from` state, a migration can never silently run against a database in the wrong shape. If the marker does not match, the run stops before any SQL executes, with an error naming the mismatch.
+Because each edge declares its `from` state, a migration will not run against a database in the wrong shape. If the marker does not match, the run stops before any SQL executes, with an error naming the mismatch.
 
 ### Rollback as a normal move
 
@@ -176,7 +176,7 @@ The graph, pathfinding, refs, and the marker/ledger model all work today. A few
 - **No split.** You cannot yet break one large migration into smaller ones after the fact.
 - **Ambiguous targets need a choice.** When two branch tips are both reachable, `migrate` asks you to pick one with `--to` rather than guessing.
 
-The graph was designed with these in mind; the commands simply have not shipped. Each migrations page calls out what is missing rather than papering over it.
+The graph was designed with these in mind; the commands have not shipped yet. Each migrations page calls out what is missing rather than papering over it.
 
 ## Common tasks
 
diff --git a/apps/docs/content/docs/postgres/index.mdx b/apps/docs/content/docs/postgres/index.mdx
index d1b7c80f12..cf562086b7 100644
--- a/apps/docs/content/docs/postgres/index.mdx
+++ b/apps/docs/content/docs/postgres/index.mdx
@@ -3,39 +3,62 @@ title: Prisma Postgres
 description: 'Connect to Prisma Postgres from Prisma ORM, serverless runtimes, and PostgreSQL clients.'
 url: /postgres
 metaTitle: Overview | Prisma Postgres
-metaDescription: Learn everything you need to know about Prisma Postgres.
+metaDescription: Prisma Postgres is a managed PostgreSQL database with connection pooling, query caching, and edge support. Connect from Prisma ORM, Kysely, Drizzle, or any PostgreSQL client.
 ---
 
 [Prisma Postgres](https://www.prisma.io/postgres?utm_source=docs) is a managed PostgreSQL database with built-in connection pooling, query caching, and edge runtime support.
-Use this page to choose a connection path and get started quickly.
 
-## What's included
+To your application it is a regular PostgreSQL database behind a connection string:
 
-Everything below is included with every Prisma Postgres database. No extra services to configure.
+```text no-copy
+Your application
+      ↓ DATABASE_URL
+Prisma Postgres
+```
 
-- **Connection pooling** — A dedicated PgBouncer instance runs alongside your database. You don't need to set one up or manage it. Works automatically for serverless and edge deployments. See [Connection pooling](/postgres/database/connection-pooling).
-- **Query caching** — Add a `cacheStrategy` to any Prisma ORM query to cache results at the edge, using TTL or stale-while-revalidate. See [Caching](/accelerate/caching).
-- **Edge and serverless support** — Connect from Cloudflare Workers, Vercel Edge Functions, and other edge runtimes via the [serverless driver](/postgres/database/serverless-driver), which uses HTTP instead of TCP.
-- **Automated backups** — Daily backups with point-in-time recovery. See [Backups](/postgres/database/backups).
+Any PostgreSQL client works: Prisma ORM, `psql`, Kysely, Drizzle, `node-postgres`, or anything else that speaks Postgres.
 
 ## Getting started
 
-### Create a database
+### 1. Create a database
+
+The fastest way, with no account required:
+
+```npm
+npx create-db@latest
+```
+
+`create-db` creates a temporary Prisma Postgres database and prints a connection string plus a claim URL. Open the claim URL to keep the database in your workspace. See [create-db](/postgres/npx-create-db) for details. You can also create databases in the [Console](https://console.prisma.io) or with the [Prisma CLI](/cli/v8/postgres) (`npx prisma@next postgres create`).
+
+### 2. Copy the connection string
+
+`create-db` prints it once. For an existing database, open it in [Prisma Console](https://console.prisma.io) and click **Connect to your database**. Store it where your app reads configuration:
+
+```text title=".env"
+DATABASE_URL="postgres://...@db.prisma.io:5432/postgres?sslmode=require"
+```
+
+### 3. Connect and run a query
 
-New to Prisma Postgres? Start here. In the [recommended stack](/), Prisma Postgres is the database behind a [Prisma 8](/v8) app, and [Prisma Compute](/compute) later runs that app next to it.
+Pick the client you use; each quickstart takes you from connection string to a first query:
 
 <Cards>
-  <Card href="/prisma-postgres/quickstart/prisma-next" title="Quickstart with Prisma 8" icon={<Rocket className="text-primary" />}>
-    Scaffold a Prisma 8 app and let setup provision Prisma Postgres.
+  <Card href="/prisma-postgres/quickstart/prisma-next" title="Prisma 8 quickstart" icon={<Rocket className="text-primary" />}>
+    Define a data contract and query with Prisma 8 (Release Candidate).
   </Card>
-  <Card href="/postgres/npx-create-db" title="Create a database with create-db" icon={<Terminal className="text-primary" />}>
-    Create a temporary Prisma Postgres database in one command, no account needed.
+  <Card href="/prisma-orm/quickstart/prisma-postgres" title="Prisma ORM 7 quickstart" icon={<Database className="text-primary" />}>
+    Connect with the current GA release of Prisma ORM.
   </Card>
-  <Card href="/prisma-orm/quickstart/prisma-postgres" title="Quickstart with Prisma ORM 7" icon={<Database className="text-primary" />}>
-    Set up Prisma ORM 7, the current GA release, and connect it to Prisma Postgres.
+  <Card href="/prisma-postgres/quickstart/kysely" title="Kysely quickstart">
+    Connect Prisma Postgres from Kysely.
+  </Card>
+  <Card href="/prisma-postgres/quickstart/drizzle-orm" title="Drizzle ORM quickstart">
+    Connect Prisma Postgres from Drizzle ORM.
   </Card>
 </Cards>
 
+Also available: the [TypeORM quickstart](/prisma-postgres/quickstart/typeorm) and [Connecting to your database](/postgres/database/connecting-to-your-database), which covers connection strings for `psql`, GUI tools, and serverless runtimes.
+
 Working with a coding agent? Copy this prompt:
 
 <AgentPrompt>
@@ -52,52 +75,28 @@ Current docs: https://www.prisma.io/docs/postgres.md.
 
 </AgentPrompt>
 
-### Get your connection string
-
-In [Prisma Console](https://console.prisma.io), open your database and click **Connect to your database** to copy connection URLs.
-
-## Choose a connection type
-
-### Prisma ORM (recommended default)
-
-Use Prisma ORM for migrations and type-safe queries.
-
-<Cards>
-  <Card href="/prisma-orm/quickstart/prisma-postgres" title="Prisma Postgres quickstart">
-    Get started with the recommended Prisma ORM workflow.
-  </Card>
-</Cards>
-
-### Any PostgreSQL client or ORM
+## What's included
 
-Use Prisma Postgres with `psql`, GUI tools, `node-postgres`, or other ORMs.
+Each Prisma Postgres database includes the following, with no extra services to configure:
 
-<Cards>
-  <Card href="/prisma-postgres/quickstart/kysely" title="Kysely quickstart">
-    Connect Prisma Postgres from Kysely.
-  </Card>
-  <Card href="/prisma-postgres/quickstart/drizzle-orm" title="Drizzle ORM quickstart">
-    Connect Prisma Postgres from Drizzle ORM.
-  </Card>
-  <Card href="/prisma-postgres/quickstart/typeorm" title="TypeORM quickstart">
-    Connect Prisma Postgres from TypeORM.
-  </Card>
-  <Card href="/postgres/database/connecting-to-your-database" title="Connecting to your database">
-    Choose the right connection string for Prisma ORM, PostgreSQL tools, and serverless runtimes.
-  </Card>
-</Cards>
+- **Connection pooling**: a dedicated PgBouncer instance runs alongside your database, with nothing to set up or manage. It also works for serverless and edge deployments. See [Connection pooling](/postgres/database/connection-pooling).
+- **Query caching**: add a `cacheStrategy` to any Prisma ORM query to cache results at the edge, using TTL or stale-while-revalidate. See [Caching](/accelerate/caching).
+- **Edge and serverless support**: connect from Cloudflare Workers, Vercel Edge Functions, and other edge runtimes via the [serverless driver](/postgres/database/serverless-driver), which uses HTTP instead of TCP.
+- **Automated backups**: daily backups with point-in-time recovery. See [Backups](/postgres/database/backups).
 
-### Serverless and edge runtimes
+## Local development
 
-Use the serverless driver for HTTP/WebSocket connectivity in edge or constrained runtimes.
+Run Prisma Postgres locally with `prisma dev`, then switch to cloud when ready.
 
-- [Serverless driver (`@prisma/ppg`)](/postgres/database/serverless-driver)
+- [Local development](/postgres/database/local-development)
 
-### Local development
+## Use with the rest of Prisma
 
-Run Prisma Postgres locally with `prisma dev`, then switch to cloud when ready.
+Each integration is optional. Prisma Postgres works with any PostgreSQL client.
 
-- [Local development](/postgres/database/local-development)
+- Using [Prisma 8](/v8)? The quickstart provisions a database and connects it to your data contract.
+- Deploying on [Prisma Compute](/compute)? Each branch of a Compute project can have its own Prisma Postgres database; pass the connection string through [environment variables](/compute/environment-variables).
+- Building a multi-service application? [Prisma Composer](/composer/databases) declares a database as a service dependency and injects the connection at runtime.
 
 ## Manage
 
diff --git a/apps/docs/content/docs/studio/prisma-next.mdx b/apps/docs/content/docs/studio/prisma-next.mdx
index 80e0cf97a1..26d82224ec 100644
--- a/apps/docs/content/docs/studio/prisma-next.mdx
+++ b/apps/docs/content/docs/studio/prisma-next.mdx
@@ -11,7 +11,7 @@ Prisma Studio shows the migration history of your [Prisma 8](/orm/v8) database a
 
 This guide takes you from an empty directory to inspecting your own migration history. For browsing, editing, and filtering data in general, see [Getting Started](/studio/getting-started).
 
-The Migrations view requires `@prisma/studio-core` 0.32.0 or later, currently available in the Prisma CLI's `dev` release: run Studio with `npx prisma@dev studio`. The Prisma 8 [Release Candidate](/orm/v8) is available.
+The Migrations view requires `@prisma/studio-core` 0.32.0 or later, which currently ships in the Prisma CLI's `dev` release. Run Studio with `npx prisma@dev studio`. The Prisma 8 [Release Candidate](/orm/v8) is available.
 
 ## Prerequisites
 
@@ -20,27 +20,27 @@ The Migrations view requires `@prisma/studio-core` 0.32.0 or later, currently av
 
 Create the project and provision a [Prisma Postgres](/postgres) database in one step:
 
-```bash
+```npm
 npm create prisma@next
 ```
 
 To skip the prompts:
 
-```bash
+```npm
 npm create prisma@next -- my-app --yes --provider postgres --authoring psl \
   --template minimal --prisma-postgres --install --emit
 ```
 
-This writes your `DATABASE_URL` into `.env` and scaffolds a [data model](/orm/v8/data-modeling) at `src/prisma/contract.prisma`, authored in [PSL](/orm/v8/contract-authoring/psl-syntax). The database expires after 24 hours unless you claim it; open the `CLAIM_URL` in `.env` to keep it and attach it to your Prisma Console account.
+This writes your `DATABASE_URL` into `.env` and scaffolds a [data model](/orm/v8/data-modeling) at `src/prisma/contract.prisma`, authored in [PSL](/orm/v8/contract-authoring/psl-syntax). The database expires after 24 hours unless you claim it. Open the `CLAIM_URL` in `.env` to keep it and attach it to your Prisma Console account.
 
 ## Apply the first migration
 
 The scaffolded [contract](/orm/v8/contract-authoring/the-data-contract) defines a `User` and a `Post` model. Compile it, [plan a migration](/orm/v8/migrations/generating-a-migration), and [apply it](/orm/v8/migrations/applying-a-migration):
 
-```bash
-npx @prisma/cli@next contract emit
-npx @prisma/cli@next migration plan --name init_users_posts
-npx @prisma/cli@next migrate --advance-ref db
+```npm
+npx prisma@next contract emit
+npx prisma@next migration plan --name init_users_posts
+npx prisma@next migrate --advance-ref db
 ```
 
 The CLI confirms the apply:
@@ -90,10 +90,10 @@ model Post {
 
 Compile the updated contract, plan, and apply:
 
-```bash
-npx @prisma/cli@next contract emit
-npx @prisma/cli@next migration plan --name add_roles_and_publishing
-npx @prisma/cli@next migrate --advance-ref db
+```npm
+npx prisma@next contract emit
+npx prisma@next migration plan --name add_roles_and_publishing
+npx prisma@next migrate --advance-ref db
 ```
 
 Because the `db` ref was advanced in the previous step, the planner produces a delta: four `ALTER TABLE` operations that add the new columns and the enum's check constraint. To edit a planned migration before it runs, for example to add a backfill, see [Editing a migration](/orm/v8/migrations/editing-a-migration).
@@ -106,11 +106,11 @@ Without a `db` ref and without `--from`, `migration plan` compares against an em
 
 Migration history is easier to read next to real rows:
 
-```bash
+```npm
 npm run db:seed
 ```
 
-The CLI confirms with `Seeded 3 users.` The seed script writes through the Prisma 8 ORM client; see [Writing data](/orm/v8/fundamentals/writing-data) for the API it uses.
+The CLI confirms with `Seeded 3 users.` The seed script writes through the Prisma 8 ORM client. See [Writing data](/orm/v8/fundamentals/writing-data) for the API it uses.
 
 :::note[Namespaced ORM access]
 `db.orm` is keyed by namespace first: reach models as `db.orm.public.User`, not `db.orm.User`. If the scaffolded `seed.ts` uses the shorter form, it fails with `TypeError: Cannot read properties of undefined (reading 'where')`. Add the namespace to fix it.
@@ -172,7 +172,7 @@ Open the **Schema** panel to see a Prisma-schema diff between the migration's be
 
 ![The Schema panel showing a color-coded diff of the Prisma schema before and after a migration, with collapsed unchanged sections.](/img/studio/prisma-next-migrations/studio-migrations-schema-diff.png)
 
-The diff is a projection built for stable comparison, not a copy of your source file. It uses a fixed field order and renders some attributes in expanded form, such as `@default(dbgenerated("autoincrement()"))`.
+The diff is built for stable comparison and is not a copy of your source file. It uses a fixed field order and renders some attributes in expanded form, such as `@default(dbgenerated("autoincrement()"))`.
 
 ## Browse the resulting data
 
@@ -187,7 +187,7 @@ Prisma 8 records every apply in two tables in your database:
 - `prisma_contract.ledger`: one row per applied migration, with its name, apply time, executed operations, and the schema versions it moved between.
 - `prisma_contract.contract`: each schema version, stored once and keyed by hash.
 
-Studio joins the two to build the timeline and the diffs. Nothing is read from disk and nothing is reconstructed, which is why the history of any database you connect to is complete, including migrations you never ran yourself. These table names are also where to look if you inspect the history over SQL.
+Studio joins the two to build the timeline and the diffs. Because everything is read from the database, the history of any database you connect to is complete, including migrations you never ran yourself. These table names are also where to look if you inspect the history over SQL.
 
 The hashes are the same ones that make Prisma 8 migrations [a graph rather than a numbered list](/orm/v8/migrations/the-migration-graph); the design story is in [Rethinking Database Migrations](https://www.prisma.io/blog/rethinking-database-migrations).
 
diff --git a/apps/docs/src/components/concept-animation/flow-presets.ts b/apps/docs/src/components/concept-animation/flow-presets.ts
index ae7865fb8b..f5c1c5c927 100644
--- a/apps/docs/src/components/concept-animation/flow-presets.ts
+++ b/apps/docs/src/components/concept-animation/flow-presets.ts
@@ -1325,12 +1325,255 @@ const migrationRollback: FlowScene = {
   ],
 };
 
+// ---------------------------------------------------------------------------
+// Composer scenes.
+// ---------------------------------------------------------------------------
+
+// What a Composer application is made of: services, the contracts between
+// them, and the resources they depend on. Teaches composition before syntax.
+const composerAppGraph: FlowScene = {
+  label: "A Prisma App: services, contracts, and resources",
+  width: 700,
+  height: 300,
+  groupLabels: [
+    { text: "Prisma App · store", x: 24, y: 18 },
+    { text: "Resources", x: 520, y: 18 },
+  ],
+  nodes: [
+    {
+      id: "storefront",
+      label: "storefront",
+      sub: "Next.js service",
+      variant: "scope",
+      x: 24,
+      y: 110,
+      w: 170,
+      h: 64,
+    },
+    {
+      id: "orders",
+      label: "orders",
+      sub: "service",
+      variant: "source",
+      x: 274,
+      y: 36,
+      w: 160,
+      h: 64,
+    },
+    {
+      id: "catalog",
+      label: "catalog",
+      sub: "service",
+      variant: "source",
+      x: 274,
+      y: 196,
+      w: 160,
+      h: 64,
+    },
+    {
+      id: "orders-db",
+      label: "Prisma Postgres",
+      sub: "orders database",
+      variant: "project",
+      x: 512,
+      y: 36,
+      w: 170,
+      h: 64,
+    },
+    {
+      id: "catalog-db",
+      label: "Prisma Postgres",
+      sub: "catalog database",
+      variant: "project",
+      x: 512,
+      y: 196,
+      w: 170,
+      h: 64,
+    },
+  ],
+  edges: [
+    {
+      id: "sf-orders",
+      from: "storefront",
+      fromSide: "r",
+      to: "orders",
+      toSide: "l",
+      label: "orders contract",
+    },
+    {
+      id: "sf-catalog",
+      from: "storefront",
+      fromSide: "r",
+      to: "catalog",
+      toSide: "l",
+      label: "catalog contract",
+    },
+    {
+      id: "orders-catalog",
+      from: "orders",
+      fromSide: "b",
+      to: "catalog",
+      toSide: "t",
+      dashed: true,
+      label: "catalog contract",
+    },
+    { id: "orders-pg", from: "orders", fromSide: "r", to: "orders-db", toSide: "l" },
+    { id: "catalog-pg", from: "catalog", fromSide: "r", to: "catalog-db", toSide: "l" },
+  ],
+  steps: [
+    {
+      title: "1. Services",
+      caption:
+        "An application is one or more services. Each service is a process that Composer builds a declaration for: what it is called, how it is built, and what it depends on.",
+      nodes: ["storefront", "orders", "catalog"],
+      edges: [],
+      emphasize: ["storefront", "orders", "catalog"],
+    },
+    {
+      title: "2. Contracts connect services",
+      caption:
+        "A service that other services call exposes a contract: its API described as schemas. A consumer declares a dependency on that contract and receives a typed client. TypeScript checks that every declared dependency matches a contract some service exposes.",
+      nodes: ["storefront", "orders", "catalog"],
+      edges: ["sf-orders", "sf-catalog", "orders-catalog"],
+      emphasize: ["storefront"],
+    },
+    {
+      title: "3. Resources attach to services",
+      caption:
+        "A resource is something a service depends on that is not a service: a Prisma Postgres database, an object-store bucket, a secret. Each service declares its own resources, so the orders and catalog services each get their own database.",
+      nodes: ["storefront", "orders", "catalog", "orders-db", "catalog-db"],
+      edges: ["sf-orders", "sf-catalog", "orders-catalog", "orders-pg", "catalog-pg"],
+      emphasize: ["orders-db", "catalog-db"],
+    },
+  ],
+};
+
+// From declaration to running infrastructure, and how app code receives its
+// dependencies at runtime.
+const composerDeployFlow: FlowScene = {
+  label: "From declarations to running services",
+  width: 700,
+  height: 286,
+  groupLabels: [
+    { text: "You write", x: 24, y: 18 },
+    { text: "composer deploy provisions", x: 470, y: 18 },
+  ],
+  nodes: [
+    {
+      id: "decl",
+      label: "Service declarations",
+      sub: "compute({ name, deps, build })",
+      subBelow: true,
+      variant: "source",
+      x: 24,
+      y: 36,
+      w: 220,
+      h: 78,
+    },
+    {
+      id: "root",
+      label: "Root module",
+      sub: "module.ts wires deps",
+      subBelow: true,
+      variant: "scope",
+      x: 24,
+      y: 176,
+      w: 220,
+      h: 78,
+    },
+    {
+      id: "deploy",
+      label: "composer deploy",
+      sub: "diffs against stored state",
+      subBelow: true,
+      variant: "neutral",
+      x: 320,
+      y: 106,
+      w: 190,
+      h: 78,
+    },
+    {
+      id: "compute",
+      label: "Prisma Compute",
+      sub: "one service each",
+      variant: "vars",
+      x: 546,
+      y: 36,
+      w: 148,
+      h: 64,
+    },
+    {
+      id: "postgres",
+      label: "Prisma Postgres",
+      sub: "one database each",
+      variant: "project",
+      x: 546,
+      y: 126,
+      w: 148,
+      h: 64,
+    },
+    {
+      id: "load",
+      label: "service.load()",
+      sub: "typed clients at runtime",
+      variant: "resolved",
+      x: 546,
+      y: 216,
+      w: 148,
+      h: 56,
+    },
+  ],
+  edges: [
+    { id: "d-root", from: "decl", fromSide: "b", to: "root", toSide: "t" },
+    { id: "root-deploy", from: "root", fromSide: "r", to: "deploy", toSide: "l" },
+    { id: "deploy-compute", from: "deploy", fromSide: "r", to: "compute", toSide: "l" },
+    { id: "deploy-pg", from: "deploy", fromSide: "r", to: "postgres", toSide: "l" },
+    {
+      id: "deploy-load",
+      from: "deploy",
+      fromSide: "b",
+      to: "load",
+      toSide: "l",
+      dashed: true,
+      label: "injected env",
+    },
+  ],
+  steps: [
+    {
+      title: "1. Declare",
+      caption:
+        "Each service is declared as data: its name, its dependencies, and how it is built. The root module provisions the services and wires each dependency to the service or resource that provides it.",
+      nodes: ["decl", "root"],
+      edges: ["d-root"],
+      emphasize: ["decl", "root"],
+    },
+    {
+      title: "2. Deploy",
+      caption:
+        "composer deploy loads the root module, compares the declared application against the deploy state stored on the platform for that environment, and creates or updates the services on Prisma Compute and the databases on Prisma Postgres. Re-running a deploy applies only the difference; unchanged resources are not recreated.",
+      nodes: ["decl", "root", "deploy", "compute", "postgres"],
+      edges: ["d-root", "root-deploy", "deploy-compute", "deploy-pg"],
+      emphasize: ["deploy", "compute", "postgres"],
+    },
+    {
+      title: "3. Run",
+      caption:
+        "At runtime, each service calls service.load() once and receives its dependencies as typed values: an RPC client for each contract dependency, a connection for each database. The values come from environment variables Composer wrote at deploy time; your code never reads process.env itself.",
+      nodes: ["decl", "root", "deploy", "compute", "postgres", "load"],
+      edges: ["d-root", "root-deploy", "deploy-compute", "deploy-pg", "deploy-load"],
+      emphasize: ["load"],
+    },
+  ],
+};
+
 /**
  * Names that render as visual flow diagrams. Any name not listed here falls
  * back to the Code Hike token animation in presets.ts.
  */
 export const FLOW_SCENES = {
   "compute-model": computeModel,
+  "composer-app-graph": composerAppGraph,
+  "composer-deploy-flow": composerDeployFlow,
   "env-layers": envLayers,
   "github-connection": githubConnection,
   "relation-one-to-one": relationOneToOne,
diff --git a/apps/docs/src/lib/agent-skill.ts b/apps/docs/src/lib/agent-skill.ts
index bf82944c06..1d831da882 100644
--- a/apps/docs/src/lib/agent-skill.ts
+++ b/apps/docs/src/lib/agent-skill.ts
@@ -162,6 +162,18 @@ Add it with the standard MCP configuration:
 
 The server exposes a \`search_prisma_documentation\` tool that returns cited answers grounded in the official Prisma docs — prefer it over training data for Prisma questions.
 
+## Installable agent skills
+
+Prisma publishes deeper, task-specific skills in the Agent Skills format (https://agentskills.io/). Installing them into a project gives you version-accurate command and API knowledge without re-reading the docs:
+
+\`\`\`bash
+npx skills add prisma/skills          # Prisma CLI, Prisma Client, Prisma Postgres, Prisma Compute, upgrade guides
+npx skills add prisma/prisma/skills   # Prisma 8 (also installed automatically by \`npx prisma@next orm init\`)
+npx skills add prisma/composer        # Prisma Composer
+\`\`\`
+
+The catalog of skills and what each one teaches: https://www.prisma.io/docs/ai/tools/skills.md
+
 ## Documentation for agents
 
 - **Index:** https://www.prisma.io/docs/llms.txt — links to per-area indexes (Prisma ORM, Prisma Postgres, Guides, CLI, Studio, Platform, and more).
diff --git a/apps/site/src/lib/agent-skills.ts b/apps/site/src/lib/agent-skills.ts
index 7856afd4be..561f722b3f 100644
--- a/apps/site/src/lib/agent-skills.ts
+++ b/apps/site/src/lib/agent-skills.ts
@@ -220,6 +220,20 @@ and backups; restoring backups; running SQL queries; introspecting schemas; and
 official docs with citations. Once connected, you can prompt your agent to
 "List the Prisma tools" for the latest supported tools.
 
+## Installable agent skills
+
+Prisma publishes deeper, task-specific skills in the Agent Skills format
+(https://agentskills.io/). Installing them into a project gives you
+version-accurate command and API knowledge without re-reading the docs:
+
+\`\`\`bash
+npx skills add prisma/skills          # Prisma CLI, Prisma Client, Prisma Postgres, Prisma Compute, upgrade guides
+npx skills add prisma/prisma/skills   # Prisma 8 (also installed automatically by \`npx prisma@next orm init\`)
+npx skills add prisma/composer        # Prisma Composer
+\`\`\`
+
+The catalog of skills and what each one teaches: ${docsUrl}/ai/tools/skills.md
+
 ## Where to read the docs
 
 - Docs index (machine-readable): ${baseUrl}/docs/llms.txt