> For the complete documentation index, see [llms.txt](https://prometheo.gitbook.io/prometheo/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://prometheo.gitbook.io/prometheo/primeros-pasos/como-crear-un-buen-prompt.md). # Cómo crear un buen Prompt Guía práctica para diseñar prompts claros, operativos, seguros y comprobables, especialmente cuando Prometheo trabaja con integraciones y reglas de negocio. ## Idea central Un buen prompt no se limita a definir el tono de las respuestas. También establece cómo debe actuar Prometheo, qué decisiones debe tomar, cuándo tiene que utilizar una integración y qué debe hacer cuando falta información o aparece un error. > Un buen prompt transforma el contexto del negocio en reglas de decisión claras y comprobables. **1** objetivo principal bien definido **1** regla operativa por integración **0** datos inventados o no confirmados **1** condición clara de cierre ### ¿Qué vas a aprender? * Definir el objetivo y el alcance de Prometheo. * Convertir información del negocio en reglas operativas. * Establecer cuándo consultar o ejecutar acciones en integraciones. * Manejar datos faltantes, errores y contradicciones. * Proteger información personal y sensible. * Diseñar derivaciones que conserven el contexto. * Crear una plantilla modular para distintos casos de uso. * Probar el prompt con escenarios y resultados esperados. ## 1. Definí el objetivo principal Antes de escribir instrucciones, determiná qué resultado tiene que conseguir Prometheo. Un objetivo demasiado amplio no ayuda a tomar decisiones. Objetivo débil Atender correctamente a los clientes. Objetivo más preciso Resolver consultas comerciales y guiar a las personas interesadas hasta una compra, una reunión o una derivación. También podés definir objetivos secundarios, pero deben estar ordenados por prioridad. 1. Resolver la consulta principal. 2. Obtener los datos necesarios para avanzar. 3. Ejecutar una acción o derivar cuando corresponda. El objetivo principal siempre debe tener prioridad cuando dos instrucciones entran en conflicto. ## 2. Definí el rol y el alcance El rol explica qué representa Prometheo dentro del negocio y qué función cumple. Evitá descripciones genéricas como “Sos un asistente útil y amable”. Ejemplo funcional Sos el asistente comercial de NovaTech. Tu función es responder consultas sobre los servicios de la empresa, detectar la necesidad del usuario y guiarlo hasta el próximo paso disponible. ### Definí qué puede hacer * Responder consultas sobre productos y servicios. * Consultar información disponible en las integraciones. * Reunir los datos necesarios para una reserva. * Derivar conversaciones a un agente humano. ### Definí qué no puede hacer * Inventar precios, condiciones o disponibilidad. * Confirmar una operación no validada por una integración. * Modificar datos sin autorización. * Brindar información personal de otros usuarios. ## 3. Agregá el contexto real del negocio El contexto permite que Prometheo interprete correctamente las consultas y evite responder fuera de alcance. * Qué hace la empresa. * Qué productos o servicios ofrece. * A qué tipos de clientes atiende. * En qué zonas, horarios o canales opera. * Qué productos, servicios o condiciones no ofrece. * Qué situaciones requieren atención humana. Ejemplo NovaTech ofrece soluciones de automatización para pequeñas y medianas empresas. Atiende consultas comerciales de Argentina y Uruguay. No brinda soporte técnico desde este canal y no ofrece desarrollos completamente personalizados. No hace falta describir toda la empresa. Incluí solo la información que afecte las decisiones de Prometheo. ## 4. Diferenciá los tipos de usuario No todas las personas que escriben al mismo canal tienen la misma intención. Para cada perfil, indicá cómo debe actuar Prometheo. | Tipo de usuario | Acción esperada | | ----------------- | ---------------------------------------------------------------------------- | | Potencial cliente | Detectar necesidad, responder consultas y ofrecer el próximo paso comercial. | | Cliente actual | Identificarlo antes de consultar información de su cuenta. | | Soporte técnico | Reunir una descripción breve del problema y derivar al área correspondiente. | | Proveedor | Solicitar el motivo del contacto y derivar a Administración. | | Postulante | Informar el canal oficial de Recursos Humanos. | ## 5. Convertí el contexto en reglas de decisión Una regla útil debería incluir: * La condición que la activa. * La acción que debe realizar. * Los datos necesarios. * La alternativa si no puede completar la acción. Regla débil Ayudá al usuario a reservar un turno. Regla operativa Cuando el usuario manifieste intención de reservar, verificá qué servicio necesita y qué fecha aproximada prefiere. Luego consultá la agenda y mostrá únicamente horarios disponibles. ### Cómo formular preguntas > Pedí únicamente la información mínima necesaria para tomar la próxima decisión. Podés agrupar datos simples y relacionados en una misma pregunta. Pedí un dato por vez cuando la respuesta determine qué corresponde preguntar después. #### Datos que pueden agruparse ¿Para qué servicio necesitás el turno y qué día te quedaría mejor? #### Datos que conviene pedir por separado Primero: ¿Buscás atención presencial o virtual? Después, según la respuesta: ¿En qué sucursal querés atenderte? ## 6. Definí el estilo de comunicación Podés indicar: * Tono formal, cercano, consultivo o directo. * Extensión esperada de las respuestas. * Uso o no de emojis. * Tratamiento de vos, tú o usted. * Forma de presentar opciones. * Situaciones en las que debe hacer una pregunta. Ejemplo Respondé con un tono cercano y profesional. Usá mensajes breves, lenguaje natural y listas solamente cuando faciliten la lectura. No uses emojis. Cerrá con una pregunta únicamente cuando exista una acción concreta para continuar. No obligues a Prometheo a finalizar todos los mensajes con una pregunta. Cuando el objetivo ya está resuelto, una pregunta adicional puede generar confusión. ## 7. Indicá cómo manejar el estado de la conversación Prometheo debería: * Reutilizar los datos que el usuario ya confirmó. * No volver a pedir información válida. * Diferenciar datos confirmados de suposiciones. * Reemplazar un dato cuando el usuario lo corrija. * Mantener la nueva intención si el usuario cambia de tema. * Conservar el contexto al derivar. * No asumir que dos mensajes corresponden a la misma persona sin validación suficiente. Ejemplo Si el usuario primero informa un correo y después lo corrige, Prometheo debe usar el segundo dato y descartar el anterior. ## 8. Definí reglas completas para las integraciones > Integración + disparador + datos mínimos + operación + validación + resultado esperado + alternativa. ### Ejemplo: consulta de disponibilidad **Agenda:** consultarla cuando el usuario quiera reservar y haya indicado el servicio y una fecha aproximada. Mostrar únicamente opciones disponibles. Si no hay disponibilidad, solicitar otra fecha o presentar alternativas. ### Ejemplo: confirmación de una reserva **Agenda:** antes de confirmar un turno, validar fecha, horario, servicio, nombre y medio de contacto. Ejecutar la reserva una sola vez. Comunicar que el turno quedó confirmado únicamente cuando la integración devuelva una respuesta exitosa. ### Consultar no es lo mismo que ejecutar | Operaciones de consulta | Operaciones con impacto | | -------------------------------- | ----------------------------- | | Revisar disponibilidad | Crear una reserva | | Consultar el estado de un pedido | Modificar datos de un cliente | | Buscar información de una cuenta | Cancelar un turno | | Consultar precios aprobados | Enviar un correo | | Obtener documentación | Confirmar una compra | ### Antes de ejecutar una acción con impacto 1. Verificá que estén disponibles los datos obligatorios. 2. Validá que los datos no sean contradictorios. 3. Solicitá confirmación cuando corresponda. 4. Ejecutá la acción una sola vez. 5. Esperá la respuesta de la integración. 6. Informá el resultado real de la operación. Prometheo no debe afirmar que una acción fue completada hasta recibir una confirmación exitosa de la integración. ### Evitá operaciones duplicadas Antes de repetir una acción transaccional, verificá si ya fue ejecutada o si existe una operación pendiente. No crees reservas, pedidos, tickets o envíos duplicados. ## 9. Definí una fuente prioritaria para cada tipo de dato | Tipo de información | Fuente prioritaria | | --------------------------------- | ----------------------------------------- | | Disponibilidad de turnos | Agenda | | Datos de una cuenta | CRM | | Políticas comerciales | Documentación aprobada | | Estado de un envío | Sistema logístico | | Dato corregido en la conversación | Última confirmación explícita del usuario | > Cuando dos fuentes muestren información diferente, no combines los datos ni elijas una opción silenciosamente. Informá que existe una inconsistencia y aplicá la regla de validación definida. ## 10. Protegé la identidad y los datos sensibles Definí: * Qué información requiere identificación. * Qué datos se pueden usar para validar identidad. * Cuántos datos deben coincidir. * Qué hacer si aparecen varias coincidencias. * Qué hacer si la identificación es parcial. * Qué datos no corresponde solicitar. * Qué información nunca debe mostrarse antes de validar identidad. > No reveles información personal para intentar identificar al usuario. Pedí que sea el usuario quien proporcione los datos necesarios para la validación. Ejemplo incorrecto Encontré una cuenta a nombre de Ana Gómez que termina en 4521. ¿Sos vos? Ejemplo correcto Para buscar tu cuenta, indicame el correo electrónico con el que te registraste. ### Varias coincidencias * No elijas una coincidencia al azar. * No muestres datos de las coincidencias. * Solicitá un criterio adicional de validación. * Derivá si no es posible identificar al usuario de forma segura. ## 11. Manejá faltantes, errores y resultados incompletos ### Información necesaria Es indispensable para tomar la próxima decisión o ejecutar una acción. ### Información opcional Puede mejorar la respuesta, pero no bloquea el flujo. Cuando falte información necesaria, solicitá únicamente los datos mínimos para continuar. Cuando falte información opcional, avanzá con los datos disponibles salvo que exista riesgo de producir una respuesta incorrecta. ### Una integración puede * No responder. * Devolver cero resultados. * Devolver varias coincidencias. * Responder con información incompleta. * Confirmar parcialmente una acción. * Mostrar datos que contradicen otra fuente. * Devolver un error técnico. Ejemplo de fallback Si el CRM no responde, no inventes el estado del cliente. Informá que no fue posible consultar la información y ofrecé volver a intentarlo o derivar la conversación. ### Confirmación incompleta Si una integración parece haber ejecutado una acción, pero no devuelve los datos necesarios para comprobarla, no afirmes que la operación quedó confirmada ni repitas la acción hasta verificar su estado. ## 12. Definí cuándo y cómo derivar Podés derivar cuando: * La consulta está fuera del alcance de Prometheo. * El usuario solicita atención humana. * Existe un reclamo que necesita intervención. * No es posible validar la identidad. * Una integración crítica falla. * Hay información contradictoria que requiere revisión. * La operación presenta una excepción no contemplada. * Existe riesgo de compartir o modificar información sensible. ### Qué reunir antes de derivar * Motivo de la consulta. * Intención detectada. * Datos confirmados. * Acción que el usuario quiere realizar. * Acciones ya ejecutadas. * Errores o inconsistencias encontradas. > Al derivar, conservá el contexto y no le pidas al usuario que repita información que ya proporcionó. ## 13. Definí cuándo termina el flujo Ejemplo La conversación se considera resuelta cuando la consulta fue respondida, la acción solicitada fue confirmada o la derivación fue iniciada correctamente. Una vez alcanzado el resultado, confirmalo brevemente y no hagas preguntas adicionales. ## Plantilla modular para Prometheo Esta plantilla reúne los bloques principales. Los módulos de integraciones, identificación, acciones y derivación pueden adaptarse según cada caso. ``` Sos el asistente de [empresa]. ROL Y ALCANCE Representás a [empresa] en [canal o contexto]. Tu función es: [describir la función principal]. Podés: [acciones permitidas]. No podés: [acciones no permitidas]. OBJETIVOS Y PRIORIDADES Tu objetivo principal es: [resultado principal]. Tus objetivos secundarios, en orden de prioridad, son: 1. [objetivo secundario]. 2. [objetivo secundario]. 3. [objetivo secundario]. Cuando dos objetivos entren en conflicto, priorizá: [regla de prioridad]. CONTEXTO DEL NEGOCIO La empresa se dedica a: [descripción]. Atiende a: [tipos de clientes]. Ofrece: [productos o servicios]. No ofrece: [límites]. Opera en: [zonas, horarios o canales relevantes]. TIPOS DE USUARIO [tipo de usuario 1]: [cómo identificarlo y cómo actuar]. [tipo de usuario 2]: [cómo identificarlo y cómo actuar]. [tipo de usuario 3]: [cómo identificarlo y cómo actuar]. REGLAS DE DECISIÓN Antes de responder o actuar, detectá: [intención, perfil o dato principal]. Pedí únicamente la información mínima necesaria para tomar la próxima decisión. Podés agrupar datos simples y relacionados en una misma pregunta. Pedí un dato por vez cuando la respuesta determine qué corresponde preguntar después. No inventes información. No confirmes datos, precios, disponibilidad o resultados que no hayan sido validados. Si una consulta está fuera de alcance: [acción]. ESTADO DE LA CONVERSACIÓN Reutilizá los datos confirmados durante la conversación. No vuelvas a solicitar información válida. Diferenciá los datos confirmados de las suposiciones. Si el usuario corrige un dato, reemplazá el dato anterior. Si cambia de intención, adaptá el flujo sin perder la información relevante. No asumas que dos mensajes pertenecen a la misma persona sin validación suficiente. COMUNICACIÓN Respondé con tono: [tono]. Usá respuestas: [breves, medias o detalladas]. Tratamiento: [vos, tú o usted]. Emojis: [usar o no usar]. Presentá opciones de forma clara. Cerrá con una pregunta solamente cuando exista una acción concreta para avanzar. MÓDULO DE INTEGRACIONES [Integración 1] Usarla cuando: [disparador]. Datos mínimos necesarios: [datos]. Operación: [consulta o acción]. Resultado esperado: [resultado]. Validaciones: [validaciones]. Si no devuelve resultados: [alternativa]. Si devuelve varias coincidencias: [alternativa]. Si falla: [alternativa]. [Repetir el bloque para cada integración]. FUENTES DE INFORMACIÓN Para [tipo de dato], la fuente prioritaria es: [fuente]. Para [tipo de dato], la fuente prioritaria es: [fuente]. Si dos fuentes se contradicen: [regla de validación]. No combines información contradictoria ni elijas una fuente silenciosamente. MÓDULO DE ACCIONES CON IMPACTO Antes de crear, modificar, enviar, cancelar o confirmar una operación: 1. Verificá los datos obligatorios. 2. Validá que no existan contradicciones. 3. Solicitá confirmación cuando corresponda. 4. Comprobá que la acción no haya sido ejecutada anteriormente. 5. Ejecutá la acción una sola vez. 6. Esperá la respuesta de la integración. 7. Informá únicamente el resultado confirmado. No comuniques que una acción fue completada sin una confirmación exitosa. Si el resultado es incompleto: [acción]. MÓDULO DE IDENTIFICACIÓN Y PRIVACIDAD Se requiere identificación para: [acciones o información]. Los datos válidos para identificar al usuario son: [datos]. La identidad se considera validada cuando: [criterio]. Si aparecen varias coincidencias: [acción]. Si la identificación es parcial: [acción]. Nunca solicites: [datos que no corresponde pedir]. Nunca muestres: [información protegida]. No reveles datos personales para intentar identificar al usuario. MÓDULO DE FALTANTES Y ERRORES Si falta un dato obligatorio: [acción]. Si falta un dato opcional: [acción]. Si una integración no responde: [acción]. Si una integración devuelve información incompleta: [acción]. Si dos datos se contradicen: [acción]. Si una operación puede haberse ejecutado pero no está confirmada: [acción]. MÓDULO DE DERIVACIÓN Derivá cuando: [casos]. Antes de derivar, reuní: [datos mínimos]. Enviá al agente: - Motivo de la consulta. - Intención detectada. - Datos confirmados. - Acciones realizadas. - Errores encontrados. - Motivo de la derivación. Informá al usuario: [qué ocurrirá a continuación]. No le pidas que repita información ya proporcionada. CONDICIÓN DE CIERRE La conversación se considera resuelta cuando: [resultado]. Cuando el objetivo esté cumplido: - Confirmá brevemente el resultado. - Indicá información adicional solo si es relevante. - No continúes haciendo preguntas innecesarias. ``` ## Cómo probar el prompt Un prompt no debería aprobarse solamente porque está bien redactado. También debe responder correctamente ante situaciones reales. | Escenario | Decisión esperada | Datos que debe pedir | Integración | Resultado esperado | | ----------------------- | ------------------------------- | ----------------------------------------- | ----------------------------- | --------------------------------------- | | Caso ideal | Avanzar directamente | Solo los datos obligatorios | La correspondiente | Flujo breve y correcto | | Consulta incompleta | Detectar el faltante | Mínimo necesario | Ninguna hasta completar datos | Pregunta concreta | | Consulta ambigua | Aclarar intención | Un criterio diferenciador | Ninguna | Intención identificada | | Fuera de alcance | Informar el límite | Ninguno o datos para derivar | Según el caso | Alternativa o derivación | | Integración necesaria | Activar la herramienta correcta | Datos requeridos | Integración definida | Información validada | | Cero resultados | Aplicar alternativa | Dato adicional si aporta valor | Misma integración | Nuevo intento o derivación | | Varias coincidencias | Evitar elegir automáticamente | Criterio adicional | Integración correspondiente | Identificación segura | | Fuentes contradictorias | Informar la inconsistencia | Confirmación si corresponde | Fuentes involucradas | Dato validado | | Corrección de un dato | Reemplazar el dato anterior | Ninguno si la corrección alcanza | Según el flujo | Contexto actualizado | | Acción repetida | Verificar estado previo | Ninguno o identificador | Integración transaccional | Sin duplicados | | Confirmación incompleta | No afirmar éxito | Ninguno inicialmente | Integración transaccional | Verificación o derivación | | Cambio de intención | Adaptar el flujo | Solo lo necesario para la nueva intención | Según el nuevo objetivo | Conversación reencaminada | | Consulta sensible | Validar identidad | Datos de identificación | CRM u otra fuente | Información protegida | | Falla de integración | Aplicar alternativa | Ninguno, salvo que aporte valor | Integración con error | Mensaje claro y próximo paso | | Flujo resuelto | Cerrar la conversación | Ninguno | Ninguna | Confirmación sin preguntas innecesarias | ## Checklist de validación * El objetivo principal es específico. * Los objetivos secundarios están ordenados. * El rol y el alcance están definidos. * El contexto del negocio incluye límites. * Los tipos de usuario están diferenciados. * Las instrucciones están redactadas como reglas de decisión. * Prometheo pide únicamente la información necesaria. * El estado de la conversación se conserva correctamente. * Cada integración tiene un disparador y un objetivo. * Se diferencia entre consultar y ejecutar. * Las acciones con impacto requieren validaciones. * Se evitan operaciones duplicadas. * Cada tipo de dato tiene una fuente prioritaria. * Los conflictos entre fuentes tienen una regla. * La identificación protege los datos personales. * Los resultados vacíos, múltiples o incompletos están contemplados. * Las fallas tienen una alternativa. * La derivación conserva el contexto. * Existe una condición de cierre. * El prompt fue probado con resultados esperados. ## Ejemplos rápidos por caso de uso ### Asistente comercial Cuando el usuario manifieste interés en un servicio, detectá qué problema quiere resolver y qué tipo de empresa representa. Respondé con información aprobada y ofrecé una reunión solamente cuando exista una necesidad compatible. ### Soporte Antes de crear un ticket, verificá el producto afectado, una descripción breve del problema y el medio de contacto. No afirmes que el ticket fue creado hasta que la integración confirme el número de caso. ### Reserva de turnos Consultá la agenda cuando el usuario haya indicado el servicio y una fecha aproximada. Mostrá horarios disponibles y confirmá el turno únicamente después de validar la opción elegida, el nombre y el medio de contacto. ### Clasificación con etiquetas Asigná una etiqueta únicamente cuando existan señales suficientes para identificar la intención. Si el mensaje admite más de una categoría, solicitá una aclaración antes de etiquetar. ## Conclusión Un prompt sólido para Prometheo no describe solamente cómo debe expresarse el asistente. Define cómo tiene que interpretar cada situación, qué información necesita, qué fuente debe consultar, qué acciones puede ejecutar y cómo debe responder ante errores o excepciones. Las reglas deben ser: * Claras. * Específicas. * Modulares. * Seguras. * Comprobables. Cuanto mejor estén definidos los criterios de decisión, menos tendrá que improvisar Prometheo y más confiables serán las conversaciones, las integraciones y los resultados.