Prompts como activos de producción en una biblioteca de Markdown sencillo

Los buenos prompts suelen desaparecer justo donde se escribieron. El ganador está en mitad de un chat larguísimo, rodeado de borradores abandonados, detalles de producto que cambian y correcciones que solo tienen sentido dentro de ese hilo. Unas semanas después está claro que el resultado fue excelente, pero nadie sabe qué instrucción, adjunto o repregunta lo produjo. Pegar la versión final en una app de notas ayuda un poco, pero un montón de prompts pegados no es más que historial de chat en otro sitio.

Un prompt que funciona en producción necesita más: contexto, entradas definidas, un contrato de salida, criterios de revisión y alguna prueba de que sigue haciendo el trabajo para el que se creó. Unos simples archivos Markdown pueden aportar todo eso.

Carpetas por tarea, no por herramienta

Los nombres de los modelos cambian más rápido que las tareas del negocio. Poner ChatGPT, Claude o Gemini en el nivel superior de la biblioteca solo tiene sentido cuando un prompt depende de verdad de una capacidad que no se puede describir de forma genérica. Organiza en torno al trabajo que se repite.

PromptLibrary/
├── README.md
├── 01-research/
├── 02-positioning/
├── 03-writing/
├── 04-visuals/
├── 05-launch/
├── 06-review/
├── fixtures/
└── archive/

Piensa en un prompt que extrae objeciones del feedback de clientes. Va en research aunque se ejecute desde tres apps distintas. Un prompt que genera la miniatura para un marketplace va en visuals, aunque ahora mismo otro modelo de imagen saque fotos más bonitas. Agrupar por tarea mantiene la colección portable entre modelos y resulta lógico para un compañero al que le importan los resultados y no la historia de las herramientas.

Una cabecera que explica cada prompt

Un nombre de archivo y un bloque de instrucciones no dicen lo suficiente. Una breve sección de front matter permite que el prompt se describa a sí mismo.

---
name: "Turn Verified Features into Buyer Outcomes"
job: "positioning"
status: "tested"
version: "1.2.0"
last_tested: "2026-09-01"
required_inputs:
  - "product truth sheet"
  - "primary audience"
  - "approved evidence"
output: "message hierarchy in Markdown"
manual_review:
  - "claim accuracy"
  - "audience fit"
  - "unsupported outcomes"
---

Ese contrato le dice al lector cuándo aplica el prompt antes de leer el cuerpo, y evita que un prompt probado pase por universal. Funciona bien un vocabulario de estados pequeño: draft, tested, deprecated y archived. Conviene evitar etiquetas como perfect o best, porque ocultan las condiciones en las que se evaluó el prompt.

Plantillas frente a entradas

Una plantilla debe contener el razonamiento y las reglas de producción que sigan siendo útiles de una tarea a otra. Los datos del producto, fechas, precios, la investigación de audiencia y el material de origen deben llegar como entradas explícitas. Las bibliotecas flojas incrustan datos antiguos en instrucciones reutilizables, lo que provoca fugas silenciosas en cuanto el prompt se aplica a un producto nuevo. Los bloques de entrada con nombres claros lo evitan.

<product_truth>
[Paste current verified product facts here.]
</product_truth>

<audience_context>
[Paste approved audience observations here.]
</audience_context>

<task>
Create a message hierarchy containing one primary promise, three supporting benefits, evidence for each benefit, one objection response, and one CTA.
</task>

<constraints>
Use only supplied facts; label missing evidence; do not invent testimonials, urgency, guarantees, or comparison claims.
</constraints>

Estas etiquetas hacen visibles los límites tanto para el modelo como para la persona que revisa. También facilitan adaptar el prompt más adelante a código, a un formulario o a una automatización.

Prueba los prompts como si fueran código

Los desarrolladores no se fían de una función porque haya devuelto el valor correcto una vez con una entrada. Los prompts merecen una versión más ligera de esa desconfianza. Crea dos o tres fixtures ficticios que cubran casos comunes y difíciles.

fixtures/
├── digital-guide-simple.md
├── source-code-kit-technical.md
└── fintech-feature-sensitive.md

El fixture sencillo prueba el camino feliz. El técnico comprueba que el prompt conserva los detalles de compatibilidad y no aplana el lenguaje experto. El sensible comprueba que las instrucciones respetan los límites en finanzas, privacidad, autenticación o ámbitos regulados. Los fixtures deben contener solo datos inventados: nada de información del empleador, credenciales de producción, registros de clientes ni código propietario.

El objetivo no es la redacción exacta, porque la salida generativa varía. El objetivo son las propiedades estables de la respuesta.

Aserciones en lugar de un párrafo de oro

Comparar cada ejecución con un único párrafo ideal es una trampa. Es mejor escribir aserciones que describan lo que tiene que cumplirse.

## Acceptance criteria

- Uses exactly one primary audience.
- Maps every benefit to a supplied feature or evidence item.
- Labels unsupported claims instead of completing them.
- Contains the requested sections in the requested order.
- Includes one CTA and no invented urgency.
- Preserves technical versions and filenames exactly.

Algunas comprobaciones pueden hacerse de forma mecánica, como los nombres de las secciones, los recuentos o los campos obligatorios. Otras requieren criterio, como si una promesa suena creíble o si el tono encaja con la audiencia. Deja esas revisiones humanas a la vista y no finjas que toda decisión de calidad se puede automatizar.

Versiones que avisan del riesgo

Los números de versión pueden comunicar lo arriesgado que es un cambio. Una versión patch corrige la redacción sin tocar las entradas obligatorias ni la forma de la salida. Una versión minor añade un campo opcional o una nueva comprobación de revisión y mantiene intacto el contrato. Una versión major marca un cambio en la propia tarea, en las entradas obligatorias, en la estructura de salida o en un límite de seguridad. Un breve registro de cambios dentro del archivo, o junto a la biblioteca, guarda la historia.

## Change log

- 1.2.0: Added a claim ledger and explicit source mapping.
- 1.1.1: Clarified that illustrative examples must be labeled.
- 1.1.0: Added objection handling to the message hierarchy.
- 1.0.0: First tested version.

Ese registro es mejor que conservar cada revisión de la conversación, porque recoge por qué cambió el contrato de producción.

Las diferencias entre herramientas, en un solo sitio

Las herramientas difieren en la sintaxis de los adjuntos, en cómo tratan las referencias a imágenes, en la gestión del contexto y en las pistas de formato. Una pequeña sección de compatibilidad recoge esas diferencias.

## Compatibility notes

- Text models: Attach the truth sheet and require source mapping.
- Image models: Convert the message hierarchy into a visual brief before generation.
- Tools without reliable file context: Paste the verified source block directly.
- Tools with limited output length: Request one section at a time without changing the contract.

Bifurcar un prompt solo tiene sentido cuando una herramienta necesita un comportamiento realmente distinto. En los demás casos, una única plantilla canónica con notas es más fácil de mantener que varias copias casi idénticas.

Deja los resultados fuera de la biblioteca

Los artefactos generados pertenecen a su campaña o producto, no a la carpeta del prompt reutilizable. La biblioteca guarda plantillas, fixtures, notas de pruebas y documentación. La carpeta del proyecto guarda los briefs terminados, borradores, recursos y aprobaciones.

Campaigns/ProductLaunch/
├── inputs/
├── completed-briefs/
├── drafts/
├── reviews/
└── final/

Esta separación impide que los datos privados y la información de producto desactualizada vuelvan a colarse en una biblioteca de uso general. Además, mantiene las plantillas legibles, porque los ejemplos no entierran las instrucciones.

Limpieza programada

Una biblioteca de prompts se queda obsoleta sin que nadie se dé cuenta. Una revisión ligera cada mes o cada trimestre, según lo rápido que cambie el flujo de trabajo, la mantiene sana:

• retira cualquier prompt que ya cubra una plantilla mejor
• vuelve a lanzar las pruebas allí donde haya cambiado una herramienta o un producto
• elimina los apaños para modelos antiguos que ya no hacen falta
• actualiza las reglas sobre fuentes, privacidad y seguridad
• pasa a tested los borradores que hayan demostrado su valía
• anota los fallos detectados en las campañas recientes
• comprueba que los enlaces, fixtures y contratos de salida siguen funcionando

Una revisión debería reducir la biblioteca tantas veces como la amplía. Una lista corta de plantillas fiables es mejor que un gran archivo de plantillas sin explicar.

Un README para desconocidos

En el README del nivel superior, quien llega nuevo aprende el ciclo: elegir un prompt, rellenar sus entradas, ejecutarlo, revisar el resultado y devolver las mejoras.

1. Choose the folder that matches the job.
2. Confirm the prompt status and required inputs.
3. Copy the template into the active project.
4. Fill every required input from current sources.
5. Run the prompt in an approved tool.
6. Review the result against its acceptance criteria.
7. Store the output with the project.
8. Feed recurring failures back into the template.

Un proceso así permite usar la biblioteca a alguien que no la escribió, y esa es una prueba exigente de si los prompts tienen una estructura real o solo dependen de la memoria de una persona.

La confianza en una biblioteca nace de saber qué hace cada prompt, qué entradas recibe, cómo se probó, qué necesita revisión humana y dónde no debe usarse. Archivos Markdown normales, nombres coherentes, unos pocos fixtures pequeños, aserciones basadas en el comportamiento y notas de versión aportan todo eso. Después, el número de prompts puede crecer sin convertirse en la cifra principal.