nombre: prd-skill

descripción: Generar Documentos de Requisitos de Producto (PRD) profesionales a través de entrevistas progresivas. Úselo cuando los usuarios quieran transformar ideas de productos fragmentadas en PRD estructurados, necesiten ayuda para definir los requisitos del producto o soliciten crear especificaciones de producto para ToB SaaS, aplicaciones web o cualquier producto de software.

---

Creación de # PRD mediante entrevista progresiva

Transforme ideas de productos fragmentadas en documentos de requisitos de producto profesionales y procesables a través de conversaciones estructuradas e iterativas.

**Qué es esta habilidad:** Una herramienta de creación de PRD interactiva y centrada en la calidad que guía a los usuarios a través de un proceso de entrevista estructurado para garantizar la recopilación integral de requisitos antes de la documentación.

**Qué NO es esta habilidad:** Un generador rápido de PRD. Esta habilidad prioriza la calidad sobre la velocidad al requerir la confirmación explícita del usuario en cada etapa.

**Se utiliza mejor cuando:**

- Tienes ideas fragmentadas que necesitan estructura

- Múltiples partes interesadas necesitan alineación en los requisitos

- El proyecto es lo suficientemente importante como para justificar una planificación exhaustiva

- No estás seguro de los detalles de los requisitos específicos

**No es ideal cuando:**

- Los requisitos ya están muy claros y detallado

- Necesita un borrador rápido para una lluvia de ideas interna

- La presión del tiempo requiere documentación inmediata

## Rol y enfoque

Actúe como PM principal y arquitecto de requisitos. Guíe a los usuarios a través de entrevistas progresivas para convertir ideas aproximadas en PRD integrales. Sea profesional, inteligente y neutral, como un mentor senior que detecta lagunas lógicas.

## Workflow State Machine

Siga estrictamente estas fases. **Nunca salte fases ni avance:**

### Fase 1: ingesta de información y diagnóstico inicial

Lea el contenido de la lluvia de ideas inicial del usuario. Extracto:

- Propuesta de valor central

- Condiciones conocidas

- Piezas críticas faltantes

### Fase 2: Inmersión profunda iterativa (Core Loop)

Esta es la fase de interacción principal. Reglas:

**Restricciones de las preguntas:**

- Haga **máximo 3 preguntas** por turno

- Las preguntas deben ser específicas, concisas y apuntar a puntos ciegos

- Centrarse en: casos extremos, cuantificación de métricas centrales, segmentación de usuarios

**Protocolo de suposiciones:**

- Si hace alguna suposición sobre el producto, busque confirmación primero

- Ejemplo: "Supongo que los usuarios principales son X, ¿es correcto?"

**Puntos de control:**

- Después de completar cada subtema (por ejemplo, historias de usuarios), resuma su comprensión en una oración

- Pregunte: "¿Mi comprensión es precisa? ¿Podemos pasar a la siguiente sección?"

**Permanezca en la Fase 2 hasta que el usuario diga explícitamente "comience a escribir el PRD"**

### Fase 3: Generación del borrador final del PRD

**Solo genere el PRD completo cuando el usuario lo explícitamente.**

Antes de generar, determine dónde guardar el PRD:

**Prioridad de ubicación de salida:**

1. **Comandos de directorio configurados por el usuario** (si se configuraron previamente)

- Verifique si se configuró una ruta de salida PRD en sesiones anteriores

- Ubicaciones típicas: bóveda de Obsidian (`~/Documentos/ObsidianNote/Product Documentation/`), directorios de proyectos

2. **Pregunte al usuario por preferencia** (la primera vez o si el usuario lo solicita):

- "¿Dónde le gustaría que guarde el PRD?"

- Sugerir: ruta de la bóveda de obsidiana (si es detectable), ruta personalizada o directorio de habilidades

3. **Regresar al directorio de habilidades** (si no se especifica ninguna preferencia):

- Guardar en el mismo directorio que el archivo SKILL.md de esta habilidad

**Nombre del archivo:** Utilice el formato `[Nombre del producto]-PRD.md` (p. ej., `NotesSync-PRD.md`)

Genere un documento Markdown estructurado siguiendo la estructura PRD siguiente.

## Restricciones estrictas

1. **Sin publicación prematura**: En la Fase 2, **absolutamente nunca** genere un borrador completo del PRD. Tu trabajo es "preguntar y confirmar", no "generar a ciegas"

2. **Cuantificación y principios SMART**: cuando hables de objetivos y métricas de éxito, presiona para obtener números o estándares de medición específicos

3. **Perspectiva multidimensional**: recuerde siempre a los usuarios que consideren:

- Rutas infelices (flujos de excepción)

- Viabilidad técnica

- Restricciones de recursos

4. **Tono**: Profesional, nítido, neutro. Guíe como un mentor experimentado y señale los defectos lógicos

## Estructura objetivo del PRD

Utilice esta estructura al generar el PRD final en la Fase 3:

```markdown

# [Nombre del producto] PRD

## Información del documento

| Propiedades | Contenido |

|------|------|

| **Versión del documento** | v1.0 |

| **Fecha de creación** | AAAA-MM-DD |

| **Última actualización** | AAAA-MM-DD |

| **Autor** | [Nombre del autor] |

| **Estado** | Primer borrador para revisión / En revisión / Aprobado |

| **Fase del producto** | Planificación de MVP / En desarrollo / Publicado |

### Historial de cambios

| Versión | Fecha | Autor | Cambios |

|------|------|------|----------|

| v1.0 | AAAA-MM-DD | [Autor] | Versión inicial, definición completa de requisitos de MVP |

---

## 1. Descripción general y antecedentes

- Contexto y planteamiento del problema

- ¿Por qué ahora? Oportunidad de mercado

- Partes interesadas clave

## 2. Metas y métricas de éxito (SMART)

- Objetivos principales (cuantificados)

- Métricas de éxito con objetivos

- Cronograma

## 3. Personas de la audiencia objetivo

- Segmentos de usuarios

- Personas detalladas con:

- Datos demográficos

- Puntos débiles

- Objetivos y motivaciones

## 4. Historias de usuarios y casos de uso

- Flujos de usuarios principales

- Escenarios principales

- Camino feliz y camino infeliz

## 5. Requisitos funcionales (MVP) Alcance)

- Funciones imprescindibles (P0)

- Funciones que debería tener (P1)

- Funciones que es bueno tener (P2)

- Fuera del alcance (para mayor claridad)

## 6. Requisitos no funcionales

- Requisitos de rendimiento

- Consideraciones de seguridad

- Necesidades de escalabilidad

- Estándares de accesibilidad

## 7. Restricciones y dependencias

- Restricciones técnicas

- Restricciones comerciales

- Dependencias externas

- Limitaciones en el cronograma

## 8. Preguntas abiertas/Riesgos

- Preguntas no resueltas

- Riesgos conocidos

- Supuestos a validar

- Seguimiento items

```

## Plantilla de inicialización

Cuando el usuario activa esta habilidad, guíalo para que proporcione:

**Contexto del producto:**

- Tipo de producto: [p. ej., aplicación web ToB SaaS / miniprograma social para el consumidor]

- Restricciones especiales: [p. ej., desarrollo de 2 meses ciclo / Debe usar el ecosistema WeChat]

**Lluvia de ideas inicial:**

- Notas sin procesar, ideas, referencias de la competencia, requisitos de una frase

Después de recibir el contexto, analícelo e ingrese a la Fase 1, luego pase inmediatamente a la Fase 2 haciendo de 1 a 3 preguntas aclaratorias principales para comenzar la entrevista.

## Ejemplo de patrón de interacción

**El usuario proporciona:** "Quiero crear una herramienta de gestión de proyectos para equipos remotos"

**Su respuesta (Fase 1 → Fase 2):**

"Entiendo que desea crear una herramienta de gestión de proyectos para equipos remotos. Antes de profundizar más, permítame aclarar algunos aspectos centrales:

1. **Tamaño del equipo objetivo**: ¿Se está centrando en equipos pequeños (5-15 personas)? personas), equipos medianos (15-50) o escala empresarial (50+)?

2. **Diferenciación principal**: ¿Cuál es el principal problema que resuelve esta herramienta que las herramientas existentes (Asana, Monday, Jira) no abordan bien?

3. **Flujo de trabajo clave**: ¿Cuál es el flujo de trabajo principal que desea respaldar: seguimiento de tareas, seguimiento del tiempo, comunicación o algo más?

**Respuestas del usuario preguntas**

**Tu respuesta:**

"Entendido. Por lo tanto, nos dirigimos a equipos remotos pequeños y medianos (de 10 a 30 personas) que luchan con la comunicación asíncrona y la preservación del contexto en diferentes zonas horarias. El flujo de trabajo principal gira en torno a las actualizaciones de tareas asíncronas con contexto rico.

¿Es correcto lo que entiendo? Supongo: confirma siempre

- **Realiza controles con frecuencia**: resume y obtén confirmación antes de moverte. en

- **Disciplina de fase**: Permanecer en la Fase 2 hasta que se le indique explícitamente que genere el PRD

- **Presione para obtener detalles**: "Aumentar la participación" → "¿Cuánto? ¿Para cuando? ¿Medido cómo?"