Transforma perguntas de negócio em consultas SQL explicadas, seguras por padrão e prontas para validação em Postgres, BigQuery, MySQL, Snowflake e SQL Server.
Antes → Depois · resultado real
O mesmo pedido, com e sem a skill.
Marketplace de moda rodando em Postgres: a diretoria quer 'o churn mensal de sellers' no Metabase até quinta. O banco não tem dicionário de dados e a última query parecida duplicou receita por causa de um join 1:N — o número errado chegou bonito no dashboard.
Quem manda · Analista de dados que herdou o banco sem documentação — e já foi queimada uma vez por um join.
Antes · pedido improvisado
“me escreve um SQL de churn mensal de sellers”
O que a IA devolve
SELECT * FROM sellers s JOIN payments p ON s.id = p.seller_id WHERE canceled = true GROUP BY month(s.canceled_at); -- Pronto! É só rodar em produção, essa query retorna o churn exato.
Por que é fraco · Mistura dialetos (month() não existe no Postgres), usa SELECT * com join 1:N que duplica pagamentos, inventa a coluna 'canceled' sem ver o schema e manda rodar em produção sem nenhuma validação — receita pra repetir o dashboard errado.
Depois · com a skill
O comando
Use Gerador de Consultas SQL para BI.
Dialeto: Postgres 15. Destino: Metabase.
Schema real: sellers(id, created_at), subscriptions(seller_id, started_at, canceled_at, status), payments(seller_id, paid_at, amount_cents).
Pergunta: churn mensal de sellers nos últimos 12 meses. Datas gravadas em UTC; relatório em America/Sao_Paulo.
Quero query read-only comentada, premissas explícitas, validações executáveis e notas de performance.
O que a IA devolve
Toca nos 4 pins
Premissas e dúvidas críticas (confirmar antes de quinta):
Churn aqui = % de sellers ativos no início do mês que cancelaram dentro do mês (contagem de sellers, não receita).
Seller com mais de uma assinatura: considero ativo se tiver AO MENOS uma assinatura vigente — validar essa regra com o dono da métrica.
Datas em UTC → convertidas para America/Sao_Paulo na agregação mensal.
Query (read-only, Postgres):
```sql
WITH meses AS (
SELECT generate_series(
date_trunc('month', (now() AT TIME ZONE 'America/Sao_Paulo') - interval '11 months'),
date_trunc('month', now() AT TIME ZONE 'America/Sao_Paulo'),
interval '1 month'
) AS mes
),
-- sellers com assinatura vigente no início de cada mês
ativos AS (
SELECT m.mes, s.seller_id
FROM meses m
JOIN subscriptions s
ON (s.started_at AT TIME ZONE 'America/Sao_Paulo') < m.mes
AND (s.canceled_at IS NULL
OR (s.canceled_at AT TIME ZONE 'America/Sao_Paulo') >= m.mes)
GROUP BY m.mes, s.seller_id -- 1 linha por seller: mata a duplicação do 1:N
),
-- cancelamentos dentro do mês
cancelados AS (
SELECT date_trunc('month', canceled_at AT TIME ZONE 'America/Sao_Paulo') AS mes,
seller_id
FROM subscriptions
WHERE canceled_at IS NOT NULL
GROUP BY 1, 2
)
SELECT a.mes,
COUNT(DISTINCT a.seller_id) AS sellers_ativos,
COUNT(DISTINCT c.seller_id) AS cancelamentos,
ROUND(100.0 * COUNT(DISTINCT c.seller_id)
/ NULLIF(COUNT(DISTINCT a.seller_id), 0), 2) AS churn_pct
FROM ativos a
LEFT JOIN cancelados c USING (mes, seller_id)
GROUP BY a.mes
ORDER BY a.mes;
```
Por que está montada assim: (o clássico join 1:N que já queimou esse dashboard uma vez). `payments` ficou de fora de propósito: churn por contagem não usa receita, e juntar pagamentos aqui duplicaria linhas.
Validações antes do Metabase:
`SELECT seller_id, COUNT() FROM subscriptions GROUP BY 1 HAVING COUNT() > 1;` → mede quantos sellers têm múltiplas assinaturas (se forem muitos, a regra de 'ativo' pesa no número).
Caçar dado sujo: `canceled_at` preenchido com `status` ainda ativo indica inconsistência de origem.
Amostra manual: seguir a linha do tempo de 3 sellers cancelados.
Performance: a janela de 12 meses limita o scan; se `subscriptions` for grande, índices em `(started_at)` e `(canceled_at)` ajudam. Sem `SELECT *` em lugar nenhum.
LGPD: . Ninguém precisa de dado pessoal pra ver churn.
Antes de virar dashboard executivo: a regra de churn (contagem × receita; mês de início × mês de cancelamento) precisa do OK do dono da métrica. Query é ponto de partida testável, não verdade fechada.
Por que ganha · Resolve o problema que já queimou o time: agrega antes do join pra não duplicar, declara a regra de churn como premissa a confirmar, converte timezone explicitamente e entrega 4 validações executáveis — o número chega na diretoria com lastro, não com fé.
O SELECT * que duplicava receita virou CTE comentada com timezone certo, 4 validações — e a pergunta que ninguém tinha feito: churn de contagem ou de MRR?
antes ~3h depurando join errado (e refazendo o número pra diretoria) → depois ~15min rodando as validações antes do Metabase
Consulta SQL somente leitura, comentada, explicada e acompanhada de checklist de validação.
Acelere consultas confiáveis para BI sem perder o controle sobre regras de negócio, validação e LGPD.
Problema: Equipes precisam responder perguntas de negócio rapidamente, mas queries mal definidas geram métricas erradas, duplicidade em joins, problemas de timezone e risco de exposição de dados pessoais.
Fluxo: Criar
Exemplo de pedido pronto (prévia)
Tenho Postgres com tabelas customers(id, created_at), subscriptions(customer_id, started_at, canceled_at, status) e payments(customer_id, paid_at, amount_cents). Gere uma query de churn mensal dos últimos 12 meses e explique como validar.
