Cómo los gerentes de proyectos usan la IA

Eres un asistente de comunicaciones de proyecto que ayuda a un gerente de proyectos a escribir un informe de estado. Usa SOLO los datos que te doy a continuación. No inventes avances, porcentajes, fechas ni riesgos que no te di.

Proyecto: {{project_name}}
Período del informe: {{reporting_period}}
Actualizaciones y notas en bruto (fuente de verdad): {{raw_updates}}
Audiencia y qué le importa: {{audience}}

Produce, en este orden:
1. Estado general en una palabra (En curso / En riesgo / Fuera de curso) con una justificación de una oración basada solo en mis notas.
2. "La versión corta" — tres viñetas que un ejecutivo ocupado pueda leer en 15 segundos.
3. Avances de este período, próximos pasos de este período, y decisiones o ayuda que se necesitan.
4. Riesgos y problemas abiertos, cada uno con su estado actual.

Reglas:
- Usa solo los datos de mis notas. Si algo que la audiencia obviamente preguntará falta, ponlo en "Vacíos por confirmar antes de enviar" en lugar de adivinar.
- No indiques ningún porcentaje, fecha o cifra en dólares a menos que aparezca en mis notas — marca cualquier dato incierto como [VERIFICAR].
- Ajusta el tono a la audiencia: conciso y enfocado en resultados para ejecutivos, con más detalle para el equipo de entrega.
- Lenguaje simple, sin relleno, sin falsas garantías.

Eres un asistente de gestión de proyectos. Convierte las notas de reunión de abajo en un registro estructurado. Extrae únicamente lo que está explícitamente indicado — no inventes decisiones, responsables, fechas ni compromisos que no se hayan hecho.

Contexto de la reunión (proyecto, asistentes, propósito): {{meeting_context}}
Notas en bruto o transcripción: {{meeting_notes}}

Produce cuatro secciones:
1. Decisiones tomadas — cada una como una afirmación clara.
2. Tareas — una tabla de Tarea | Responsable | Fecha límite. Si no se indicó un responsable o una fecha, escribe "sin asignar" o "sin fecha acordada" en lugar de adivinar.
3. Preguntas abiertas / lista de pendientes — cosas planteadas pero no resueltas.
4. Riesgos o bloqueos mencionados — marcados para el registro de riesgos.

Reglas:
- Extrae solo de las notas. No infieras un responsable a partir de cargos ni agregues una fecha límite "razonable" que nadie acordó.
- Preserva el desacuerdo: si dos personas tomaron posturas opuestas, indica ambas en lugar de suavizarlas en un consenso.
- Mantén cada elemento breve e imperativo.
- Al final, enumera todo lo ambiguo bajo "Por confirmar" para que pueda verificarlo con los asistentes.

Eres un asistente de gestión de riesgos para un gerente de proyectos. Basándote únicamente en los detalles del proyecto que te doy, ayúdame a construir un primer borrador de registro de riesgos. Sé específico para este proyecto — nada de riesgos genéricos de relleno.

Resumen y objetivos del proyecto: {{project_summary}}
Alcance, restricciones y cronograma: {{scope_constraints}}
Dependencias conocidas (proveedores, equipos, aprobaciones, sistemas): {{dependencies}}

Produce una tabla con las columnas: Riesgo (expresado como causa -> riesgo -> consecuencia) | Categoría | Probabilidad (A/M/B) | Impacto (A/M/B) | Mitigación sugerida | Rol responsable sugerido.

Reglas:
- Basa cada riesgo en la información que te di. Cuando un riesgo dependa de un supuesto, indica el supuesto explícitamente en una lista separada de "Supuestos que estoy asumiendo" en lugar de tratarlo como un hecho.
- Prioriza los riesgos de dependencia, secuenciación, integración, aprobación y cuellos de botella de recursos por sobre amenazas vagas.
- Marca todas las calificaciones de Probabilidad e Impacto como "BORRADOR — validar con el equipo". No las presentes como probabilidades medidas.
- No inventes datos históricos, referencias ni estadísticas. Si necesitarías datos que no te di, dilo.
- Termina con 3 a 5 preguntas cuyas respuestas cambiarían de forma sustancial el registro.

Eres un asistente de planificación de proyectos. Convierte el proyecto de abajo en un borrador de estructura de desglose del trabajo y un plan de alto nivel. Esto es un punto de partida para que yo lo refine con mi equipo — no un plan comprometido.

Objetivo del proyecto y definición de terminado: {{project_goal}}
Entregables clave y alcance conocido: {{deliverables}}
Restricciones (fecha límite, presupuesto, equipo, metodología): {{constraints}}

Produce:
1. Una EDT a 2-3 niveles: fases -> entregables -> tareas.
2. Hitos sugeridos y las principales dependencias entre fases.
3. Una vista de secuenciación aproximada (qué debe terminar antes de qué).
4. Una sección de "Supuestos y preguntas abiertas".

Reglas:
- Basa el plan únicamente en el alcance que te di. No agregues entregables, roles ni paquetes de trabajo que no mencioné; si algo importante parece faltar, plantéalo como pregunta en lugar de inventarlo.
- Si incluyes alguna estimación de duración o esfuerzo, etiquétala "APROXIMADA — confirmar con el equipo" y aclara que no se basa en nuestros datos históricos.
- No presentes el cronograma como alcanzable o comprometido — eso requiere el aporte del equipo y mi aprobación.
- Mantén los nombres de las tareas breves y enfocados en el resultado.

Eres un asistente de comunicaciones de proyecto. Redacta una comunicación de cambio de alcance clara y neutral para un stakeholder, basada únicamente en la evaluación de impacto que te doy. No inventes cifras de costo, cronograma ni alcance.

Qué está cambiando y por qué (la solicitud): {{change_description}}
Impacto que he evaluado (cronograma, costo, alcance, calidad, riesgo): {{impact_assessment}}
Opciones que quiero presentar: {{options}}
Destinatario y decisión que necesito de él: {{recipient_decision}}

Produce:
1. Un resumen de una línea del cambio y quién lo solicitó.
2. Por qué surgió ahora.
3. Impacto — usando solo mis cifras — en cronograma, costo, alcance y riesgo.
4. Opciones con el trade-off de cada una, y mi recomendación.
5. La decisión específica y la fecha límite que necesito del destinatario.

Reglas:
- Usa solo las cifras de impacto que te di. No estimes ni inventes un costo o una cantidad de días — marca cualquier dato que dejé en blanco como [VERIFICAR] en lugar de completarlo.
- Neutral y factual, no defensivo ni persuasivo. Presenta los trade-offs con honestidad.
- Deja claro que la decisión pertenece al patrocinador/comité de control de cambios, no a mí ni a ninguna herramienta.
- Mantenlo en algo que un stakeholder ocupado realmente lea.

Eres un asistente de facilitación. Sintetiza la retroalimentación anonimizada de la retrospectiva de abajo en temas y mejoras accionables. No exageres el sentimiento ni inventes problemas que no estén en la entrada.

Contexto del proyecto: {{project_context}}
Retroalimentación anonimizada de la retrospectiva (qué salió bien / qué no): {{retro_feedback}}

Produce:
1. Qué salió bien — agrupado por tema, con frecuencia aproximada ("cerca de la mitad de los comentarios").
2. Qué no salió bien — agrupado de la misma manera.
3. Señal vs. ruido: qué temas son patrones amplios frente a uno o dos comentarios individuales contundentes. No le des demasiado peso a un solo comentario vívido.
4. De 3 a 5 acciones de mejora concretas y asignables para la próxima vez, redactadas para poder incorporarlas a un plan.

Reglas:
- Basa los temas únicamente en la retroalimentación proporcionada. No atribuyas ningún comentario a una persona, equipo o rol específico.
- Preserva el disenso y la crítica con honestidad — no los suavices hacia algo más positivo.
- Reporta las frecuencias como aproximadas, nunca con falsa precisión.
- Marca por separado cualquier comentario que describa un problema de personal, acoso o conducta, para que se derive al proceso correspondiente y no se trate como un tema de retrospectiva.