Generar PRD (Product Requirements Document)

Resumen

Este skill genera un documento de requisitos de producto estructurado y completo. El PRD sirve como fuente de verdad compartida entre producto, desarrollo y diseño, asegurando que todo el equipo entiende el problema que se resuelve, la solución propuesta y los criterios con los que se medirá el éxito.

El proceso es iterativo: se genera un borrador que el usuario debe revisar y aprobar antes de considerarlo definitivo. Esto evita que se construya sobre suposiciones no validadas.

Proceso

1. Recopilar contexto inicial. Preguntar al usuario por el problema que quiere resolver, el público objetivo y cualquier restricción conocida. Si el usuario ya ha proporcionado esta información, no repetir preguntas.

2. Investigar el contexto del proyecto. Revisar documentación existente en docs/, issues abiertos, y cualquier PRD anterior para evitar duplicidades y mantener coherencia con decisiones previas.

3. Redactar el PRD con la siguiente estructura:

   • Título y versión: nombre descriptivo del documento y fecha de creación.
   • Problema: descripción clara del dolor o necesidad del usuario. Incluir datos si están disponibles.
   • Contexto: por qué este problema importa ahora, qué se ha intentado antes, qué limitaciones existen.
   • Solución propuesta: descripción de alto nivel de lo que se va a construir. Sin entrar en detalles de implementación, centrarse en el valor para el usuario.
   • Historias de usuario: formato "Como [rol], quiero [acción], para [beneficio]". Cada historia debe ser independiente y verificable.
   • Criterios de aceptación: en formato Given/When/Then para cada historia. Deben ser lo bastante concretos como para convertirse en tests automatizados.
   • Métricas de éxito: KPIs medibles que indiquen si la solución funciona. Evitar métricas vanidosas.
   • Riesgos y mitigaciones: qué puede salir mal y cómo se aborda cada riesgo.
   • Fuera de alcance: qué NO se va a hacer en esta iteración y por qué.

4. Utilizar la plantilla base. Si existe templates/prd.md, usarla como punto de partida para mantener consistencia entre PRDs del proyecto.

5. Presentar el borrador al usuario para revisión. HARD-GATE: el PRD no se da por finalizado hasta que el usuario lo aprueba explícitamente. Iterar sobre el feedback recibido.

6. Guardar el PRD aprobado en docs/prd/ con un nombre descriptivo que incluya la fecha o un identificador del proyecto (por ejemplo, docs/prd/2024-autenticacion-social.md).

Criterios de éxito

• El PRD cubre todas las secciones obligatorias: problema, contexto, solución, historias de usuario, criterios de aceptación, métricas y riesgos.
• Las historias de usuario son independientes, verificables y priorizadas.
• Los criterios de aceptación siguen el formato Given/When/Then y cubren escenarios positivos y negativos.
• El usuario ha revisado y aprobado el documento explícitamente.
• El fichero se ha guardado en docs/prd/ siguiendo la convención de nombres del proyecto.