Cuando utilizas la IA en tareas recurrentes, quizá notes que redactas una y otra vez los mismos tipos de prompts: un correo cordial pero firme para rechazar una propuesta, una revisión documental, apoyo estructurado para tomar decisiones o un briefing de imagen. Al reescribir la estructura, también cambian las instrucciones, lo que dificulta comparar los resultados.
Una respuesta práctica es una biblioteca de prompts: un conjunto pequeño y seleccionado de plantillas que puedas recuperar, probar y revisar. Aquí explicamos cómo crearla, qué registrar, cómo organizarla y cómo elegir un almacenamiento adecuado.
Una biblioteca compartida de prompts no es un montón de fragmentos. Cada prompt reutilizable necesita un caso de uso, una persona responsable, una versión, ejemplos, límites y una fecha de revisión. De lo contrario, la biblioteca se convierte en consejos obsoletos con un título más atractivo.
Por qué una biblioteca y no «prompts más ingeniosos»
Al leer sobre diseño avanzado de prompts, resulta tentador coleccionar técnicas cada vez más ingeniosas. En un flujo recurrente, una hipótesis más útil es comprobar si una plantilla estable reduce variaciones evitables. Compárala con el método actual en casos representativos, en vez de asumir que reutilizarla mejorará el resultado por sí solo.
Tres beneficios específicos de una biblioteca:
Reduces la configuración repetida. La estructura de la tarea y los marcadores ya están disponibles, aunque cada uso siga necesitando las entradas adecuadas y una revisión.
Los cambios se pueden probar. Una plantilla revisada puede ejecutarse con los mismos casos y criterios de aceptación antes de sustituir la versión anterior.
Tu equipo puede compartir un punto de partida. Las personas pueden usar la misma versión aprobada en lugar de reconstruirla a partir del historial del chat.
Hay una cuarta ventaja para los equipos: la calidad se puede revisar. Un prompt perdido en el historial de chat de una persona no se presta a revisión, control de versiones o mejora colectiva. Uno guardado en una biblioteca sí.
Qué debe incluir una biblioteca
Una biblioteca útil de prompts tiene tres capas. Las construiremos por separado.
Capa 1: Plantillas de uso frecuente
Empieza por los prompts recurrentes cuyos resultados importen lo suficiente como para probarlos. Cada entrada debe ser una plantilla completa con marcadores y un registro de cómo se evaluó.
Algunas candidatas posibles son:
El redactor de correos estructurado.
Redacta un correo con mi voz. Contexto: {{situation}}. Audiencia: {{recipient and their preferences}}. Objetivo: {{what I want to happen}}. Restricciones: menos de {{N}} palabras, terminar con una acción concreta y no utilizar «Espero que estés bien». Produce tres versiones: breve, media y extensa. Identifica cada una.
El revisor de documentos en tres pasos.
Revisa el documento que voy a compartir en tres pasos:
Pasada 1: Primera impresión. ¿Qué tipo de documento es, cuáles son sus tres conclusiones principales y cuál es su estructura general? Pasada 2: Riesgos y señales de alerta. ¿Qué cláusulas o secciones podrían perjudicarme? Cita cada una y explica el riesgo con lenguaje sencillo. Pasada 3: Decisiones y acciones. ¿Qué debo decidir, preguntar o hacer? Enuméralo e incluye los plazos indicados.
Marca la incertidumbre con [unclear]. Mi contexto: {{your role and stake}}.
El compañero de debate para decisiones.
Estoy decidiendo {{the decision}}. Antes de decir nada, haz solo las preguntas necesarias para aclarar las opciones, las restricciones, los criterios de éxito y lo que más lamentaría. Espera mis respuestas. Después, enumera los argumentos más sólidos a favor de cada opción, las alternativas que podría estar pasando por alto, la dimensión más importante y mi suposición más débil. Actúa como abogado del diablo frente a mi preferencia. Por último, ofrece una recomendación matizada e indica qué evidencia la cambiaría; no trates una puntuación de confianza declarada por el propio modelo como evidencia calibrada.
El analizador estructurado.
Analiza {{the thing}} con esta estructura:
Qué es (un párrafo) Las tres características más importantes (con evidencia para cada una) Dónde destaca (cuándo lo utilizaría) Dónde falla (cuándo no lo utilizaría) Errores comunes al usarlo Dos observaciones realmente útiles que un lector ocasional pasaría por alto
Sé específico. Evita las generalidades.
El reescritor con coincidencia de voz.
Reescribe este borrador para que coincida con mi voz, definida por estos ejemplos: {{example 1}} {{example 2}} {{example 3}}
Edita de forma quirúrgica: conserva la estructura y cambia únicamente lo que no coincida con la voz. Cita cada cambio y explica el motivo en una frase breve.
Crea solo las entradas que justifique tu trabajo recurrente. El conjunto será distinto para un ingeniero, una profesional de marketing o un abogado. El patrón común es una plantilla probada, con marcadores claros y un límite de revisión explícito.
Capa 2: Enfoques por dominio
Algunos tipos de trabajo necesitan sus propios enfoques, distintos de las plantillas generales anteriores. Ejemplos:
Síntesis de entrevistas con clientes.
A partir de esta transcripción de una entrevista con un cliente, extrae:
- Sus palabras exactas sobre los problemas que experimenta (citas textuales con marcas de tiempo)
- Las funcionalidades o mejoras que desea, ordenadas según la intensidad con que las menciona
- El producto que utiliza actualmente y qué le gusta o disgusta de él
- Cualquier necesidad no satisfecha que haya insinuado sin expresarla directamente
- Las frases exactas con las que se describe a sí mismo y explica su trabajo
Cita al cliente siempre que sea posible. Marca cualquier inferencia con [my read]. Sé específico.
Generación de especificaciones técnicas.
A partir de esta descripción de una funcionalidad, genera una especificación técnica con el formato de nuestro equipo:
- Planteamiento del problema (la necesidad del usuario, expresada con sus palabras)
- Solución propuesta (a alto nivel)
- Flujos detallados (flujo principal + 2-3 casos límite)
- Fuera de alcance (objetivos que se excluyen expresamente)
- Preguntas abiertas (aspectos que requieren una decisión antes de implementar)
- Riesgos (ingeniería, producto, negocio)
- Métricas de éxito (cómo sabremos que funcionó)
Tono: directo, sin evasivas. Cita mis palabras cuando expresen bien una idea. Marca con [confirm] cualquier punto en el que hayas tenido que inventar detalles.
Ayuda para revisión de código.
Revisa el código siguiente. En orden:
- Errores: código que producirá un comportamiento incorrecto. Cita y explica.
- Problemas de seguridad: cualquier elemento que amplíe la superficie de ataque. Cita y explica.
- Problemas de rendimiento: cualquier elemento que probablemente sea lento a escala, con una estimación aproximada del orden de magnitud.
- Mantenibilidad: cualquier elemento que pueda confundir a la siguiente persona que lea el código.
- Detalles de estilo: señálalos solo si importarían a un revisor cuidadoso; evita los reparos insignificantes.
No reescribas el código. Cita los números de línea. Termina con la corrección más importante.
Cada plantilla está adaptada a un tipo de trabajo. Crea una plantilla de capa 2 para cada categoría de tarea que se repita en tu flujo.
Capa 3: Materiales de referencia para adjuntar
Algunos prompts necesitan archivos de apoyo, no solo instrucciones. Tu biblioteca debe incluir:
- Ejemplos de voz de marca. Entre tres y cinco textos breves que reflejen la voz deseada.
- Guías de estilo. Los estándares editoriales de tu empresa, el estilo de código de tu equipo, tus tokens de diseño.
- Glosarios por dominio. Terminología interna, nombres en clave y abreviaturas que el modelo podría interpretar mal.
- Plantillas. Las estructuras reales de plantilla que deseas que el modelo rellene.
- Contraejemplos. Material que debe evitarse: ejemplos genéricos, alejados de la marca o mal estructurados que muestran al modelo qué no debe producir.
Almacenar estos junto con tus prompts significa que cualquiera que aplique una plantilla también puede acceder a los materiales de referencia adecuados.
Dónde almacenar la biblioteca
Elige el almacenamiento según los controles y el flujo que necesites, no según una clasificación genérica. Compara estas dimensiones:
Acceso y permisos. ¿Quién puede leer, ejecutar, editar, aprobar y retirar una entrada?
Fricción de recuperación y captura. ¿Las personas pueden encontrar la versión aprobada en el momento de trabajar y guardar una candidata sin perder el contexto?
Versionado y revisión. ¿Puedes comparar cambios, conservar el historial, exigir aprobación y revertir?
Evidencia de evaluación y uso. ¿Puedes vincular casos de prueba y resultados, y distinguir el uso real de una entrada que simplemente existe?
Auditabilidad. ¿Puedes identificar al responsable, la versión activa, la configuración, la aprobación y el límite de uso?
Coste y portabilidad. ¿Cuáles son los costes de suscripción, implantación, migración y dependencia del proveedor?
Varios patrones de almacenamiento pueden satisfacer distintas combinaciones de esos requisitos:
Almacenamiento ligero e individual
Herramientas de expansión de texto como los fragmentos de Raycast, Espanso o TextExpander. La recuperación puede ser rápida para una persona, pero quizá necesites otro sistema para los permisos, los registros de evaluación y la revisión de cambios.
Herramientas documentales o de conocimiento como Apple Notes, Notion, Obsidian o Confluence. Pueden mantener juntos los prompts, la orientación y los ejemplos. Comprueba si sus permisos, historial de versiones, aprobaciones y opciones de exportación satisfacen tus necesidades.
Almacenamiento gestionado y para equipos
Un repositorio Git de archivos de texto estructurados. Puede proporcionar diferencias, revisión por pares, reglas de propiedad y reversión. Funciona mejor cuando los usuarios se sienten cómodos con el flujo del repositorio o cuando otra interfaz se encarga de la recuperación.
Herramientas de gestión y observabilidad de prompts. Productos como PromptHub, Langfuse o Helicone pueden conectar versiones de prompts con despliegues, evaluaciones y datos de uso. Comprueba sus funciones actuales, la ruta de los datos, los permisos y los precios frente a tus requisitos; por ejemplo, la documentación de gestión de prompts de Langfuse describe prompts versionados y etiquetas de despliegue.
Asistentes guardados en espacios de trabajo gestionados. Los GPT personalizados y los Proyectos de Claude pueden empaquetar instrucciones y material de referencia tras una interfaz de chat. ChatGPT Team pasó a llamarse ChatGPT Business en 2025; los espacios Business y Enterprise pueden compartir GPT conforme a los controles del espacio. Los proyectos de Claude Team y Enterprise pueden compartirse con miembros concretos o con toda la organización y tener permisos por proyecto, como explica la documentación de Proyectos de Claude. Comprueba las políticas actuales de uso compartido, retención, uso de datos y exportación antes de añadir material interno.
Puedes combinar patrones, pero designa una única versión autoritativa para evitar que una copia práctica se aparte sin avisar de la entrada revisada.
El control de versiones importa
Una biblioteca sin control de versiones puede acumular contradicciones y plantillas rotas. Versiona los prompts para que los usuarios puedan identificar la entrada activa, revisar los cambios y revertir cuando sea necesario.
Como mínimo, registra:
- Identidad, propiedad y contrato: nombre de la entrada, versión, responsable, caso de uso aprobado, persona aprobadora cuando sea necesaria, plantilla, entradas obligatorias, salida esperada y regla de revisión humana.
- Última configuración probada: proveedor, modelo o instantánea exactos cuando estén disponibles, instrucciones pertinentes del sistema o del desarrollador, herramientas, fuentes de recuperación y ajustes de razonamiento o generación.
- Evidencia y límites de la evaluación: fecha de la última prueba, casos representativos, criterios de aceptación, resultados, fallos relevantes, usos no aprobados, límite de datos sensibles, modos de fallo conocidos y condiciones que exigen revisión cualificada.
- Alternativa e historial de cambios: qué debe hacer el usuario si faltan entradas, falla un control o la configuración aprobada no está disponible; qué cambió, por qué, quién lo aprobó y qué pruebas se repitieron.
Una práctica útil consiste en archivar la versión anterior cuando hagas un cambio importante y sustituirla por la nueva. Así podrás consultar el historial y recordar por qué se modificó.
En bibliotecas de equipo, somete los cambios importantes a la revisión que requiera el riesgo del flujo. La revisión por pares puede detectar errores, pero no sustituye la evaluación ni la aprobación cualificada cuando sean necesarias.
¿Qué capturar más allá del prompt en sí
Una plantilla de prompt aislada carece de contexto. Una entrada útil de la biblioteca incluye:
- El prompt en sí, con
{{placeholders}}. - El caso de uso previsto: una frase que explique cuándo utilizarlo.
- Un ejemplo completo, identificado claramente como sintético salvo que proceda de un caso aprobado y documentado.
- Las limitaciones conocidas: qué hace mal la plantilla y qué debes vigilar.
- La configuración probada: modelo, ajustes y herramientas pertinentes, fecha de la prueba y base de comparación.
- El autor y la última modificación: quién la creó, cuándo y por qué se hizo el último cambio.
- La regla de revisión: qué revisión humana exige la salida antes de utilizarla.
- El modo de fallo: de qué forma suele fallar la plantilla.
Esto añade trabajo de mantenimiento. Conviene medir si compensa frente al flujo actual: tiempo invertido, tasa de fallos, esfuerzo de revisión y valor de contar con una versión auditable.
La plantilla complementaria ofrece una estructura inicial. Antes de considerar una entrada apta para producción, amplíala con el último modelo y configuración probados, la evidencia de evaluación, los límites y las alternativas descritas arriba.
La disciplina de mantenimiento
Una biblioteca necesita desencadenantes de mantenimiento explícitos:
Revisión por cambios. Repite la evaluación correspondiente cuando cambien el prompt, el modelo, las instrucciones del sistema, las herramientas, la fuente de recuperación, el contrato de salida o la política. No conserves la etiqueta de «probado» de una configuración que difiera de forma sustancial.
Revisión por riesgo. Revisa una entrada cuando pase a un uso con más consecuencias, obtenga acceso a datos sensibles o acciones, o produzca un fallo de impacto relevante. Añade revisión cualificada y controles validados cuando el dominio los exija.
Revisión por uso. Examina las entradas con fallos reiterados, anulaciones, poca adopción o costes inesperados. El poco uso puede indicar escasa visibilidad, una plantilla deficiente o una tarea que no necesita un prompt compartido; los datos de uso por sí solos no permiten distinguir la causa.
Captura con evidencia. Guarda un prompt prometedor como candidato y pruébalo antes de marcarlo como aprobado. Conserva la entrada y la salida solo cuando la política lo permita, y elimina la información sensible.
Consolida duplicados de forma deliberada. Si varias entradas abordan la misma tarea, compáralas con los mismos casos antes de elegir una versión canónica. Mantén variantes separadas cuando respondan a contextos o políticas documentados.
Ejemplo completo: crear una entrada de la biblioteca
Para concretarlo, aquí tienes una entrada sintética. Ilustra el esquema; no demuestra que la plantilla funcione para un cliente, destinatario u organización reales.
Nombre: Redactor de correos en tres versiones
Caso de uso: Redactar un correo cuando aún no he decidido el destinatario, el tono o la extensión y quiero comparar opciones.
Versión: v0.3 (candidata ilustrativa)
Configuración candidata: Un modelo de chat y un espacio de trabajo aprobados por la organización. Compara la configuración normal con una alternativa de mayor razonamiento solo si la evaluación muestra una mejora pertinente.
Última prueba: Aún no se ha probado. Antes de aprobarla, ejecútala con correos sintéticos representativos o autorizados que cubran una petición clara, un límite sensible, contexto ausente y un hilo largo.
Plantilla:
Redacta un correo electrónico con mi estilo.
Contexto: {{the situation, including any prior thread}}
Destinatario: {{who the recipient is — name, role, our relationship, their communication preferences if known}}
Objetivo: {{what I want to happen as a result of this email}}
Restricciones:
- Menos de {{N}} palabras
- Termina con un siguiente paso claro
- No uses «Espero que estés bien», «Quería ponerme en contacto contigo» ni «Avísame si tienes alguna pregunta»
- {{any other specific constraints}}
Prepara tres versiones con estas etiquetas:
1. **Breve y directa** ({{N1}} palabras)
2. **Cercana y convencional** ({{N2}} palabras)
3. **Más larga y detallada** ({{N3}} palabras)
Debajo de cada versión, añade una nota breve: «envía esta versión cuando...»
Límites candidatos que deben validarse:
- Los hilos largos pueden contener antecedentes irrelevantes, contradictorios o sensibles; incluye el mínimo contexto aprobado necesario para la tarea y comprueba que no se haya omitido ningún compromiso imprescindible.
- Es posible que las tres versiones no sean realmente distintas; define criterios de diversidad o solicita menos variantes si las pruebas muestran repeticiones.
- La nota «envía esta versión cuando…» puede generar consejos genéricos; elimínala si no supera la evaluación.
Registro de cambios ilustrativo:
- v3: se añadieron fórmulas de apertura prohibidas; vuelve a ejecutar los casos de tono y seguimiento de instrucciones antes de aprobarla.
- v2: se añadió la nota «envía esta versión cuando…»; comprueba que sea específica y segura.
- v1: candidata inicial.
Cuando la entrada haya superado su evaluación y proceso de aprobación, un usuario podrá recuperar la versión revisada, completar los marcadores y producir un borrador candidato para revisión humana.
La perspectiva del equipo
Para una biblioteca en equipo, algunas consideraciones adicionales:
Vocabulario compartido. Asegúrate de que las plantillas estén escritas para el equipo y no para ti en particular. Sustituye «mi voz» por «la voz de [brand name]» y documenta cómo es.
Incorporación. Enseña a los nuevos usuarios a localizar la versión autoritativa, comprender su límite de uso, aportar entradas aprobadas e informar de fallos. Prioriza las entradas pertinentes para su trabajo en lugar de una cantidad fija.
Responsables. Cada plantilla aprobada necesita una persona responsable de sus desencadenantes de revisión, su evidencia y la decisión de retirarla.
Flujo de aprobación. Ajusta la aprobación a las consecuencias de un fallo. Los flujos dirigidos a clientes o relacionados con asuntos regulatorios, jurídicos, financieros, médicos o de seguridad pueden exigir fuentes autoritativas, revisión cualificada, controles validados y evidencia conservada antes de publicar cambios.
Un hábito pequeño que puede ganar valor
Revisa la biblioteca cuando se activen los desencadenantes definidos. Captura los prompts prometedores como candidatos, adjunta la evidencia permitida y compáralos con la versión actual antes de promoverlos. Registra tanto los fallos como los aciertos para que la selección no se base solo en ejemplos memorables.
El objetivo es una biblioteca cuyas entradas activas tengan responsables, configuraciones actuales, evaluaciones representativas y alternativas claras. Retira las entradas cuyo coste de mantenimiento ya no esté justificado.
Es preferible una biblioteca pequeña y probada a una colección sin revisar
Una biblioteca de prompts puede resultar útil cuando las tareas recurrentes justifican su mantenimiento. Empieza por las plantillas que ya reescribes y mide si reutilizarlas mejora la coherencia, el esfuerzo de revisión, el éxito de la tarea o el coste.
Captura cada candidata con marcadores, un caso de uso, una configuración probada, evidencia, límites conocidos, desencadenantes de revisión y una alternativa. Conserva solo las entradas que sigan siendo útiles bajo esos controles.
