Crea un radar de eventos: del prompt a la automatización con ChatGPT

La idea: enterarse antes de que sea tarde

A todos nos ha pasado que nos hemos perdido un evento al que nos hubiera interesado asistir, porque nos hemos enterado demasidado tarde o incluso después de que haya pasado. De aquí surge la idea de este artículo y de ahi aparece la pregunta obvia:

¿Y si en lugar de buscar eventos cuando me acuerdo, tuviera un sistema que estuviera pendiente de ellos por mí?

Vamos a orientar este artículo en eventos de música electrónica pero podria ser aplicado a cualquier otro tipo de evento. No buscamos una simple agenda. Tampoco una lista interminable de conciertos, festivales o sesiones. Lo que buscamos es algo más útil: un sistema capaz de detectar con antelación aquello que realmente te interesa y presentarlo de una forma rápida de revisar.

Crea un radar de eventos

La idea inicial es muy concreta: seguir a determinados DJs y saber dónde van a tocar durante las siguientes semanas. Pero enseguida se quedó corta, ya que podría ser interesante saber si hay algún otro evento que encaje en mis gustos donde pueda aparecer un DJ que no estaba en mi lista.

Ahí es donde la idea empieza a cambiar. Ya no se trata de hacer una búsqueda, sino de construir un radar de eventos de interés. Un sistema al que podemos decirle qué cosas nos interesan especialmente, qué zonas queremos vigilar, qué tipo de eventos queremos descubrir y con cuánto tiempo de antelación queremos conocerlos.

Y, a partir de ahí, dejar que haga tres cosas por nosotros: buscar, seleccionar y priorizar, porque ese es realmente el problema. Internet ya contiene la información. Los artistas publican sus giras, los festivales anuncian fechas, las salas actualizan sus agendas y las plataformas de entradas muestran cientos de eventos.

Lo difícil no es que la información exista. Lo difícil es enterarse de la información correcta en el momento adecuado. Por eso el objetivo de este experimento no será crear otra agenda más, siino que será construir algo que consiga provocar frases como estas: "esto me interesa", "esto está cerca", "esto merece un viaje", "no sabía que esto existía", “todavía estoy a tiempo de comprar entradas”, y, sobre todo: “Menos mal que me he enterado con tiempo.”

Para probar la idea vamos a utilizar un caso muy concreto: TechnoRadar, un radar orientado a música electrónica, DJs, festivales y fiestas Remember.

Pero lo importante no será TechnoRadar. Lo importante será el sistema que hay detrás, porque si funciona, exactamente el mismo enfoque podría servir para vigilar congresos, exposiciones, carreras, ferias gastronómicas, eventos tecnológicos, competiciones deportivas o prácticamente cualquier cosa que tenga una fecha, un lugar y suficiente interés como para querer enterarnos antes de que ocurra.

Y esa será precisamente la idea que iremos construyendo a lo largo del artículo: pasar de una necesidad muy sencilla: “no quiero volver a enterarme tarde”, a un radar configurable, visual y, finalmente, automatizado para que se ejecute periódicamente.

TechnoRadar: nuestro caso práctico

Para construir el sistema necesitábamos un ejemplo real. Y ahí nació TechnoRadar. La idea era sencilla: vigilar durante los próximos 90 días los eventos de música electrónica que pudieran resultar interesantes, dando prioridad a ciertos DJs, festivales y zonas.

La configuración inicial quedó así:

• DJs prioritarios: Miss Monique, Tiësto, NOVAH, Korolova y Charlotte de Witte.

• Eventos prioritarios: Tomorrowland, Medusa, Summer History, Love The 90's y otros eventos similares.

• Zona prioritaria: España, con especial atención a Madrid.

• Radares temáticos: España, Remember y Radar Abierto.

• Horizonte temporal: 90 días.

El Radar Abierto es importante porque evita que el sistema se limite a lo que ya conocemos. Si aparece un festival, una sesión o un artista interesante fuera de nuestras listas, también puede entrar en el informe. El resultado que buscamos no es una agenda completa de música electrónica, sino una selección útil: qué merece atención, qué está cerca, qué puede agotarse y qué conviene tener en mente con antelación.

TechnoRadar será nuestro laboratorio durante el resto del artículo, pero toda la estructura que construyamos estará pensada para poder reutilizarse después con cualquier otro tipo de evento.

La clave: separar configuración y motor

Empezamos por darle unas instrucciones generales

Quiero que generes un briefing/webapp HTML autocontenido, visualmente atractivo, dinámico, responsive y descargable, basado en eventos, artistas, actividades o temáticas que yo defina.

El sistema debe funcionar como un radar periódico: buscar información actualizada en Internet, detectar próximos eventos, destacar oportunidades relevantes, incluir enlaces oficiales o fiables y organizar todo en un HTML que pueda abrirse directamente en cualquier navegador.

El resultado debe estar diseñado específicamente para funcionar correctamente en ORDENADOR, TABLET y MÓVIL.

El HTML debe sentirse como una combinación entre:
- briefing ejecutivo
- magazine digital
- agenda visual
- radar de oportunidades

Evitar una apariencia excesivamente similar a una base de datos o dashboard analítico.

Priorizar:
- ritmo visual
- titulares
- tarjetas
- bloques destacados
- jerarquía
- navegación rápida
- lectura fluida
- sensación de descubrimiento

Si queremos que el radar sea reutilizable, el prompt no puede estar lleno de datos fijos repartidos por todo el prompt.

La mejor solución es dividirlo en dos capas.

• La primera es la configuración: todo aquello que queremos poder cambiar fácilmente.

• La segunda es el motor: las reglas que explican cómo investigar, priorizar y generar el informe.

La parte editable puede empezar así:

# 1. CONFIGURACIÓN EDITABLE
======================================================================
[NOMBRE_DEL_RADAR]
TechnoRadar

[DESCRIPCIÓN]
Radar mundial de música electrónica, techno, DJs, festivales y fiestas Remember.

[HORIZONTE_TEMPORAL]
90 días

[COBERTURA_GEOGRÁFICA_GENERAL]
Mundial

[ZONA_PRIORITARIA]
España

[CIUDAD_O_ZONA_DE_ESPECIAL_INTERÉS]
Madrid y alrededores

La ventaja es que toda la personalización queda concentrada al principio. Para crear otro radar no necesitamos rehacer la lógica completa: basta con cambiar esta sección.

Debajo quedará el motor del prompt, que será común a cualquier versión y definirá, entre otras cosas:

• cómo buscar la información;

• qué fuentes priorizar;

• cómo decidir qué merece aparecer;

• cómo estructurar el briefing;

• y cómo generar el HTML final.

Qué queremos vigilar

Una vez definida la estructura general, toca concretar qué elementos deben tener prioridad dentro del radar.

En TechnoRadar distinguimos tres bloques: artistas prioritarios, eventos o marcas prioritarias y contexto geográfico. El horizonte temporal ya lo hemos fijado en 90 días.

La configuración puede ampliarse así:

## 1.2 ARTISTAS / DJs / ENTIDADES PRIORITARIAS
--------------------------------------------------
- Miss Monique
- Tiësto
- NOVAH
- Korolova
- Charlotte de Witte

## 1.3 EVENTOS / FESTIVALES / MARCAS PRIORITARIAS
--------------------------------------------------
- Tomorrowland
- Medusa Festival
- Medusa Winter
- Summer History
- Love The 90's
- Los 90

Estos bloques sirven para decirle al sistema qué cosas queremos vigilar de forma explícita. Si uno de esos DJs anuncia una fecha dentro del horizonte definido, debe ganar relevancia. Lo mismo ocurre si aparece una nueva edición, un cambio de cartel o la apertura de entradas de alguno de los eventos prioritarios.

La parte geográfica que indicamos en el capítuo anterior (cobertura geográfica general, zona prioritaria, zona de interés) añade contexto, así evitamos tratar todos los eventos como si tuvieran el mismo valor. Un gran festival en otro continente puede seguir siendo interesante, pero una fecha de un artista prioritario en Madrid debería destacar mucho más.

Con esto ya tenemos definido qué queremos seguir de forma consciente. El siguiente paso será añadir una capa más interesante: permitir que el radar también encuentre cosas que no habíamos incluido previamente en ninguna lista.

Vigilando eventos

Los radares: convertir una búsqueda en un sistema

Hasta ahora hemos definido lo que ya sabemos que nos interesa. Pero si el sistema solo buscara esos nombres, seguiríamos dependiendo demasiado de nuestras propias listas.

Por eso añadimos los radares. Un radar es una categoría de búsqueda independiente que puede ser geográfica, temática o de descubrimiento. En TechnoRadar vamos a empezar usando tres:

• 🇪🇸 España

• 📼 Remember

• 🌍 Radar Abierto

La configuración queda así:

## 1.4 RADARES ACTIVOS
--------------------------------------------------
### RADAR 01
[ACTIVO]: Sí
[NOMBRE]: España
[EMOJI]: 🇪🇸
[TIPO]: Geográfico
[DESCRIPCIÓN]: Eventos relevantes celebrados en España.
[CRITERIOS]
- Evento celebrado en España.
- Prioridad adicional si se celebra en Madrid o alrededores.
- Incluir eventos no prioritarios si son suficientemente interesantes.
[PRIORIDAD]: Alta

### RADAR 2
[ACTIVO]: Sí
[NOMBRE]: Remember
[EMOJI]: 📼
[TIPO]: Temático
[DESCRIPCIÓN]: Fiestas y festivales relacionados con música Remember.
[CRITERIOS]
- años 90
- eurodance
- makina
- bakalao
- trance clásico
- techno clásico
- dance 90s
- electrónica de finales de los 90 y primeros 2000
[PRIORIDAD]: Alta

### RADAR 3
....

Esta parte es la que hace realmente reutilizable el sistema. Podemos añadir o quitar radares sin tocar el resto del prompt. Por ejemplo, podríamos crear uno para Ibiza, otro para Hard Techno o, en otro tipo de proyecto, uno para congresos de IA, ferias de motor o eventos gastronómicos.

Además, un mismo evento puede pertenecer a varios radares. Una fiesta Remember en Madrid podría aparecer a la vez como: 🇪🇸 España + 📼 Remember, así, el radar deja de ser una simple lista de búsquedas y empieza a funcionar como un pequeño sistema de clasificación de oportunidades.

También podemos añadir unos criterios globales de calidad

## 1.5 CRITERIOS GLOBALES DE PRIORIDAD
--------------------------------------------------
Dar mayor puntuación a eventos que cumplan una o varias de estas condiciones:
1. Aparece uno de los artistas prioritarios.
2. Es uno de los festivales o eventos prioritarios.
3. Se celebra en la zona prioritaria.
4. Se celebra en la ciudad o zona de especial interés.
5. Tiene un cartel especialmente potente.
6. Es un evento singular o poco frecuente.
7. Las entradas acaban de salir.
8. Puede agotarse pronto.
9. Está próximo en el tiempo.
10. Pertenece a uno de los radares activos.
11. Merece desplazamiento o viaje.
12. Es un evento de gran relevancia internacional.
13. Tiene una combinación especialmente atractiva de artistas, lugar y fecha.
14. Supone una oportunidad que conviene conocer con antelación.

El objetivo del radar: detectar oportunidades, no acumular eventos

Antes de definir cómo buscar, necesitamos dejar claro qué esperamos del resultado. Un radar útil no debería limitarse a devolver una agenda. Su función es ayudar a detectar oportunidades con tiempo suficiente para actuar.

La sección del prompt puede quedar así:

## 2. OBJETIVO DEL INFORME
============================
Crear un radar que permita saber con antelación qué eventos interesantes se aproximan. El informe NO debe limitarse a listar eventos. Debe ayudar a tomar decisiones. Debe detectar situaciones como:
- "Esto ocurre dentro de tres semanas."
- "Este DJ prioritario toca en Madrid."
- "Merece plantearse un viaje."
- "Acaban de anunciar este festival."
- "Las entradas ya están a la venta."
- "Este evento puede agotarse."
- "Este evento está sold out."
- "Este evento ha cambiado de fecha."
- "Este evento ha sido cancelado."
- "Esto no estaba en nuestra lista, pero merece mucho la pena."

[OBJETIVO PRINCIPAL]: NO ENTERARSE TARDE DE EVENTOS INTERESANTES.
[FILOSOFÍA]: DETECCIÓN DE OPORTUNIDADES, no simple agregación de información.

Este bloque es importante porque condiciona todo lo que viene después. Si solo pedimos “buscar eventos”, obtendremos una lista. Si pedimos detectar oportunidades, el sistema tiene una razón para priorizar, destacar y ordenar la información según su utilidad.

Investigar bien: fuentes, validación y calidad

Una vez definido qué queremos encontrar, toca decidir cómo debe buscarlo el sistema. En un radar de eventos la calidad de la información es crítica. Una fecha incorrecta, un recinto equivocado o un evento ya celebrado puede hacer que todo el briefing pierda valor.

Por eso añadimos una jerarquía de fuentes y unas reglas mínimas de verificación.

## 3. INVESTIGACIÓN EN INTERNET
==============================
[OBJETIVO]:
Buscar información actualizada sobre los eventos incluidos dentro del horizonte temporal definido.

[PRIORIDAD DE FUENTES]:
1. Web oficial del evento.
2. Ticketing oficial.
3. Web oficial del artista.
4. Plataformas especializadas: Resident Advisor, Dice, Songkick, Bandsintown, etc.
5. Medios especializados y otras fuentes fiables.

[REGLAS]:
- Priorizar siempre la fuente oficial más reciente.
- Comprobar fecha, año, ciudad y recinto.
- Evitar eventos ya celebrados.
- Evitar duplicados.
- No mezclar artistas o eventos con nombres similares.
- No inventar fechas, carteles, precios, horarios o disponibilidad.
- Si una información no está suficientemente confirmada, no presentarla como segura.

La clave aquí no es obligar a usar una web concreta, sino indicar qué fuentes tienen más peso.

También conviene aceptar que algunos datos pueden no estar disponibles todavía. Si no hay precio, horario o cartel completo, es mejor omitirlo que rellenar ese hueco con una suposición.

Con este bloque, el radar empieza a comportarse menos como un buscador y más como un pequeño proceso de investigación y validación.

Investigación

La ventana temporal: cuánto queremos mirar hacia delante

Un radar de eventos necesita un límite temporal claro. Si buscamos demasiado poco, llegaremos tarde; si buscamos demasiado, el informe puede llenarse de eventos todavía poco relevantes.

Por eso usamos el horizonte definido en la configuración:

## 4. VENTANA TEMPORAL
======================
Buscar eventos entre:
FECHA ACTUAL y FECHA ACTUAL + [HORIZONTE_TEMPORAL]

Si existe un evento especialmente relevante justo fuera del rango, puede aparecer en una pequeña sección: "Próximamente fuera del radar" pero únicamente si merece claramente la pena.

En TechnoRadar hemos elegido 90 días porque permite anticipar compras de entradas, viajes o reservas sin convertir el briefing en una agenda de todo el año. El valor está en que sigue siendo configurable: para otro tipo de radar quizá basten 30 días, mientras que una feria profesional o un congreso podrían necesitar seis meses de antelación. Así, el radar mantiene una mirada suficientemente larga para anticiparse, pero lo bastante corta como para seguir siendo útil y manejable.

Alerta y prioridad: hacer visible lo importante

Una vez definido qué buscar y durante cuánto tiempo, necesitamos decidir qué merece destacar. El radar no debería obligarnos a revisar todo para descubrir que hay algo importante mañana o que uno de nuestros artistas prioritarios toca cerca.

Por eso añadimos una alerta principal:

## 5. ALERTA PRINCIPAL
======================
[SECCIÓN]: 🚨 ALERTA [NOMBRE_DEL_RADAR]
[CASOS DE ALERTA]
- evento hoy o mañana o en menos de 3 días
- evento este fin de semana
- artista prioritario en la ciudad prioritaria
- venta de entradas recién abierta
- evento cerca de agotarse
- cancelación o cambio de fecha
- cambio importante de cartel

[REGLAS]
- Mostrar entre 1 y 3 alertas cuando existan.
- Incluir fecha, ciudad, recinto, artistas principales y enlace.
- Explicar brevemente por qué merece atención.
- Dar a esta sección mayor peso visual que al resto.

La alerta debe destacar visualmente mucho más que el resto del contenido.
Debe ser lo primero que llame la atención al abrir el HTML.

La prioridad no depende solo de la fecha. Un evento dentro de dos meses puede ser más interesante que uno mañana si combina un artista prioritario, una ubicación cercana o un cartel especialmente atractivo. Así conseguimos que el radar no solo nos diga qué va a ocurrir, sino también dónde deberíamos mirar primero.

Del dato al briefing visual

Hasta aquí hemos definido qué buscar, cómo validarlo y qué debe destacar. El siguiente paso es decidir cómo queremos consumir esa información. No queremos una respuesta larga en texto. Queremos un briefing que se pueda abrir, recorrer y entender de un vistazo.

Por eso pedimos un HTML autocontenido con una estructura visual clara:

## 6. SALIDA VISUAL
====================
[FORMATO]: HTML autocontenido y descargable.
[OBJETIVO]: Convertir la información en un briefing visual, no en una lista de resultados.
[ESTRUCTURA]
- Cabecera con nombre, fecha, cobertura y horizonte temporal.
- 🚨 Alerta principal.
- Una sección por cada radar activo.
- 🎧 Artistas prioritarios.
- 🎪 Eventos prioritarios.
- ⚠️ Cambios y cancelaciones.
- 🎯 Selección final.

[COMPONENTES VISUALES]
- tarjetas
- badges
- titulares claros
- bloques destacados
- tablas cuando ayuden a resumir
- enlaces directos a las fuentes
- jerarquía visual entre información normal, prioritaria y urgente

Pero la estructura no es suficiente. También definimos explícitamente el estilo visual, porque si no lo hacemos, dejamos esa decisión completamente abierta.

Esta parte del prompt también es importante: no solo estamos definiendo qué debe decir el radar, sino también cómo queremos que se sienta al abrirlo. La idea es que se parezca más a una publicación digital que apetece recorrer que a un informe técnico lleno de datos.

También definimos el comportamiento responsive. Si el radar va a consultarse igual desde el ordenador que desde el móvil, merece la pena decirle explícitamente cómo debe adaptarse a cada formato.

## 8. DISEÑO RESPONSIVE
========================
El HTML debe estar diseñado específicamente para: 
- ordenador
- tablet
- móvil
[ORDENADOR]
- tarjetas en 2 o 3 columnas cuando tenga sentido
- buena densidad de información
- navegación horizontal clara
[TABLET]
- adaptación a 1 o 2 columnas
- controles y enlaces cómodos de pulsar
- tablas con scroll horizontal si es necesario
[MÓVIL]
- tarjetas en una sola columna
- navegación horizontal desplazable
- tipografía legible
- botones y enlaces táctiles
- márgenes reducidos
- tablas adaptadas o con scroll horizontal
La experiencia móvil no debe ser una simple versión encogida del escritorio.

Menos filtros y más navegación

En una primera versión pensamos en añadir filtros por ubicación, tipo de evento, artista o periodo. Funcionaban, pero convertían el radar en algo demasiado parecido a una base de datos, pero ese no era el objetivo.

Queríamos un briefing que se pudiera recorrer rápidamente, no una herramienta que exigiera configurar la vista antes de leerla.

Por eso sustituimos los filtros por una navegación simple entre secciones:

## 9. NAVEGACIÓN RÁPIDA
===========================
No utilizar filtros ni controles de búsqueda.
Añadir una barra de navegación sticky con saltos internos a:
- 🚨 Alerta
- cada radar activo
- 🎧 Artistas prioritarios
- 🎪 Eventos prioritarios
- ⚠️ Cambios y cancelaciones
- 🎯 Selección del radar

La navegación debe generarse automáticamente a partir de los radares activos.
[ORDENADOR] Barra horizontal compacta.
[TABLET] Mantener navegación horizontal siempre que sea posible.
[MÓVIL] Permitir desplazamiento horizontal táctil.

Añadir opcionalmente un botón discreto:
↑ Volver arriba

La diferencia parece pequeña, pero cambia bastante la experiencia. En lugar de preguntarnos “¿qué filtro aplico?”, simplemente saltamos a la parte que nos interesa: Remember, España, DJs prioritarios o Radar Abierto. Es una de esas decisiones en las que mejorar el resultado no consiste en añadir más funciones, sino en quitar fricción.

La estructura final del Radar

Con las decisiones anteriores ya podemos definir la arquitectura completa del briefing. La idea es mantener siempre el mismo orden para que el lector sepa dónde encontrar cada cosa, aunque cambien los artistas, los eventos o incluso la temática del radar.

## 10. ESTRUCTURA FINAL DEL INFORME
==================================
1. CABECERA
   - Nombre del radar
   - Descripción
   - Fecha
   - Cobertura
   - Horizonte temporal
   - Radares activos

2. 🚨 ALERTA [NOMBRE_DEL_RADAR]
   - Entre 1 y 3 alertas cuando existan.

3. RADARES ACTIVOS
   - Crear una sección por cada radar configurado como activo.
   - Usar automáticamente su nombre, emoji, descripción y criterios.

4. 🎧 ARTISTAS / ENTIDADES PRIORITARIAS
   - Mostrar sus próximas fechas relevantes.

5. 🎪 EVENTOS / FESTIVALES PRIORITARIOS
   - Mostrar próximas ediciones, fechas, carteles, entradas y estado.

6. ⚠️ CAMBIOS Y CANCELACIONES
   - Mostrar solo cuando exista información relevante.

7. 🎯 SELECCIÓN DEL RADAR
   - Resumir entre 8 y 15 oportunidades especialmente interesantes.

La última sección funciona como una especie de resumen ejecutivo. No sustituye al resto del radar, pero permite terminar la lectura con una selección clara de aquello que merece tener en mente.

Con esto ya tenemos prácticamente construido el motor del sistema: sabemos qué buscamos, cómo lo investigamos, cómo lo priorizamos y cómo queremos que se presente. El siguiente paso será el que realmente demuestra que no hemos creado solo TechnoRadar: convertir toda esta estructura en una plantilla reutilizable para cualquier otro tipo de evento.

De TechnoRadar a cualquier radar de eventos

Llegados a este punto, TechnoRadar ya es solo un ejemplo. La estructura que hemos construido puede reutilizarse para casi cualquier tipo de evento porque la lógica permanece intacta y lo único que cambia es la configuración inicial.

Por ejemplo, podríamos crear:

• AIRadar para congresos, presentaciones y eventos de inteligencia artificial.

• MotorRadar para ferias, concentraciones y pruebas.

• GastroRadar para ferias gastronómicas, jornadas y festivales.

• PMRadar para congresos y encuentros de Project Management.

• TravelRadar para eventos interesantes en una ciudad o país concreto.

La adaptación se hace modificando únicamente la cabecera de configuración:

## 1. CONFIGURACIÓN EDITABLE
==============================
[NOMBRE_DEL_RADAR]: AIRadar
[DESCRIPCIÓN]: 
Radar de congresos, conferencias y eventos relacionados con inteligencia artificial.
[HORIZONTE_TEMPORAL]: 180 días
[ZONA_PRIORITARIA]: Europa
[CIUDAD_O_ZONA_DE_ESPECIAL_INTERÉS]: Madrid
[ENTIDADES PRIORITARIAS]:
- OpenAI
- Microsoft
- Google
- NVIDIA
[EVENTOS PRIORITARIOS]:
- Web Summit
- Mobile World Congress
- South Summit

Después solo tendríamos que redefinir los radares activos, por ejemplo:

### RADAR 1
[NOMBRE]: España
[TIPO]: Geográfico

### RADAR 2
[NOMBRE]: IA Generativa
[TIPO]: Temático

### RADAR 3
[NOMBRE]: Radar Abierto
[TIPO]: Descubrimiento

El resto del sistema puede permanecer igual. Y ahí está precisamente la parte más interesante del proyecto: no hemos construido un prompt para buscar fiestas, sino una plantilla de vigilancia de eventos que se puede adaptar a casi cualquier ámbito.

Radar de eventos

El prompt definitivo

Después de construirlo por partes, ya podemos reunir todo en una única versión coherente. La estructura final del prompt queda dividida en dos zonas muy claras:

1. Configuración editable

• identidad del radar;

• horizonte temporal;

• cobertura;

• artistas o entidades prioritarias;

• eventos prioritarios;

• radares activos.

2. Motor del sistema

• objetivo del informe;

• investigación y fuentes;

• ventana temporal;

• alertas;

• prioridad;

• estructura visual;

• responsive;

• navegación;

• control de calidad;

• generación del HTML.

Ese reparto es importante porque permite reutilizar el radar sin tener que tocar su lógica interna.

Una versión resumida de la cabecera quedaría así:

# PROMPT MAESTRO — RADAR DE EVENTOS
## 1. CONFIGURACIÓN EDITABLE
[NOMBRE_DEL_RADAR]: TechnoRadar
[DESCRIPCIÓN]:
Radar mundial de música electrónica, techno, DJs, festivales y fiestas Remember.
[HORIZONTE_TEMPORAL]: 90 días
[COBERTURA_GEOGRÁFICA_GENERAL]: Mundial
[ZONA_PRIORITARIA]: España
[CIUDAD_O_ZONA_DE_ESPECIAL_INTERÉS]: Madrid y alrededores
[ARTISTAS PRIORITARIOS]:
- Miss Monique
- Tiësto
- NOVAH
- Korolova
- Charlotte de Witte
[EVENTOS PRIORITARIOS]:
- Tomorrowland
- Medusa Festival
- Summer History
- Love The 90's
[RADARES ACTIVOS]:
- 🇪🇸 España
- 📼 Remember
- 🌍 Radar Abierto

A partir de ahí, el resto del prompt ya define cómo debe trabajar el radar, no qué debe vigilar.

La instrucción final también deja claro qué esperamos obtener:

[RESULTADO FINAL]:
Generar un único archivo HTML descargable, autocontenido y responsive.
Debe estar optimizado para:
- ordenador
- tablet
- móvil
Debe incluir:
- cabecera
- alerta principal
- radares activos
- artistas prioritarios
- eventos prioritarios
- cambios y cancelaciones
- selección final
- enlaces a las fuentes

Descarga los prompts

Vamos a dejar disponibles dos versiones descargables en formato TXT del prompt que hemos construido a lo largo del artículo:

Prompt Maestro — Radar de Eventos

Es la versión principal que hemos ido construyendo durante el artículo. Es la versión recomendada para empezar y modificar.

TechnoRadar_Prompt.txt

Descargar TXT • 10KB

Prompt Extendido — Radar de Eventos

También incluimos una versión más extensa, que desarrollamos previamente y que añade instrucciones más detalladas sobre el comportamiento del radar, la investigación, la presentación del contenido y la generación del resultado.

Puede resultar útil si queremos dar al modelo más contexto y menos margen de interpretación, especialmente en ejecuciones complejas o cuando queramos mantener un formato muy consistente.

TechnoRadar_Prompt.txt

Descargar TXT • 10KB

Convertirlo en una herramienta: crear un GPT

Hasta ahora tenemos un prompt que podemos copiar, modificar y ejecutar cuando queramos. El siguiente paso lógico es evitar tener que pegarlo cada vez. Para eso podemos crear un GPT específico para nuestro Radar de Eventos.

Además, tendrá la ventaja que una vez generado el informe, podríamos hacer preguntas sobre la información recibida o cualquier otra relacionada, siguiendonos de base, por ejemplo, para, tras ver un evento, ver opciones de viaje, o profundizar en mas detalle, o ver información de los artistas qua aparecen en el evento.

Vamos a configurar el GPT paso a paso:

• Nombre: LK_TechnoRadar

• Icono: creamos un icono para el GPT

• Descripción: LK_TechnoRadar es un radar inteligente de eventos de música electrónica, techno, festivales y fiestas Remember. Busca próximos eventos, sigue DJs y festivales prioritarios, detecta oportunidades relevantes y genera briefings actualizados, incluyendo una versión HTML descargable y responsive.

• Instrucciones: las instrucciones ya están en el archivo de texto con el prompt que le voy a subir como conocimiento. No se incluye como texto directamente en el campo instrucciones porque el límite es de 8.000 caracteres.

  
  

Así que en el campo de texto ponemos únicamente indicaciones para iniciar la conversación y para que sepa que las instrucciones completas están en e archivo TXT que hemos incluido en su conocimiento.

GPT TechnoRadar

El enlace para acceder al GPT sería este: "https://chatgpt.com/g/g-6aa7023f66788191922478696d0ed622-technoradar", pero lamentablemente OpenAI ha dejado de permitir comparrtir GPTs y los mantiene ahora mismo como algo que sólo quien lo crea lo puede usar.

Septiembre 2026 - OpenAI no permite compartir GPTs

Con el GPT ya no tenemos que recordar el prompt, ni copiarlo cada vez que lo queramos usar, pero podemos ir un paso más alla: conseguir que ni siquiera tengamos que acordarnos de ejecutarlo manualmente.

Automatizar TechnoRadar con ChatGPT Work

Hasta ahora hemos creado dos cosas distintas:

• un Prompt Maestro, donde vive toda la lógica de TechnoRadar;

• un GPT personalizado, LK_TechnoRadar, para ejecutar el radar manualmente de forma cómoda.

El siguiente paso es conseguir que el informe aparezca sin tener que acordarnos de pedirlo, y aquí entra la automatización. ChatGPT permite crear tareas programadas que se ejecutan de forma periódica. Se gestionan desde la sección Programadas, disponible en web, móvil y aplicación de escritorio para cuentas compatibles.

Pero hay una limitación importante: Las tareas programadas no pueden utilizar directamente GPTs personalizados. Por tanto, no podemos decir simplemente: “Ejecuta LK_TechnoRadar cada jueves.”. Tenemos que trasladar a la tarea las instrucciones necesarias para realizar el radar.

Vamos dentro de ChatGPT a la zona de "Programadas", y ahí vamos a "Crear" y crearemos una nueva tarea. Usaremos el asístente, así que podemos incluir un prompt como este y añadir el archivo con el prompt:

Todos los jueves por la mañana genera una nueva edición de TechnoRadar.

Busca información actualizada en Internet para los próximos 90 días.

Utiliza las reglas, configuración, radares, prioridades y formato definidos en las instrucciones de esta tarea "TechnoRadar_Prompt.txt".

Genera el resultado como un archivo HTML descargable.

Crear tarea programada

Conclusión

Con esto cerramos el recorrido completo:

Prompt → GPT → Work → Radar periódico

Lo que empezó como una búsqueda puntual termina convertido en un pequeño sistema capaz de investigar, seleccionar, priorizar y preparar periódicamente la información que nos interesa.

TechnoRadar es solo el ejemplo. Cambiando la configuración, el mismo enfoque podría utilizarse para seguir congresos, exposiciones, ferias, viajes, eventos deportivos, gastronomía o cualquier otro tipo de evento que queramos mantener bajo vigilancia.

La idea de fondo es sencilla: no se trata solo de pedir información a ChatGPT, sino de definir qué nos interesa y construir un sistema que se ocupe de buscarlo por nosotros con antelación.