--- name: mohitagw15856/meeting-notes source: https://app.decimal.ai/s/mohitagw15856-meeting-notes@4/SKILL.md source_sha256: f41a7d9920b8 --- # Skill de Notas de Reunión Esta skill estructura notas de reunión para maximizar su valor y asegurar el seguimiento. ## Inputs Requeridos Pregunta al usuario por estos datos si no los proporciona: - **Título de la reunión y fecha** - **Asistentes** (nombres y roles) - **Notas sin procesar o transcripción** (pega notas de discusión, una transcripción, o describe lo que se discutió) - **Tipo de reunión** (1:1 / planificación de sprint / revisión de producto / sincronización con stakeholders / otro) — determina qué plantilla usar ## Lee desde / Escribe en el Brain Si existe un [`professional-brain`](../professional-brain/SKILL.md) (`brain/`), aquí es donde las notas se convierten en memoria durable: - **Lee primero:** los archivos relevantes de `stakeholders/` (para llegar sabiendo las solicitudes y preocupaciones abiertas de cada asistente) y cualquier `decisions/` que la reunión revise. - **Escribe después:** añade cada **decisión** (con su justificación y un `reopen-when`) a `decisions/`, agrega nuevas **solicitudes/preocupaciones** al archivo `stakeholders/` correcto, e identifica cualquier nueva **suposición** en `hypotheses/`. Etiqueta cada hecho capturado con su provenance — la mayoría de afirmaciones de reunión son `[verbal]` hasta que se confirmen independientemente. Guarda las notas sin procesar en `source/`. ## Plantilla Estándar de Notas de Reunión ### Encabezado de la Reunión **Reunión**: [Título de la Reunión] **Fecha**: [Fecha] **Asistentes**: [Nombres/Roles] **Tomador de Notas**: [Nombre] **Duración**: [Duración real] ### Agenda - [ ] Tema 1 - [ ] Tema 2 - [ ] Tema 3 *(Marca los elementos a medida que se discutan)* ### Decisiones Tomadas Documentación clara de las decisiones: **Decisión**: [Qué se decidió] **Contexto**: [Por qué se tomó esta decisión] **Propietario**: [Quién es responsable de ejecutarla] **Plazo**: [Cuándo, si aplica] Usa este formato para cada decisión tomada. ### Elementos de Acción Todos los elementos de acción deben ser: - [ ] **[Elemento de acción]** - @Propietario - Vence: [Fecha] - [ ] **[Elemento de acción]** - @Propietario - Vence: [Fecha] Formato: - Acción clara y específica - Un solo propietario (sin propiedad de "equipo") - Plazo concreto - Casilla de verificación para seguimiento ### Notas de Discusión Puntos clave discutidos organizados por tema: **Tema 1: [Nombre]** - Punto clave o destaque de la discusión - Contexto importante o preocupación planteada - Cualquier dato o información compartida **Tema 2: [Nombre]** - Puntos clave de la discusión - Decisiones o conclusiones alcanzadas ### Preguntas Abiertas / Seguimiento Preguntas que no pudieron ser respondidas: - **Pregunta**: [Qué necesitamos saber] - **Propietario**: [Quién lo investigará] - **Para Cuándo**: [Plazo] ### Próximos Pasos Resumen claro de lo que sucede a continuación: 1. [Acción inmediata siguiente] 2. [Reunión de seguimiento si es necesaria] 3. [Cualquier proceso más amplio a iniciar] ## Mejores Prácticas **Durante la reunión:** - Enfócate en decisiones y elementos de acción más que en el diálogo - Captura compromisos específicos, no discusiones generales - Anota opiniones disidentes sobre decisiones importantes - Pide claridad sobre compromisos vagos ("Investigaré" → "Analizaré los datos y compartiré hallazgos el viernes") **Después de la reunión:** - Envía notas dentro de 2 horas mientras estén frescas - Etiqueta a los propietarios de elementos de acción (@menciónalos) - Incluye enlaces a documentos relevantes - Realiza seguimiento de elementos de acción vencidos **Qué capturar:** ✅ Decisiones tomadas ✅ Elementos de acción con propietarios y plazos ✅ Puntos clave de la discusión ✅ Preguntas abiertas ✅ Próximos pasos **Qué omitir:** ❌ Transcripciones verbatim ❌ Tangentes fuera de tema ❌ Discusión preliminar antes de decisiones ❌ Información redundante ## Tipos de Reunión y Adaptaciones ### Reuniones 1:1 Enfoque en: - Discusiones de desarrollo de carrera - Retroalimentación (ambas direcciones) - Desafíos actuales - Elementos de acción para ambas partes Adiciones a la plantilla: - **Logros Recientes**: Qué está yendo bien - **Desafíos**: Qué no está yendo bien - **Discusión de Carrera**: Temas de desarrollo - **Retroalimentación**: Para ambas partes ### Planificación de Sprint Enfoque en: - Criterios de aceptación de historias - Decisiones de estimación/dimensionamiento - Identificación de dependencias - Compromiso del sprint Adiciones a la plantilla: - **Objetivo del Sprint**: Qué nos comprometemos a entregar - **Puntos de Historia**: Capacidad y estimaciones - **Dependencias**: Bloqueadores externos - **Definición de Hecho**: Criterios de aceptación ### Revisiones de Producto Enfoque en: - Decisiones de diseño - Retroalimentación de usuarios discutida - Cambios solicitados - Evaluación de preparación para lanzamiento Adiciones a la plantilla: - **Decisiones de Diseño**: Qué se aprobó/rechazó - **Retroalimentación de Usuarios**: Insights clave discutidos - **Preguntas de Diseño Abiertas**: Qué necesita iteración - **Criterios de Lanzamiento**: Requisitos pendientes ### Sincronización con Stakeholders Enfoque en: - Actualizaciones de estado entregadas - Preocupaciones planteadas - Aprobaciones otorgadas - Necesidades de escalada Adiciones a la plantilla: - **Descripción General del Estado**: Progreso de alto nivel - **Aprobaciones Obtenidas**: Sign-offs recibidos - **Escaladas**: Problemas planteados a stakeholders - **Próxima Sincronización**: Cuándo y qué cubrir ## Ejemplo de Notas de Reunión ``` # Revisión de Roadmap de Producto - Q1 2026 **Fecha**: 20 de enero de 2026 **Asistentes**: Sarah (CPO), Mike (Líder de Ing), Jennifer (Diseño), Tom (PM) **Tomador de Notas**: Tom **Duración**: 45 minutos ## Agenda - [x] Revisar features planeadas para Q1 - [x] Discutir restricciones de recursos - [x] Discusión de priorización - [x] Alineación de cronograma ## Decisiones Tomadas **Decisión**: Mover dashboard multicanal a Q2, priorizar mejoras de app móvil para Q1 **Contexto**: La retroalimentación de clientes muestra que la experiencia móvil está impactando significativamente la retención (65% de usuarios principalmente móviles). El equipo de ingeniería solo puede abordar una iniciativa mayor este trimestre. **Propietario**: Tom (PM) para comunicar a stakeholders **Plazo**: 22 de enero **Decisión**: Asignar 20% del tiempo de ingeniería a deuda técnica **Contexto**: La deuda técnica acumulada está ralentizando el desarrollo de features. La velocidad del equipo bajó 30% el trimestre pasado. **Propietario**: Mike (Líder de Ing) para crear backlog de deuda técnica **Plazo**: 27 de enero **Decisión**: Ejecutar beta móvil con 100 usuarios antes del lanzamiento completo **Contexto**: Necesitamos validar mejoras en dispositivos diversos **Propietario**: Jennifer (Diseño) para coordinar con QA **Plazo**: 10 de febrero ## Elementos de Acción - [ ] **Actualizar deck del roadmap Q1 con nueva priorización** - @Tom - Vence: 22 de enero - [ ] **Programar reunión de alineación con equipo de soporte sobre retraso del dashboard** - @Tom - Vence: 24 de enero - [ ] **Crear rubric de priorización de deuda técnica** - @Mike - Vence: 27 de enero - [ ] **Ejecutar user testing en diseños móviles** - @Jennifer - Vence: 3 de febrero - [ ] **Documentar justificación de decisión para ejecutivos** - @Sarah - Vence: 23 de enero - [ ] **Identificar 100 usuarios para beta móvil** - @Tom - Vence: 1 de febrero ## Notas de Discusión **Priorización de Features Q1** - La retención de clientes es la prioridad #1 de la empresa este trimestre - NPS de app móvil es 6.2 (vs 8.1 en web) - Móvil representa 65% de usuarios activos diarios - Dashboard multicanal tomaría 8 semanas de ingeniería - Mejoras móviles estimadas en 6 semanas de ingeniería con ROI más alto - Ventas tiene 3 deals empresariales esperando feature de dashboard **Restricciones de Recursos** - Actualmente 4 ingenieros disponibles (bajó de 6 el trimestre pasado por attrición) - Equipo de diseño puede soportar ambas iniciativas pero con capacidad reducida - Equipo de QA necesita 2 semanas para testing exhaustivo en móvil - Un ingeniero prestado al equipo de seguridad hasta febrero **Discusión de Riesgos** - Retrasar dashboard puede impactar ventas empresariales (3 deals esperando) - Sarah señaló: "Podemos posicionar mejoras móviles como fundación para features empresariales" - Mike planteó preocupación sobre estabilidad del stack tecnológico móvil — abordado mediante asignación de deuda técnica - Necesitamos comunicar claramente con Ventas sobre cambio de cronograma **Plan de Implementación Móvil** - Semana 1-2: Refinamientos de diseño basados en retroalimentación de usuarios - Semana 3-4: Implementación de ingeniería - Semana 5: Testing interno - Semana 6: Beta con 100 usuarios - Semana 7: Lanzamiento completo ## Preguntas Abiertas - **Pregunta**: ¿Cuál es el impacto en pipeline empresarial si retrasamos el dashboard? **Propietario**: Sarah verificará con liderazgo de Ventas **Para Cuándo**: 23 de enero - **Pregunta**: ¿Podemos hacer una beta limitada del dashboard para clientes empresariales? **Propietario**: Tom explorará alcance de MVP con Mike **Para Cuándo**: 25 de enero - **Pregunta**: ¿Cuál es nuestro plan si las mejoras móviles no alcanzan métricas objetivo? **Propietario**: Tom creará plan de contingencia **Para Cuándo**: 27 de enero ## Próximos Pasos 1. Tom enviar roadmap actualizado a liderazgo antes de fin de miércoles (22 de enero) 2. Equipo comenzar planificación de sprint para mejoras móviles el próximo lunes (27 de enero) 3. Reunión de seguimiento el 1 de febrero para revisar progreso y validar priorización 4. Sarah presentar justificación de decisión a equipo ejecutivo el 24 de enero --- **Próxima Reunión**: 1 de febrero de 2026 - Revisión de Progreso **Notas Enviadas**: 20 de enero de 2026 5:30 PM ``` ## Controles de Calidad - [ ] Cada elemento de acción tiene un propietario único nombrado (no "equipo") - [ ] Cada elemento de acción tiene un plazo concreto - [ ] Las decisiones incluyen contexto (por qué se tomó la decisión) - [ ] Las preguntas abiertas tienen un propietario y un "para cuándo" - [ ] Sin transcripciones verbatim — solo síntesis ## Anti-Patrones - [ ] No asignes elementos de acción a "el equipo" o "todos" — cada elemento de acción debe tener exactamente un propietario nombrado o no se completará - [ ] No captures contenido de transcripción verbatim — las notas de reunión registran decisiones y compromisos, no la ruta conversacional completa para llegar allí - [ ] No omitas el contexto de las decisiones — una decisión sin su justificación es inútil cuando alguien pregunta "¿por qué hicimos esto?" seis meses después - [ ] No dejes preguntas abiertas sin un propietario y plazo — una pregunta sin respuesta sin seguimiento asignado es una decisión bloqueada - [ ] No retrases el envío de notas más allá de 2 horas después de la reunión — las notas enviadas al día siguiente pierden la ventana cuando los propietarios de elementos de acción pueden actuar sobre compromisos mientras están frescos ## Distribución de Notas **Formato de Línea de Asunto**: "[Tipo de Reunión] Notas - [Fecha] - [Tema Clave]" Ejemplo: "Notas de Revisión de Roadmap de Producto - 20 de enero - Priorización Q1" **Destinatarios**: - Todos los asistentes - Cualquiera mencionado en elementos de acción - Cualquiera que haya solicitado notas **Seguimiento**: - Enviar recordatorio 3 días antes de las fechas de vencimiento de elementos de acción - Resumen semanal de todos los elementos de acción abiertos - Marcar elementos de acción como completados y compartir actualizaciones ## Ejecución Para agentes que usan herramientas con servidores MCP conectados (Notion, Linear/Jira, Slack). Los runtimes sin acceso a herramientas ignoran esta sección y entregan el documento. Ver [SKILLSPEC.md §5](../../SKILLSPEC.md) y [connectors/mcp-pairings.md](../../connectors/mcp-pairings.md). ### Precondiciones - Las notas estructuradas anteriores han sido mostradas al usuario y **explícitamente aprobadas**, incluyendo el destino (qué base de datos/página de Notion, qué proyecto de tracker). - Los servidores MCP ya están conectados y autenticados en el entorno del agente. - Cada elemento de acción tiene un propietario nombrado — los elementos sin propietario se resuelven con el usuario primero, nunca se asignan por suposición. ### Acciones Permitidas - Crear UNA página en la base de datos de Notion aprobada (o herramienta de docs equivalente) conteniendo las notas aprobadas, verbatim. - Crear un issue de tracker por cada elemento de acción aprobado (título, propietario, fecha de vencimiento de las notas) en el proyecto aprobado. - Publicar el enlace de la página (solo el enlace y un resumen de una línea) en el canal aprobado, si el usuario especificó uno. - Nada más: sin editar páginas/issues existentes, sin invitar o notificar personas más allá del canal nombrado, sin escrituras de calendario. ### Verificación - Obtener la página creada y cada issue creado; confirmar que títulos, propietarios y fechas coincidan con las notas aprobadas. - Reportar cada URL creada al usuario en una lista. ### Rollback - Deshacer = archivar/eliminar la página y los issues recién creados, solo con instrucción explícita del usuario. - Detener y preguntar a un usuario si: la base de datos/proyecto destino no se encuentra, cualquier creación de issue falla a mitad (reporta qué FUE creado), o un propietario de elemento de acción no existe en el tracker.