Prisma

View saved version →

---
name: prisma-build-and-deploy
description: >-
  Build and deploy applications when the user selects or invokes the Prisma
  plugin, including requests like "Build a simple Todo app and deploy it" that
  do not name a stack. Use Prisma Composer for new apps and Prisma Compute for
  deployment. Also use for explicit Composer/Compute requests, deployment
  diagnostics, and recovering Composer deployments. Does not cover unrelated ORM
  or database administration.
---

# Build and deploy with Prisma

Guide the requested application from working code to a verified deployment.
Selecting Prisma for this task supplies the default: Composer for a new app and
Compute for deployment. The user need not name either product or separately ask
for local and live verification. State that choice briefly and follow this
workflow. Respect explicit stack/hosting choices and local-only requests;
installation alone is not a provider choice.

This journey requires ChatGPT's desktop app with local execution. Check the
actual execution environment: a cloud task launched from desktop is still out of
scope. In web/cloud execution, explain that the user must continue in a desktop
task running locally; do not offer manual credentials as a workaround.

Do not process protected health information (PHI) or payment card data regulated
by PCI DSS through files, CLI commands, database operations, MCP tools, logs, or
application verification. If the request or available context indicates such
data may be present, stop before accessing affected resources; clarify without
requesting real data samples and offer an isolated environment with synthetic
data only. If encountered unexpectedly, stop further access and do not reproduce
the data in responses or artifacts. Never retrieve it merely to redact it later
or switch tools to bypass this restriction. Ordinary Todo requests need no extra
questionnaire; healthcare or payment prototypes using synthetic data are supported.

For Composer declarations, wiring, builds, and database concepts, read the bundled
[Composer core concepts](../prisma-composer-core-concepts/SKILL.md). Reuse its
guidance rather than re-deriving the API. For CLI installation and authentication,
read [the version-specific toolchain reference](references/toolchain.md): the
bundled core reference describes the standalone CLI, while this workflow defaults
to the unified Prisma CLI for new interactive projects.

## Establish the project and toolchain

- Inspect the app, package manifest, lockfile, existing Composer configuration,
  and scripts. Preserve the framework, package manager, and database strategy of
  an existing app. If it is not Composer-ready, explain the concrete adaptation
  needed before undertaking a substantial rewrite.
- Resolve Node and the package-manager executable together, plus Bun when used.
  Before install, build, or deploy, verify their paths and versions in the actual
  execution context against package requirements and project pins. Preserve the
  selected executables across install, build, dev, and deploy; repeat this check
  before work in a new execution context. Use available host capabilities to
  supply supported tooling and install project-local dependencies yourself.
  Explain progress or genuine blockers in plain language; the user should not
  need to open a terminal, run commands, or configure credentials.
- For a new project, use the dependency set in the toolchain reference, including
  required peers, and prefer its verified Node/npm pair when available. For an
  existing project, inspect its installed versions and
  their matching skill/documentation; do not downgrade it to the bundled version.
- Choose a simple implementation suited to the request. Do not turn a small Todo
  request into a design interview. Make the schema and persistence approach
  explicit. New Composer apps requiring persistent application data must use
  Prisma Postgres through Composer: local Postgres during development and managed
  

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: prisma-composer-core-concepts
metadata:
  library: "@prisma/composer"
  library_version: "0.21.0"
  version: 2026.9.1
description: >-
  Use when deploying or managing an app that uses Prisma Composer
  (`@prisma/composer`): wiring its services and Modules, running it locally,
  testing composed services, or standing up / tearing down an environment.
  Triggers on "prisma composer", "@prisma/composer", "prisma app", the
  `prisma-composer` CLI, `compute()`, `module()`, `contract()`,
  `service.load()`, `mockService`, `bootstrapService`.
---

# Prisma Composer core concepts

A **Prisma App** is a tree of typed declarations composed in TypeScript and
handed to the `prisma-composer` CLI. This file covers structures,
hierarchies, relationships, and workflows: the concepts you cannot observe
from the code or the CLI's help output. It is not a CLI reference; discover
any individual command and its flags with `--help`. Commands named here
belong to the `prisma-composer` CLI itself; a host CLI that embeds Composer
may not carry every verb, so confirm a command exists via `--help` rather
than inferring it. The Prisma platform moves fast, so treat this file as the
stable conceptual core and find current, fuller documentation at
<https://www.prisma.io/docs>. For working code, read `examples/` in the
prisma/composer repo.

Two principles govern everything and are binding
(`docs/design/01-principles/`):

1. **Your code never reads its environment.** Dependencies, configuration,
   credentials, and the port all arrive through the service node, typed.
   `process.env` is never the answer.
2. **Composer never bundles or transforms your code.** You build with your own
   bundler; the framework assembles the built output by deterministic steps
   and hands it to the configured deploy target.

## Declarations are data

Everything you author is a declaration: plain data describing a piece of the
app, executing nothing when imported. Three node kinds exist:

| Kind | Declared with | Purpose |
| --- | --- | --- |
| Service | `compute()` | A running unit of your code; atomic, Composer sees only its ports |
| Resource | `rawPostgres()`, `bucket()` | A stateful managed dependency |
| Module | `module()` | A grouping boundary; runs no code of its own, exposes typed ports |

Nodes connect through **ports**: `deps` declares what a node requires,
`expose` declares what it offers. Wiring happens in a Module's builder via
`provision()`, and the root Module, handed to the CLI, is the App:

```ts
// module.ts
import { module } from '@prisma/composer';

export default module('store', ({ provision }) => {
  const catalog = provision(catalogModule);
  provision(storefrontService, { deps: { catalog: catalog.rpc } });
});
```

Because ports are typed, **the compiler verifies every wire**. A dependency
wired to the wrong producer, a missing RPC handler, a literal input value of
the wrong shape: all of it fails `tsc`, not the deploy. Env-bound input is
the exception: those values exist only at deploy, so secret-binding
mismatches and missing platform variables surface as early deploy-time
refusals instead (see Two channels below). Typecheck, then build, then
deploy; don't use the cloud to find out whether the wiring is correct.

Composer itself is target-agnostic: `@prisma/composer` carries authoring,
testing, and the CLI, coupled to no platform. A deploy target is an extension
registered in the deploy config; `@prisma/composer-prisma-cloud` is the
Prisma Cloud target and the one this skill's deploy sections assume. Its
root exports `compute`, `rawPostgres`, `bucket`, `envSecret`, and
`envParam`; the ORM vocabulary (`postgres`, `dataContract`) lives under the
`/orm` subpath, alongside the shared `/cron`, `/storage`, `/streams`,
`/auth`, and `/email` modules. These are the only two Composer packages a
basic Prisma Cloud app needs, and nothing installs them for you: a fresh
project starts with neither, so add both as dependencies first. An
extension adds its 

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: prisma-github-deploy
description: >-
  Save a Prisma Composer app to GitHub, connect its existing Prisma project,
  and enable or diagnose default-branch automatic deployments. Use when
  the user accepts the offer to save their code to GitHub and connect it to Prisma
  for automatic updates, accepts the shorter GitHub-saving offer, or
  directly requests this setup, including resuming an interrupted connection.
  Do not start GitHub setup for an ordinary build/deploy request, unrelated Git
  work, or a request to deploy an app before a live target has been established.
---

# Save to GitHub and enable automatic updates

Take a working Composer app with a verified Prisma deployment through repository
saving, project connection, and verified GitHub deployments. Use the existing
[build-and-deploy workflow](../prisma-build-and-deploy/SKILL.md) for local setup,
authentication, and application verification, and its Composer reference for APIs.
Read [GitHub deployment details](references/github-deploy.md) before configuring CI.
For automatic deployments, establish a missing live target through that journey
first. A save-only request needs no cloud deployment or Prisma connection.
Do not add unrelated PR-management or migration work.

Accepting the build workflow's combined offer authorizes saving, connection, and
automatic-update setup. Honor an explicit save-only or no-deploy request: save
the source and finish without connecting or enabling deployments. Do not turn
setup into a branch-preview demonstration or invent an application change.

The agent works locally in the desktop app; GitHub Actions executes the resulting
workflow remotely. Browser/cloud agent execution remains unsupported. Handle
commands and supported authentication yourself. The user completes browser consent
when required, without terminal commands, pasted tokens, or credential copying.

Do not access or upload PHI or PCI-regulated payment card data, including project
files, databases, and logs. If context suggests it is present, stop before access,
clarify without requesting real examples, and offer a separate synthetic-data
environment. If encountered unexpectedly, stop and do not reproduce it. Never
switch from MCP to CLI or GitHub to bypass the restriction. Ordinary Todo apps
need no extra questionnaire. Preserve secret redaction during diagnostics.

## Establish the same app and save its code

- Inspect Git state, remotes, package manifest, lockfile, Composer configuration,
  and existing workflows. Preserve the user's uncommitted work and app conventions.
  For automatic updates, confirm the authenticated Prisma workspace and deployed
  project by ID, production/default versus named target, actual live branch,
  region, service/database IDs, and both verified app/project links; retain a
  non-sensitive persistence sample for verification.
  Resolve ambiguity before pushing or connecting; never infer identity from a
  matching display name alone.
- Reuse an appropriate existing repository. Otherwise propose an app-derived
  name, default to private visibility, and confirm owner/destination unless already
  specified. New repositories use `main` as the default branch; preserve an
  existing repository's default branch. Check access and contents before pushing. Never
  replace a remote, force-push, or overwrite repository contents to resolve a conflict.
- Save source, Composer configuration, and the lockfile. Review the exact staged
  files and diff first; exclude secrets, local auth, deployment state/reports, logs,
  and private test instructions. Do not commit an entire directory blindly.
  Record the repository and known workspace/project IDs, target kind and branch,
  region, verified app/project links,
  and deployment behavior in existing app documentation, without credentials or
  machine-specific paths. Keep dependency/runtime pins. For save-only requests,
  finish here without connecting, adding automation, or triggering a workflow;
  clari

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.