Agent Skills
› mohitagw15856/pm-claude-skills
› meeting-notes
meeting-notes
GitHub将会议笔记结构化并格式化，遵循项目管理最佳实践。支持创建、整理笔记，提取行动项与决策。集成Brain系统，读写利益相关者及决策文件，确保信息持久化与可追溯性。
Trigger Scenarios
创建会议纪要
格式化讨论笔记
提取行动项
记录会议决策
Install
npx skills add mohitagw15856/pm-claude-skills --skill meeting-notes -g -y
SKILL.md
Frontmatter
{
"name": "meeting-notes",
"description": "Estructura y formatea notas de reunión siguiendo mejores prácticas de PM. Úsalo cuando te pidan crear notas de reunión, formatear notas de discusión, capturar elementos de acción, o documentar decisiones de cualquier tipo de reunión. Produce notas estructuradas con decisiones, elementos de acción (propietario + plazo), preguntas abiertas y próximos pasos."
}
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 (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 cualquierdecisions/que la reunión revise. - Escribe después: añade cada decisión (con su justificación y un
reopen-when) adecisions/, agrega nuevas solicitudes/preocupaciones al archivostakeholders/correcto, e identifica cualquier nueva suposición enhypotheses/. 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 ensource/.
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:
- [Acción inmediata siguiente]
- [Reunión de seguimiento si es necesaria]
- [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 y 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.
Version History
- a38bc30 Current 2026-07-05 11:08
