TL;DR: Inspect the failed row, decide whether the migration actually landed, then tell prisma which it is with `migrate resolve`. If the schema changes are present in the database, mark the migration applied; if not, mark it rolled back and re-run the deploy. Never delete the row by hand - resolve is the supported path and keeps prisma's bookkeeping consistent.

The problem as reported:
```text
the agent's prisma migrate lost its database connection halfway - the _prisma_migrations table has a row stuck in failed state
```

1. Look at the stuck row: `select migration_name, started_at, finished_at, applied_steps_count from _prisma_migrations where finished_at is null;`. Expected: one row for the interrupted migration, with finished_at null.
2. Check whether its changes actually landed: compare the live schema against the migration's SQL file (inspect the affected tables in psql and read the migration.sql). Expected: a yes-or-no answer - the statements either ran or they didn't.
3. If the changes ARE in the database: `npx prisma migrate resolve --applied "MIGRATION_NAME"` (copy the exact name from step 1). Expected: prisma reports the migration marked as applied.
4. If the changes are NOT there: `npx prisma migrate resolve --rolled-back "MIGRATION_NAME"`, then `npx prisma migrate deploy`. Expected: the failed row is cleared and the migration applies cleanly.
5. Run `npx prisma migrate status`. Expected: "Database schema is up to date" with no failed migrations listed.

## Use this when
- A prisma migrate died mid-run after losing its database connection.
- _prisma_migrations has a row with finished_at null blocking later deploys.
- You need to choose between resolve --applied and --rolled-back.

## Not for this skill when
- The complaint is drift rather than a failed row - that's a baseline problem, different fix.
- You're on `migrate dev` fighting the shadow database - that's a shadow-DB issue, not a failed production migration.

## Variant phrasings
- prisma migration stuck in failed state
- prisma migrate resolve applied vs rolled back
- _prisma_migrations finished_at null
- prisma deploy blocked by failed migration

## Why it happens
Prisma writes the migration row when the migration starts and only stamps finished_at on success. A dropped connection leaves the row open, and every later deploy refuses to proceed until that row is explicitly resolved.

## Edge cases
- The migration half-applied (some statements ran): reconcile the schema by hand before resolving - resolving --applied on a half-applied migration corrupts future diffs.
- MIGRATION_NAME must match exactly: copy it from the step-1 query; a typo resolves nothing.
- Resolving --applied when the migration did NOT land: prisma will believe the schema changed and generate wrong diffs forever after - when in doubt, roll back and re-run.

## Provenance

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