TL;DR: Do not run migrate dev in automation at all - it is an interactive command, and the reset prompt it is waiting on has no safe default answer. Switch the agent to prisma migrate deploy, which applies pending migrations with no prompts. If a dev database genuinely needs resetting, do it as an explicit, separately approved step, never as a side effect of a hung migrate.

```text
prisma migrate dev hung because the agent couldnt answer the interactive reset-the-database prompt - no tty in the sandbox
```

1. Confirm the hang is the reset prompt: check the process - it is idle, and the drift report from migrate status mentions drift or a needed reset.
   Expected: `prisma migrate status` shows drift that explains why dev wanted to reset.
2. Kill the hung process - it will never proceed without input.
   Expected: the process exits and the database is untouched (the prompt appears before any destructive action).
3. Replace the agent's apply step with `prisma migrate deploy`.
   Expected: it prints which migrations it applied (or "No pending migrations to apply") and exits on its own, no prompt.
4. If the database actually needs a reset for development, make it explicit: drop and recreate the dev database as its own step, then run migrate deploy against the empty database.
   Expected: a clean schema with no interactive prompt anywhere in the flow.
5. Guard the agent loop: fail the step fast if any command waits on stdin (redirect stdin from an empty source so a prompt errors instead of hanging).
   Expected: future prompt-waits surface as immediate errors with a clear message, not long stalls.

## Use this when
- prisma migrate dev hangs in a sandbox, CI, or any headless environment
- the agent cannot answer the reset-the-database prompt
- a migrate step stalls with zero output

## Not for this skill when
- you are developing interactively with a real terminal - migrate dev is fine there, just answer the prompt
- migrate deploy reports failed migrations - resolve those in the migrations table first
- the database connection itself is broken - fix connectivity

## Variant phrasings
- prisma migrate dev waiting for input in CI
- migrate dev reset prompt hangs with no tty
- headless prisma migrate dev stalls on drift

## Why it happens
migrate dev detects drift between your migrations and the database, and its response is to offer a database reset - a destructive action it will not take without confirmation. With no tty, the confirmation never comes and the process waits forever. The command was designed for a developer at a keyboard; the agent sandbox has no keyboard, so the correct move is a different command, not a cleverer way to answer.

## Edge cases
- Piping an automatic "yes" into migrate dev technically answers the prompt - do not do this in automation; an unexpected drift would wipe the database with no human in the loop.
- migrate deploy refuses to run when drift or failed migrations exist - that refusal is the safety net; resolve the underlying state instead of bypassing it.
- The shadow database used for drift detection needs database-creation privileges; in restricted sandboxes that failure can masquerade as a hang.
- If the agent truly needs migrate dev behavior, it needs a terminal - but deploy plus explicit reset steps is the better design.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_toSk-rgHq9nnUkFYi5bj3Q