why

Visão geral de por que usar o skill why

O skill why é uma ferramenta focada de análise dos 5 Porquês para transformar um sintoma em uma cadeia de causa raiz e, depois, em uma correção que você pode aplicar. Se você precisa do why skill para uma UX Audit, problema de produto, bug ou falha de processo, ele ajuda a separar o que aconteceu do porquê aconteceu.

Para que o why serve

Use why quando a primeira explicação provavelmente é superficial demais: “os usuários abandonaram”, “o build falhou” ou “o time perdeu o prazo”. O skill foi pensado para manter a análise em movimento até você chegar a uma causa sistêmica, e não só a um sintoma visível.

Para quem esse skill é mais indicado

Este guia do why é ideal para operadores, analistas, engenheiros e revisores de UX que querem um caminho estruturado de causa raiz sem precisar criar um framework do zero. Ele atende bem quem já tem um problema específico e precisa de uma forma disciplinada de investigá-lo.

O que torna o why útil

O principal valor está no ritmo e no foco: ele oferece um formato de prompt repetível, uma profundidade padrão e uma etapa de validação para verificar se a causa realmente explica o sintoma. Isso torna a instalação do why valiosa quando o brainstorming genérico fica girando em torno da mesma resposta óbvia.

Como usar o skill why

Instale e acione o why

Instale o why skill no seu fluxo de trabalho de skills e, depois, invoque-o com um sintoma concreto, não com um tema vago. Um bom começo seria: /why checkout conversion fell 18% after the redesign ou /why CI failures spike on main branch.

Dê uma declaração de problema, não uma teoria

O skill funciona melhor quando você informa um único problema observável, o contexto em que ele aparece e quaisquer restrições conhecidas. Um bom input: Mobile users abandon the signup form on step 2 after the new validation rules shipped; analyze root causes in the current UX flow. Um input fraco: Why is UX bad?

Leia primeiro os arquivos de origem que realmente importam

Comece por SKILL.md para entender o fluxo da análise e, depois, inspecione README.md, AGENTS.md, metadata.json e quaisquer pastas rules/, resources/, references/ ou scripts/, se elas existirem no seu ambiente. Neste repositório, SKILL.md é a principal fonte de verdade, então o caminho mais rápido é ler primeiro as etapas da análise e os exemplos antes de adaptá-los.

Execute a análise como uma sessão de trabalho

Use why como uma cadeia guiada: declare o sintoma, responda cada “por quê” com evidências e pare quando a causa for fundamental e testável. Se aparecer mais de uma causa, crie ramificações em vez de forçar uma única linha, e termine propondo mudanças que eliminem a causa raiz em vez de apenas mascarar o sintoma.

Perguntas frequentes sobre o skill why

O why é só para depuração técnica?

Não. O skill why funciona para UX Audit, operações, produto, suporte e problemas de processo de equipe, desde que você consiga descrever um sintoma real. O requisito principal é que exista um problema que possa ser rastreado por uma relação de causa e efeito.

Preciso sempre de cinco iterações?

Não necessariamente. Cinco é a profundidade padrão, mas a regra melhor é “pare quando a explicação ficar acionável e estável”. Se a cadeia já chegou a uma causa raiz de verdade em três passos, forçar mais dois normalmente só adiciona ruído.

Em que o why é diferente de um prompt comum?

Um prompt comum geralmente pede ideias; o why pede causalidade disciplinada. Ele é melhor quando você quer uma análise de causa raiz, uma ação corretiva ou uma revisão que possa ser validada de trás para frente, da causa ao sintoma.

Quando não devo usar o why?

Não use para ideação aberta, estratégia ampla ou problemas sem sintoma observável. Se você não consegue definir o problema com clareza suficiente para testar uma cadeia de causas, o skill why vai gerar palpites superficiais.

Como melhorar o skill why

Comece com um sintoma mais preciso

A qualidade da saída do why depende da primeira frase. Inclua o que quebrou, quem sentiu o impacto, quando mudou e qual é o ambiente: After the new onboarding copy, first-time activation dropped on iOS only. Isso é muito melhor do que activation is down.

Adicione evidências, não conclusões

Traga logs, falas de usuários, etapas do funil, capturas de tela, timestamps ou marcos de release quando tiver isso. As evidências ajudam o why a separar correlação de causa e evitam que a análise pare na primeira explicação plausível.

Teste a cadeia de trás para frente

Um bom resultado de why deve explicar o sintoma a partir da causa raiz, de baixo para cima. Se a última causa não produzir claramente as etapas anteriores, refine a cadeia ou separe-a em ramificações antes de agir.

Transforme os achados em uma ação que dê para corrigir

Os melhores resultados do why terminam com uma mudança que você pode publicar, documentar ou medir. Foque o próximo passo na causa que você realmente consegue controlar e, depois, rode o skill novamente após a correção para confirmar que o sintoma se moveu na direção esperada.