TL;DR: Stop using migrate dev in the loop - it is an interactive development command that creates a shadow database to detect drift, and in automation it keeps flagging its own shadow as drift. Switch the agent to prisma migrate deploy for applying migrations and prisma migrate diff for inspection. If you must use migrate dev, point it at a disposable dev database it is allowed to reset, never at shared state.

```text
agent keeps re-running prisma migrate dev because drift detection flags its own shadow database as drift
```

1. Confirm the loop: run `prisma migrate status` and read the drift report.
   Expected: it names the shadow database or shows drift that reappears immediately after a successful dev run.
2. Check where migrate dev is pointed: inspect the datasource URL the agent is using.
   Expected: if it points at a shared, CI, or production-like database, that is the problem - migrate dev wants to reset whatever it touches on drift.
3. Switch the agent's apply step to `prisma migrate deploy`.
   Expected: output shows how many migrations it applied (or "No pending migrations to apply"), with no drift prompt and no reset.
4. Use `prisma migrate diff` for the inspection step the agent was using migrate dev for.
   Expected: a readable diff of schema changes without creating or resetting any database.
5. Reserve migrate dev for an interactive dev database the agent owns and may reset freely.
   Expected: drift prompts there are answerable and harmless because the database is disposable.

## Use this when
- prisma migrate dev keeps reporting drift and wanting to reset in a loop
- an agent re-runs migrate dev and it never converges
- drift detection flags the shadow database rather than real schema changes

## Not for this skill when
- the drift is real (someone hand-edited the database) - resolve the actual schema difference
- migrations fail to apply with SQL errors - that is a migration bug, not drift detection
- you are setting up the very first migration - migrate dev is fine interactively for that

## Variant phrasings
- prisma migrate dev drift loop on shadow database
- migrate dev keeps detecting drift after successful run
- prisma drift detection will not settle in CI

## Why it happens
migrate dev is built for interactive development: it creates a shadow database, diffs it against your migrations to detect drift, and on drift asks to reset the database. In a headless agent loop there is nobody to answer, and the shadow-database mechanics mean each run can re-detect its own artifacts as drift. migrate deploy skips all of this - it just applies pending migrations, which is what automation actually wants.

## Edge cases
- migrate deploy does not create the database or run seed scripts - handle database creation and seeding as separate steps.
- If drift is genuine, migrate deploy still refuses to run until it is resolved - check the prisma migrations table for failed rows first.
- The shadow database needs database-creation privileges; in locked-down environments the shadow creation itself can fail and look like drift.
- Never let an agent run migrate dev against a database with real data - the reset prompt it wants to answer destroys data.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_yf0GBq9TODxkP0mrN7Lr4w