Prisma prompts should start with the installed version and the files that define data access. The same request can require a different configuration or migration workflow across releases. A useful agent first reads the repository, then proposes changes that fit it. These prompts cover three practical tasks: explaining an expensive query path, reviewing a migration and checking authorization around data access.
Give the agent a version-specific starting point
Provide the package manifest, lockfile, Prisma configuration and the relevant schema or contract files. Include one established data access module. If you are upgrading Prisma, state the starting and target versions separately from the application feature. This prevents an apparently small query task from becoming an accidental migration between tool generations.
The Prisma migration documentation describes its current workflow. Use documentation for your actual release before running a command. The prompts here deliberately ask the agent to discover commands in context rather than prescribing one migration command for every project.
Inspect a query through the request path
A slow endpoint can perform many small queries or one expensive query. Include both the application call path and a sanitized query trace. Ask which fields the caller needs and where additional reads happen. Reducing returned fields may simplify an interface, but it is not proof of a latency improvement without a comparable measurement.
Review Prisma data access for {{request_path}} in {{repository_paths}}.
Read the installed Prisma version and configuration first.
Use {{sanitized_query_trace}} to count queries and identify repeated work.
Explain the data the caller actually needs. Propose one focused change,
then compare query count, response shape and timing on {{test_dataset}}.
Do not claim a performance gain without observed evidence.
Review a generated migration before applying it
Give the agent the desired behavior and generated operations, not only the changed model file. The review should explain whether data is copied, validated, transformed or removed. Include old application instances in the plan. A schema that matches the new code can still be incompatible with the previous deployment during a rolling release.
Review {{generated_migration}} for this intended change: {{change}}.
Our Prisma version is {{version}} and database is {{database_version}}.
Check for destructive operations, compatibility gaps and assumptions
about existing rows. Propose rehearsal data, verification queries and a
recovery plan. Identify the correct commands for this installed version,
but do not apply the migration or reset any database.
Check ownership at the data access boundary
ORM calls can look type-safe while querying the wrong person's records. Supply the authorization contract and the route or service responsible for applying it. Ask the agent to trace identifiers from request to query. Include a second user in the test plan and distinguish a missing record from a forbidden operation where your product requires that distinction.
Review {{data_access_module}} for {{ownership_rule}}.
Trace authenticated identity and request-provided IDs into each Prisma
query. Find reads or writes that lack the required ownership condition.
Add focused tests with users A and B using our existing database fixture.
Preserve transaction boundaries and report what was actually executed.
Keep version changes separate from behavior changes
Review any generated files and lockfile modifications before accepting the result. Make sure the agent has not regenerated the entire data layer to fix a single filter. If a tool upgrade is necessary, explain why and verify it as an explicit task. This keeps query regressions distinguishable from configuration changes.
Save your Prisma review recipe in Kipt with blanks for version, data path and evidence. Keep database connection strings outside reusable prompts. The database migration prompts provide a broader staged-release plan when the generated operations are only one part of the change.