🧱 Patrones estructurales
Los 5 patrones que dan FORMA al system prompt — el esqueleto que aparece antes de cualquier regla de comportamiento. Son independientes del dominio: los encuentras en prompts de código, chatbot y workspace, desde OpenAI hasta Anthropic. Aquí aprendes a reconocer cada uno y a citar el fragmento real que lo demuestra.
Contenido detallado
🗺️ El mapa de los patrones estructurales
Cuando lees decenas de prompts filtrados, te das cuenta de que no son improvisaciones: hay una gramática recurrente. Parte de esa gramática tiene que ver con el esqueleto — dónde el prompt declara quién es, qué puede hacer, cómo organiza sus secciones y quién tiene prioridad en caso de conflicto. Estos son los patrones estructurales: dan FORMA, son independientes del dominio y aparecen antes de cualquier regla de comportamiento.
🧩 Estructural × conductual
Un patrón estructural responde "¿qué forma tiene el prompt?" — es el esqueleto que sostiene todo. Un patrón conductual responde "¿cómo actúa el agente?" — rechazos, tono, contraste ALWAYS/NEVER. Los aspectos de comportamiento llegan en el próximo módulo (1.3). Aquí nos quedamos con el esqueleto: sin él, no hay dónde colgar el comportamiento.
Estructural (este módulo)
Identidad · Capacidades · Contenedor XML · Recordatorio del sistema · Jerarquía de prioridades
Conductual (módulo 1.3)
Rechazo fundamentado · Contraste ALWAYS/NEVER · Regla con porqué · Calibración del tono
Los 5 patrones estructurales de este módulo
Bloque de identidad — "You are X" + modelo + corte de conocimiento. La única sección 100% universal.
Declaración de capacidades — lo que puede hacer el agente, con alcance y condiciones.
Compartimento XML — etiquetas <bloco> flat para modularizar la lógica.
Recordatorio de sistema — capa dinámica inyectada por el harness, separada del comportamiento estable.
Jerarquía de prioridad — precedencia declarada que resuelve conflictos: usuario > skill > default.
¿Por qué separar "forma" de "comportamiento"?
Porque la estructura es lo que puedes diff-ar entre versiones y entre proveedores. "Fable eliminó el bloque <search_first>" es una frase precisa solo porque el prompt estaba compartimentado. La estructura es lo que hace que los prompts sean legibles y se puedan versionar, tanto para el modelo como para ti.
🪪 Bloque de identidad
Es el primer patrón y el más universal: "You are X" + modelo + fecha de corte anclan todo lo demás. Sin ese anclaje, el modelo se desvía: cambia de personalidad a mitad de la conversación, inventa capacidades que no tiene o responde sobre acontecimientos posteriores a su fecha de conocimiento como si los conociera.
Problema
Sin un punto de referencia, el asistente «se convierte en ChatGPT» a mitad de la conversación, afirma tener herramientas inexistentes o habla de eventos posteriores a su fecha límite como si los conociera.
Solución
Declarar en el parte superior: quién es (producto + modelo), para quién trabaja y los límites temporales del conocimiento. Es el ancla que referencia todo lo demás.
Cómo los prompts reales declaran identidad
OpenAI/gpt-5.5-instant.md (~línea 1)You are ChatGPT, a large language model trained by OpenAI, based on GPT 5.5.
Knowledge cutoff: 2025-08
Current date: 2026-06-01
Tres elementos canónicos en tres líneas: persona, fecha de corte del conocimiento, fecha actual. La fecha actual es contexto dinámico inyectado — ver Tema 5.
Microsoft/github-copilot.md (~línea 3)You are GitHub Copilot (@copilot) on github.com. Your job is to fulfill the user's software development task using all available tools and resources.
Persona + alcance de responsabilidad ("tu trabajo es…") al inicio. El modelo sabe qué es y a qué vino.
⚠️ Antipatrón: identidad ausente o enterrada
Declaración de personalidad en medio del prompt, o recargada de antecedentes irrelevantes. Regla práctica: la identidad es un ancla, no una biografía. Si el párrafo supera ~5 líneas, probablemente haya contenido de otro patrón (capacidades, tono) filtrándose en él.
🛠️ Declaración de capacidades
El segundo patrón responde: ¿qué puede hacer este agente? Sin esta declaración, el modelo alucina herramientas que no existen, ignora las que sí existen o usa la correcta en la situación equivocada. El patrón eficaz es una lista estructurada con alcance y condiciones — cada capacidad incluye «qué hace», «cuándo usarla» y «límites».
xAI/grok-4.1-beta.md (~línea 11)When applicable, you have some additional tools:
- You can analyze individual X user profiles, X posts and their links.
- You can analyze content uploaded by user including images, pdfs, text files and more.
- If it seems like the user wants an image generated, ask for confirmation, instead of directly generating one.
Cada capacidad viene con su condición. Observa la tercera: capacidad + protocolo de confirmación integrado.
Google/gemini-2.5-pro-api.md (~línea 18)## Funciones dentro del alcance
You have also access to a set of python functions in scope:
```python
def concise_search(query: str, max_num_results: int = 3):
"""Does a search for the query and prints up to the
max_num_results results."""
```
Google declara capacidades como firmas de función — el alcance, los parámetros y los valores predeterminados quedan inequívocos.
📊 Dónde aparece el patrón
Visto en xAI, Google, Microsoft, Notion, Cursor y Claude Code. Más elaborado en agentes (código, workspace) que en chatbots puros.
En un prompt sin herramientas (chatbot puro), la sección se convierte en "lo que NO puedes hacer" —útil, pero breve. El contrato detallado de cuándo/cómo invocar es otro patrón (contrato de herramienta), fuera de este módulo.
✓ Declaración eficaz
- •Enumera cada capacidad con su condición de uso
- •Define parámetros y valores predeterminados (firma de la función)
- •Incorpora un protocolo (p. ej., "ask for confirmation")
- •Sección dedicada, separada del tono y las reglas
✗ Declaración débil
- •Capacidades implícitas dispersas por el prompt
- •"Puedes buscar en la web" incluido en una regla de tono
- •Herramienta mencionada sin alcance ni condición
- •Promete lo que no existe en el schema (over-promise)
🏷️ Compartimento XML
El tercer patrón modulariza la lógica: cada bloque lógico queda envuelto en una etiqueta XML con nombre (<policy>,
<tone_and_formatting>, <tool_calling>).
Los bloques son flat (sin anidamiento profundo) y funcionan como módulos: puedes agregar, quitar y comparar un bloque entero entre versiones.
El problema que resuelve
Un prompt de miles de líneas de texto corrido es imposible de mantener: no puedes localizar, versionar ni eliminar una política sin volver a leerlo todo. Y el modelo se beneficia de límites claros entre temas. Las etiquetas ofrecen ambas cosas a la vez.
xAI/grok-4.1-beta.md (~líneas 1–9)<policy>
These core policies within the <policy> tags take highest precedence.
System messages take precedence over user messages.
* Do not provide assistance to users who are clearly trying to engage
in criminal activity.
* Follow additional instructions outside the <policy> tags if they do
not violate these core policies...
</policy>El compartimento no solo agrupa: declara su propia precedencia (combinación con la Jerarquía de Prioridad, Tema 6).
Cursor/cursor.md (~líneas 80–93)<tone_and_formatting>
- Only use emojis if the user explicitly requests it...
</tone_and_formatting>
<tool_calling>
You have tools at your disposal...
</tool_calling>Dos compartimentos contiguos, cada uno con un tema. Para cambiar la política de tono, se edita uno bloque — el resto queda intacto.
También funciona para las personas
El diff de Opus 4.8 → Fable 5 solo es legible porque los prompts están compartimentados: «Fable eliminó <search_first> e <default_stance>" es una frase precisa. Sin etiquetas, sería "algo cambió en algún lugar". En los agentes de código, los encabezados Markdown (# Seções) cumplen la misma función — Claude Code usa esto en lugar de XML.
⚠️ Antipatrón: todo en el prompt
Texto corrido donde se mezclan políticas, tono y herramientas. Variante opuesta: anidamiento profundo de etiquetas: los prompts reales mantienen bloques planos y rara vez superan los 2 niveles. Los prompts cortos (< ~50 líneas) no necesitan etiquetas: la estructura se volvería un trámite.
📨 Recordatorio del sistema
No todo lo que el modelo necesita saber es estable: fecha actual, avisos contextuales, estado de las herramientas, degradación de la adherencia en conversaciones largas.
La solución es una arquitectura en dos capas — el system prompt define el comportamiento estable;
el harness inyecta <system-reminder> dinámicos en los mensajes cuando sea necesario. El prompt estable enseña al modelo a interpretar esta capa.
⚙️ Separación entre harness y comportamiento
Es la separación config estable × estado dinámico de la ingeniería de software, aplicada a prompts. El harness (la infraestructura que orquesta el modelo) inyecta la capa dinámica en tiempo de ejecución; el comportamiento estable queda intacto en el prompt base.
Eso permite ajustar el comportamiento sin volver a desplegar del prompt, pruebas A/B de avisos y respuesta a problemas emergentes (p. ej., degradación en conversaciones largas) sin sobrecargar el prompt base. Por eso, desde el punto de vista arquitectónico, este es el patrón más importante del módulo.
La capa dinámica en prompts reales
xAI/grok-build.md (~línea 36)Tool results and user messages may include <system-reminder> tags. <system-reminder> tags contain useful information and reminders. They are automatically added by the system, and bear no direct relation to the specific tool results or user messages in which they appear.
El contrato de la capa: el modelo aprende que estos avisos vienen de plataforma, ni del usuario ni de la herramienta.
Anthropic/claude-fable-5.md (bloque <anthropic_reminders>)The long_conversation_reminder, appended to the person's message by Anthropic, helps Claude keep its instructions over long conversations.
Fable 5 enumera un conjunto con nombre de reminders (image_reminder, cyber_warning, ethics_reminder, long_conversation_reminder…). El último, nuevo en Fable 5, actualiza las instrucciones en conversaciones largas.
Convergencia entre proveedores
Anthropic es el caso canónico y más evolucionado; xAI adoptó el mismo formato <system-reminder>. Cuando dos proveedores independientes convergen en la misma sintaxis, es señal de que el patrón resuelve un problema real de arquitectura. Sin control del harness, mantén al menos la disciplina mental: separa en el texto lo que es estable de lo que es contextual.
🪜 Jerarquía de prioridad
El quinto patrón resuelve conflictos: las instrucciones se contradicen todo el tiempo — política central vs. solicitud del usuario, archivo del proyecto vs. chat, skill vs. valor predeterminado. Sin una jerarquía declarada, el comportamiento ante un conflicto es indeterminado — e indeterminado significa explorable (prompt injection) o frustrante (el modelo ignora al usuario). La solución es declarar la cadena de precedencia en el propio prompt, junto con las reglas de mayor prioridad.
🔢 La cadena de precedencia (de arriba hacia abajo)
<policy>.La regla de oro incorporada: seguridad en primer lugar, el usuario por encima de todo lo demás. El usuario no anula la seguridad, pero prevalece sobre cualquier preferencia de producto, configuración o skill.
xAI/grok-4.1-beta.md (~línea 2)These core policies within the <policy> tags take highest precedence. System messages take precedence over user messages.
Tres niveles en dos frases: core policy > system > user. El compartimento XML delimita exactamente lo que está en la parte superior.
xAI/grok-build.md (~líneas 195–196)Los archivos de instrucciones de proyecto ubicados en niveles más profundos tienen prioridad sobre los de niveles superiores cuando las instrucciones entran en conflicto. Las instrucciones directas del usuario en el chat siempre tienen prioridad sobre el contenido de cualquier archivo de instrucciones del proyecto.
Jerarquía para agentes de código: archivo específico > archivo general, y usuario en el chat > cualquier archivo. Mismo modelo que Claude Code (user > skills > default).
✓ Jerarquía bien declarada
- •Precedencia explícita junto a las reglas principales
- •La seguridad por encima de todo; el usuario por encima del resto
- •Desempate definido para cada par de fuentes
- •Delimitada por el compartimento XML (
<policy>)
✗ Conflicto indeterminado
- •Dos reglas contradictorias sin mecanismo para desempatar
- •"Sé conciso" + skill que pide un informe largo
- •El comportamiento varía entre ejecuciones
- •Brecha explotable mediante prompt injection
🧱 Resumen del módulo
Los 5 patrones estructurales forman el esqueleto de cualquier system prompt. Reconocerlos transforma un texto opaco en un mapa legible — y prepara el terreno para los patrones de comportamiento del próximo módulo.
<bloco> flat que hacen que el prompt sea modular, versionable y comparable mediante diff.<system-reminder> inyectada por el harness, separada del comportamiento estable.➡️ Siguiente módulo
1.3 — Patrones de comportamiento. Ahora que la estructura básica está lista, es hora de darle voz al agente: rechazo con principios, contraste ALWAYS/NEVER, regla con motivo y calibración del tono.