Fix a Flaky DB Migration Playbook

Don’t want to set this up manually? Paste a link to this page into a Devin session and ask it to set everything up for you.

Spot the pattern across sessions

Your team has been using the !db-migration playbook for a few weeks. It handled renaming columns and adding indexes without issue — but the last two sessions crashed mid-migration when they tried to drop a column referenced by other tables.Open each session and look at the failure point. In this case, sessions 3 and 4 both errored at the same step:

ERROR: cannot drop column "account_id" because other objects depend on it
DETAIL: constraint fk_orders_account_id on table orders depends on column account_id
HINT: Use DROP ... CASCADE to drop dependent objects too.

You now have a clear signal: the playbook has no step for checking foreign key dependencies before destructive operations. Two sessions succeeded because they touched standalone tables; two failed because they didn’t.

Open the Improve Playbook tab with session links

Go to app.devin.ai and click Advanced below the input box. Select the Improve Playbook tab.Pick !db-migration from the playbook dropdown, then select all four sessions from the session multi-dropdown — both the successes and the failures. Including successful sessions lets Devin see what the playbook does well, not just where it breaks.What makes this prompt effective:

Names the exact failure — “foreign key constraints” instead of “it sometimes fails”
Contrasts successes and failures — Devin can diff the session transcripts to see where they diverge
Lists concrete fixes while leaving room for Devin to surface issues you missed

Review the playbook diff

Devin reads all four session transcripts, pinpoints where failures diverged from successes, and proposes targeted edits. The output looks like a changelog for your playbook:

## Analysis

Sessions 1-2 succeeded because they only modified tables with no
incoming foreign keys. Sessions 3-4 failed at step 4 ("Drop the
old column") because the orders and invoices tables had FK
references to the target column.

## Changes to !db-migration

Added step 3a: "Before any DROP or ALTER that removes a column,
  query information_schema.key_column_usage to list dependent FKs.
  If any exist, generate ALTER TABLE ... DROP CONSTRAINT statements
  and execute them first. Save the original constraint DDL for
  rollback."

Added step 7: "Rollback procedure — if any step after FK removal
  fails, re-create the dropped constraints using the saved DDL
  from step 3a."

Updated Advice section: "Always run the migration against a staging
  database first. FK chains can be deeper than expected — a column
  in table A may be referenced by B, which is referenced by C.
  Query recursively."

The playbook saves automatically. If something is off, reply in the same session — for example, “Also add a step to notify the #database Slack channel before running destructive migrations.”

Verify the fix on a fresh migration

You don’t need to leave your current Devin session. After the playbook update is saved, use the same session to launch a standard Devin session that tests the updated playbook against the exact scenario that failed before:If this session succeeds, the fix works. If it hits a new edge case (e.g., circular FK references), feed that session back into the Improve Playbook tab for another round.