Não quer configurar isso manualmente? Cole um link para esta página em uma sessão do Devin e peça que ele configure tudo para você. Uma skill de repositório é um arquivo Markdown que você faz commit em `.agents/skills//` em qualquer um dos seus repositórios. Devin vê todas as skills em todos os repositórios conectados — você pode acioná-las manualmente ou o Devin pode decidir acioná-las automaticamente quando detectar uma situação relevante. Esta skill informa ao Devin exatamente como revisar migrações de banco de dados antes de abrir ou atualizar um PR — identificando erros que a revisão de código normalmente não encontra. Faça commit de `.agents/skills/migration-checklist/migration-checklist.md` no seu repositório: ```markdown theme={null} # Checklist de Segurança de Migração ## Description Revise cada migração de banco de dados no PR atual em busca de problemas de segurança antes de abrir ou atualizar o pull request. ## When to use Invoque esta skill sempre que o diff do PR incluir arquivos novos ou modificados em `db/migrate/` (Rails), `migrations/` (Django), ou `prisma/migrations/` (Prisma). ## Checklist ### 1. Detect destructive operations Verifique cada arquivo de migração em busca de: - `DROP TABLE` or `drop_table` - `DROP COLUMN`, `remove_column`, or column removal - `TRUNCATE` - Data-type changes that lose precision (e.g. `text` → `varchar(50)`) Se algum for encontrado, adicione um comentário no PR sinalizando a operação e confirmando se existe uma etapa de backup de dados na migração. ### 2. Verify foreign-key indexes Para cada `add_reference`, `add_foreign_key`, ou nova coluna terminada em `_id`, confirme se existe um índice correspondente. Caso contrário, adicione um à migração antes de fazer o commit. ### 3. Check rollback safety - Execute `bin/rails db:migrate:rollback STEP=` (onde n = número de novas migrações) no banco de dados de teste. - Se o rollback falhar, adicione um método `down` ou bloco reversível e tente novamente. - Relate quaisquer migrações irreversíveis na descrição do PR. ### 4. Validate schema file is up-to-date Após executar as migrações, compare `db/schema.rb` (ou `structure.sql`) com a versão no PR. Se diferirem, regenere o arquivo de schema e inclua-o no commit. ### 5. Run model tests Execute `bin/rails test test/models/` para identificar validações ou associações quebradas por alterações no schema. Todos os testes devem passar antes de o PR ser aberto. ``` Depois que esse arquivo for incluído em um commit, Devin o verá como uma capacidade disponível. Sempre que uma sessão envolver arquivos de migração neste repositório, Devin poderá acionar a checklist automaticamente — ou você pode invocá-la manualmente a qualquer momento. Quando o Devin trabalha em uma tarefa que adiciona ou modifica um arquivo de migração, ele lê o diff, identifica a skill de checklist de migração e segue o checklist antes de abrir o PR. Veja como isso funciona na prática: 1. **Examina o diff** — Devin vê um novo arquivo em `db/migrate/` e ativa a skill de checklist de migração 2. **Sinaliza uma operação destrutiva** — A migração remove a coluna `legacy_email`. Devin adiciona um comentário no PR: > `remove_column :users, :legacy_email` é uma operação destrutiva. > Verificado: a migração inclui uma etapa de backup de dados, copiando os valores para > `user_archives` antes da remoção. 3. **Adiciona um índice ausente** — A migração adiciona `account_id` à tabela `invoices`, mas não tem índice. Devin acrescenta `add_index :invoices, :account_id` ao arquivo de migração 4. **Executa o rollback** — Devin executa `bin/rails db:migrate:rollback STEP=1` no banco de dados de teste. A execução é bem-sucedida 5. **Regenera o schema** — Devin executa `bin/rails db:schema:dump`, detecta um diff em `db/schema.rb` e inclui o arquivo atualizado no commit 6. **Executa os testes de models** — Todos os testes de models passam. Devin abre o PR com um resumo de cada verificação A descrição do PR inclui um checklist mostrando o que passou e o que o Devin corrigiu, para que revisores possam focar na lógica de negócios em vez da mecânica da migração. A checklist acima é voltada para Rails, mas a mesma estrutura funciona para qualquer ORM. Peça ao Devin para reescrever a skill para o seu stack: ```txt Adapt for Django theme={null} Reescreva a skill de checklist de migração para o nosso projeto Django: - Analise arquivos em `apps/*/migrations/` em busca de operações destrutivas como RemoveField, DeleteModel e AlterField com perda de dados - Após executar `python manage.py migrate`, verifique se `python manage.py showmigrations` não mostra migrações pendentes - Execute `python manage.py test --tag=models` para validar alterações de esquema - Verifique se as migrações têm um `reverse_code` ou um `RunSQL` de reversão para segurança em caso de rollback ``` ```txt Adapt for Prisma theme={null} Reescreva a skill de checklist de migração para o nosso projeto Prisma: - Analise arquivos em `prisma/migrations/` em busca de DROP TABLE, DROP COLUMN e ALTER COLUMN que reduza a largura de campos - Execute `npx prisma migrate deploy` contra o banco de dados de teste e confirme que a execução seja bem-sucedida - Execute `npx prisma migrate diff` para verificar se o schema.prisma corresponde ao estado das migrações aplicadas - Execute `npm test -- --grep "model"` para identificar relacionamentos quebrados ``` Cada incidente de migração revela uma lacuna não coberta pela checklist. Depois de cada um deles, adicione uma regra — é só um commit de uma linha no arquivo de skill. Aqui estão algumas adições comuns que as equipes fazem após incidentes reais: ```markdown theme={null} ### 6. Aplicar convenções de nomenclatura de migrations Rejeite migrations que não seguem o padrão `YYYYMMDDHHMMSS_verb_noun.rb` (ex.: `add_index_to_invoices`). Renomeie o arquivo se necessário. ### 7. Verificar locks de longa duração Sinalize qualquer `add_column` em tabelas com >1M de linhas que não use `disable_ddl_transaction!` (Postgres) ou `ALGORITHM=INPLACE` (MySQL). Tabelas grandes precisam de migrations sem bloqueio. ### 8. Exigir um teste de migration Certifique-se de que existe um arquivo de teste correspondente em `test/migrations/YYYYMMDDHHMMSS_migration_name_test.rb`. Se estiver ausente, gere um teste esqueleto que execute a migration up e down. ``` Como o arquivo de skill fica no seu repositório, essas regras passam por code review — toda a sua equipe concorda com o que será verificado, e isso está sempre alinhado às suas ferramentas de migração.

{title}