Habilidade Preventiva Monte Carlo

Esta habilidade traz o contexto de observabilidade de dados do Monte Carlo diretamente para o seu editor. Ao modificar um modelo dbt ou um pipeline SQL, use-a para exibir a saúde da tabela, linhagem, alertas ativos e para gerar monitores como código sem sair do Claude Code.

Arquivos de referência ficam ao lado deste arquivo de habilidade. Use a ferramenta Read (não recursos MCP) para acessá-los:

• Instruções passo a passo do fluxo de trabalho completo: references/workflows.md (relativo a este arquivo)
• Detalhes dos parâmetros do MCP: references/parameters.md (relativo a este arquivo)
• Solução de problemas: references/TROUBLESHOOTING.md (relativo a este arquivo)

Quando ativar esta habilidade

Não espere ser perguntado. Execute o fluxo de trabalho apropriado automaticamente sempre que o usuário:

• Referenciar ou abrir um arquivo .sql ou modelo dbt (arquivos em models/) → execute o Fluxo de Trabalho 1

• Mencionar um nome de tabela, dataset ou nome de modelo dbt de passagem → execute o Fluxo de Trabalho 1

• Descrever uma alteração planejada em um modelo (nova coluna, atualização de join, alteração de filtro, refatoração) → PARE — execute o Fluxo de Trabalho 4 antes de escrever qualquer código

• Adicionar uma nova coluna, métrica ou expressão de saída a um modelo existente → execute o Fluxo de Trabalho 4 primeiro, e então SEMPRE ofereça o Fluxo de Trabalho 2 independentemente do nível de risco — não pule a oferta de monitoramento

• Perguntar sobre qualidade de dados, frescor, contagem de linhas ou anomalias → execute o Fluxo de Trabalho 1

• Quiser triar ou responder a um alerta de qualidade de dados → execute o Fluxo de Trabalho 3

Apresente os resultados como contexto que o engenheiro precisa antes de prosseguir — não como resposta a uma pergunta.

Quando NÃO ativar esta habilidade

Não invoque ferramentas do Monte Carlo para:

• Arquivos de seed (arquivos no diretório seeds/)
• Arquivos de análise (arquivos no diretório analyses/)
• Scripts SQL pontuais ou ad-hoc que não fazem parte de um projeto dbt
• Arquivos de configuração (dbt_project.yml, profiles.yml, packages.yml)
• Arquivos de teste, a menos que o usuário esteja especificamente perguntando sobre qualidade de dados

Se tiver dúvidas se um arquivo é um modelo dbt, verifique as referências Jinja {{ ref() }} ou {{ source() }} — se ausentes, não ative.

Macros e snapshots — controle edições, pule contexto automático

Arquivos de macro (macros/) e arquivos de snapshot (snapshots/) não são modelos, portanto, não busque automaticamente o contexto do Monte Carlo (Fluxo de Trabalho 1) quando eles forem abertos. No entanto, macros são inseridas em todos os modelos que as chamam no momento da compilação — uma alteração de macro de uma linha pode alterar silenciosamente dezenas de modelos. Snapshots controlam o rastreamento histórico e são igualmente sensíveis.

O hook pré-edição controla esses arquivos. Se o hook disparar para uma macro ou snapshot, identifique quais modelos são afetados e execute a avaliação de impacto da alteração (Fluxo de Trabalho 4) para esses modelos antes de prosseguir com a edição.

REQUERIDO: Avaliação de impacto da alteração antes de qualquer edição SQL

Antes de editar ou escrever qualquer SQL para um modelo dbt ou pipeline, você DEVE executar o Fluxo de Trabalho 4.

Isso se aplica sempre que o usuário expressar a intenção de modificar um modelo — incluindo frases como:

• "Quero adicionar uma coluna…"
• "Deixe-me adicionar / Estou adicionando…"
• "Gostaria de alterar / atualizar / renomear…"
• "Você pode adicionar / modificar / refatorar…"
• "Vamos adicionar…" / "Adicionar uma coluna <column>"
• Qualquer outra descrição de uma alteração planejada de esquema ou lógica
• "Excluir / filtrar / remover [registros/clientes/linhas]…"
• "Ajustar / aumentar / diminuir [limite/parâmetro/valor]…"
• "Corrigir / corrigir bug / patch [problema/bug]…"
• "Reverter / restaurar / desfazer [alteração/comportamento anterior]…"
• "Desabilitar / habilitar [recurso/lógica/flag]…"
• "Limpar / remover [referências/colunas/código]…"
• "Implementar [backend/recurso] para…"
• "Criar [modelos/modelos dbt] para…" (ao modificar tabelas referenciadas existentes)
• "Aumentar / diminuir / alterar [max_tokens/limite/constante de data/parâmetro numérico]…"
• Qualquer alteração em um valor codificado, constante ou parâmetro de configuração dentro do SQL
• "Remover / excluir / deletar [coluna/campo/tabela]"
• "Renomear [coluna/campo] para [novo nome]"
• "Adicionar [coluna]" (forma imperativa curta, por exemplo, "adicionar uma coluna created_at")
• Qualquer comando imperativo de verbo único direcionado a uma coluna, tabela ou modelo (por exemplo, "remover X", "renomear Y", "adicionar Z", "remover W")

Alterações de parâmetros (valores de limite, constantes de data, limites numéricos) parecem seguras, mas alteram silenciosamente a saída do modelo. Trate-as da mesma forma que as alterações de lógica para fins de avaliação de impacto.

Não escreva ou edite nenhum SQL até que a avaliação de impacto da alteração (Fluxo de Trabalho 4) tenha sido apresentada ao usuário. A avaliação deve vir primeiro — não depois da edição, não em paralelo.

Controle pré-edição — verifique antes de modificar qualquer arquivo

…