| name | write-prd |
| description | Generar un PRD completo con problema, solución, historias de usuario y criterios de aceptación. Activar cuando el usuario quiera definir requisitos de producto, decidir que construir, crear un documento de requisitos, redactar un PRD o elaborar una especificacion funcional. |
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
-
Recopilar contexto inicial. Formular preguntas una a una (una por turno, esperar respuesta antes de la siguiente) sobre el problema que quiere resolver, el público objetivo y restricciones conocidas. Usar AskUserQuestion con opciones cuando la pregunta tenga respuestas predefinidas; texto directo cuando sea abierta. Si el usuario ya ha proporcionado información suficiente, saltar las preguntas cuya respuesta ya se tiene.
-
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.
-
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é.
-
Utilizar la plantilla base. Si existe templates/prd.md, usarla como punto de partida para mantener consistencia entre PRDs del proyecto.
-
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.
-
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.
Que NO hacer
- No confundir la solución propuesta con una especificación técnica detallada. El PRD describe el qué y el por qué, no el cómo a nivel de implementación.
- No escribir historias de usuario que describen implementación en vez de valor. "Como usuario, quiero que se use Redis para cachear" no es una historia de usuario; "Como usuario, quiero que la búsqueda responda en menos de 200ms" sí lo es.
- No dar el PRD por cerrado sin aprobación explícita del usuario. El PRD es un acuerdo entre partes; publicarlo sin validación anula su función como contrato.
