Generación de PRD

Genera Documentos de Requisitos de Producto (PRD) estructurados a partir de ideas de funciones.

Qué Hace Este Skill

Transforma solicitudes de funciones informales en PRD completos con historias de usuario, criterios de aceptación, requisitos funcionales, métricas de éxito y orientación sobre cumplimiento normativo. El resultado está listo para que los equipos de ingeniería lo implementen y las partes interesadas lo revisen.

Cuándo Usarlo

Activa este skill cuando:

El usuario quiera documentar una nueva función o idea de producto
Aparezcan frases como "escribe un PRD", "crea requisitos", "documenta esta función"
Se esté preparando una revisión de producto, alineación de partes interesadas o traspaso a ingeniería
El usuario mencione historias de usuario, criterios de aceptación o métricas de éxito
Sea necesario formalizar una idea vaga en documentación estructurada

Detección de Escenario (CRÍTICO - Primer Paso)

Antes de generar cualquier contenido del PRD, DEBES identificar el escenario.

Usa AskUserQuestion para determinar qué escenario aplica:

P: Selecciona el escenario de generación del PRD

Opción	Descripción
Actualización iterativa	Optimización basada en funciones existentes
Nueva función	Añadir un nuevo módulo a un producto existente
Producto nuevo de 0 a 1	Planificar un producto completamente nuevo desde cero

Recopilación de Contexto por Escenario

Una vez identificado el escenario, recopila el contexto requerido:

Escenario	Información Requerida	Método de Recopilación
Actualización iterativa	1. Descripción de la función actual2. Estado de la UI (captura/HTML/enlace)3. Objetivo de la iteración	Entrada del usuario + AskUserQuestion para la opción de estado de la UI
Nueva función	1. Arquitectura general del producto2. Guía de diseño (biblioteca de componentes/patrones de interacción)3. Ubicación de entrada	Leer de `docs/product/` o entrada del usuario
Producto nuevo de 0 a 1	1. Antecedentes del producto y usuarios objetivo2. Restricciones de recursos3. Productos de referencia	Entrada del usuario + análisis competitivo

Recopilación del Estado de la UI para Actualizaciones Iterativas: Cuando el usuario seleccione "Actualización iterativa", pregunta cómo quiere proporcionar el estado actual de la UI:

Captura - El usuario proporciona una captura, usa mcp__zai-mcp-server__ui_to_artifact o mcp__4_5v_mcp__analyze_image
Archivo HTML - El usuario proporciona una ruta HTML local, usa la herramienta Read para analizar la estructura DOM
Enlace en línea - El usuario proporciona una URL, usa mcp__web_reader__webReader (sin necesidad de inicio de sesión)

Paso 0.5: Análisis de Brechas de Información y Plan del PRD (CRÍTICO — PUERTA ESTRICTA)

PUERTA ESTRICTA: No continúes con la Verificación de Referencias de la Industria ni con la generación del PRD hasta que este paso esté completo y el usuario haya aprobado el plan.

Protocolo de Omisión Explícita (cuando el usuario rechaza explícitamente la interacción): Si el usuario prohíbe explícitamente las preguntas (por ejemplo, "no preguntes más, escribe directamente"), PUEDES omitir las puertas interactivas, pero entonces DEBES comenzar la salida con un bloque de declaración de supuestos que enumere cada suposición realizada (escenario, capítulos seleccionados/excluidos, producto objetivo, valores predeterminados clave), para que el usuario pueda corregirlos. La declaración de supuestos también sirve como lista de integridad de la Disciplina de Evidencia: la información no confirmada se marca como [pendiente de confirmación], las afirmaciones sin evidencia se marcan como [no verificado] (ver la Disciplina de Evidencia más abajo). Nunca rellenes valores predeterminados sin confirmación. Nunca omitas en silencio.

Después de la detección del escenario y la recopilación de contexto:

Análisis de Brechas: Compara la información proporcionada por el usuario con los requisitos de contexto para este escenario. Enumera cada campo requerido faltante. También verifica docs/product/ para datos de percepción existentes (market-analysis.json, competitive-analysis, user-research.json, positioning.md).

Una Pregunta a la Vez: Para cada elemento faltante, pregunta al usuario usando AskUserQuestion con opciones de opción múltiple. NO agrupes múltiples preguntas en un solo mensaje.

Elemento Faltante	Ejemplo de Pregunta
Captura de UI	"¿Cómo quieres proporcionar el estado de la interfaz de la función actual?" → A. Ya tengo una captura B. Tengo un archivo HTML C. Tengo un enlace en línea D. No tengo nada, saltar por ahora
Lista de competidores	"¿Qué competidores necesitas analizar?" → selección múltiple + "Otros"
Usuarios objetivo	"¿Quiénes son los usuarios objetivo?" → A. Perfil ya definido B. Yo dicto y tú organizas C. Necesito hacer investigación de usuarios primero
Producto de referencia	"¿Tienes algún producto de referencia?" → A. Sí, yo lo explico B. Tú buscas referencias del sector C. No necesito referencias

Manejo de Recursos Faltantes: Si el usuario dice "Proporcionaré capturas más tarde" o "saltar por ahora", registra qué elementos están pendientes y menciónalos en el plan del PRD como [pendiente de completar].

Generar el Plan del PRD: Prepara (pero no muestres todavía) la estructura del plan del PRD. La tabla siguiente muestra la plantilla con las selecciones predeterminadas:

### Capítulos previstos del PRD a generar
| Capítulo | Resumen del Contenido | Seleccionado | Estado de Dependencia |
|:-----|:---------|:-----|:---------|
| Capítulo 0 Análisis de Referencias del Sector | Se investigarán X productos de referencia | ✅ | Completado / [pendiente de completar] |
| Capítulo 1 Resumen del Proyecto | Se desarrolla a partir de la descripción del usuario | ✅ | Completado |
| Capítulo 2 Análisis de Negocio | Usuarios objetivo X, puntos débiles Y | ✅ | Completado / [pendiente de completar] |
| Capítulo 3 Requisitos Funcionales | [Lista de funciones clave] | ✅ | Completado |
| Capítulo 4 Requisitos No Funcionales | Requisitos estándar del sector | ✅ | Generación automática |
| Capítulo 5 Flujo de Experiencia de Usuario | Derivado de las funciones | ✅ | Necesita UI complementaria |
| Capítulo 6 Riesgos del Proyecto | Basado en la complejidad funcional | ✅ | Generación automática |
| Capítulo 7 Recomendaciones de Cumplimiento | Basado en el tipo de datos | ❌ | Generación automática |
| Capítulo 8 Diseño de Prototipos | [Enlace al prototipo] | ❌ | - |
| Capítulo 9 Métricas de Éxito | Derivado de los objetivos | ❌ | Generación automática |

### Lista de Exclusión (no se generará el siguiente contenido)
- Solución técnica / Diseño de arquitectura — El PRD es un documento de requisitos de producto, no incluye detalles de implementación técnica
- Definiciones de interfaces API / Especificaciones de endpoints — El equipo de desarrollo las redactará por separado en la solución técnica
- Diseño de estructura de tablas de base de datos — No está dentro del alcance de los requisitos de producto

Nota: La tabla anterior utiliza las selecciones predeterminadas. Los valores reales de la columna «Seleccionado» se completarán en el Paso 4.5 según las respuestas del usuario a la selección de capítulos. NO presentes esta tabla al usuario todavía.

4.5. Selección de Capítulos (PUERTA ESTRICTA — Antes de presentar el Plan del PRD):

Presenta la selección de capítulos al usuario mediante AskUserQuestion con multiSelect. Debido al límite de 4 opciones, divide la selección en 3 preguntas secuenciales. Construye las listas capítulos_seleccionados y capítulos_excluidos a partir de las respuestas, y actualiza la columna «Seleccionado» de la tabla del Plan del PRD en consecuencia.

Pregunta 1 — Capítulos Principales (Capítulos 0-3):

Opción	Predeterminado	Descripción
Capítulo 0 Análisis de Referencias del Sector	✅ Seleccionado	Investiga productos de referencia y mejores prácticas
Capítulo 1 Resumen del Proyecto	✅ Seleccionado	Antecedentes, objetivos y alcance del proyecto
Capítulo 2 Análisis de Negocio	✅ Seleccionado	Usuarios objetivo, puntos débiles, análisis de mercado
Capítulo 3 Requisitos Funcionales	✅ Seleccionado	Lista de funciones, historias de usuario, requisitos detallados

Pregunta 2 — Capítulos Extendidos (Capítulos 4-7):

Opción	Predeterminado	Descripción
Capítulo 4 Requisitos No Funcionales	✅ Seleccionado	Rendimiento, seguridad, disponibilidad, compatibilidad
Capítulo 5 Flujo de Experiencia de Usuario	✅ Seleccionado	Recorrido del usuario, diagramas de flujo de páginas
Capítulo 6 Riesgos del Proyecto	✅ Seleccionado	Riesgos del proyecto y estrategias de mitigación
Capítulo 7 Recomendaciones de Cumplimiento	⬜ No seleccionado	Directrices de cumplimiento y categorías de riesgo

Pregunta 3 — Capítulos Opcionales (Capítulos 8-9):

Opción	Predeterminado	Descripción
Capítulo 8 Diseño de Prototipos	⬜ No seleccionado	Enlaces a prototipos y notas de diseño
Capítulo 9 Métricas de Éxito	⬜ No seleccionado	Métricas de estrella del norte, proceso y resultados

Exclusiones Permanentes (no están en la lista de selección, NUNCA se generan):

Solución técnica / Diseño de arquitectura — El PRD no incluye detalles de implementación técnica
Definiciones de interfaces API — La documentación de la interfaz la redacta el equipo de desarrollo por separado
Diseño de estructura de tablas de base de datos — No está dentro del alcance de los requisitos de producto

Después de recopilar las selecciones: Actualiza la columna «Seleccionado» de la tabla del Plan del PRD para reflejar las elecciones del usuario (✅ para seleccionado, ❌ para excluido).

Aprobación del Usuario: Usa AskUserQuestion para presentar el Plan del PRD (con las selecciones de capítulos) y obtener la aprobación explícita:

Opción	Descripción
Confirmar, generar el PRD con este plan de capítulos	Ir al Paso 1 Referencias del Sector y al Paso 2 Generación del PRD
Ajustar la selección de capítulos	Volver a seleccionar los capítulos a generar
Necesito ajustar el plan	Modificar el Plan del PRD y volver a confirmar
Tengo más información que añadir	Volver al Paso 0.5 para añadir información y regenerar el plan
Primero añadir datos de percepción	Llamar a market-research / competitive-analysis

Antipatrón: "Tengo suficiente información, déjame generar" — prohibido. Incluso con brechas mínimas, presenta el plan y obtén la aprobación.

Guía de Manejo de Imágenes en Entorno TUI

En un entorno de terminal (TUI), el usuario puede proporcionar imágenes de las siguientes maneras:

Método 1: Ruta de Archivo Local (La más simple)

Proporciona directamente la ruta local de la imagen, usa la herramienta Read para leerla:

# Ejemplo de conversación del usuario
"Analiza esta captura de UI: /Users/fh/Desktop/screenshot.png"
"Interfaz actual: ~/Screenshots/ui-2025-03-12.png"
"Imagen de referencia: ./docs/product/images/reference.png"

Formatos de ruta admitidos:

Ruta absoluta: /Users/fh/Desktop/screenshot.png
Abreviatura de directorio personal: ~/Screenshots/ui.png
Ruta relativa: ./images/ui.png

Formatos de imagen admitidos: PNG, JPG, JPEG, WebP, GIF

Método 2: URL de Imagen en Línea

El usuario sube la imagen a un alojamiento de imágenes/almacenamiento en la nube y proporciona la URL:

# Ejemplo de conversación del usuario
"Captura de UI: https://i.imgur.com/xyz.png"
"Imagen de referencia: https://s3.aws.com/bucket/screenshot.png"

Usa la herramienta mcp__4_5v_mcp__analyze_image o mcp__zai-mcp-server__ui_to_artifact para leer la imagen remota.

Alojamientos de imágenes recomendados:

imgur.com (gratuito, sin necesidad de registro)
GitHub (como archivo adjunto de issue)
Almacenamiento en la nube (AWS S3, Alibaba Cloud OSS)

Método 3: Comando de Captura de Terminal

Guía al usuario para usar herramientas de captura de terminal para generar capturas rápidamente:

macOS:

# Capturar área seleccionada (interactivo)
screencapture -i ~/screenshot.png

# Capturar toda la ventana
screencapture -w ~/screenshot.png

# Capturar toda la pantalla
screencapture ~/screenshot.png

Linux:

# ImageMagick (requiere instalación: sudo apt install imagemagick)
import ~/screenshot.png

# gnome-screenshot (Ubuntu/GNOME)
gnome-screenshot -a -f ~/screenshot.png

#spectacle (KDE)
spectacle -r -o ~/screenshot.png

Método 4: Obtener directamente del Portapapeles (macOS)

# Instalar la herramienta pngpaste
brew install pngpaste

# Guardar la imagen del portapapeles como archivo
pngpaste ~/screenshot.png

Flujo de Procesamiento

Cuando el usuario proporciona una imagen:

Ruta local → Usar la herramienta Read para leer directamente
URL remota → Usar mcp__4_5v_mcp__analyze_image o mcp__zai-mcp-server__ui_to_artifact
Analizar el contenido de la imagen → Extraer estructura de UI, diseño, elementos interactivos
Generar el PRD → Generar el documento de requisitos basado en los resultados del análisis de la imagen

Verificación de Referencias del Sector

Después de la detección del escenario, la recopilación de contexto y la aclaración de la información:

Referencias proporcionadas por el usuario (prioridad): Productos de referencia especificados por el usuario
Búsqueda complementaria del agente: Búsqueda automática de mejores prácticas del sector basada en palabras clave del escenario
Extraer mejores prácticas: 3-5 patrones de interacción/diseños de funciones de referencia
Citar en el PRD: Hacer referencia a las soluciones de referencia con la justificación de su adopción/diferenciación

Mapeo de Palabras Clave de Búsqueda:

Escenario	Palabras Clave de Búsqueda
Actualización iterativa	"{nombre de la función} mejores prácticas", "diseño de {nombre de la función} del sector"
Nueva función	"Solución de {tipo de producto} {nombre del módulo}", "{función} en productos similares"
Producto nuevo de 0 a 1	"Marco de producto {industria}", "Mapa de producto {ámbito}"

Cómo Funciona

El proceso de generación garantiza PRD completos y procesables:

Detección de Escenario - Usar AskUserQuestion para identificar iteración/nueva función/nuevo producto
Recopilación de Contexto - Recopilar la información requerida según el tipo de escenario
Análisis de Brechas de Información - Identificar información faltante, preguntar una cosa a la vez
Selección de Capítulos - El usuario selecciona qué capítulos del PRD generar (multiSelect)
Presentación del Plan del PRD - Presentar el plan con las selecciones de capítulos para la aprobación del usuario (PUERTA ESTRICTA)
Investigación de Referencias del Sector - Buscar y extraer mejores prácticas (especificadas por el usuario + búsqueda del agente)
Analizar requisitos - Estructurar la solicitud de función del usuario en componentes clave
Recopilar contexto - Leer análisis de mercado, perspectivas competitivas, investigación de usuarios
Montar secciones - Construir SOLO las secciones del PRD SELECCIONADAS con el detalle apropiado
Verificar integridad - Comprobar con los estándares de calidad (solo los capítulos seleccionados)
Autorevisión previa a la entrega - Ejecutar la comprobación final del PRD (autocomprobación de capítulos + desafío desde la perspectiva de las partes interesadas); corregir bloqueos o marcar como【pendiente de confirmación】
Generar salida - Escribir en docs/product/prd/{nombre-función}-{fecha}-v{versión}.md (incluyendo una sección final de «Registro de Revisión»)

Restricciones de Contenido (REGLAS ESTRICTAS):

Antes de generar el contenido del PRD, ten en cuenta:

Genera SOLO los capítulos seleccionados por el usuario. Omite los capítulos no seleccionados por completo.
NUNCA generes los siguientes tipos de contenido, independientemente de la entrada del usuario:
- Arquitectura técnica / detalles de implementación
- Definiciones de endpoints de API o especificaciones
- Esquema de base de datos o diseños de tablas
Si la descripción de la función del usuario menciona detalles técnicos, resúmelos como requisitos funcionales SIN exponer los detalles de implementación.

Parámetros de Entrada

Parámetro	Tipo	Requerido	Descripción
`requirements`	string	Sí	Descripción de la función o historia de usuario a documentar
`target_audience`	string	No	Segmento de usuario objetivo o persona
`context_refs`	list	No	Archivos de contexto relacionados a los que hacer referencia

Disciplina de Evidencia (Disciplina de Evidencia)

Marcar información faltante como【pendiente de confirmación】：Cualquier información que no se pueda obtener de la entrada o el contexto, márcala como【pendiente de confirmación】, no inventes valores predeterminados.
Rastreo de evidencia【no verificado】：Las afirmaciones sobre necesidades del usuario/mercado deben ser seguidas de preguntas sobre la fuente de evidencia; las que no tengan evidencia se marcan como【no verificado】y se indica el método de verificación requerido.
Puerta de control de integridad：Antes de la entrega formal de la salida, primero genera una lista de integridad de la información (confirmado ✅ / pendiente de confirmación ⚠️ / no verificado ❓), y solo después de la confirmación del usuario se genera el cuerpo principal.

Relación con el Protocolo de Omisión Explícita (Paso 0.5): La disciplina de evidencia es una disciplina de salida (etiquetado de información y autocomprobación previa a la entrega), mientras que la Omisión Explícita es una disciplina de interacción (manejo degradado cuando el usuario rechaza explícitamente la interacción). Son complementarias y no entran en conflicto. En el escenario de Omisión Explícita, la lista de integridad no se exime; se combina con la «declaración de supuestos» para la salida, pero ya no se espera la confirmación del usuario; la información no confirmada en la declaración de supuestos también se etiqueta según las reglas de esta sección como【pendiente de confirmación】/【no verificado】.

Estructura de Salida

El PRD sigue esta estructura (alineada con la plantilla estándar de PRD). IMPORTANTE: Esta plantilla muestra todos los capítulos posibles. Genera SOLO los capítulos seleccionados por el usuario. Omite los capítulos no seleccionados por completo. No generes arquitectura técnica, especificaciones de API o diseños de base de datos bajo ninguna circunstancia.

# [Nombre de la Función] PRD

## Información Básica del Documento
- **Versión del documento**: v1.0
- **Fecha de creación**: YYYY-MM-DD
- **Última actualización**: YYYY-MM-DD
- **Estado del documento**: Borrador/Revisión/Aprobado
- **Creado por**: [nombre de usuario]
- **Revisado por**: [pendiente]

## Historial de Revisiones
| Versión | Fecha | Contenido de la Revisión | Revisor |
|:-----|:-----|:---------|:-------|
| v1.0 | YYYY-MM-DD | Versión inicial | [Creador] |

## 0. Análisis de Referencias del Sector
### 0.1 Productos de Referencia
| Producto | Función Clave | Adopción/Diferenciación |
|:-----|:---------|:-----------|
| [Competidor A] | XXX | Se adopta su patrón XXX, porque... |
| [Competidor B] | XXX | El punto de diferenciación es... |

### 0.2 Resumen de Mejores Prácticas
- **Patrón de interacción**: [Patrón de interacción estándar del sector adoptado]
- **Diferenciación principal**: [Características únicas de esta solución]

## 1. Resumen del Proyecto
### 1.1 Antecedentes del Proyecto
[Antecedentes del mercado, antecedentes competitivos, antecedentes de las necesidades del usuario]

### 1.2 Objetivos del Proyecto
#### 1.2.1 Objetivo Principal
- [Objetivo principal cuantificable]

#### 1.2.2 Objetivos Secundarios
- [Objetivos de apoyo]

### 1.3 Alcance del Proyecto
#### 1.3.1 Alcance Incluido
- [Contenido incluido en esta iteración/función]

#### 1.3.2 Alcance Excluido
- [Elementos explícitamente fuera del alcance]

## 2. Análisis de Negocio
### 2.1 Usuarios Objetivo
| Rol de Usuario | Descripción | Necesidad Principal |
|:---------|:-----|:---------|
| Usuario A | [De la investigación de usuarios] | XXX |
| Usuario B | [De la investigación de usuarios] | XXX |

### 2.2 Puntos Débiles del Usuario
| ID de Punto Débil | Descripción del Punto Débil | Nivel de Impacto |
|:-------|:---------|:---------|
| P-001 | XXX | Alto/Medio/Bajo |
| P-002 | XXX | Alto/Medio/Bajo |

### 2.3 Análisis de Mercado
[Tendencias del sector, panorama competitivo, oportunidades de mercado]

## 3. Requisitos Funcionales
### 3.1 Lista de Funciones Principales
| ID de Función | Nombre de la Función | Prioridad | Descripción |
|:-------|:---------|:-------|:-----|
| F-001 | XXX | P0/P1/P2 | XXX |
| F-002 | XXX | P0/P1/P2 | XXX |

### 3.2 Historias de Usuario
#### US-1: [Nombre de la Función]
**Como** [rol de usuario]
**Quiero** [descripción de la función]
**Para** [valor de negocio]

**Criterios de Aceptación**:
- Dado [condición previa]
- Cuando [acción realizada]
- Entonces [resultado esperado]

**Prioridad**: P0/P1/P2
**Estimación**: X Puntos de Historia

#### US-2: [Nombre de la Función]
...

### 3.3 Detalles de la Función
#### F-001: [Nombre de la Función]
**Descripción**: [Descripción detallada de la función]

**Flujo de Interacción**:
1. Paso uno
2. Paso dos
3. Paso tres

**Casos Límite**:
- Flujo normal: ...
- Caso excepcional: ...

## 4. Requisitos No Funcionales
### 4.1 Requisitos de Rendimiento
- Tiempo de respuesta de la página < XXXms
- Soporte para XXX usuarios concurrentes
### 4.2 Requisitos de Seguridad
- Cifrado de almacenamiento de datos
- Control de permisos de usuario
### 4.3 Requisitos de Disponibilidad
- Disponibilidad del sistema > 99.9%
### 4.4 Requisitos de Compatibilidad
- iOS 14+, Android 10+
- Compatibilidad con los principales navegadores

## 5. Flujo de Experiencia de Usuario
### 5.1 Recorrido del Usuario
[Descripción de la ruta clave del usuario]
1. El usuario entra → 2. Realiza la acción → 3. Logra el objetivo

### 5.2 Diagrama de Flujo de Páginas
[Descripción de las relaciones de navegación entre páginas]
- Página A → Página B → Página C

## 6. Riesgos del Proyecto y Mitigación
> Nota: Esta sección solo incluye riesgos de producto/negocio, no incluye riesgos de implementación técnica (los riesgos técnicos los evalúa el equipo de desarrollo en la solución técnica)
| ID de Riesgo | Descripción del Riesgo | Probabilidad | Impacto | Medida de Mitigación |
|:-------|:---------|:-----|:-----|:---------|
| R-001 | XXX | Alta/Media/Baja | Alta/Media/Baja | XXX |
| R-002 | XXX | Alta/Media/Baja | Alta/Media/Baja | XXX |

## 7. Recomendaciones de Cumplimiento

### 7.1 Resumen de Puntos Clave de Cumplimiento
[Resumen de los puntos clave de la revisión del experto en cumplimiento]

### 7.2 Advertencias de Riesgo
| Categoría de Riesgo | Descripción | Recomendación |
|:---------|:-----|:-----|
| Cumplimiento de Privacidad | [Manejo de los datos del usuario involucrados] | [Recomendación de cumplimiento] |
| Cumplimiento de Contenido | [Puntos clave de revisión de contenido involucrados] | [Recomendación de cumplimiento] |
| Seguridad de Datos | [Requisitos de almacenamiento y transmisión de datos] | [Recomendación de cumplimiento] |
| Cumplimiento de Terceros | [Cumplimiento de los servicios de terceros de los que se depende] | [Recomendación de cumplimiento] |

### 7.3 Anexo del Informe de Cumplimiento
- [ ] Se ha adjuntado el informe de análisis de cumplimiento (si lo hay, proporcionar la ruta)
- [ ] En espera de revisión de cumplimiento (si es necesario, programar una revisión del experto en cumplimiento)


…

[truncado para traducción]

kelegele/oh-my-pm

¿Qué es oh-my-pm?

Preguntar en tu IA favorita

Documentación