why

Descripción general de por qué usar why

El skill why es una herramienta centrada en el análisis de los Five Whys para convertir un síntoma en una cadena de causa raíz y, después, en una corrección que puedas aplicar. Si necesitas el why skill para un UX Audit, un problema de producto, un bug o una falla de proceso, te ayuda a separar qué pasó de por qué pasó.

Para qué sirve why

Usa why cuando la primera explicación probablemente sea demasiado superficial: “los usuarios se fueron”, “falló la compilación” o “el equipo no llegó a tiempo”. El skill está diseñado para mantener el análisis en movimiento hasta llegar a una causa sistémica, no solo a un síntoma visible.

Para quién encaja mejor

Esta guía de why es ideal para operadores, analistas, ingenieros y revisores de UX que quieren una ruta estructurada hacia la causa raíz sin tener que construir un marco desde cero. Encaja con personas que ya tienen un problema concreto y necesitan una forma disciplinada de interrogarlo.

Qué lo hace útil

Su valor principal es el ritmo y el enfoque: ofrece una forma de prompt repetible, una profundidad por defecto y un paso de validación para comprobar si la causa realmente explica el síntoma. Eso hace que la instalación de why valga la pena cuando el brainstorming genérico vuelve una y otra vez a la misma respuesta obvia.

Cómo usar el skill why

Instala y activa why

Instala el why skill en tu flujo de trabajo de skills y luego invócalo con un síntoma concreto, no con un tema vago. Un buen inicio sería: /why checkout conversion fell 18% after the redesign o /why CI failures spike on main branch.

Dale un planteamiento del problema, no una teoría

El skill funciona mejor cuando proporcionas un único problema observable, el contexto en el que aparece y cualquier restricción conocida. Entrada sólida: Mobile users abandon the signup form on step 2 after the new validation rules shipped; analyze root causes in the current UX flow. Entrada débil: Why is UX bad?

Lee primero los archivos fuente que importan

Empieza por SKILL.md para entender el flujo de análisis, y después revisa README.md, AGENTS.md, metadata.json y cualquier carpeta rules/, resources/, references/ o scripts/ si existen en tu entorno. En este repositorio, SKILL.md es la principal fuente de verdad, así que la ruta más rápida es leer antes los pasos y ejemplos del análisis y luego adaptarlos.

Ejecuta el análisis como una sesión de trabajo

Usa why como una cadena guiada: plantea el síntoma, responde cada “why” con evidencia y detente cuando la causa sea fundamental y comprobable. Si aparece más de una causa, ramifica en lugar de forzar una sola línea, y termina proponiendo cambios que eliminen la causa raíz en vez de maquillar el síntoma.

Preguntas frecuentes sobre el skill why

¿why es solo para depuración técnica?

No. El skill why funciona para UX Audit, operaciones, producto, soporte y problemas de procesos de equipo siempre que puedas describir un síntoma real. El requisito clave es que el problema se pueda rastrear a través de una relación de causa y efecto.

¿Necesito siempre cinco iteraciones?

No necesariamente. Cinco es la profundidad por defecto, pero la mejor regla es “detente cuando la explicación sea accionable y estable”. Si la cadena ya llegó a una verdadera causa raíz en tres pasos, forzar dos más suele añadir ruido.

¿En qué se diferencia why de un prompt normal?

Un prompt normal suele pedir ideas; why pide causalidad disciplinada. Es mejor cuando quieres un análisis de causa raíz, una acción correctiva o una revisión que pueda validarse hacia atrás, desde la causa hasta el síntoma.

¿Cuándo no debería usar why?

No lo uses para ideación abierta, estrategia amplia o problemas sin un síntoma observable. Si no puedes definir el problema con suficiente claridad como para probar una cadena causal, el why skill producirá conjeturas superficiales.

Cómo mejorar el skill why

Empieza por un síntoma más preciso

La calidad del resultado de why depende de la primera frase. Incluye qué se rompió, quién lo sintió, cuándo cambió y en qué entorno: After the new onboarding copy, first-time activation dropped on iOS only. Esto es mucho mejor que activation is down.

Añade evidencia, no conclusiones

Proporciona logs, citas de usuarios, pasos del funnel, capturas de pantalla, marcas de tiempo o marcadores de lanzamiento cuando los tengas. La evidencia ayuda a why a separar correlación de causalidad y evita que el análisis se conforme con la primera explicación plausible.

Prueba la cadena hacia atrás

Un buen resultado de why debería explicar el síntoma desde la causa raíz hacia arriba. Si la última causa no produce con claridad los pasos anteriores, refina la cadena o divídela en ramas antes de actuar.

Convierte los hallazgos en una única acción corregible

Los mejores resultados de why terminan con un cambio que puedas lanzar, documentar o medir. Enfoca el seguimiento en la causa que realmente puedes controlar y luego vuelve a ejecutar el skill después de la corrección para confirmar que el síntoma se mueve en la dirección esperada.