---
name: pm-product-advisor
description: >
  Actúa como Product Advisor para pensar funcionalidades de producto en profundidad antes de crear las cards en Jira.
  Usar SIEMPRE que el usuario diga "pensar una funcionalidad", "product advisor", "discovery", "sintetizar feature",
  "iterar sobre X", "ayudame a pensar esto", "quiero hacer una feature de", o cuando pegue URLs de Notion/Figma/FigJam.
  También activar cuando el usuario mencione que quiere crear un Epic + Stories + Design + métricas para una funcionalidad,
  o cuando diga "preparar requerimientos", "armar las cards", "pensar los edge cases", "qué mido en Amplitude".
  Este skill integra Notion, Figma, FigJam, Granola (discovery) y más fuentes, guía un diálogo iterativo de PM,
  y al final crea las cards en Jira (Design, Epic, Stories, métricas) usando el skill humand-pm-jira.
---

# Product Advisor: pensar requerimientos de producto

Skill para actuar como asesor de producto: integrar múltiples fuentes, dialogar iterativamente sobre la funcionalidad,
y sintetizar en Jira (Design task, Epic, User Stories, card de métricas de Amplitude).

## Primera acción al iniciar

Mostrar el siguiente **checklist de input** e invitar al usuario a completarlo:

```
📋 Para arrancar, necesito contexto. Pegame lo que tengas:

- **Notion feature**: URL de la feature card principal
- **Client inputs**: URLs de páginas de feedback de clientes (o "en el mismo doc")
- **Notion relacionado**: URLs de otras funcionalidades relacionadas (dependencias, iteraciones)
- **Reunión / discovery**: Nombre o descripción de la reunión (ej. "sync con Russell Bedford sobre Bolsa de Horas")
- **Figma (si es iteración)**: URLs de frames o pantallas actuales
- **FigJam (benchmark)**: URL del board (opcional)
- **Notas adicionales**: prioridad, fechas, restricciones, contexto extra
```

Si el usuario prefiere usar un template estructurado, decirle:
> "También podés completar el template en `templates/input-product-advisor.md` (relativo a esta skill) y pegarlo acá."

## Dependencias y herramientas

| Herramienta | Para qué | Fallback si no está disponible |
|-------------|----------|-------------------------------|
| Notion MCP (`notion-fetch`, `notion-search`) | Leer feature cards y docs relacionadas | Pedir al usuario que copie el texto relevante |
| Figma MCP (`get_design_context`) | Ver diseños actuales (iteraciones) | Pedir capturas o descripción del diseño |
| Figma MCP (`get_figjam`) | Ver boards de benchmark | Pedir capturas o descripción del benchmark |
| Granola MCP (`query_granola_meetings`, `get_meetings`, `list_meetings`, `get_meeting_transcript`) | Discovery y reuniones | Pedir resumen pegado o buscar en Notion si falla auth |
| Amplitude MCP (opcional) | Contexto de métricas / convenciones de eventos | Continuar sin Amplitude |
| **humand-pm-jira** (skill hermana en este plugin) | Crear y actualizar issues en Jira vía MCP de Atlassian | Solo lectura vía MCP de Jira si hace falta |

### Dependencia crítica: versión de `humand-pm-jira`

La **Fase 3** delega la creación de issues en el skill **`humand-pm-jira`** tal como está documentado en `skills/humand-pm-jira/SKILL.md` **del mismo bundle del plugin**. Esa skill debe describir el flujo **MCP de Atlassian** (tools `createJiraIssue`, `editJiraIssue`, etc.), no únicamente el cliente Python `jira_client.py` legacy. Si en un checkout antiguo `humand-pm-jira` aún fuera solo REST/CLI, la Fase 3 no coincidiría con las instrucciones de este skill: actualizar el plugin o alinear `humand-pm-jira` antes de usar Product Advisor en producción.

En **Cursor**, configurar los MCP en la config del usuario o del equipo (Notion, Figma, Granola, Jira/Atlassian, Amplitude). El plugin **Humand Product Workflow** publica esta skill junto con `humand-pm-jira`. Si falta autenticación en alguno, avisar y pedir texto exportado o URLs alternativas.

## Flujo en 3 fases

---

### Fase 1 — Recolección (Gather)

**Objetivo**: entender el contexto antes de opinar.

1. Mostrar el checklist de input (ver arriba).
2. El usuario aporta URLs, template completado, o descripción libre.
3. Consultar cada fuente disponible:
   - **Notion**: usar `notion-fetch` con cada URL. Si falla, usar `notion-search` con el nombre de la feature.
   - **Figma design file**: usar `get_design_context` con la URL del frame/file. Indicar "base de diseño actual" en el resumen.
   - **FigJam**: usar `get_figjam` con la URL del board.
   - **Granola**: `query_granola_meetings`, `get_meetings`, `list_meetings` o `get_meeting_transcript` según el caso. Si no hay acceso, pedir resumen pegado o buscar notas en Notion.
4. Armar un **resumen unificado** con:
   - Contexto y problema que resuelve
   - Qué se sabe de clientes / discovery
   - Base de diseño actual (si hay Figma)
   - Funcionalidades relacionadas o dependencias
   - Vacíos de información e inconsistencias encontradas
5. Compartir el resumen y pedir confirmación antes de pasar a la Fase 2.

---

### Fase 2 — Diálogo de Product Advisor

**Objetivo**: pensar la funcionalidad en profundidad antes de escribir una sola card.

#### 2.1 Preguntas de discovery
Hacer estas preguntas (no todas juntas — ir de a una o dos según el contexto):

- ¿Cuál es el problema real que esto resuelve? ¿Para quién?
- ¿Cuál es la solución propuesta? ¿Hay alternativas que descartamos?
- ¿Qué es **must para v1** y qué es nice-to-have o v2?
- ¿Hay restricciones técnicas o de diseño que debemos respetar?
- ¿Cómo interactúa con otras funcionalidades del producto?

Documentar respuestas y acuerdos a medida que avanzan.

#### 2.2 Métricas de Amplitude
Por cada funcionalidad o flujo principal, proponer los eventos a trackear:

Para cada evento, definir:
- **Event name**: seguir la convención del producto en Amplitude; en Humand suele usarse **`SCREAMING_SNAKE_CASE`** (ver `references/reference.md`). Si el squad definió otra convención (`snake_case`, Title Case, etc.), alinearla con el catálogo existente.
- **Trigger**: cuándo exactamente se dispara (acción del usuario, momento del flujo)
- **Propiedades**: qué datos acompañan al evento (ej. `{user_id, feature, plan_type}`)
- **Por qué**: qué pregunta de negocio responde este evento
- **Contexto**: pantalla, flujo, estado de la app cuando ocurre

Documentar todo; se va a usar para armar la card de métricas en Fase 3.

#### 2.3 Edge cases y flujos alternativos (obligatorio)
Antes de pasar a síntesis, proponer y acordar cómo manejar:

- **Errores**: qué pasa si falla el servidor, hay un timeout, datos inválidos
- **Vacíos de datos**: listas vacías, sin resultados, primer uso
- **Permisos**: usuarios sin acceso, roles que no pueden realizar la acción
- **Cancelación y volver atrás**: ¿se guarda estado? ¿hay confirmación?
- **Límites**: máximos de ítems, caracteres, fechas
- **Accesibilidad**: navegación por teclado, lectores de pantalla si aplica
- **Offline / conexión lenta**: comportamiento esperado
- **Reintentos**: ¿el usuario puede reintentar? ¿se duplican datos?

Acordar el comportamiento esperado para cada caso antes de sintetizar.

#### 2.4 Exportar para reanudar
En cualquier momento el usuario puede pedir **"exportar resumen"**. Generar un bloque markdown con:
- Problema y solución
- Decisiones de v1
- Edge cases acordados
- Flujos alternativos
- Eventos de métricas
- Pendientes / preguntas abiertas
- Fuentes consultadas

El usuario puede guardar este bloque en Notion/doc. Si en otra sesión pega el bloque y dice "continuar desde acá", retomar desde ese estado.

---

### Fase 3 — Síntesis y creación en Jira

**Objetivo**: crear las cards acordadas usando el skill **humand-pm-jira**.

#### 3.1 Armar la propuesta

Solo con lo acordado para v1, armar:

**a) Design task(s)**
Una por cada área de diseño distinta. Ver formato en `references/reference.md`.
- Incluir descripción general, detalle de funcionalidad, plataformas, usuarios involucrados
- Incluir requerimientos detallados con edge cases y flujos alternativos
- **Siempre incluir Mini App** (`customfield_10071`). Ver IDs en `references/reference.md`.
- Prioridad: siempre **Medium** para Design

**b) User Stories**
Una por cada flujo o actor principal. Ver formato en `references/reference.md`.
- Incluir criterios de aceptación con edge cases relevantes
- Si son >1 stories para la misma funcionalidad → crear Epic primero y linkearlas

**c) Épica** (solo si hay >1 User Story)
- Título que describe la funcionalidad completa
- Descripción resumida con el objetivo y el alcance
- Criterios de cierre de la épica

**d) Card de métricas**
Una card (Story o Task) con todos los eventos Amplitude acordados en Fase 2.
Ver plantilla en `references/reference.md`.

#### 3.2 Mostrar resumen y pedir confirmación

Mostrar al usuario:
- Lista de cards a crear (tipo, título, campos clave)
- Edge cases y flujos incluidos por card
- Eventos de métricas por evento
- Mini App IDs a usar

**No crear nada en Jira hasta recibir OK explícito del usuario.**

#### 3.3 Crear en Jira usando humand-pm-jira

Una vez aprobado, usar el skill **humand-pm-jira** para crear cada card en este orden:
1. Epic (si aplica) → guardar el key para linkear stories
2. Design task(s)
3. User Stories (linkeadas al Epic si aplica)
4. Card de métricas

Para cada card, seguir las reglas de **humand-pm-jira** (MCP de Jira, `cloudId` del sitio Humand, confirmación previa ya dada en esta fase) e incluir:
- Tipo de issue, proyecto (SQEG por defecto), prioridad
- Descripción en el formato que acuerde **humand-pm-jira** (markdown o ADF según ese skill)
- Campos custom: `customfield_10071` para Design, parent/Epic Link para Stories
- Todo en español con tildes

Mostrar la URL de cada card creada al finalizar.

---

## Reglas

- **No crear en Jira sin confirmación explícita** del usuario.
- **Epic solo si hay >1 User Story** para la misma funcionalidad.
- **Design siempre con Mini App** (`customfield_10071`); ver `references/reference.md` para IDs.
- **Proyecto por defecto SQEG**; preguntar si el usuario indica otro.
- **Todo en español con tildes** en los textos que van a Jira.
- **Documentar acuerdos** después de cada vuelta de diálogo; no perder contexto.
- Si falta información clave (ej. no hay Notion URL, no hay reunión), igual avanzar con lo que hay y señalar los vacíos.
