La decisión que tomaría en trabajo real
Si una tarea con IA se va a repetir, no dejaría la instrucción importante dentro del chat. La pasaría a una instrucción de trabajo en Markdown.
No es por gusto técnico. Es por operación. Un archivo Markdown puede vivir junto al trabajo, tener historial, revisarse y volver a usarse. Un prompt largo ayuda en la primera ejecución. A los pocos días ya mezcla reglas permanentes, excepciones del momento y frases improvisadas por quien lo escribió.
OpenAI usa archivos como AGENTS.md y Skills para dar contexto reutilizable a Codex. Claude Code tiene memory y settings. MCP trata los prompts reutilizables como una capacidad estructurada. Son piezas distintas, pero la señal práctica es la misma: el trabajo con IA que se repite necesita una capa de instrucción fuera de la conversación.
Mi regla es sencilla. Para una respuesta, un prompt basta. Para que otra persona pueda repetir el trabajo el mes que viene, prefiero Markdown.
Por qué los prompts largos se rompen después
Los prompts largos mejoran rápido al principio. Añades contexto, restricciones, ejemplos, y la respuesta sube de calidad. Eso sirve.
El problema llega en la tercera o cuarta ejecución.
Alguien pregunta qué versión del prompt se usó. Otra persona añade una excepción al final. Cambia la ruta de un archivo. Una columna del reporte se renombra. Después de un error, cambia la regla de aprobación. El prompt sigue pareciendo completo, pero nadie sabe qué líneas eran permanentes.
La automatización con IA pierde tiempo ahí. No porque el modelo no sepa escribir. Lo pierde porque el relevo queda demasiado abierto.
| Hábito con prompt | Problema posterior | Hábito con Markdown |
|---|---|---|
| Pegar un bloque largo | No queda versión clara | Guardar la regla en archivo |
| Repetir el contexto | Cada persona lo cuenta distinto | Reutilizar la sección de contexto |
| Pedir “una tabla” | Cambia el formato | Nombrar campos obligatorios |
| Contar excepciones de palabra | Se pierden casos límite | Separar condiciones de parada |
| Revisar solo a ojo | La revisión es subjetiva | Dejar comprobaciones |
| Guardar ejemplos en chat | Desaparecen | Ponerlos junto a la regla |
| No nombrar responsable | Nadie actualiza | Definir responsable y cuándo actualizar |
| Corregir a mano | El fallo vuelve | Convertir el fallo en regla |
No es una clasificación bonita. Es lo que aparece tras varias semanas: buena primera respuesta, y después varias personas corrigiendo la misma instrucción débil.
Cuándo Markdown encaja y cuándo no
Markdown no sirve para todo. Sirve cuando hay repetición suficiente para justificar un archivo.
Lo usaría en trabajos como estos:
- comparación mensual de proveedores
- clasificación de feedback de clientes
- limpieza de notas de reunión
- revisión de borradores de políticas internas
- reporte a partir de hojas de cálculo
- preparación de notas de lanzamiento
- enrutamiento de tickets de soporte
- brief de investigación recurrente
El patrón común no es “la IA escribe”. El patrón común es el relevo del trabajo. Hay una entrada, una salida esperada, un punto de revisión humana y una regla que debe sobrevivir al chat actual.
No lo elijas para una pregunta única, una exploración abierta o una tarea cuyos criterios todavía nadie sabe explicar. En ese caso el archivo añade ceremonia. Primero ejecuta el trabajo un par de veces. Cuando aparezca la misma corrección dos veces, conviértela en regla.
Dónde se decide de verdad: una buena instrucción es más corta de lo que parece
El error habitual es convertir la instrucción en un manual que nadie quiere abrir.
Un archivo útil suele ser corto. No cuenta toda la historia de la empresa. No enumera todos los casos posibles. Da a la IA y al operador la estructura suficiente para repetir el trabajo sin inventar las reglas.
Miro primero nueve piezas.
| Sección | Qué pongo ahí | Señal de fallo |
|---|---|---|
| Propósito | Por qué existe la tarea | La IA optimiza otra cosa |
| Contexto | Solo lo necesario | Parece una wiki interna |
| Entradas | Archivos, periodo, campos | El agente adivina fuentes |
| Formato de entrega | Formato, columnas, tono, destino | Cada ejecución sale distinta |
| Reglas de decisión | Clasificar, priorizar, aprobar | El juicio cambia con la redacción |
| Acciones prohibidas | No editar, no borrar, no publicar | Se toca fuera del alcance |
| Comprobaciones | Validación, revisión, fuentes | Nadie sabe si terminó |
| Condiciones de parada | Cuándo pausar | El riesgo avanza en silencio |
| Regla de actualización | Cuándo se cambia el archivo | El mismo fallo vuelve |
Si cabe en dos o tres pantallas, puede funcionar. Si necesita índice antes de la primera ejecución, dividiría el trabajo.
Una plantilla que sí entregaría a un operador
Empezaría con esta forma. El lenguaje debe ser claro, no elegante. Una instrucción de trabajo no es una pieza de marca.
# Instrucción de trabajo: [nombre]
## Propósito
- Por qué existe este trabajo:
- Quién usa la salida:
- Qué decisión apoya:
## Entradas
- Archivos fuente:
- Periodo:
- Sistemas:
- Campos que no se deben adivinar:
## Formato de entrega
- Formato:
- Secciones o columnas obligatorias:
- Tono:
- Destino:
- Qué no debe cambiar:
## Reglas de decisión
- Cómo clasificar:
- Cómo priorizar:
- Evidencia suficiente:
- Juicio humano necesario:
## Acciones prohibidas
- No editar:
- No publicar:
- No borrar:
- No inferir:
## Comprobaciones antes de terminar
- Validación:
- Revisión manual:
- Cruce de fuentes:
- Revisión de archivo o enlace:
## Condiciones de parada
- Detenerse si:
- Preguntar al responsable si:
- Dejar nota si:
## Criterios de aceptación
- La salida está en:
- Comprobaciones pasadas:
- Preguntas abiertas listadas:
- Otra persona puede repetirlo:
## Regla de actualización
- Cambiar este archivo cuando:
- Responsable:
- Última revisión:La línea que más cuido es “campos que no se deben adivinar”. Si la IA rellena con valores plausibles donde no debe, el coste aparece más tarde.
Ejemplo: comparación mensual de proveedores
Pensemos en una comparación mensual de proveedores para herramientas de soporte o colaboración. El responsable quiere saber tres cosas: por qué cambió el gasto, si también cambió el uso y si hay que hablar con algún proveedor.
Sin instrucción, la petición suele quedar así:
Compara los reportes de proveedores y escribe un resumen.
Es demasiado floja. La IA puede escribir un memo legible, pero saltarse la regla de negocio. En Markdown se vuelve más concreta:
- Usa solo el export del mes actual y el del mes anterior.
- Si existe oferta de renovación, no uses el precio de lista.
- Separa crecimiento de uso y crecimiento de asientos.
- Marca proveedor solo si el gasto sube más del 12% y el uso no sube.
- Lleva términos contractuales desconocidos a “preguntas abiertas”.
- No recomiendes cancelar si no hay bajo uso y confirmación del responsable.
Ahora la IA no solo resume. Trabaja con criterio, límite y punto de parada.
Criterios de aceptación y condiciones de parada
Un trabajo con IA no termina porque haya texto. Texto hay siempre. Termina cuando deja evidencia.
Pondría al menos cuatro criterios:
- existe el archivo o página esperada
- están los campos obligatorios
- las fuentes usadas quedan nombradas
- excepciones y datos faltantes aparecen en una lista
Las condiciones de parada importan todavía más. Frenan errores seguros de sí mismos.
Detendría la ejecución si:
- falta el archivo fuente
- dos fuentes no coinciden
- la salida se publicaría fuera
- aparecen datos de cliente, pago, legal o seguridad sin estar previstos
- se pide borrar, editar de forma irreversible o cambiar cuentas
- hace falta una decisión de negocio que no está escrita
Aquí la instrucción Markdown deja de ser un prompt mejorado y se convierte en límite operativo.
Los primeros siete días
No lo plantearía como un proyecto enorme. Basta con una tarea repetida durante una semana.
Día 1: elegir una tarea que ya se repite y escribir la primera instrucción. Máximo tres pantallas.
Día 2: ejecutarla una vez y anotar dónde la IA adivinó.
Día 3: convertir esas adivinanzas en regla de entrada, salida o parada.
Día 4: pedir a otra persona que ejecute el archivo sin explicación adicional.
Día 5: contar retrabajo. No precisión abstracta, sino correcciones humanas.
Día 6: separar lo que pertenece al archivo de lo que debe ir a un checklist.
Día 7: convertirlo en camino estándar o borrarlo. Una mala instrucción es peor que ninguna porque crea confianza falsa.
Qué se puede conectar después
Cuando el archivo funciona, puede entrar en automatización más fuerte.
Las instrucciones de proyecto en Codex orientan al agente dentro del repositorio. Skills guarda procedimientos reutilizables. Claude Code memory mantiene contexto entre ejecuciones. MCP prompts ofrece formas reutilizables de petición desde un servidor.
El orden que usaría es:
- Escribir la instrucción Markdown.
- Ejecutarla manualmente con ayuda de IA.
- Añadir comprobaciones y condiciones de parada.
- Mover solo lo estable a una instrucción de agente, skill o plantilla.
- Mantener revisión humana hasta que los fallos sean aburridos.
No automatices la versión desordenada. Primero haz que una persona pueda repetirla.
Antes de elegir este patrón
Markdown merece la pena cuando hay repetición, responsable y formato de entrega claro. No lo uses solo para parecer más ordenado.
La prueba más rápida: entrega el archivo a otra persona y no expliques nada. Si puede empezar y sabe cuándo parar, sirve. Si antes de empezar hace cinco preguntas, la instrucción real sigue en tu cabeza.
No es un problema de redacción. Es un problema de diseño operativo.
Preguntas que conviene resolver antes
¿Es solo prompt engineering guardado en un archivo?
No. El prompt mejora la petición. La instrucción mejora el relevo del trabajo: entradas, salida, revisión, responsable y condiciones de parada.
¿Toda tarea con IA necesita Markdown?
No. Una pregunta única no necesita ese peso. Encaja mejor en trabajo repetido, compartido, basado en archivos o sensible a revisión.
¿Dónde debería vivir el archivo?
Donde vive el trabajo. En un repositorio puede ser algo tipo AGENTS.md o /docs/operations/. En una carpeta de negocio, mejor junto a la hoja de cálculo o el reporte.
¿Qué se corrige primero después de un fallo?
Condiciones de parada y formato de entrega. Muchos fallos vienen de campos inventados, excepciones saltadas o resultados que no se pueden pasar al siguiente sistema.
Fuentes y referencias
- OpenAI Codex AGENTS.md guide OpenAI
- OpenAI Codex Skills documentation OpenAI
- Claude Code memory documentation Anthropic
- Claude Code settings documentation Anthropic
- Model Context Protocol prompts specification Model Context Protocol
