De tu carpeta a la del equipo: instrucciones que todos reutilizan

Este artículo es la segunda parte de la serie Del prompt al sistema. La primera trató sobre cómo una persona deja de escribir prompts y le da contexto a su herramienta. Esta trata sobre el paso siguiente: cómo un equipo convierte lo que una persona hace bien en instrucciones que todos reutilizan. La tercera cerrará con por qué el sistema que construyes alrededor del modelo importa más que el modelo.

Hace poco revisé cómo usaba la IA el equipo comercial de una empresa de servicios en Bogotá. Cinco personas, las cinco con su asistente configurado, las cinco convencidas de que lo usaban bien. Y en buena medida era cierto: cada una había armado su carpeta de contexto, más o menos como la del artículo anterior. El problema apareció cuando pedí la misma cosa en los cinco asistentes: una propuesta para un cliente nuevo. Salieron cinco propuestas con cinco estructuras, dos listas de precios distintas, tres formas de nombrar el mismo servicio y una que todavía ofrecía un plan que la empresa había retirado en junio. Cada persona tenía una IA que sabía cómo trabajaba ella. Ninguna tenía una IA que supiera cómo trabajaba la empresa.

Ese es el techo del contexto personal. Funciona muy bien para uno y se rompe en cuanto son varios, por tres razones que se repiten en todas las empresas que he visto. Primero, el esfuerzo se duplica: cinco personas escribiendo cinco veces la misma página sobre qué hace la empresa. Segundo, los resultados divergen: la calidad del trabajo depende de quién armó mejor su carpeta, y el cliente nota la diferencia. Y tercero, el conocimiento se va con la persona: cuando la mejor vendedora renuncia, su carpeta se va con ella y el equipo vuelve a cero.

Las tres piezas que un equipo comparte

La solución no es un prompt mejor ni una herramienta nueva. Es separar lo que es de cada persona de lo que es de la empresa, y poner lo segundo en un lugar donde todos lo usen sin copiarlo. En la práctica son tres piezas, de la más estable a la más puntual.

1. El contexto compartido. Las dos primeras capas del artículo anterior, pero en una sola versión para todos: quién es la empresa, qué vende y qué no, cómo escribe, qué reglas de negocio nunca se saltan. Esto se escribe una vez, tiene un dueño y vive en un espacio común. Todas las herramientas lo permiten hoy: un Proyecto compartido en Claude, un GPT del equipo en ChatGPT, un Gem compartido en Gemini. Cada persona conserva su carpeta personal para lo suyo (su rol, sus clientes, sus proyectos), pero la parte de la empresa ya no se reescribe. Con esto solo, las cinco propuestas de la empresa de servicios habrían salido con la misma lista de precios.

2. Las skills. Esta es la pieza que casi nadie tiene y la que más cambia las cosas. Una skill es un procedimiento escrito para una tarea que se repite: cómo hacemos una propuesta comercial, cómo respondemos una queja, cómo preparamos el informe mensual para la junta. No es una instrucción de dos líneas; es la receta completa, con los pasos, el formato de salida, dos ejemplos de cómo queda bien y la lista de cosas que hay que verificar antes de entregar. El modelo la lee cuando le toca esa tarea, y la ejecuta igual sin importar quién se la pidió. El nombre viene de Anthropic, que las formalizó como archivos que Claude carga cuando los necesita, pero la idea sirve con cualquier herramienta: si tu equipo usa ChatGPT, una skill es un documento dentro del GPT compartido que las instrucciones dicen cuándo consultar.

3. Las plantillas y prompts compartidos. La versión ligera. Para las tareas que no justifican una skill completa, un prompt con huecos para rellenar alcanza: el resumen de una reunión, la circular para padres de familia, el correo de seguimiento a un cliente que no respondió. Se copian, se completan, se usan. Tenemos una colección pública de prompts y otra de skills listas para copiar en un Proyecto, un GPT o un Gem, si quieres ver cómo se ven unas y otras antes de escribir las tuyas.

De lo que alguien hace bien a una skill que todos usan

Lo más valioso que tiene un equipo no está en ningún documento. Está en la cabeza de la persona que hace esa tarea mejor que los demás: la que escribe las propuestas que ganan, la que calma al cliente molesto en dos mensajes, la que entrega el informe que la junta entiende a la primera. Una skill es la forma de sacar eso de una cabeza y ponerlo en un lugar donde el modelo, y el resto del equipo, lo pueda usar. Este es el método que seguimos en Saphia Labs, y toma una semana por tarea, no más.

Elige la tarea, no la persona. Busca algo que se haga al menos una vez por semana, que hoy salga con calidad dispareja según quién lo haga y que tenga un resultado claro: un documento, un correo, una respuesta. Las propuestas comerciales, las respuestas a quejas y los informes periódicos son los tres clásicos. No empieces por la tarea más importante; empieza por la más repetida.

Observa, no entrevistes. Si le preguntas a la persona que mejor lo hace cómo lo hace, te va a dar una versión limpia y falsa. Mejor siéntate a su lado la próxima vez que lo haga y anota lo que hace de verdad: qué abre primero, qué revisa, qué se salta, dónde duda, qué corrige al final. Las reglas que valen son las que ella no sabe que aplica. "Siempre abro la última propuesta de un cliente parecido antes de empezar" es una regla. "Reviso que los precios estén sin IVA" es otra. Van las dos.

Escribe el procedimiento en el orden en que ocurre. Qué necesita el modelo para empezar (qué le vas a dar: el correo del cliente, el brief, los datos del mes). Los pasos en orden. El formato exacto de la salida: secciones, extensión, tono, qué va primero. Y al final, la lista de verificación: las cinco cosas que la persona experta revisa antes de enviar. Esa lista es la parte que más valor tiene y la que más se olvida. Una skill buena cabe en una o dos páginas. Si llega a cinco, estás escribiendo un manual, no una skill.

Agrega dos ejemplos. Uno de cómo queda bien y otro de cómo no. Si tienes la propuesta que ganó y la que se perdió por mal planteada, úsalas. Un ejemplo real le enseña al modelo más que una página de reglas, y a la persona nueva del equipo también.

Prueba con quien no es experto. Dale la skill a la persona que peor hace esa tarea hoy y pídele que la use con un caso real. Compara el resultado con lo que esa persona entregaba antes y con lo que entrega la experta. Si el resultado se parece más al de la experta, la skill funciona. Si no, lo que falta es casi siempre una regla que la experta aplica sin saberlo. Vuelve a observar.

Tres skills bien hechas cubren la mayor parte del trabajo repetido de un equipo pequeño. No hacen falta veinte. Y la regla de mantenimiento es la misma del artículo anterior, pero ahora con destinatario: cuando alguien corrige al modelo dos veces por lo mismo, le manda la corrección al dueño de la skill. Una línea. El dueño la incorpora o la descarta, y la skill mejora con el uso de todos, no solo con el de quien la escribió.

Las convenciones: dónde vive, quién lo cuida

Una skill sin dueño muere en tres meses. Lo he visto suficientes veces como para decirlo sin matices. Lo que separa a los equipos que sostienen esto de los que lo abandonan no es la calidad de lo que escribieron, sino cuatro acuerdos sencillos que tomaron al principio.

Un lugar. El contexto compartido, las skills y las plantillas viven en un solo espacio al que todos acceden: el Proyecto compartido, el GPT del equipo, una carpeta común. No en el chat de cada uno, no en un correo de hace dos meses, no en el escritorio de la persona que lo armó. Si alguien tiene que preguntar dónde está, no hay sistema.

Un dueño por pieza. Cada skill tiene un nombre al lado. Esa persona recibe las correcciones, decide qué entra, y revisa la pieza una vez al mes en un repaso de quince minutos. Normalmente el dueño es la persona que mejor hacía la tarea antes de la skill, y suele estar contenta con el rol: su forma de trabajar se vuelve la del equipo.

Una fecha en cada documento. La primera línea de cada skill y de cada documento del contexto compartido dice cuándo se revisó por última vez. Es la forma más barata de saber que la lista de precios es la vigente y que el plan que se retiró en junio ya no aparece. Un documento sin fecha es un documento en el que nadie confía, y con razón.

Una regla sobre qué entra y qué no. Lo que no iba en la carpeta personal tampoco va en la compartida, con una diferencia: ahora el error se multiplica por el número de personas que lo usan. Datos personales de clientes, credenciales, información de terceros bajo confidencialidad, nada de eso. Si tu empresa todavía no tiene reglas escritas sobre qué se puede compartir con herramientas de IA, este es el momento de tenerlas, antes de que el espacio compartido se llene de cosas que no deberían estar ahí.

Los errores que se repiten

Escribir el manual de la empresa. El primer impulso es volcar todo el conocimiento del equipo en el espacio compartido. El resultado es una skill de veinte páginas que el modelo lee a medias y que nadie mantiene. Una skill cubre una tarea. Si cubre tres, son tres skills.

Escribirla sin probarla. Una skill que sale de una reunión y nunca pasa por un caso real es una lista de buenos deseos. La prueba con la persona no experta no es opcional: es la única forma de saber que la receta funciona sin la experta al lado.

Dejar que cada uno siga con lo suyo. Cuando el espacio compartido existe pero cada persona sigue usando su carpeta personal para las tareas de la empresa, no cambió nada. Las primeras semanas hay que ser explícito: las propuestas salen de la skill de propuestas, aunque la tuya te guste más. Lo que te guste más se lo mandas al dueño, y si es mejor, entra.

Creer que la skill reemplaza el criterio. Una propuesta que sale de una skill bien hecha es un borrador muy bueno con la estructura, los precios y el tono correctos. Sigue siendo un borrador. La lista de verificación al final de la skill existe para que la persona la recorra, no para que el modelo la recite. El costo de verificar baja mucho con una buena skill. No desaparece.

Conclusión

Lo que una persona hace bien es un activo de esa persona. Lo que está escrito como skill, con dueño, fecha y ejemplos, es un activo de la empresa. La diferencia no se nota el primer mes. Se nota cuando entra alguien nuevo y entrega una propuesta decente la primera semana, y se nota más cuando se va alguien bueno y las propuestas siguen saliendo igual.

Este mes, elige una tarea repetida, siéntate al lado de quien mejor la hace y escribe la skill. Pruébala con quien peor la hace. Ponle dueño y fecha. Si al final del mes las dos personas entregan algo parecido, acabas de convertir conocimiento tácito en un activo que no se va con nadie.

Y cuando tengas el contexto compartido, tres skills y las convenciones funcionando, te vas a dar cuenta de algo que a mí me tomó tiempo ver: la calidad de lo que entrega tu equipo con IA ya casi no depende de qué modelo usas. Depende de todo lo que armaste alrededor. De eso trata la tercera parte de esta serie.