GPTs, proyectos y skills: dejar de reescribir el mismo prompt

Hace tres semanas escribiste el prompt que por fin devolvía el informe con el formato correcto. Lo recuerdas: llevaba el contexto de la empresa, dos ejemplos y la instrucción rara que arreglaba el tono. Hoy lo necesitas otra vez y no aparece. Está en alguna conversación de un jueves, entre otras cuarenta.

Así que lo reescribes de memoria. Sale peor. Y el mes que viene volverás a reescribirlo, un poco peor todavía.

El prompt bueno siempre está en otra conversación

Este ciclo tiene un nombre poco glamuroso: el trabajo no se acumula. Cada conversación empieza de cero, así que el conocimiento que vas ganando sobre cómo hablarle al modelo se evapora en el historial en lugar de convertirse en algo que puedas usar mañana.

Los síntomas son fáciles de reconocer, y si te ves en dos de estos tres, el problema ya está instalado:

• Empiezas los chats importantes pegando un bloque de contexto que has copiado de otro chat.
• Tienes un documento, una nota o un canal donde guardas «prompts buenos» que nadie más consulta.
• Dos personas de tu equipo hacen la misma tarea con instrucciones distintas, y ninguna sabe cuál funciona mejor.

La solución no es escribir prompts más elaborados. Es sacarlos de la conversación y ponerlos en un sitio donde se apliquen solos.

Cuatro niveles de reutilización

Hay cuatro contenedores distintos, y se confunden constantemente porque los nombres comerciales cambian cada seis meses. Lo que no cambia es lo que resuelve cada uno.

Los tres primeros niveles se eligen desde un menú: tú decides qué asistente abrir. El cuarto funciona al revés, y ese es su rasgo distintivo: el skill se activa cuando la tarea encaja con su descripción, sin que nadie lo seleccione. Por eso su descripción importa tanto como su contenido, algo que está desarrollado en la guía sobre qué son los skills.

Por encima del cuarto nivel hay un quinto que conviene nombrar para no confundirlo: conectar el asistente a sistemas reales —tu CRM, tu base de datos, tus tickets— mediante MCP. Eso ya no es reutilizar un prompt, es darle acceso, con las decisiones de permisos que eso arrastra. Va aparte, en la guía de plugins y MCP.

Cuál te toca: tres preguntas

La elección se resuelve casi siempre con tres respuestas, y en este orden.

¿Cuántas veces al mes se ejecuta? Por debajo de dos, no empaquetes nada: una nota con el prompt es suficiente y cualquier otra cosa es sobreingeniería. Entre dos y ocho, un proyecto. Por encima de ocho, o si forma parte de un proceso, merece un activo con nombre.

¿Quién más lo usa? Solo tú: proyecto. Tu equipo, con permiso para adaptarlo: proyecto compartido. Gente que debe usarlo sin modificarlo, incluida gente que se incorpora: GPT o skill. Esta pregunta pesa más que la anterior, porque es la que decide si hace falta que el activo tenga una versión canónica.

¿Necesita evolucionar con control? Si el activo codifica algo que cambia —la política de descuentos, el tono de marca, el formato del informe trimestral— y equivocarse tiene coste, necesitas historial y revisión. Eso hoy solo lo dan bien los skills, porque son ficheros en un repositorio. Un GPT editado a mano por cuatro personas en tres meses es una deuda esperando.

Un atajo que funciona en la mayoría de las organizaciones: los proyectos son para explorar, los skills para lo que ya está decidido. Trabajas en un proyecto hasta que las instrucciones se estabilizan y entonces lo conviertes en skill.

Qué contiene una instrucción reutilizable que aguanta

Un prompt de conversación y una instrucción reutilizable se escriben distinto, y no es cuestión de longitud. El prompt de conversación puede dar cosas por supuestas porque tú estás delante para corregir. La instrucción reutilizable se ejecuta sin ti.

Lo que no puede faltar:

1. Cuándo aplica y cuándo no. La frontera explícita evita que el activo se use para lo que no sirve. En un skill esto va en la descripción y es lo que decide si se carga.
2. El contexto estable. Quién es la empresa, a quién le hablas, qué vocabulario se usa y cuál está prohibido. Todo lo que hoy pegas a mano cada vez.
3. El formato de salida, descrito hasta el detalle aburrido. Secciones, orden, longitud, qué va en tabla. Aquí la ambigüedad se paga cada ejecución.
4. Uno o dos ejemplos completos. Un ejemplo bueno hace más que tres párrafos de explicación, y es lo primero que se omite por prisa.
5. Qué hacer cuando falta información. Sin esta regla, el modelo rellena el hueco. Con ella —«si falta el dato, márcalo como PENDIENTE y sigue»— el hueco queda visible.
6. Un criterio de terminado. Tres o cuatro comprobaciones que el propio modelo aplica antes de devolver. Sube la calidad media sin coste.

El punto cinco es el que más devuelve y el que casi nadie escribe. Un activo compartido se ejecuta a menudo con menos contexto del que tú tenías cuando lo probaste, así que la pregunta no es qué hace con la información completa, sino qué hace cuando le falta la mitad.

El adjunto que cambia el resultado, y el que lo estropea

Poder adjuntar documentos es lo que convierte un asistente genérico en uno que conoce tu casa. También es donde más rápido se degrada.

La intuición dice que más material es mejor contexto. En la práctica ocurre lo contrario a partir de cierto punto: cuando hay veinte documentos parecidos entre sí, la recuperación empieza a devolver el fragmento equivocado, y como la respuesta sigue sonando segura, el error no se ve. El caso típico es el manual con tres versiones: el modelo cita la de 2024 con el mismo aplomo que la vigente.

Tres reglas que evitan casi todo:

• Un documento por asunto, en su versión vigente. Si hay dos versiones, borra una. No hay ninguna configuración que arregle esto.
• Documentos con estructura, no volcados. Un PDF escaneado sin texto o una exportación de mil páginas sin encabezados aportan ruido. Un documento con títulos claros se recupera bien.
• Fecha visible dentro del propio documento. Así, cuando el modelo cita, la cita trae su fecha y tú puedes detectar que viene de material caducado.

Y una precaución que no es técnica: lo que subes a un asistente compartido lo ve todo el que tenga acceso al asistente, no todo el que tenga acceso al documento original. Los permisos del sistema de ficheros no viajan con el adjunto. Es la vía más común de filtración interna involuntaria, y está tratada en la guía de usar IA sin filtrar datos de clientes.

Cuando lo comparte un equipo: la parte que nadie planifica

Compartir un activo es fácil. Mantenerlo vivo es lo que falla, y falla siempre por el mismo sitio: nadie es dueño.

El patrón que se repite: alguien monta un GPT excelente, el equipo lo adopta, funciona tres meses. Cambia la política de precios. El GPT sigue diciendo lo anterior. Nadie lo actualiza porque no está claro de quién es, y como sigue respondiendo con seguridad, tardan seis semanas en darse cuenta. Para entonces la gente ya ha vuelto a escribir sus propios prompts.

Cuatro cosas evitan ese final, y son baratas si se ponen desde el principio:

• Un responsable con nombre, escrito dentro del propio activo. No un equipo: una persona.
• Fecha de última revisión visible en la salida. Que cada respuesta arrastre «instrucciones revisadas el [fecha]» hace evidente lo caducado sin que nadie audite nada.
• Un sitio donde reportar fallos, aunque sea un canal. Sin eso, quien detecta el error simplemente deja de usarlo y no lo cuenta.
• Revisión en el calendario, trimestral. Diez minutos. Si no está en el calendario, no ocurre.

Cuando el activo es un skill en un repositorio, tres de esas cuatro salen gratis: el responsable es quien aparece en el historial, los cambios pasan por revisión y el fallo se reporta como una incidencia. Es la razón práctica por la que el formato de fichero gana al formato de interfaz web en cuanto hay más de dos personas implicadas.

Cinco errores que hacen inútil el activo

El primero es el más frecuente con diferencia. Un activo que empieza resolviendo una tarea acaba, a fuerza de parches, intentando resolver seis, y a partir de ahí no resuelve bien ninguna. La señal de alarma es tener que explicar a alguien «úsalo, pero para lo de los informes ignora la parte de arriba».

Por dónde empezar esta semana

No hace falta un plan. Hace falta una tarea concreta y una hora.

1. Elige la tarea que más repites. No la más importante: la más repetida. Suele ser un resumen, un informe o un tipo de correo.
2. Busca la última vez que salió bien y recupera ese prompt del historial. Ese es el borrador, no lo escribas de nuevo.
3. Añádele lo que falta: cuándo aplica, qué hacer si falta un dato, cómo debe ser la salida, un ejemplo real.
4. Ponlo en un proyecto y úsalo una semana sin tocarlo. Anota cada vez que tengas que corregir algo a mano.
5. Corrige con esas notas y decide: si solo lo usas tú, se queda como proyecto; si lo va a usar alguien más, se convierte en skill.

La parte que hace que esto funcione es el paso cuatro, y es la que se salta todo el mundo. Un activo se afina con lo que falla en uso real, no con lo que uno imagina al escribirlo. Una semana de anotar correcciones vale más que una tarde entera puliendo el texto en abstracto.

Y la regla que queda por encima de todas: si has escrito el mismo prompt tres veces, ya no es un prompt, es una herramienta a medio hacer. Lo único que falta es sacarla de la conversación.