TL;DR: Note the correction first: this prompt comes from makemigrations (the autodetector), not from migrate - migrate itself never asks questions. In a headless run, generate migrations with --noinput so nothing can hang, and write the rename explicitly as a RenameModel operation instead of letting the autodetector guess. An explicit rename is also safer: the alternative the autodetector falls back to is drop-and-recreate, which loses data.

```text
Did you rename the [model] model to [new name]? [y/N]
```

1. Confirm where the hang is: the stuck step is the makemigrations step, not the migrate step.
   Expected: the process command line shows makemigrations, and re-running it interactively shows the rename question.
2. Kill the hung process - no migration file was written yet.
   Expected: the process exits and the migrations directory is unchanged.
3. Write the rename explicitly: create the migration with a RenameModel operation naming the old and new model (generate the file with makemigrations --noinput, then edit the operations list, or write the migration by hand).
   Expected: the migration file contains RenameModel and nothing else for this change.
4. Run the migration generation and apply steps with --noinput in the agent loop from now on.
   Expected: generation never blocks on a question; unrecognized renames become explicit errors or plain add/delete operations the agent can see.
5. Verify: run `python manage.py makemigrations --dry-run` and then `python manage.py migrate`.
   Expected: dry-run reports no changes, and migrate applies the RenameModel cleanly.

## Use this when
- migration generation hangs on the Did-you-rename-the-model question with no tty
- an agent renames a Django model and the next makemigrations stalls
- you want rename detection to be explicit rather than guessed

## Not for this skill when
- the model was actually deleted and a new one added (not a rename) - let the autodetector do its job interactively once
- migrate itself fails with an error - that is an apply-time problem
- you are at a terminal - just answer the question

## Variant phrasings
- django makemigrations hangs on rename model question
- did you rename the model prompt with no tty
- headless django migration generation stalls on rename detection

## Why it happens
When the autodetector sees a model disappear and a similar one appear, it cannot tell a rename from a delete-plus-add, so it asks. That question only exists in makemigrations - migrate applies whatever migration files exist and never prompts. In a headless agent run the question is never seen, so the process waits forever. Answering "no" (or defaulting to it with --noinput) is actively dangerous here: the fallback is separate delete and create operations, which drops the table and its data.

## Edge cases
- RenameModel also renames the database table - check for raw SQL, views, or external systems referencing the old table name.
- If the rename already went out as delete-plus-add in an earlier run, the data is already gone from that table - restore from backup before writing the RenameModel.
- The autodetector's rename guess can be wrong when two models change at once - explicit RenameModel avoids it guessing the wrong pair.
- After the rename, grep the codebase for the old model name - imports, admin registrations, and string references do not rename themselves.

## Provenance

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