🔄 ¿Más contexto es mejor? No con Fable 5
🧠 Imagínalo así: La ingeniería clásica de prompts se construye como un contrato blindado de abogado: cada cláusula prevé una excepción, "haz siempre X", "nunca hagas Y", "si ocurre Z, entonces W". Eso protegía frente a un modelo que olvidaba reglas a mitad del proceso. Con un modelo que ya sigue instrucciones de sobra, el mismo contrato se convierte en burocracia que nadie lee hasta el final.
La convención que probablemente ya aprendiste dice: cuanto más contexto y más reglas explícitas, mejor el resultado. Eso tenía sentido mientras el seguimiento de instrucciones (instruction following) era inconsistente: enumerar cada comportamiento era la única forma de garantizar que el modelo no pasara por alto nada importante.
Con Claude Fable 5 esta premisa cambia. El seguimiento de instrucciones se volvió lo bastante sólido como para que una instrucción breve y bien elegida ya guíe el comportamiento correcto, sin necesidad de enumerar cada regla. Enumerarlo todo dejó de ser una protección y se convirtió en ruido: cada regla adicional compite por la atención con las que realmente importan, infla el prompt e incluso puede llevar el estilo de la respuesta al mismo tono prolijo del propio prompt.
Leyenda: a la izquierda, cada regla enumerada compite por la atención y el resultado queda diluido; a la derecha, una sola instrucción breve se entiende con claridad: un buen seguimiento de instrucciones no necesita una lista.
⚠️ No lo confundas con recortar información
"Di menos, no más" no significa eliminar el contexto que cambia el resultado; significa eliminar la redundancia de reglas que el modelo cumpliría por sí solo. La información sobre la intención sigue siendo tan importante como siempre (el tema 5 explica por qué).
En una frase: los modelos débiles necesitaban una lista; Fable 5 necesita una dirección clara: enumerarlo todo se convirtió en ruido, no en protección.
🎯 Strong instruction following — el prompt oficial
🧠 Imagínalo así: es la diferencia entre capacitar a un pasante nuevo (que necesita un manual paso a paso) y darle una directriz a un sénior (que ya sabe completar los detalles). Fable 5 ya se acerca al perfil de «sénior»: trátalo así.
La documentación oficial "Prompting Claude Fable 5" es clara al respecto: el seguimiento de instrucciones mejoró lo suficiente como para que puedas guiar la mayoría de los comportamientos con una instrucción breve, en vez de enumerar cada comportamiento por su nombre. Es un cambio de estrategia, no solo de estilo de escritura.
Instruction-following is improved enough that you can steer most behaviors with a brief instruction rather than enumerating each behavior by name.
El seguimiento de instrucciones mejoró lo suficiente como para que puedas guiar la mayoría de los comportamientos con una instrucción breve, en vez de enumerar cada comportamiento por su nombre.
En la práctica: si tu prompt del sistema tiene una lista de 15 viñetas que intenta cubrir todos los comportamientos posibles («haz siempre X», «nunca hagas Y», «en el caso Z, haz W»...), es probable que Fable 5 ya responda bien a una frase que exprese la intención central. Prueba quitando la mitad de la lista antes de considerar agregar otra regla.
✓ Qué HACER
- ✓Escribir 1-2 oraciones que expresen la intención y el resultado esperado.
- ✓Confiar en que los comportamientos predeterminados (formato, tono, cuidado con los casos límite evidentes) ya vienen incorporados.
- ✓Agregar una regla nueva solo cuando el comportamiento predeterminado falle de verdad en una prueba real.
✗ Qué NO hacer
- ✗Copiar y pegar la misma lista de 20 reglas que usabas para modelos anteriores.
- ✗Repetir la misma instrucción de distintas formas "por si acaso".
- ✗Tratar cada excepción hipotética como si tuviera que convertirse en una regla permanente.
En una frase: una instrucción breve y bien enfocada sustituye la lista: el modelo ya sigue suficientes instrucciones.
✂️ Empieza por el resultado — legible ≠ conciso
🧠 Imagínalo así: piensa en un titular de periódico. No es corto porque hayan cortado las palabras por la mitad, sino porque alguien decidió cuidadosamente qué es lo más importante contar primero.
La documentación oficial también ofrece la receta para la respuesta final: empieza por el resultado ("lead with the outcome"). La primera frase después de terminar debe responder "qué pasó" o "qué encontraste": lo que el usuario pediría si dijera "solo dame el resumen". Los detalles y el razonamiento vienen después.
Objetivo: hacer que el agente empiece cualquier respuesta larga por el resultado y solo después lo justifique, sin comprimir la salida en fragmentos ilegibles.
Lead with the outcome. Your first sentence after finishing should answer "what happened" or "what did you find": the thing the user would ask for if they said "just give me the TLDR." Supporting detail and reasoning come after. Being readable and being concise are different things, and readability matters more. The way to keep output short is to be selective about what you include (drop details that don't change what the reader would do next), not to compress the writing into fragments, abbreviations...
Empieza por el resultado. Tu primera frase después de terminar debe responder "qué pasó" o "qué encontraste": lo que el usuario pediría si dijera "solo dame el resumen". Los detalles de apoyo y el razonamiento vienen después. Ser legible y ser conciso son cosas distintas, y la legibilidad importa más. La forma de mantener la respuesta breve es seleccionar qué incluir (eliminar detalles que no cambian lo que el lector haría después), no comprimir el texto en fragmentos, abreviaturas…
Cómo comprobar: pega esto al final de tu CLAUDE.md o system prompt y observa la próxima respuesta larga. La primera frase ya debería contar el resultado, sin un «déjame explicar primero lo que hice» antes de llegar a él.
🔍 Distinción clave: legible ≠ conciso
- Legibilidad — el lector lo entiende a la primera, sin tener que descifrarlo. Eso importa más.
- Brevedad — menos palabras. Solo importa si no afecta la legibilidad.
- Mantenerlo breve tiene que ver con selectividad (lo que dejas afuera), no sobre compresión (cómo escribes lo que quedó).
✓ Conciso y bien hecho
- ✓Elimina el párrafo que no cambia la próxima acción del lector.
- ✓Escribe oraciones completas, aunque sean cortas.
- ✓Escribe los nombres de archivos y números con todas sus letras la primera vez que aparezcan.
✗ Concisión mal hecha
- ✗Comprime en fragmentos como "ok, hecho, sig.".
- ✗Abrevia todo hasta convertirlo en un telegrama.
- ✗Elimina el resultado principal pensando que «menos siempre es mejor».
En una frase: ser conciso tiene que ver con lo que omites, no con cómo redactas lo que queda.
🔀 Breve entre llamadas a herramientas vs. resumen final (re-grounding)
🧠 Imagínalo así: un cirujano puede hablar con jerga técnica breve durante la operación, con el equipo que está allí. Pero el informe que entrega a la familia al final debe volver a explicarlo todo desde cero, en un lenguaje claro: quienes lo reciben no estaban en la sala.
Durante el trabajo — entre una llamada a una herramienta y otra — la taquigrafía breve es excelente. Es como «pensar en voz alta»; nadie lo está leyendo en tiempo real, y ser breve allí ahorra tiempo y tokens sin perder claridad de verdad.
Leyenda: la taquigrafía entre tool calls está bien para pensar en voz alta; pero el mensaje final debe volver a dar contexto a quien no vio el proceso: primero el resultado, y cada identificador explicado como si fuera nuevo.
Inicias la tarea y te ausentas
Durante la noche, o en una sesión larga en la que no estás leyendo cada paso del agente.
Entre llamadas a herramientas: taquigrafía concisa
Buena señal: es el agente pensando en voz alta, y que sea breve ahí no cuesta nada porque nadie lo está leyendo en tiempo real.
Sesión larga, muchas idas y vueltas
La jerga interna se acumula: nombres de flags, siglas de PR, atajos que solo tienen sentido para quienes siguieron todo el proceso.
Mensaje final: cambio de modo
De "continuación de la línea de razonamiento" a "re-grounding": primero el resultado, y cada identificador (archivo, commit, flag) explicado como si el lector oyera hablar de él por primera vez.
Objetivo: hacer que el agente cambie del «modo telegráfico» al «modo de volver a fundamentar» al cerrar una sesión larga sin supervisión.
Terse shorthand is fine between tool calls (that's you thinking out loud, and brevity there is good). Your final summary is different: it's for a reader who didn't see any of that. If you've been working for a while without the user watching (overnight, across many tool calls, since they last spoke), your final message is their first look at any of it. Write it as a re-grounding, not a continuation of your working thread: the outcome first, then the one or two things you need from them, each explained as if new. When you mention files, commits, flags, or other identifiers, give each one its own plain-language clause. Open with the outcome: one sentence on what happened or what you found. Then the supporting detail. If you have to choose between short and clear, choose clear.
Está bien ser telegráfico entre llamadas a herramientas: eso es pensar en voz alta, y la brevedad ayuda. El resumen final es diferente: está dirigido a alguien que no vio nada de eso. Si trabajaste durante un tiempo sin que el usuario te observara (de un día para otro, a lo largo de varias llamadas a herramientas, desde la última vez que habló), tu mensaje final es su primer contacto con todo lo ocurrido. Escríbelo como una reorientación, no como una continuación de tu línea de razonamiento: primero el resultado y luego una o dos cosas que necesitas de esa persona, cada una explicada como si fuera nueva. Al mencionar archivos, commits, flags u otros identificadores, dedica a cada uno su propia oración en lenguaje sencillo. Empieza con el resultado: una oración sobre lo que ocurrió o lo que encontraste. Después, los detalles de apoyo. Si tienes que elegir entre brevedad y claridad, elige la claridad.
Cómo comprobar: pega esto en las instrucciones de tu agente (system prompt/skill) y, en la próxima sesión larga y asíncrona, relee el mensaje final por tu cuenta: ¿se puede entender el resultado sin haber visto ninguna llamada a herramientas? Si sí, funcionó.
En una frase: perder el hilo mientras nadie ve; volver a fundamentar cuando alguien finalmente lo va a leer.
⚖️ Esto no contradice «da el porqué» (módulo 1.2)
🧠 Imagínalo así: un buen briefing de diseño tiene una frase de propósito («esto es para convencer a un inversionista escéptico») y cero páginas de reglas de píxeles. Una intención rica y pocas reglas enumeradas siempre han convivido bien; solo parecían lo mismo porque los prompts antiguos solían acumular ambas cosas.
El módulo 1.2 (explica el porqué) te pide que expliques la intención detrás de la solicitud. Este módulo (1.5) te pide que no enumeres las reglas una por una. A primera vista parece contradictorio —más por un lado, menos por el otro—, pero son dos ejes distintos, no una misma escala.
⚖️ Dos ejes independientes
La intención (el porqué) mide la calidad del contexto — qué quieres y por qué lo quieres. La verbosidad (cuántas reglas) mide volumen — cuántos elementos enumeras. Puedes tener ambas cosas: una frase densa de intención y ninguna lista de reglas.
- •Eje 1 (intención): "porque este endpoint lo usan 3 servicios críticos" — 1 frase, mucho valor.
- •Eje 2 (verbosidad): "siempre haz X, nunca hagas Y, en el caso Z haz W..." — cuantos más puntos, más ruido.
- •"Di menos" apunta hacia abajo en el eje 2. "Explica por qué" apunta hacia arriba en el eje 1. No compiten por el mismo espacio.
Leyenda: «di menos» modifica el eje horizontal (menos reglas enumeradas); «explica el porqué» modifica el eje vertical (más contexto de intención). Son ejes independientes: puedes tener ambos al mismo tiempo.
En la práctica, un prompt «ideal» para Fable 5 queda en la esquina superior izquierda del diagrama de arriba: 1-2 frases de intención genuina, sin la lista de reglas que ya cumpliría por sí solo. Si tienes dudas sobre qué recortar, revisa primero el módulo 1.2: la pregunta correcta no es «¿tengo demasiado contexto?», sino «¿este contexto expresa una intención o es una regla redundante?»
Relacionado→ Repasa el módulo 1.2 — Da el porqué + no pidas razonamiento
En una frase: una intención rica + pocas reglas enumeradas no es una contradicción — es la combinación ideal.
🛠️ En la práctica: refactorizando CLAUDE.md y skills antiguas
🧠 Imagínalo así: CLAUDE.md y las skills escritas para modelos antiguos son como manuales de instrucciones traducidos de un aparato viejo: están llenos de advertencias que ya no se aplican al nuevo modelo, pero siguen ahí, ocupando espacio y compitiendo por la atención.
La documentación oficial ofrece un objetivo concreto para aplicar todo esto: tu CLAUDE.md, system prompts y skills antiguas escritas para modelos anteriores. Si enumeran cada comportamiento, es probable que compitan con el propio criterio de Fable 5 en vez de ayudarlo.
Fuente oficial · doc «Prompting Claude Fable 5»
"Skills developed for prior models are often too prescriptive for Claude Fable 5 and can degrade output quality. Review and consider removing older instructions if default performance is better."
PT-BR: "Las skills desarrolladas para modelos anteriores suelen ser demasiado prescriptivas para Claude Fable 5 y pueden empeorar la calidad de la respuesta. Revísalas y considera quitar las instrucciones antiguas si el rendimiento predeterminado ya es mejor."
Esto vale especialmente para las skills y los system prompts heredados de proyectos con modelos más antiguos: vuelve a leerlos con ojo crítico y prueba si quitar la mitad de las reglas cambia el resultado. Si no cambia, esa regla ya no hacía ninguna diferencia: solo inflaba el prompt y competía por la atención con lo que de verdad importa.
Objetivo: pedirle al propio Claude Code que audite su CLAUDE.md/system prompt actual e indique qué probablemente sea una enumeración redundante para Fable 5.
Releia o CLAUDE.md (ou system prompt) deste projeto <cole o conteúdo ou aponte o arquivo>. Aponte quais instruções são regras enumeradas que um modelo com strong instruction-following como o Fable 5 provavelmente já seguiria por padrão, e proponha uma versão mais curta que mantenha só o que muda o comportamento de fato. Não remova nada relacionado a intenção, contexto de negócio ou fronteiras de segurança — só o que é enumeração redundante.
Cómo comprobar: ejecuta ambas versiones (original y concisa) en la misma tarea real y compara el resultado. Si el comportamiento no cambió, la versión concisa es estrictamente mejor (menos tokens, menos ruido). Si desapareció algo importante, se recortó por error el contexto de intención: devuélvelo al prompt.
⚠️ Atención
No borres todo de una vez. Elimina un bloque de reglas a la vez y ejecuta la misma tarea antes y después. Conserva las reglas que existen por un incidente real (seguridad, datos sensibles, integración frágil); el objetivo son las reglas que solo existían «por si acaso».
📎 Profundiza (opcional): señales de que una skill es demasiado prescriptiva
- •Lista con más de 10 «siempre/nunca» sin ninguna frase de contexto que explique por qué.
- •Instrucciones redundantes con el sentido común predeterminado del modelo (formato obvio, tono educado, no inventar hechos).
- •Reglas que intentan prevenir un escenario hipotético que nunca ocurrió realmente en el proyecto.
- •Instrucciones como "muestra tu razonamiento" o "explica paso a paso antes de responder": el módulo 1.3 ya mostró que esto puede activar la categoría de rechazo
reasoning_extractionen Fable 5.
En una frase: vuelve a leer CLAUDE.md y las skills antiguas con el criterio de Fable 5 — si la regla no cambia el resultado, es ruido; elimínala.
🧾 Resumen del Módulo
Próximo módulo:
1.6 — Esfuerzo y enrutamiento de seguridad: niveles de esfuerzo (max/xhigh/high/medium/low) y las 4 categorías de rechazo.