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. 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. Go to [app.devin.ai](https://app.devin.ai/?utm_source=docs\&utm_medium=use-case-gallery) 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. ```txt Improve the db-migration playbook theme={null} Our !db-migration playbook works for simple table changes but fails when sessions hit foreign key constraints. Sessions 1 and 2 succeeded on standalone tables, but sessions 3 and 4 crashed on FK errors. Analyze all 4. Figure out what the successful sessions did differently (they hit standalone tables with no incoming FKs). Then update the playbook to: 1. Query information_schema for FK dependencies before any DROP or ALTER 2. Generate ALTER TABLE ... DROP CONSTRAINT statements when FKs exist 3. Add a rollback step that re-creates dropped constraints if the migration fails partway through ``` 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 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." 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: ```txt Test the updated playbook theme={null} Use the !db-migration playbook to drop the legacy_account_id column from the users table. This column is referenced by orders.account_id and invoices.billing_account_id — the playbook should handle the FK dependencies automatically. ``` 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.

{title}