Diez páginas de prompting se volvieron una, y una técnica que usabas dejó de funcionar.

Durante años, aprender a escribirle a Claude era ir de página en página en la documentación de Anthropic. Una para ser claro y directo, otra para los ejemplos, otra para las etiquetas XML, otra para la cadena de pensamiento, otra para el contexto largo. Cada quien guardaba sus tres favoritas en marcadores.

Ese mapa ya no existe. Once de esas páginas dejaron de tener contenido propio: diez ahora te mandan a una sola referencia —ocho al apartado exacto que les toca, dos a la página completa—, y la onceava —la de escribirle el principio de su respuesta— ni siquiera eso, porque la técnica que documentaba se retiró.

Esta página es esa referencia única, en español y traducida a la suscripción: el chat de Claude, Claude Code y Cowork. Está ordenada igual que la oficial a propósito, para que cuando Anthropic mueva la suya se pueda actualizar apartado por apartado en vez de reescribirla entera.

La página que buscabas y a dónde te manda hoy

Vale la pena leer la última fila dos veces. Que diez páginas se fundan en una es orden; que una se quede sin apartado a dónde ir es una técnica jubilada, y es la que más gente sigue usando sin saber que dejó de servir. Tiene su propia parada, la 05, con los cinco reemplazos.

Cómo está ordenada, y por qué en ese orden

La referencia oficial se declara a sí misma en tres partes, y esta guía respeta las tres. No es un capricho de índice: es lo que hace que una página así se pueda mantener sin que se pudra.

Los tres requisitos que la doc pide antes de afinar nada

La documentación oficial abre con una advertencia que casi nadie lee: da por hecho que ya tienes tres cosas. Si te faltan, afinar el prompt es dar palos de ciego, porque no vas a poder saber si el cambio mejoró algo o solo lo hizo distinto.

Y una honestidad que la doc pone de entrada: no todo se arregla con el prompt. Hay problemas que se resuelven más rápido cambiando de modelo que reescribiendo instrucciones, y esa decisión tiene su propia guía en la bóveda. Si te sientes atorado reescribiendo lo mismo por quinta vez, empieza por ahí.

Dónde vive lo que copias de aquí

Los bloques de esta página no son código: son instrucciones en español que se pegan una vez y cambian cómo te contesta a partir de entonces. Hay tres lugares donde ponerlos, y elegir mal es la razón más común de que un bloque «no haga nada».

Por qué pasa esto —cuánto le cabe, qué se lee primero y qué se diluye— está explicado a fondo en otra guía, y aquí no se repite.

Qué quedó fuera, a propósito

La página oficial está escrita para quien construye con Claude desde código. Esta no. Todo lo que solo tiene sentido con código de por medio se descartó, no se tradujo a medias:

• Los identificadores técnicos de los modelos y los ajustes que se pasan al llamarlos.
• Los ejemplos en código y las llamadas desde la terminal: aquí el lector no programa.
• Los códigos de error: cuando algo dejó de funcionar, aquí simplemente dice que ya no funciona.
• Los precios, el consumo por millón y todo lo que dependa de facturación por uso.
• Las plataformas de nube donde se despliegan los modelos.

Lo que sí sobrevivió es todo lo que cambia el resultado cuando escribes desde una suscripción. Que es, en la práctica, casi toda la página.

Si algún día quieres el original en inglés —y sí, conviene mirarlo cada tanto— la referencia oficial vive aquí. Esta guía se verificó contra ella el 17 de agosto de 2026, y se actualiza cuando Anthropic mueve la suya.

Con el mapa listo, empieza lo que sí se aplica hoy: los principios que aplican a todos los modelos, todos los días, escribas donde escribas.

Esto es lo que la referencia llama principios generales: lo que aplica a todos los modelos actuales, sin excepción y sin importar desde dónde escribas. Es también la parte que menos se mueve cuando sale un modelo nuevo, así que es la que más rinde aprenderse.

Son seis ideas. Ninguna es un truco: las seis son formas de quitarle ambigüedad a lo que pides.

1. Sé claro y directo

Claude responde bien a instrucciones claras y explícitas, y ser específico sobre la salida que quieres mejora el resultado. Si lo que buscas es que se pase de bueno —que vaya más allá de lo mínimo—, pídelo con todas sus letras en vez de esperar a que lo deduzca de un encargo vago.

La analogía de la doc es buena y conviene tenerla presente: piensa en Claude como un empleado nuevo, brillante, que no conoce tus normas ni cómo trabajan ustedes. No es que no pueda; es que no estaba ahí cuando ustedes decidieron cómo se hacen las cosas.

• Sé específico sobre el formato de salida que quieres y sobre las restricciones que no se pueden romper.
• Da las instrucciones como pasos secuenciales, en lista numerada o con viñetas, cuando el orden o la completitud de los pasos importan.

Las dos frases piden lo mismo. La segunda es la única que dice qué tan lejos quieres que llegue, y ésa es toda la diferencia entre un tablero de prueba y uno que puedes enseñar.

2. Dale el motivo, no solo la orden

Explicarle por qué le pides algo —qué hay del otro lado, para qué se va a usar el resultado— hace que la respuesta le atine mejor a lo que necesitas. Compara estas dos instrucciones sobre lo mismo:

Claude es lo bastante listo para generalizar a partir de la explicación. Con la primera instrucción obedece los puntos suspensivos y nada más. Con la segunda entiende el problema de fondo —esto se va a oír, no a leer— y por su cuenta empieza a evitar los guiones largos, los símbolos raros y las abreviaturas que suenan horrible en voz alta.

Es la diferencia entre una regla que cubre un caso y un criterio que cubre los que no se te ocurrió escribir.

3. Usa bien los ejemplos

Los ejemplos son una de las formas más confiables de dirigir el formato, el tono y la estructura de lo que te devuelve. Unos pocos, bien hechos, mejoran la precisión y la consistencia más que otro párrafo de instrucciones. Pero tienen que cumplir tres cosas:

• Relevantes: que se parezcan a tu caso real, no a un caso de manual.
• Diversos: que cubran los casos raros y que varíen lo suficiente para que no agarre un patrón que tú no querías.
• Estructurados: cada ejemplo entre etiquetas <example>, y todos juntos dentro de <examples>, para que los distinga de las instrucciones.

Estos son los ejemplos que pienso incluir en mis instrucciones para una tarea que voy a repetir muchas veces.

Evalúalos en dos cosas:
1. Relevancia: qué tanto se parecen al trabajo real que te voy a pedir.
2. Diversidad: si entre todos cubren los casos raros, o si se parecen tanto entre sí que podrías agarrar un patrón que yo no quería.

Dime cuál sobra y por qué, qué caso me falta cubrir, y después escríbeme dos ejemplos nuevos que tapen los huecos que encontraste.

<examples>
<example>
[aquí va tu primer ejemplo: la entrada real y la salida que habrías querido]
</example>
<example>
[aquí va tu segundo ejemplo]
</example>
</examples>

4. Estructura con etiquetas XML

Las etiquetas le ayudan a leer un prompt largo sin ambigüedad, sobre todo cuando en el mismo mensaje mezclas instrucciones, contexto, ejemplos y el material del día. Envolver cada tipo de contenido en su propia etiqueta —<instructions>, <context>, <input>— reduce las malas interpretaciones.

No hay que saber programar para esto. Una etiqueta es abrir con <nombre> y cerrar con </nombre>; lo de adentro va en español normal. Dos reglas y ya:

• Usa nombres descriptivos y consistentes: si en un prompt le llamaste <contexto>, no le llames <antecedentes> en el siguiente.
• Anida cuando el contenido tiene jerarquía natural: los documentos dentro de <documents>, y cada uno dentro de su propio <document index="1">.

<instructions>
[qué quieres que haga. Si el orden de los pasos importa, numéralos]
</instructions>

<context>
[lo que necesita saber de tu negocio, tu equipo o tu proyecto para no inventar]
</context>

<examples>
<example>
[una entrada real y la salida que habrías querido para esa entrada]
</example>
</examples>

<input>
[el material sobre el que tiene que trabajar hoy]
</input>

5. Dale un rol

Ponerle un rol enfoca su comportamiento y su tono para tu caso. Una sola frase ya hace diferencia, y la doc lo demuestra con un ejemplo tan corto como éste: «Eres un asistente de programación especializado en Python».

6. Si necesita saber qué modelo es, díselo tú

Suena raro, pero es real y está en la doc: si quieres que tu asistente se identifique correctamente, hay que escribírselo en las instrucciones. No lo asume, y preguntárselo en frío no es confiable. Solo importa si armaste algo que le habla a otras personas —un Proyecto que usa tu equipo, un asistente que atiende clientes— y quieres que conteste bien cuando le pregunten con qué está hecho.

El asistente es Claude, creado por Anthropic. El modelo actual es Claude Opus 5.

Estos seis principios se aplican en cada mensaje que escribes. Lo que sigue es más específico: qué cambia cuando lo que le pasas ya no es un mensaje, sino un archivo enorme.

Ésta es, con diferencia, la regla que más rinde de toda la página, y la que casi nadie aplica. No cuesta nada, no hay que instalar nada y no cambia lo que pides: cambia el orden en que lo pides.

Cuando le pegas un PDF gigante, un contrato completo o tres archivos a la vez, el orden en que se los das cambia el resultado. Si tu pregunta va arriba y el material debajo, estás pidiéndole que recuerde qué buscaba mientras lee cuarenta páginas. Si el material va arriba y la pregunta hasta el final, lee todo primero y llega a tu pregunta con el documento fresco.

El mismo encargo, en los dos órdenes

Es literalmente la misma frase, movida de lugar. Nadie te va a decir que la segunda versión se ve mejor —de hecho se ve más incómoda de escribir— y ésa es la razón por la que casi todo el mundo hace la primera.

Cuando son varios documentos

Con un solo archivo basta con ponerlo arriba. Con varios hace falta una cosa más: decirle cuál es cuál. Si le pegas tres documentos seguidos sin separarlos, para él es un solo bloque de texto, y cuando le preguntes «¿qué dice el reporte anual?» va a tener que adivinar dónde empezaba.

La doc pide envolver cada documento en su propia etiqueta, con el nombre del archivo aparte del contenido. Éste es el ejemplo oficial, traducido:

<documents>
  <document index="1">
    <source>reporte_anual_2023.pdf</source>
    <document_content>
      {{REPORTE_ANUAL}}
    </document_content>
  </document>
  <document index="2">
    <source>analisis_competencia_q2.xlsx</source>
    <document_content>
      {{ANALISIS_COMPETENCIA}}
    </document_content>
  </document>
</documents>

Analiza el reporte anual y el análisis de competencia. Identifica ventajas estratégicas y recomienda las áreas en las que deberíamos enfocarnos el próximo trimestre.

Pídele que cite antes de opinar

El segundo truco del apartado es anclar la respuesta en citas. Para tareas sobre documentos largos, pídele que primero saque las partes relevantes del texto y hasta después haga lo que le encargaste. Según la doc, eso lo ayuda a enfocarse en el contenido que importa e ignorar el resto del documento.

El efecto secundario es el que más se agradece: si te enseña las citas, puedes verificar de dónde salió cada afirmación sin volver a leer las cuarenta páginas. Éste es el ejemplo oficial —un asistente para médicos—, traducido:

Eres un asistente médico. Tu tarea es ayudar a los doctores a diagnosticar posibles enfermedades de sus pacientes.

<documents>
  <document index="1">
    <source>sintomas_paciente.txt</source>
    <document_content>
      {{SINTOMAS_DEL_PACIENTE}}
    </document_content>
  </document>
  <document index="2">
    <source>expediente_paciente.txt</source>
    <document_content>
      {{EXPEDIENTE_DEL_PACIENTE}}
    </document_content>
  </document>
  <document index="3">
    <source>historial_citas_paciente01.txt</source>
    <document_content>
      {{HISTORIAL_DE_CITAS}}
    </document_content>
  </document>
</documents>

Busca en el expediente y en el historial de citas las frases textuales que sean relevantes para diagnosticar los síntomas que reporta el paciente. Ponlas entre etiquetas <quotes>. Después, con base en esas citas, enlista toda la información que le ayudaría al doctor a diagnosticar los síntomas. Pon esa información entre etiquetas <info>.

Fíjate en el orden del encargo final: primero citar, después razonar. No es una formalidad. Es la diferencia entre una respuesta construida sobre lo que dice el documento y una construida sobre lo que se acuerda del documento.

Con esto queda resuelto lo que le entra. Lo que sigue es lo que sale: cómo controlar la forma de la respuesta cuando lo que te devuelve no es lo que querías leer.

Esta es la sección que le sirve a todo el mundo, programe o no. Le pides un correo y te devuelve seis viñetas con negritas. Le pides una explicación y te llega un documento con encabezados, una tabla y un resumen ejecutivo que nadie pidió. No es tu culpa ni es un defecto: es un estilo por defecto, y el estilo por defecto se cambia con una instrucción.

Antes de las palancas conviene saber en qué dirección se movieron los modelos nuevos, porque cambió y a mucha gente le cambió sin avisar.

Cómo contestan hoy, comparado con antes

• Más directos y aterrizados: te dan reportes de avance con hechos en vez de celebrarse a sí mismos.
• Más conversacionales: un poco más fluidos y coloquiales, menos tono de máquina.
• Menos verbosos: para ahorrar tiempo, a veces se saltan el resumen detallado si no se lo pediste.

El tercer punto tiene una consecuencia concreta: después de usar una herramienta —leer un archivo, buscar en la web, revisar tu calendario— puede saltarse el resumen verbal y pasar directo a la siguiente acción. Si prefieres ver qué hizo antes de que siga, la documentación oficial da esta instrucción, y es de una línea.

Después de completar una tarea que involucre uso de herramientas, dame un resumen rápido del trabajo que hiciste.

Las cuatro palancas del formato

Escribe las secciones de prosa de tu respuesta dentro de etiquetas <smoothly_flowing_prose_paragraphs>.

El bloque que le quita las viñetas

Este es probablemente el bloque más útil de toda la página si escribes textos largos. Lo pegas una vez en tu CLAUDE.md o en las instrucciones de tu Proyecto y a partir de ahí los reportes, los análisis y las explicaciones te llegan en párrafos completos en vez de en fragmentos sueltos.

<avoid_excessive_markdown_and_bullet_points>
Cuando escribas reportes, documentos, explicaciones técnicas, análisis o cualquier
contenido de formato largo, escribe en prosa clara y fluida, con párrafos y oraciones
completas. Usa saltos de párrafo normales para organizar el texto y reserva el markdown
principalmente para `código en línea`, bloques de código (```...```) y encabezados
simples (## y ###). Evita usar **negritas** y *cursivas*.

NO uses listas numeradas (1. ...) ni listas con viñetas (*) salvo que: a) estés
presentando elementos verdaderamente discretos donde el formato de lista sea la mejor
opción, o b) el usuario pida explícitamente una lista o un ranking.

En vez de enumerar cosas con viñetas o con números, incorpóralas de forma natural
dentro de las oraciones. Esto aplica especialmente a la escritura técnica. Usar prosa
en lugar de formato excesivo mejora la satisfacción del usuario. NUNCA saques una serie
de viñetas demasiado cortas.

Tu objetivo es un texto legible y fluido que lleve al lector de forma natural a través
de las ideas, en vez de fragmentar la información en puntos aislados.
</avoid_excessive_markdown_and_bullet_points>

Cuando te contesta con notación matemática

Los modelos nuevos usan LaTeX por defecto para expresiones matemáticas, ecuaciones y explicaciones técnicas. Se ve bien donde hay quien lo renderice y se ve horrible donde no: en un correo, en una nota, en un mensaje que vas a pegar en otro lado. Si quieres texto plano, se lo dices.

Formatea tu respuesta solo en texto plano. No uses LaTeX, MathJax ni ninguna notación
de marcado como \( \), $ o \frac{}{}. Escribe todas las expresiones matemáticas con
caracteres de texto estándar (por ejemplo, "/" para división, "*" para multiplicación y
"^" para exponentes).

Presentaciones y documentos visuales

La documentación oficial dice que los modelos nuevos crean presentaciones, animaciones y documentos visuales siguiendo bien las instrucciones, y que normalmente sacan algo usable al primer intento. La recomendación para que salga bien es corta: pedir el diseño, no solo el contenido.

Crea una presentación profesional sobre [tema]. Incluye elementos de diseño pensados,
jerarquía visual y animaciones atractivas donde corresponda.

Si nunca has tocado el nivel de esfuerzo o no tienes claro qué mueve cada escalón, esa guía está completa en la bóveda. Aquí solo importa el límite: es una perilla de pensamiento, no de largo de respuesta.

Mantén las respuestas enfocadas, breves y concisas. Deja los descargos y las advertencias
cortos, y dedica la mayor parte de la respuesta a la respuesta principal. Cuando te pida
explicar algo, da un resumen de alto nivel salvo que se pida explícitamente una
explicación a fondo.

Hay un segundo truco, y es de los que más rinde por su tamaño: si tus instrucciones fijas ya son largas, la petición de brevedad se diluye entre todo lo demás. La documentación recomienda acompañarla con un recordatorio corto cerca del final del texto.

<tone_preference>
Mantén las salidas razonablemente concisas.
</tone_preference>

Con esto ya controlas cómo se ve lo que te contesta. La siguiente parada es una técnica que quizá aprendiste en otra guía para controlar exactamente eso, y que hoy ya no funciona.

Si aprendiste a usar Claude hace un par de años, es muy probable que te hayan enseñado este truco. Tiene nombre técnico en inglés y circuló en decenas de guías, cursos y hilos: consistía en no dejar que Claude empezara su respuesta desde cero, sino escribirle tú las primeras palabras para que las continuara.

Funcionaba porque un modelo que ya empezó una frase tiende a terminarla en el mismo carril. Si le dejabas puesta una llave, seguía en ese formato. Si le dejabas puesto «1.», seguía haciendo lista. Si le dejabas puesta una frase en el tono de un personaje, se quedaba en el personaje.

Para qué se usaba

• Abrirle la respuesta con una llave, para forzarlo a contestar en una estructura de datos y nada más.
• Abrirle la respuesta con una etiqueta, para forzarlo a devolver todo etiquetado.
• Abrirle la respuesta con «1.», para forzarlo a entregar una lista numerada.
• Abrirle la respuesta con una frase en el tono del personaje, para que no se le cayera a mitad de la conversación.

Los cinco reemplazos, de un vistazo

Caso por caso

Responde directamente, sin preámbulo. No empieces con frases como "Aquí está...",
"Basado en...", etc.

Tu respuesta anterior se interrumpió y terminaba con [pega aquí las últimas líneas que
sí llegaron]. Continúa desde donde te quedaste.

Recordatorio antes de seguir: sigues siendo [rol o personaje], estamos trabajando en
[proyecto], y las reglas que acordamos son [reglas]. Retoma desde el último punto con
eso en mente.

Resumen de la sección: si un prompt tuyo empieza a poner palabras en boca de Claude, ya no sirve. Todo lo que esa técnica lograba se consigue hoy escribiéndolo como instrucción tuya, en tu propio mensaje o en tus instrucciones fijas.

Le pides algo, te contesta una lista preciosa de recomendaciones, y tú te quedas con la sensación de que no hizo nada. Pasa todo el tiempo y casi siempre tiene la misma causa: no le pediste que lo hiciera, le preguntaste si podía.

Los modelos nuevos están entrenados para seguir instrucciones al pie de la letra, y eso incluye la forma verbal que usaste. «¿Puedes sugerir algunos cambios?» es, literalmente, una petición de sugerencias. Va a sugerir, aunque lo que tú querías era que lo arreglara.

La regla práctica cabe en una línea: verbo en imperativo si quieres acción, pregunta si quieres opinión. Y si de verdad querías la opinión, mejor todavía, porque ahora sabes que la vas a obtener sin que además te mueva cosas.

Los dos bloques opuestos

Si no quieres estar cuidando la forma verbal en cada mensaje, esto se resuelve una vez desde tus instrucciones fijas. Hay dos bloques y son espejo uno del otro: uno lo empuja a actuar por defecto, el otro lo frena por defecto. Elige el que corresponda a cómo trabajas, no los dos.

<default_to_action>
Por defecto, implementa los cambios en vez de solo sugerirlos. Si la intención del
usuario no está clara, deduce la acción más útil y procede, usando herramientas para
descubrir los detalles que te falten en vez de adivinarlos. Trata de deducir si el
usuario quiere o no que uses una herramienta (por ejemplo, editar o leer un archivo) y
actúa en consecuencia.
</default_to_action>

<do_not_act_before_instructions>
No te lances a implementar ni cambies archivos salvo que se te indique con claridad que
hagas cambios. Cuando la intención del usuario sea ambigua, opta por dar información,
investigar y hacer recomendaciones en vez de tomar acción. Procede con ediciones,
modificaciones o implementaciones solo cuando el usuario las pida explícitamente.
</do_not_act_before_instructions>

Llamadas en paralelo

Los modelos nuevos corren en paralelo las herramientas que no dependen una de otra. En la práctica se nota en tres cosas.

• Lanzan varias búsquedas a la vez mientras investigan, en vez de una tras otra.
• Leen varios archivos al mismo tiempo para armar contexto más rápido.
• Corren comandos en paralelo, al punto de que a veces pueden saturar el rendimiento del equipo.

La documentación oficial dice que ya lo hacen bien sin que se lo pidas, pero que pedirlo sube el acierto a casi el cien por ciento. Es de las cosas más baratas que puedes agregar a tus instrucciones fijas: no cambia el resultado, cambia cuánto esperas por él.

<use_parallel_tool_calls>
Si vas a llamar a varias herramientas y no hay dependencias entre esas llamadas, haz
todas las llamadas independientes en paralelo. Da prioridad a llamar herramientas de
forma simultánea siempre que las acciones se puedan hacer en paralelo en vez de una
tras otra. Por ejemplo, al leer 3 archivos, corre 3 llamadas en paralelo para cargar los
3 al contexto al mismo tiempo. Aprovecha al máximo las llamadas en paralelo donde se
pueda, para ganar velocidad y eficiencia. Sin embargo, si algunas llamadas dependen de
llamadas anteriores para conocer valores como los parámetros, NO llames a esas
herramientas en paralelo: hazlas de forma secuencial. Nunca uses marcadores de posición
ni adivines parámetros faltantes en las llamadas a herramientas.
</use_parallel_tool_calls>

Y el inverso, por si lo tuyo es lo contrario: cuando la máquina se ahoga, cuando quieres ir viendo paso por paso lo que hace, o cuando cada acción toca algo que prefieres revisar antes de la siguiente. Es una sola línea.

Ejecuta las operaciones de forma secuencial, con pausas breves entre cada paso para asegurar la estabilidad.

Con esto ya decides si actúa o se espera, y a qué velocidad. Lo que falta es la otra mitad: qué tanto piensa antes de moverse, que es la siguiente parada.

Durante dos años el consejo fue el mismo: dile que piense paso a paso. Hoy esa instrucción sobra casi siempre y en algunos modelos es contraproducente. Los modelos nuevos deciden solos cuándo razonar y cuánto, y el problema del día a día ya no es que piensen poco: es que a veces piensan de más.

Se ve así. Le pides algo concreto y antes de tocar nada abre media docena de archivos, se va por tres caminos distintos, vuelve al primero, y quince minutos después te entrega algo que pudo haber salido en dos. No está fallando: está explorando. La doc lo documenta en Claude Opus 4.6 —y algo parecido en Claude Fable 5 cuando el trabajo es de rutina y el esfuerzo va alto—: ese trabajo inicial muchas veces mejora el resultado final, pero puede juntar contexto de más o seguir varios hilos de investigación sin que se lo hayas pedido.

Aquí va a aparecer varias veces el nivel de esfuerzo: la perilla que decide cuánto trabajo se toma antes de contestar. En esta página solo se usa como recurso —súbelo, bájalo—, porque la guía de niveles de esfuerzo ya explica por dentro qué hace cada uno y repetirlo aquí sería ruido.

Cuando explora de más

La causa más común no es el modelo: es tu prompt viejo. Si en su momento le escribiste instrucciones para que fuera más minucioso —porque con los modelos de antes se quedaba corto—, esas líneas hoy siguen ahí empujando en una dirección que ya no hace falta. La doc da tres arreglos, en ese orden.

Cuando estés decidiendo cómo abordar un problema, elige un enfoque y comprométete con él. Evita volver sobre decisiones ya tomadas, salvo que encuentres información nueva que contradiga directamente tu razonamiento. Si estás sopesando dos enfoques, elige uno y llévalo hasta el final. Siempre puedes corregir el rumbo después si el enfoque elegido falla.

En qué modelos ya viene pensando solo

Esto es lo que casi nadie tiene claro, y explica por qué el mismo prompt se porta distinto según con quién estés hablando. No es una preferencia tuya ni una configuración escondida: es de fábrica y cambia entre generaciones.

Cuatro reglas para guiar su razonamiento

Después de recibir resultados de una herramienta, reflexiona con cuidado sobre su calidad y determina cuáles son los mejores siguientes pasos antes de continuar. Usa tu pensamiento para planear e iterar a partir de esa información nueva, y luego toma la mejor acción siguiente.

Pensar agrega tiempo de espera y solo debe usarse cuando vaya a mejorar de forma significativa la calidad de la respuesta, típicamente en problemas que requieren razonamiento de varios pasos. Ante la duda, responde directo.

Resumen operativo: no le pidas que piense, pídele que se comprometa. Limpia las instrucciones de minuciosidad que heredaste, borra el «si tienes duda», y guarda el nivel de esfuerzo para cuando lo demás ya no alcanzó. Si además el trabajo no cabe en una sola sesión, lo que sigue es dónde debe vivir la memoria.

Hay trabajos que no caben en una sola sesión. Un rediseño completo, una migración, doscientas pruebas que arreglar. Y el patrón que casi todo el mundo repite es el mismo: trabajar hasta que la conversación se pone lenta, resumir a mano lo que se hizo, abrir otra conversación, pegar el resumen y descubrir a los diez minutos que faltaba justo el detalle que importaba.

La doc oficial le dedica un bloque entero a esto, y su respuesta es incómoda de tan simple: la memoria de un trabajo largo no debe vivir en la conversación. Vive en archivos de tu proyecto. La conversación es desechable; los archivos no.

Sabe cuánto espacio le queda

Claude Sonnet 5, Claude Sonnet 4.6, Claude Sonnet 4.5 y Claude Haiku 4.5 traen conciencia de contexto: van rastreando cuánto espacio les queda a lo largo de la conversación. Es útil —les permite administrar el trabajo sabiendo con cuánto cuentan— y tiene un efecto secundario que ya viste sin saber qué era.

Es ese momento en que empieza a cerrar solo. Te entrega un resumen, propone continuar después, deja el trabajo a la mitad con buena letra. No se atoró: está intentando terminar con dignidad antes de quedarse sin espacio. Si tu herramienta compacta el contexto sola o puede guardar el estado en archivos —como Claude Code—, conviene decírselo, y entonces deja de hacerlo.

Tu ventana de contexto se compactará automáticamente conforme se acerque a su límite, lo que te permite seguir trabajando indefinidamente desde donde te quedaste. Por lo tanto, no detengas tareas antes de tiempo por preocupación por el contexto disponible. Conforme te acerques al límite, guarda tu progreso y tu estado actual en tus archivos de avance antes de que la ventana de contexto se refresque. Sé siempre tan persistente y autónomo como sea posible y completa las tareas por entero, aunque el final de tu contexto esté cerca. Nunca detengas artificialmente una tarea antes de tiempo, sin importar cuánto contexto quede.

Seis reglas para trabajar en varias ventanas

Lleva el registro de las pruebas en un archivo estructurado, tests.json, y mantenlo al día. Es inaceptable eliminar o editar pruebas, porque eso puede llevar a que quede funcionalidad faltante o rota.

Corre pwd; solo puedes leer y escribir archivos en este directorio.
Revisa progress.txt, tests.json y el historial de git.
Corre manualmente una prueba de integración fundamental antes de pasar a implementar funcionalidad nueva.

Esta es una tarea muy larga, así que puede convenirte planear tu trabajo con claridad. Se te anima a gastar todo tu contexto trabajando en la tarea; solo asegúrate de no quedarte sin contexto con trabajo importante sin guardar. Sigue trabajando de forma sistemática hasta que hayas completado esta tarea.

Dónde vive el estado, en concreto

La doc separa dos tipos de estado y les da tratamiento distinto. Lo que es estructurado —qué pruebas pasan, en qué va cada tarea— va en un formato estructurado, porque eso le ayuda a entender qué campos existen y a no inventarse otros. Lo que es narrativo —qué se hizo hoy, qué sigue, qué hay que tener cuidado— va en texto suelto, que para eso funciona mejor.

Así se ven los dos archivos que aparecen en la documentación. No hay que escribirlos a mano: se le pide que los mantenga, y lo que tú haces es leerlos.

{
  "tests": [
    { "id": 1, "name": "authentication_flow", "status": "passing" },
    { "id": 2, "name": "user_management", "status": "failing" },
    { "id": 3, "name": "api_endpoints", "status": "not_started" }
  ],
  "total": 200,
  "passing": 150,
  "failing": 25,
  "not_started": 25
}

Avance de la sesión 3:
- Arreglada la validación del token de autenticación
- Actualizado el modelo de usuario para manejar casos borde
- Sigue: investigar las fallas de user_management (prueba #2)
- Nota: no eliminar pruebas, puede dejar funcionalidad faltante

• Formatos estructurados para los datos estructurados: resultados de pruebas, estatus de tareas, cualquier cosa que se cuente.
• Texto libre para las notas de avance: para el «en qué voy» y el «qué sigue» funciona mejor que cualquier plantilla.
• Git como memoria entre sesiones: deja un registro de lo que se hizo y puntos de restauración. La doc dice que los modelos nuevos se desempeñan especialmente bien usando git para rastrear estado entre sesiones.
• Pídele explícitamente que lleve registro de su progreso y que se enfoque en avance incremental. No es implícito: si no se lo dices, no lo escribe.

Con esto un trabajo puede durar semanas sin que tú seas el pegamento entre sesiones. Lo que falta es lo otro que da miedo de dejarlo trabajar solo: qué pasa cuando toma una decisión que no se deshace.

Todo lo anterior de esta página empuja en la misma dirección: que trabaje más solo y te pregunte menos. Esta sección es la que pone el freno, y es la única que no mejora una respuesta: evita un destrozo.

La doc lo dice sin suavizarlo, y lo documenta en Claude Opus 4.6: sin guía, el modelo puede tomar acciones difíciles de revertir o que afectan sistemas compartidos. Borrar archivos, forzar un push, publicar en servicios externos. No es malicia ni error: es un ayudante muy capaz que asumió que tenía permiso porque nadie le dijo dónde estaba la línea.

Considera la reversibilidad y el impacto potencial de tus acciones. Se te anima a tomar acciones locales y reversibles como editar archivos o correr pruebas, pero para acciones difíciles de revertir, que afecten sistemas compartidos o que puedan ser destructivas, pregúntame antes de proceder.

Ejemplos de acciones que ameritan confirmación:
- Operaciones destructivas: borrar archivos o ramas, tirar tablas de una base de datos, rm -rf
- Operaciones difíciles de revertir: git push --force, git reset --hard, enmendar commits ya publicados
- Operaciones visibles para otros: subir código, comentar en PRs o issues, enviar mensajes, modificar infraestructura compartida

Cuando encuentres un obstáculo, no uses acciones destructivas como atajo. Por ejemplo, no te saltes los chequeos de seguridad (como --no-verify) ni descartes archivos desconocidos que pueden ser trabajo a medias.

El entregable es el diagnóstico, no el arreglo

Este segundo bloque viene de la página de Claude Fable 5 y es el que más se nota en el día a día, porque cubre el caso más frecuente: tú no pediste nada, solo estabas pensando en voz alta.

Pasa así. Le cuentas que algo se está portando raro, en tono de «qué crees que sea». Y para cuando terminas de escribir, ya cambió tres archivos, dejó una rama de respaldo por si acaso y te redactó un correo que nadie pidió. La doc lo nombra tal cual: Fable 5 ocasionalmente toma acciones que no se le pidieron.

El arreglo no es pedirle que sea más prudente. Es definirle qué cuenta como entregable cuando le describes un problema en vez de pedirle un cambio.

Cuando yo esté describiendo un problema, haciendo una pregunta o pensando en voz alta en vez de pedir un cambio, el entregable es tu evaluación. Reporta lo que encontraste y detente. No apliques un arreglo hasta que te lo pida. Antes de correr un comando que cambia el estado del sistema (reinicios, borrados, ediciones de configuración), comprueba que la evidencia de verdad respalda esa acción concreta. Una señal que se parece a una falla conocida puede tener otra causa.

Los dos bloques juntos

• El de reversibilidad decide qué acciones necesitan tu visto bueno, y deja lo local y reversible en sus manos.
• El de límites decide cuándo actuar siquiera, separando lo que le cuentas de lo que le pides.
• Los dos van al mismo lugar: tu CLAUDE.md, o las instrucciones del Proyecto donde trabajas seguido. Se pegan una vez.
• Sin ellos no pasa nada malo la mayoría de los días. El problema es el día que sí.

Esta es, en total, la media hoja que separa un ayudante autónomo de uno con el que amaneces revisando qué cambió mientras no veías. Lo que sigue es cuándo le conviene repartir el trabajo en subagentes y cuándo abrir uno es puro desperdicio.

Un subagente es una copia de Claude que se abre para una tarea puntual, con su propio contexto, y que al terminar le regresa nada más el resultado al que la mandó. La novedad de los modelos nuevos es que ya no hay que pedirlo: la doc dice que orquestan subagentes de forma nativa, que reconocen solos cuándo una tarea se beneficia de repartirse, y que lo hacen sin instrucción explícita.

Por eso esta sección casi no trata de cómo activar subagentes. Trata de dónde poner el freno y dónde el acelerador, porque el problema cambió de lado según con qué modelo estés trabajando.

Primero la investigación

Antes de repartir trabajo conviene arreglar el trabajo en sí. Los modelos nuevos encuentran y sintetizan información de varias fuentes bastante bien, y la doc da tres consejos para que salga mejor.

Busca esta información de forma estructurada. Conforme reúnas datos, desarrolla varias hipótesis en competencia. Anota tu nivel de confianza en tus notas de avance para calibrarte mejor. Autocritica tu enfoque y tu plan cada cierto tiempo. Mantén actualizado un árbol de hipótesis o un archivo de notas de investigación, para conservar la información y dar transparencia. Descompón esta tarea de investigación compleja de forma sistemática.

El problema cambió de lado

Durante años el consejo era el mismo: si quieres que reparta trabajo, díselo. Hoy depende del modelo, y en la mayoría el consejo se invirtió. La doc trae un ejemplo que se reconoce enseguida: el modelo abre subagentes para explorar código cuando una búsqueda directa era más rápida y suficiente.

Delegar paga cuando el trabajo es grande e independiente de verdad. Cuando no lo es, multiplica el costo y el tiempo sin mejorar nada.

Delega a un subagente solo en tareas grandes que sean genuinamente independientes y paralelizables, como una investigación amplia en muchos archivos. No delegues trabajo que puedes terminar tú mismo en unas cuantas llamadas de herramienta, y no uses subagentes para verificar ni para revisar dos veces tu propio trabajo. Si un solo subagente puede completar la tarea, usa uno en vez de varios, y mantén bajo el número de subagentes que abres.

Usa subagentes cuando las tareas puedan correr en paralelo, necesiten contexto aislado, o sean líneas de trabajo independientes que no tengan que compartir estado. Para tareas simples, operaciones en secuencia, cambios en un solo archivo, o tareas donde necesitas mantener el contexto entre pasos, trabaja directo en vez de delegar.

No abras un subagente para trabajo que puedes completar directamente en una sola respuesta (por ejemplo, reescribir una función que ya tienes a la vista).

Abre varios subagentes en el mismo turno cuando estés abriéndote en abanico sobre varios elementos o leyendo varios archivos.

No te quedes esperando a cada uno

La página de Claude Fable 5 agrega el detalle que más cambia el tiempo de una corrida larga: es mejor la comunicación asíncrona entre el que orquesta y los subagentes que quedarse bloqueado hasta que cada uno regresa.

Y los subagentes de vida larga —los que conservan su contexto entre subtareas— salen más baratos y más rápidos, porque reaprovechan lo que ya leyeron y evitan que todo se atore esperando al más lento.

Delega las subtareas independientes a subagentes y sigue trabajando mientras corren. Intervén si un subagente se sale del camino o le falta contexto relevante.

Establece un método para revisar tu propio trabajo cada [intervalo] mientras construyes. Córrelo cada [intervalo], verificando tu trabajo con subagentes contra la especificación.

¿Y encadenar prompts a mano?

Con el pensamiento adaptativo y la orquestación de subagentes, Claude ya resuelve por dentro casi todo el razonamiento de varios pasos. Partir una tarea en mensajes separados sigue sirviendo, pero por otra razón: cuando necesitas ver los resultados intermedios o forzar una estructura de proceso específica.

El patrón que la doc marca como el más común es la autocorrección, y son tres pasos.

Aquí termina lo que la referencia oficial dice de subagentes. Si lo que quieres es armar la orquesta completa —quién dirige, quién ejecuta y cómo se reparten un proyecto real—, esa guía ya está en la bóveda y entra al detalle que aquí sobraría.

Y si el flujo tiene que decidir solo por dónde seguir según lo que va encontrando, el territorio es workflows dinámicos, que es otra cosa que repartir trabajo en paralelo.

La regla corta para llevarte: si con uno alcanza, uno. Si son tres líneas de trabajo que de verdad no se hablan entre ellas, tres. Y si la corrida va a durar horas, alguien con contexto limpio tiene que revisar lo que salió.

Esta sección junta los dos vicios que más se quejan de los modelos nuevos, y son distintos entre sí. Uno es hacer de más: entregas tres archivos cuando pediste uno, capas de abstracción que nadie pidió, flexibilidad para un futuro que no existe. El otro es decir de más: afirmar algo del proyecto sin haberlo abierto, o reportar como hecho algo que todavía no está.

Los dos se arreglan igual: con un bloque de texto pegado una vez, no repitiéndolo en cada mensaje.

Hacer de más

La doc lo llama exceso de entusiasmo y se lo atribuye a Claude Opus 4.5 y Claude Opus 4.6: tendencia a inflar el trabajo creando archivos extra, agregando abstracciones innecesarias, o construyendo flexibilidad que nadie pidió. Si lo estás viendo, la recomendación es una sola: guía específica para mantener las soluciones al mínimo.

El bloque son cuatro frentes, y vale la pena leerlos por separado porque cada uno corta un tipo distinto de trabajo inflado.

Evita la sobre-ingeniería. Haz solo los cambios que se pidieron directamente o que son claramente necesarios. Mantén las soluciones simples y enfocadas:

- Alcance: no agregues funciones, no reescribas código ni hagas «mejoras» más allá de lo que se pidió. Arreglar un error no exige limpiar el código de alrededor. Una función simple no necesita configuración extra.

- Documentación: no agregues comentarios, descripciones ni anotaciones de tipos a código que no cambiaste. Agrega comentarios solo donde la lógica no se explica sola.

- Código defensivo: no agregues manejo de errores, respaldos ni validaciones para escenarios que no pueden pasar. Confía en el código interno y en las garantías del framework. Valida solo en las fronteras del sistema (lo que escribe el usuario, los servicios externos).

- Abstracciones: no crees ayudantes, utilidades ni abstracciones para operaciones que pasan una sola vez. No diseñes para requisitos futuros hipotéticos. La cantidad correcta de complejidad es la mínima que la tarea actual necesita.

Si creas archivos nuevos temporales, scripts o archivos de ayuda para iterar, límpialos borrándolos al final de la tarea.

Que no optimice para pasar las pruebas

Este es el vicio más caro de detectar, porque desde afuera se ve como éxito: las pruebas pasan. Lo que ocurrió por dentro es que se concentró demasiado en hacerlas pasar y no en resolver el problema —valores clavados a mano, o scripts de ayuda usados como atajo en vez de las herramientas estándar—.

El bloque es largo a propósito. Además de pedir la solución general, incluye la parte que casi nadie escribe: que si la tarea es imposible o una prueba está mal, te lo diga en vez de darle la vuelta.

Por favor escribe una solución de buena calidad y de propósito general, usando las herramientas estándar disponibles. No crees scripts de ayuda ni atajos para lograr la tarea de forma más eficiente. Implementa una solución que funcione correctamente para todas las entradas válidas, no solo para los casos de prueba. No claves valores fijos ni armes soluciones que solo funcionen para entradas de prueba específicas. En vez de eso, implementa la lógica real que resuelve el problema de forma general.

Concéntrate en entender los requisitos del problema e implementar el algoritmo correcto. Las pruebas están ahí para verificar que la solución es correcta, no para definirla. Entrega una implementación con principios, que siga buenas prácticas y principios de diseño de software.

Si la tarea no es razonable o no es factible, o si alguna de las pruebas está mal, dímelo en vez de darle la vuelta. La solución debe ser robusta, mantenible y extensible.

Decir de más

Los modelos nuevos inventan bastante menos y dan respuestas más aterrizadas en el código real. Aun así, la doc trae un bloque para empujar todavía más en esa dirección, y es de los que más se notan el mismo día que lo pegas: le prohíbe hablar de código que no abrió.

<investigate_before_answering>
Nunca especules sobre código que no hayas abierto. Si el usuario menciona un archivo específico, DEBES leer el archivo antes de responder. Asegúrate de investigar y leer los archivos relevantes ANTES de responder preguntas sobre el proyecto. Nunca afirmes nada sobre el código sin investigar, salvo que estés seguro de la respuesta correcta: da respuestas fundamentadas y sin invenciones.
</investigate_before_answering>

El bloque más fuerte de esta sección

Sale de la página de Claude Fable 5 y aplica a las corridas largas, esas donde te entrega un resumen de avance después de trabajar solo un buen rato. El riesgo ahí no es que se equivoque: es que te reporte como hecho algo que nunca comprobó.

La instrucción lo ata a la evidencia. Antes de reportar avance, cada afirmación se audita contra un resultado real de herramienta de esa misma sesión; lo que no está verificado se dice; si las pruebas fallan, se dice con la salida; si se saltó un paso, se dice.

Antes de reportar avance, audita cada afirmación contra un resultado de herramienta de esta misma sesión. Reporta solo el trabajo del que puedas señalar evidencia; si algo todavía no está verificado, dilo explícitamente. Reporta los resultados con fidelidad: si las pruebas fallan, dilo con la salida; si te saltaste un paso, dilo; cuando algo está hecho y verificado, dilo de forma llana, sin matizarlo.

Cinco bloques, cinco vicios distintos. Si vas a pegar uno solo hoy, que sea el de no especular: es el que cambia lo que te contesta cuando le preguntas por un archivo que todavía no ha abierto.

Dos temas que la doc pone juntos y que en la práctica se usan juntos: lo que Claude puede sacar de una imagen, y lo que produce cuando le pides que diseñe algo. Uno es entrada, el otro es salida, y los dos tienen un truco concreto.

Lo que puede sacar de una imagen

Los modelos nuevos mejoraron leyendo imágenes y extrayendo datos de ellas, y la mejora se nota sobre todo cuando hay varias imágenes en la conversación al mismo tiempo. Eso también se traslada a cuando maneja una computadora: interpreta capturas de pantalla y elementos de interfaz de forma más confiable. Y sirve para video, partiéndolo en cuadros y analizándolos.

El truco medido lo dice la doc sin rodeos: darle una herramienta o una habilidad para recortar. Cuando puede acercarse a la zona de la imagen que importa, sus evaluaciones de imagen suben de forma consistente.

El problema tiene nombre

La doc lo nombra así: sin guía, los modelos caen en patrones genéricos que producen lo que los usuarios llaman la estética de IA genérica. Ese degradado morado sobre fondo blanco que reconoces a un kilómetro no es un accidente: es el centro de la distribución, y ahí es donde un modelo aterriza si nadie le pide otra cosa.

El bloque oficial ataca cuatro frentes —tipografía, color, movimiento y fondo— y cierra con una lista de lo que hay que evitar.

<frontend_aesthetics>
Tiendes a converger hacia resultados genéricos, dentro de la distribución. En diseño de frontend eso produce lo que los usuarios llaman la estética de IA genérica. Evítalo: haz frontends creativos y distintivos, que sorprendan y den gusto.

Concéntrate en:
- Tipografía: elige fuentes bonitas, únicas e interesantes. Evita fuentes genéricas como Arial e Inter; opta por elecciones distintivas que eleven la estética del frontend.
- Color y tema: comprométete con una estética coherente. Usa variables CSS para mantener la consistencia. Los colores dominantes con acentos filosos rinden más que las paletas tímidas y repartidas por igual. Inspírate en temas de editores de código y en estéticas culturales.
- Movimiento: usa animaciones para efectos y micro-interacciones. Prioriza soluciones solo con CSS cuando sea HTML. Usa la librería Motion en React cuando esté disponible. Concéntrate en los momentos de alto impacto: una carga de página bien coreografiada con revelados escalonados (animation-delay) da más gusto que micro-interacciones sueltas.
- Fondos: crea atmósfera y profundidad en vez de caer en colores planos. Superpón capas de degradados CSS, usa patrones geométricos, o agrega efectos contextuales que combinen con la estética general.

Evita las estéticas genéricas generadas por inteligencia artificial:
- Familias tipográficas sobreexpuestas (Inter, Roboto, Arial, fuentes del sistema)
- Esquemas de color trillados (en particular degradados morados sobre fondo blanco)
- Layouts y patrones de componentes predecibles
- Diseño de molde, sin carácter propio del contexto

Interpreta con creatividad y toma decisiones inesperadas que se sientan genuinamente diseñadas para el contexto. Varía entre temas claros y oscuros, distintas fuentes, distintas estéticas. Todavía tiendes a converger en las mismas elecciones (Space Grotesk, por ejemplo) de una generación a otra. Evítalo: es crítico que te salgas del molde.
</frontend_aesthetics>

<frontend_aesthetics>
NUNCA uses estéticas genéricas generadas por inteligencia artificial: familias tipográficas sobreexpuestas (Inter, Roboto, Arial, fuentes del sistema), esquemas de color trillados (en particular degradados morados sobre fondo blanco u oscuro), layouts y patrones de componentes predecibles, y diseño de molde sin carácter propio del contexto. Usa fuentes únicas, colores y temas coherentes, y animaciones para efectos y micro-interacciones.
</frontend_aesthetics>

Por qué «que se vea limpio» no te da variedad

Este es el consejo más accionable de toda la sección y sale de la página de Claude Sonnet 5, con la misma redacción en la de Claude Opus 4.8. Las instrucciones genéricas —«no uses ese color», «que se vea limpio y minimalista»— no producen variedad: mueven al modelo a otra paleta fija. Cambias un molde por otro molde.

Hay dos salidas que sí funcionan, según la doc.

1 · Dale una dirección concreta

El modelo sigue las especificaciones explícitas con precisión. El ejemplo de la doc es una página de aterrizaje entera descrita a mano, y lo que importa no es esa página sino qué campos trae. Si tu encargo cubre estos, dejas de depender de su estilo casa:

2 · Que te proponga antes de construir

La otra salida rompe el estilo casa y además te devuelve el control: que proponga cuatro direcciones visuales distintas antes de escribir una sola línea, que tú elijas una, y que solo entonces construya. La doc apunta que esto produce direcciones genuinamente distintas entre una corrida y otra, y que es la vía recomendada si antes conseguías variedad moviendo ajustes que ya no existen.

Antes de construir, propón 4 direcciones visuales distintas hechas a la medida de este encargo (cada una como: color de fondo en hex / color de acento en hex / tipografía, más una línea de por qué). Pídeme que elija una, y luego implementa solo esa dirección.

La propia doc apunta que, para trabajo de diseño que no pasa por código, existe un canvas donde Claude genera e itera los diseños de forma interactiva. Eso es Claude Design, y tiene su guía completa en la bóveda.

Si prefieres las mismas capacidades sin salir de tu editor, la alternativa abierta también está documentada, con las diferencias reales entre una y otra.

El resumen de la sección en una línea: el bloque de estética evita lo feo genérico, pero lo que produce diseño distinto es una dirección elegida a propósito. Pega el bloque una vez; la dirección se elige en cada encargo.

Todo lo anterior aplica a los cuatro. Esta sección es lo otro: cada modelo de la generación actual tiene una rareza propia, y una sola línea que la corrige. Si te cambiaste de modelo y sientes que el mismo prompt de siempre te da un resultado distinto, casi siempre es esto y no tu prompt.

La regla que ordena la sección: a unos hay que quitarles instrucciones y a otros hay que ponérselas. Opus 5 se verifica solo, así que las líneas de «revisa tu trabajo» le sobran. Opus 4.8 delega poco, así que hay que empujarlo. Fable 5 obedece tanto que una instrucción breve alcanza, y las habilidades muy prescriptivas que escribiste para modelos viejos lo empeoran. Sonnet 5 hace exactamente lo que dijiste, ni un milímetro más.

Los cuatro, de un vistazo

Cuando tengas suficiente información para actuar, actúa. No vuelvas a deducir hechos que ya quedaron establecidos en la conversación, no reabras una decisión que ya tomé, y no me narres opciones que no vas a seguir. Si estás pesando entre dos caminos, dame una recomendación, no un repaso exhaustivo. Esto no aplica a lo que pienses por dentro.

La taquigrafía está bien entre llamadas a herramientas: ahí estás pensando en voz alta y ser breve ayuda. Tu resumen final es otra cosa: es para alguien que no vio nada de eso.

Si llevas un rato trabajando sin que yo estuviera mirando —de noche, a lo largo de muchas llamadas a herramientas, desde la última vez que hablamos—, tu mensaje final es lo primero que veo. Escríbelo como un reencuadre, no como la continuación de tu hilo de trabajo: primero el resultado, después la una o dos cosas que necesitas de mí, cada una explicada como si fuera nueva. El vocabulario que armaste mientras trabajabas es tuyo, no mío: déjalo atrás salvo que lo vuelvas a presentar.

Cuando escribas ese resumen, suelta la jerga de trabajo. Escribe oraciones completas. Desarrolla los términos. Nada de cadenas de flechas, ni palabras pegadas con guiones, ni etiquetas que te inventaste antes. Cuando menciones archivos, cambios, opciones o cualquier otro identificador, dale a cada uno su propia frase en lenguaje llano. Abre con el resultado: una oración sobre qué pasó o qué encontraste. Después el detalle que lo sostiene. Si tienes que elegir entre corto y claro, elige claro.

Mantén las respuestas enfocadas, breves y concisas. Deja cortas las advertencias y las salvedades, y gasta la mayor parte de la respuesta en la respuesta misma. Cuando te pida explicar algo, dame un resumen de alto nivel salvo que te pida expresamente una explicación a fondo.

<tone_preference>
Mantén las salidas razonablemente concisas.
</tone_preference>

Reporta todos los problemas que encuentres, incluidos los que te generen dudas y los que consideres de severidad baja. No filtres por importancia ni por confianza en esta etapa: de eso se encarga un paso de verificación aparte. Aquí tu objetivo es la cobertura: es mejor sacar un hallazgo que después se descarte que dejar caer en silencio un error real. En cada hallazgo incluye tu nivel de confianza y una severidad estimada, para que un filtro posterior los pueda ordenar.

El ejemplo se ve tonto escrito así, y por eso funciona: con Sonnet 5 la diferencia entre las dos frases es la diferencia entre una sección formateada y veinte. Cada vez que te entregue el trabajo a medias, revisa si tu instrucción decía «todas» o si tú lo diste por hecho.

No abras un subagente para trabajo que puedes terminar directamente en una sola respuesta (por ejemplo, reescribir una función que ya tienes a la vista).

Abre varios subagentes en el mismo turno cuando tengas que abrirte en abanico sobre varios elementos o leer varios archivos.

El nivel de esfuerzo aparece varias veces en esta sección y no se explica aquí a propósito: es una palanca distinta a la del prompt, con su propia guía. Si quieres saber cuál usar por tarea y cómo se cambia en el chat, en Cowork y en Claude Code, eso vive en su propia página. Aquí solo importa una cosa: en Claude Opus 5, bajarlo no te acorta la respuesta.

A fondo con cada uno

• Qué modelo de Claude usar — Si todavía no sabes cuál te toca, empieza por ahí: los cuatro comparados, con el «cuándo no» de cada uno.
• Guía de Claude Fable 5 — Qué es capaz de hacer, en qué planes aparece y cómo se paga aparte. Aquí solo está cómo se le habla.
• Guía de Claude Opus 5 — El modelo completo, no solo su manía de escribir largo.
• Guía de Claude Sonnet 5 — El que casi todos usan todo el día, con su propio recorrido.

Si tienes un CLAUDE.md que escribiste hace meses, o unas instrucciones de Proyecto que llevas arrastrando de modelo en modelo, hay una parte que envejeció mal. No porque estuviera mal escrita: porque estaba escrita contra un modelo que se portaba distinto. Las líneas que servían para que no se quedara corto hoy lo hacen dispararse de más.

La documentación oficial lo resume en seis puntos. Aquí van los seis, en orden, con qué revisar y qué cambiar en cada uno. Léelos con tu archivo abierto al lado: la mitad del trabajo es borrar.

Es el ejemplo que trae la documentación, y sirve para cualquier cosa que le pidas construir, no solo para un tablero. La frase de la derecha no describe una función nueva: le sube el techo a todas.

El punto 4 se queda a la mitad si no sabes qué nivel te toca. La guía de los niveles de esfuerzo cubre eso: cuál usar por tarea, cómo se comporta cada modelo y dónde se cambia en el chat, en Cowork y en Claude Code. Aquí basta con saber que esa decisión salió de tu prompt y se mudó a una palanca aparte.

Los reemplazos del punto 5 —los cinco, con el texto exacto que se pega— están en la sección 05 de esta página, y el punto 6 se entiende mejor después de leer la sección 06, donde están los dos bloques que deciden si actúa por su cuenta o espera a que se lo pidas.

La auditoría, en siete búsquedas

Abre tu CLAUDE.md o las instrucciones de tu Proyecto y busca esto, literal. Cada coincidencia es una línea que sobra, una que hay que suavizar o un hueco que llenar:

• «Verifica», «revisa dos veces», «asegúrate de comprobar»: si tu modelo se verifica solo, esas líneas solo agregan vueltas y no mejoran el resultado.
• Mayúsculas y palabras subidas de tono: CRÍTICO, SIEMPRE, NUNCA, DEBES. Bájalas a lenguaje normal y déjalas solo donde de verdad no haya excepción.
• «Si tienes duda, usa la herramienta»: hoy la usa de más. Cámbialo por cuándo sí conviene usarla.
• Cualquier intento de fijarle a mano cuánto piensa: eso se maneja con el nivel de esfuerzo, no con palabras.
• El lugar donde le dejabas escrita la primera línea de su respuesta: eso ya lo rechaza.
• Instrucciones que dicen qué NO hacer: reescríbelas diciendo qué SÍ hacer, que es lo que de verdad lo dirige.
• El total de reglas. Si son más de las que puedes recitar de memoria, están compitiendo entre ellas y algunas se están perdiendo.

Lee mi archivo CLAUDE.md (o las instrucciones de este Proyecto) y audítalo contra estos seis criterios:

1. Especificidad: qué instrucciones describen un adjetivo («que quede profesional») en vez de un comportamiento observable.
2. Modificadores: dónde falta un modificador que te empuje a subir la calidad y el detalle del resultado.
3. Funciones explícitas: qué cosas doy por hechas y en realidad habría que pedirte (animaciones, elementos interactivos, formato de salida).
4. Pensamiento: si hay instrucciones que intenten fijar a mano cuánto piensas antes de contestar, en vez de dejarlo al nivel de esfuerzo.
5. Principio de respuesta: si hay instrucciones que te dejen escrita la primera línea de tu contestación.
6. Exceso de empuje: qué instrucciones fueron escritas para que no fueras perezoso y hoy te hacen reaccionar de más (mayúsculas, «CRÍTICO», «siempre», «si tienes duda, hazlo»).

Devuélveme tres listas: QUÉ SOBRA (con la línea exacta y por qué), QUÉ ESTÁ DE MÁS (lo que ya haces por defecto y no hace falta pedirte) y QUÉ FALTA (lo que sí conviene agregar). En cada punto cita la línea tal como está escrita hoy. No edites el archivo: solo dime qué cambiar y espera mi visto bueno.

Cuando termines la auditoría vas a tener un archivo más corto que el que tenías. Eso es la señal de que salió bien.

Hasta aquí llegan las catorce paradas. Lo que sigue es el cierre en tres partes: el mapa de los bloques ordenado por síntoma, lo que se quedó fuera a propósito y por qué, y el registro donde va a quedar cada actualización.

El índice de bloques

Los bloques completos no se repiten aquí: cada uno vive en su sección, con el contexto que explica cuándo sirve y cuándo estorba. Este es el mapa. Busca tu síntoma en la columna de en medio y salta.

Lo que se quedó fuera, y por qué

La página oficial de la que sale todo esto está escrita para quien construye con Claude desde código. Esta guía es para quien lo usa por suscripción: el chat, Claude Code y Cowork. Todo lo que solo existe del otro lado se descartó a propósito, no por descuido:

• Los identificadores exactos de cada modelo —los que se escriben dentro de un programa— y el texto que se le pone para que se identifique a sí mismo.
• Los parámetros: cuánto puede pensar, cuánto puede responder, los ajustes de variedad y aleatoriedad. En una suscripción no hay dónde escribirlos.
• Los límites técnicos y los códigos de error. Cuando algo dejó de funcionar, aquí simplemente dice que ya no funciona.
• Los ejemplos en código, las llamadas desde la terminal y las estructuras de datos con las que se define una respuesta con forma fija.
• Los precios y las cuentas de consumo por millón: no cambian nada de lo que escribes en el chat.
• Las herramientas que se definen desde código, como la que sirve para que un agente te entregue un mensaje a media corrida sin cortar su turno.

Por qué pasa eso —qué le compite a qué dentro de la ventana de contexto— está explicado en las nuevas reglas del contexto, que es la guía que conviene leer justo después de esta si te tomaste en serio lo de podar.

Y si lo que te preocupa es gastar menos en cada conversación sin perder calidad, la guía de eficiencia toma el tema por el otro lado: qué escribir para que cada respuesta cueste menos.

El registro de cambios

Esta página se revisa contra la documentación oficial cada vez que Anthropic mueve la suya, y aquí queda el rastro de cada actualización: qué cambió allá y qué se cambió aquí.

Si encuentras algo que ya no coincide con lo que ves en tu pantalla, es que Anthropic movió la suya: avísanos en la comunidad y esta página se actualiza con su fila en el registro.