Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Valida uma análise antes de compartilhar — metodologia, precisão e verificações de viés. Use quando revisar uma análise antes de uma apresentação para stakeholders, verificar cálculos e lógica de agregação, conferir se os resultados de uma query SQL parecem corretos, ou avaliar se as conclusões são de fato suportadas pelos dados. Sempre rodar esta skill antes de compartilhar análises baseadas em Stripe, Omie, Licensing ou Evo CRM.
.claude/skills/evolution-foundation-data-validate/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-08 | ✗→✓ | ▲ Improved | 222% | 0% |
| case-10 | ✗→✓ | ▲ Improved | 198% | 0% |
| case-11 | ✗→✓ | ▲ Improved | 223% | 0% |
| case-12 | ✗→✓ | ▲ Improved | 384% | 0% |
| case-17 | ✗→✓ | ▲ Improved | 216% | 0% |
Revisar uma análise quanto à precisão, metodologia e possíveis vieses antes de compartilhar com stakeholders. Gera uma avaliação de confiança e sugestões de melhoria.
/data-validate <análise para revisar>A análise pode ser:
Examinar:
Percorrer o checklist abaixo — qualidade dos dados, cálculo, razoabilidade e verificações de apresentação.
Revisar sistematicamente contra o catálogo detalhado de armadilhas abaixo (join explosivo, viés de sobrevivência, comparação de período incompleto, denominador variável, média de médias, desalinhamento de fuso horário, viés de seleção).
Onde possível, fazer spot-checks:
Aplicar as técnicas de verificação de sanidade de resultados abaixo.
Se a análise inclui gráficos:
Revisar se:
Fornecer sugestões específicas e acionáveis:
Classificar a análise em uma escala de 3 níveis:
Pronta para compartilhar — A análise é metodologicamente sólida, cálculos verificados, ressalvas anotadas. Sugestões menores de melhoria mas nada bloqueando.
Compartilhar com ressalvas anotadas — A análise é majoritariamente correta mas tem limitações ou premissas específicas que devem ser comunicadas aos stakeholders. Listar as ressalvas obrigatórias.
Precisa de revisão — Encontrou erros específicos, problemas metodológicos, ou análises faltantes que devem ser abordados antes de compartilhar. Listar as mudanças necessárias com ordem de prioridade.
## Relatório de Validação
### Avaliação Geral: [Pronta para compartilhar | Compartilhar com ressalvas | Precisa de revisão]
### Revisão de Metodologia
[Achados sobre abordagem, seleção de dados, definições]
### Problemas Encontrados
1. [Severidade: Alta/Média/Baixa] [Descrição do problema e impacto]
2. ...
### Spot-Checks de Cálculo
- [Métrica]: [Verificado / Discrepância encontrada]
- ...
### Revisão de Visualização
[Quaisquer problemas com gráficos ou apresentação visual]
### Melhorias Sugeridas
1. [Melhoria e por que é importante]
2. ...
### Ressalvas Obrigatórias para Stakeholders
- [Ressalva que deve ser comunicada]
- ...Percorrer este checklist antes de compartilhar qualquer análise com stakeholders.
O problema: Um join many-to-many silenciosamente multiplica linhas, inflando contagens e somas.
Como detectar:
sql-- Verificar contagem de linhas antes e depois do join SELECT COUNT(*) FROM instancias; -- 1.000 SELECT COUNT(*) FROM instancias i JOIN eventos e ON i.id = e.instancia_id; -- 3.500 (problemático!) -- Sempre usar DISTINCT para contar entidades através de joins SELECT COUNT(DISTINCT i.id) FROM instancias i JOIN eventos e ON i.id = e.instancia_id;
Como prevenir:
COUNT(DISTINCT id_entidade) em vez de COUNT(*) ao contar entidades através de joinsO problema: Analisar apenas entidades que existem hoje, ignorando as que foram deletadas, fizeram churn, ou falharam.
Exemplos para o workspace:
Como prevenir: Perguntar "Quem NÃO está neste dataset?" antes de tirar conclusões.
O problema: Comparar um período parcial com um período completo.
Exemplos:
Como prevenir: Sempre filtrar para períodos completos, ou comparar mesmo-dia-do-mês / mesmo-número-de-dias.
O problema: O denominador muda entre períodos, tornando as taxas incomparáveis.
Exemplos:
Como prevenir: Usar definições consistentes em todos os períodos comparados. Anotar quaisquer mudanças de definição.
O problema: Fazer a média de médias pré-calculadas dá resultados errados quando os tamanhos dos grupos diferem.
Exemplo:
Como prevenir: Sempre agregar a partir dos dados brutos. Nunca fazer média de médias pré-agregadas.
O problema: Diferentes fontes de dados usam fusos horários diferentes, causando desalinhamento.
Exemplos no workspace:
Como prevenir: Padronizar todos os timestamps em um único fuso horário (UTC para armazenamento, BRT para exibição). Documentar o fuso horário usado.
sql-- Converter UTC para BRT corretamente no PostgreSQL SELECT criado_em AT TIME ZONE 'UTC' AT TIME ZONE 'America/Sao_Paulo' AS criado_em_brt FROM eventos; -- Truncar por dia em BRT DATE_TRUNC('day', criado_em AT TIME ZONE 'UTC' AT TIME ZONE 'America/Sao_Paulo')
O problema: Os segmentos são definidos pelo outcome que está sendo medido, criando lógica circular.
Exemplos:
Como prevenir: Definir segmentos com base em características pré-tratamento, não em outcomes.
Para qualquer número-chave na análise, verificar se passa no "teste do olfato":
| Tipo de Métrica | Verificação de Sanidade | |---|---| | Contagens de instâncias | Corresponde às figuras conhecidas de MAU do Licensing? | | MRR | Está na ordem de grandeza certa vs. ARR conhecido do Stripe? | | Taxas de conversão | Está entre 0% e 100%? Corresponde às figuras do dashboard? | | Taxas de crescimento | 50%+ MoM de crescimento é realista, ou há um problema de dados? | | Médias | A média é razoável dado o que se sabe sobre a distribuição? | | Percentuais | Os percentuais dos segmentos somam a ~100%? |
Toda análise não trivial deve incluir:
markdown## Análise: [Título] ### Pergunta [A pergunta específica sendo respondida] ### Fontes de Dados - Fonte: Stripe via `int-stripe` (referente a [data]) - Fonte: Licensing via `int-licensing` (referente a [data]) - Tabela: [schema.nome_da_tabela] (referente a [data]) ### Definições - [Métrica A]: [Exatamente como é calculada] - [Segmento X]: [Exatamente como a participação é determinada] - [Período de tempo]: [Data de início] a [data de fim], BRT (UTC-3) ### Metodologia 1. [Passo 1 da abordagem de análise] 2. [Passo 2] 3. [Passo 3] ### Premissas e Limitações - [Premissa 1 e por que é razoável] - [Limitação 1 e seu impacto potencial nas conclusões] ### Principais Achados 1. [Achado 1 com evidências de suporte] 2. [Achado 2 com evidências de suporte] ### Queries SQL [Todas as queries usadas, com comentários] ### Ressalvas - [Coisas que o leitor deve saber antes de agir com base nisso]
Para qualquer código (SQL, Python) que possa ser reutilizado:
python""" Análise: Retenção Mensal por Cohort Autor: Davidson Gomes Data: 2026-04-09 Fonte de Dados: tabela de eventos, tabela de clientes Última Validação: 2026-04-09 — resultados corresponderam ao dashboard dentro de 2% Propósito: Calcular cohorts de retenção mensal de usuários com base na data da primeira assinatura. Premissas: - "Ativo" significa pelo menos um evento no mês - Exclui contas de teste/internas (tipo_usuario != 'interno') - Usa timestamps UTC, exibição em BRT Saída: Matriz de retenção de cohort com linhas cohort_mes e colunas meses_desde_assinatura. Valores são taxas de retenção (0-100%). """
/data-validate Revisar esta análise trimestral de MRR antes de eu enviar para o conselho: [análise]/data-validate Verificar minha análise de churn — estou comparando taxas do Q4 com Q3 mas o Q4 tem uma janela de medição mais curta/data-validate Aqui está uma query SQL e seus resultados para nosso funil de conversão do Evo CRM. A lógica parece certa? [query + resultados]/data-validate antes de qualquer apresentação ou decisão de alto impacto| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-01 | fail→fail | 21,354 | 7,523 | -65% | 1 | 1 | 0% | 3,444 | 5,642 | +64% | 0 | 0 | — |
case-02 | fail→fail | 25,460 | 19,984 | -22% | 1 | 1 | 0% | 4,287 | 7,557 | +76% | 0 | 0 | — |
case-03 | pass→pass | 12,623 | 13,325 | +6% | 1 | 1 | 0% | 2,233 | 6,875 | +208% | 0 | 0 | — |
case-04 | pass→pass | 11,870 | 13,416 | +13% | 1 | 1 | 0% | 1,932 | 6,710 | +247% | 0 | 0 | — |
case-05 | pass→pass | 11,410 | 12,670 | +11% | 1 | 1 | 0% | 1,934 | 6,567 | +240% | 0 | 0 | — |
case-06 | pass→pass | 11,015 | 8,570 | -22% | 1 | 1 | 0% | 2,183 | 5,959 | +173% | 0 | 0 | — |
case-07 | pass→pass | 8,720 | 9,652 | +11% | 1 | 1 | 0% | 1,464 | 6,124 | +318% | 0 | 0 | — |
case-08 | fail→pass | 12,318 | 10,273 | -17% | 1 | 1 | 0% | 1,889 | 6,080 | +222% | 0 | 0 | — |
case-09 | pass→pass | 11,488 | 8,673 | -25% | 1 | 1 | 0% | 1,916 | 5,864 | +206% | 0 | 0 | — |
case-10 | fail→pass | 11,474 | 6,513 | -43% | 1 | 1 | 0% | 1,811 | 5,396 | +198% | 0 | 0 | — |
case-11 | fail→pass | 13,830 | 13,993 | +1% | 1 | 1 | 0% | 2,054 | 6,629 | +223% | 0 | 0 | — |
case-12 | fail→pass | 6,032 | 3,474 | -42% | 1 | 1 | 0% | 1,023 | 4,955 | +384% | 0 | 0 | — |
case-13 | fail→fail | 6,685 | 5,121 | -23% | 1 | 1 | 0% | 1,203 | 5,231 | +335% | 0 | 0 | — |
case-14 | pass→pass | 5,884 | 5,789 | -2% | 1 | 1 | 0% | 1,052 | 5,283 | +402% | 0 | 0 | — |
case-15 | pass→pass | 20,936 | 17,700 | -15% | 1 | 1 | 0% | 3,911 | 7,620 | +95% | 0 | 0 | — |
case-16 | fail→fail | 15,390 | 15,263 | -1% | 1 | 1 | 0% | 2,662 | 6,950 | +161% | 0 | 0 | — |
case-17 | fail→pass | 10,463 | 7,962 | -24% | 1 | 1 | 0% | 1,808 | 5,711 | +216% | 0 | 0 | — |
case-18 | pass→pass | 9,513 | 7,333 | -23% | 1 | 1 | 0% | 1,667 | 5,657 | +239% | 0 | 0 | — |
case-19 | pass→pass | 9,110 | 7,996 | -12% | 1 | 1 | 0% | 1,599 | 5,727 | +258% | 0 | 0 | — |
case-20 | pass→pass | 18,002 | 18,433 | +2% | 1 | 1 | 0% | 3,156 | 7,570 | +140% | 0 | 0 | — |
case-21 | pass→pass | 13,963 | 17,035 | +22% | 1 | 1 | 0% | 2,713 | 7,596 | +180% | 0 | 0 | — |
case-22 | pass→pass | 13,856 | 7,564 | -45% | 1 | 1 | 0% | 2,210 | 5,504 | +149% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 22 cases were attempted. The headline lift of +23 percentage points is the difference between those two pass rates over the 22 comparable cases. 1 case got worse with the skill loaded, and it is included in that figure.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.