wwas

Descripción general de la skill wwas

wwas es una skill de prompts para redactar ítems de backlog de producto en formato Why-What-Acceptance. Usa la skill wwas cuando necesites un ítem de backlog que sea más que un resumen de funcionalidad: debe explicar la razón de negocio, describir el cambio con claridad y definir criterios de aceptación que un equipo pueda probar.

Encaja especialmente bien para product managers, analistas, diseñadores y agentes de IA que necesitan convertir ideas de producto poco definidas en elementos listos para sprint. El verdadero trabajo a resolver es conservar el contexto estratégico sin perder independencia, valor ni capacidad de negociación en los ítems. La skill wwas es especialmente útil cuando quieres un lenguaje de backlog coherente en todo un equipo, sin sobreespecificar la implementación.

Para qué es mejor wwas

wwas funciona mejor para desgloses de funcionalidades, entrega incremental de producto y planificación transversal, cuando el equipo necesita claridad sobre la intención antes de escribir código. Ayuda cuando la entrada original es desordenada, como una nota de reunión, un enlace de diseño o una petición a medio formar.

En qué se diferencia wwas

Frente a un prompt genérico, wwas empuja al modelo a separar Why, What y Acceptance Criteria. Eso reduce los tickets ambiguos, mantiene el alcance más acotado y hace que el resultado sea más fácil de revisar en planificación. También favorece ítems que se puedan priorizar, estimar y probar sin convertir el prompt en una especificación completa.

Cuándo merece la pena instalar wwas

Instala wwas si tu flujo depende de una buena higiene del backlog, de una calidad repetible en los tickets o de la planificación de requisitos asistida por IA. Es más valiosa cuando tu equipo necesita un formato compartido para Requirements Planning, en lugar de generar texto puntual sin estructura.

Cómo usar la skill wwas

Instala wwas y encuentra los archivos fuente

Instala la skill con npx skills add phuryn/pm-skills --skill wwas. Luego lee primero SKILL.md, porque ahí están el flujo de trabajo, la plantilla del ítem y la lista de argumentos que determinan cómo se usa wwas. Si vas a adaptarla a tu propio proceso, revisa también el directorio general de skills para detectar convenciones en skills cercanas.

Qué debes aportar a wwas

wwas funciona mejor cuando le das cuatro entradas: el nombre del producto o sistema, la funcionalidad o capacidad, un enlace de diseño si existe, y supuestos o contexto estratégico. Entradas débiles como “mejorar onboarding” suelen producir criterios de aceptación vagos. Las entradas sólidas suenan más bien así: nombre del producto, usuario objetivo, resultado deseado y restricciones.

Cómo escribir un prompt mejor

Un buen prompt para wwas nombra la unidad de entrega y la razón de negocio. Por ejemplo: “Crea un ítem WWA para el flujo de pago móvil. Why: reducir el abandono del carrito en usuarios recurrentes. What: añadir selección de método de pago guardado, usando el enlace de Figma. Assumptions: solo usuarios autenticados, sin nuevo proveedor de pagos.” Eso le da a la skill suficiente contexto para producir un ítem de backlog útil, no solo un párrafo pulido.

Flujo práctico para Requirements Planning

Usa wwas después de tener una dirección de funcionalidad, pero antes de entrar en la especificación detallada. Primero, reúne la petición aproximada y cualquier nota de diseño o discovery. Segundo, ejecuta wwas para obtener la estructura Why-What-Acceptance. Tercero, revisa que sea independiente, que el alcance sea razonable y que se pueda probar. Si el ítem sigue agrupando varios resultados, divídelo y vuelve a ejecutar wwas sobre la unidad más pequeña.

Preguntas frecuentes sobre la skill wwas

¿wwas es solo para product managers?

No. La skill wwas es útil para cualquiera que necesite resultados de Requirements Planning sobre los que ingeniería y diseño puedan actuar: PMs, analistas de negocio, fundadores, responsables de delivery y flujos de documentación asistidos por IA.

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

Un prompt normal puede generar una nota descriptiva de funcionalidad. wwas es más específico: obliga a una estructura de ítem de backlog con contexto estratégico, una descripción breve de la funcionalidad y criterios de aceptación observables. Eso normalmente significa menos limpieza después de generar el texto.

¿Necesito archivos de diseño para usar wwas?

No, pero los enlaces de diseño mejoran la precisión. Si no tienes diseño, aporta suficiente contexto para definir la necesidad del usuario, el límite del trabajo y el comportamiento esperado. Sin eso, la skill puede producir ítems demasiado amplios.

¿Cuándo no debería usar wwas?

No uses wwas cuando necesites diseño técnico detallado, tareas de implementación o notas de lanzamiento. Es una herramienta de Requirements Planning, no un generador de especificaciones de código.

Cómo mejorar la skill wwas

Dale una formulación del problema más precisa

Los mejores resultados de wwas empiezan con un problema concreto de usuario o de negocio. Sustituye “añadir filtros” por “ayudar a los agentes de soporte a encontrar casos abiertos más rápido en una cola de alto volumen”. Ese tipo de entrada mejora la sección Why y evita criterios de aceptación genéricos.

Define pronto los límites

wwas funciona mejor cuando indicas qué queda fuera de alcance. Si la funcionalidad es solo para móvil, solo interna o limitada a un segmento de usuarios, dilo desde el principio. Así evitas que los criterios de aceptación se desvíen hacia casos irrelevantes.

Comprueba independencia y capacidad de prueba

El fallo más común al usar wwas es acabar con un ítem de backlog que mezcla varias entregas. Si el resultado agrupa UI, analítica y permisos en un solo ítem, separa esas partes y vuelve a ejecutar la skill. También conviene verificar que los criterios de aceptación describan resultados observables, no detalles de implementación.

Itera a partir del primer borrador

Trata la primera salida de wwas como un borrador de planificación. Si el Why es débil, devuelve el objetivo de negocio. Si el What es demasiado amplio, acota la funcionalidad. Si los criterios de aceptación son demasiado vagos, añade rol, disparador y resultado esperado. Ese ciclo de iteración suele mejorar más el artefacto final de Requirements Planning que añadir más contexto inicial.