Prompts · actualizado en 2026
En julio de 2026 Anthropic borró más del 80% del prompt de sistema de Claude Code y no perdió nada medible en sus evaluaciones. La forma óptima de pedirle cosas a Claude ha cambiado, y buena parte de lo que se enseñaba como buena práctica ha envejecido.
Esta página cuenta qué cambió, lo traduce al trabajo diario con SAP y termina con 16 prompts reescritos con el criterio nuevo.
Conviene decirlo porque circula lo contrario. La propia Anthropic mantiene que escribir bien lo que pides sigue siendo la pieza básica. Lo que ha cambiado es el equilibrio: menos andamiaje y más criterio.
Las riendas que llevaban los modelos antiguos hoy estorban. Cuando el prompt de sistema, las instrucciones del proyecto y tu petición se contradicen —y se contradicen más de lo que parece—, el modelo gasta razonamiento decidiendo a quién hacer caso antes de ponerse con tu tarea.
Estos cambios son de Anthropic y van dirigidos a quien construye agentes. Abajo están traducidos a lo que sí toca a quien simplemente escribe un prompt.
Los ejemplos de «antes» no son inventados: son nuestros propios prompts, tal como estaban escritos en esta página hasta hoy.
Antes
Eres un desarrollador ABAP senior. Explícame este programa.
Ahora
Necesito entender este programa ABAP heredado. Voy a tener que modificarlo, así que lo que más me importa es saber dónde están los peligros.
Anthropic lo dice sin rodeos: los modelos actuales son lo bastante buenos como para que asignarles un papel sea, casi siempre, innecesario. Lo que sí cambia el resultado es decir qué te importa a ti.
Antes
Redacta la nota de cierre de la incidencia. Cero jerga técnica.
Ahora
La va a leer quien abrió el ticket: usa SAP a diario pero no sabe cómo funciona por dentro, y lo único que le importa es si ya puede seguir trabajando.
Es el cambio con más recorrido. Con el motivo delante, el modelo resuelve solo las cien decisiones pequeñas que tú no habías previsto — y que ninguna regla habría cubierto.
Antes
Nada de transportes, notas OSS ni tablas.
Ahora
Habla solo de lo que él ve en pantalla: qué le fallaba antes y qué verá ahora.
Una lista de prohibiciones deja al modelo adivinando qué sí vale. Y cuando varias reglas se pisan, gasta razonamiento decidiendo cuál gana antes de ponerse con tu tarea.
Antes
(nada: el prompt daba por hecho que siempre hay respuesta)
Ahora
Si algo no se puede deducir del código, dilo en vez de suponerlo.
Una línea, y es lo que separa un análisis en el que puedes confiar de uno que rellena huecos con lo que suena bien. En SAP, un hueco rellenado a ojo acaba en un transporte.
Este es el cambio de fondo, y el que menos se está contando. La guía de Anthropic lo dice así:
Para instrucciones que quieras aplicar en cada sesión, y no en cada prompt, muévelas a ficheros CLAUDE.md, skills u otros métodos de dirección.
Traducido a tu semana: si revisas ABAP todos los martes, no deberías estar pegando el mismo prompt todos los martes. Esa checklist —con las convenciones de tu equipo, tus objetos prohibidos y tus dos ejemplos reales— se escribe una vez como Skill, y a partir de ahí Claude la aplica cuando toca sin que tú digas nada.
La diferencia práctica es grande: un prompt pegado se queda en tu portapapeles y muere contigo; una Skill se versiona, se comparte con el equipo y se corrige cuando descubres que le faltaba algo.
De las 16 de abajo, estas 6 deberían ser Skills
Reescritos: sin roles asignados, con el porqué delante y con permiso explícito para decir «esto no lo puedo deducir». Copia, pega y rellena los huecos en mayúsculas.
Si echas una en falta, pídela.
Heredas un programa Z de hace 15 años sin documentación y necesitas entenderlo rápido.
Consejo: Si el programa es enorme, pásalo por includes o por bloques funcionales y pide al final una síntesis de todo lo analizado.
Antes de transportar: una segunda opinión sistemática sobre tu desarrollo o el de otro.
Consejo: Pídele después "ahora solo los de severidad alta, ordenados por riesgo" para priorizar. No transportes nada sin revisar tú las correcciones.
Si la repites: Si revisas código cada semana, esta checklist debería ser una Skill con las convenciones de tu equipo dentro, no un prompt que pegas cada vez. Cómo se hace →
Tienes una clase sin tests y quieres una batería inicial decente sin empezar de cero.
Consejo: Si la clase tiene dependencias duras, pídele primero "propón un refactor mínimo para hacerla testeable" — suele ser más valioso que los propios tests.
Tienes un short dump y quieres hipótesis ordenadas antes de bucear en el debugger.
Consejo: No pegues el dump entero (son kilométricos): categoría del error, la sección "Error analysis", la posición en el código y las variables del extracto bastan.
Si la repites: Analizar dumps es semanal en soporte. Una Skill con los dumps típicos de tu sistema y sus causas conocidas rinde mucho más que este prompt suelto. Cómo se hace →
Planeas la migración a S/4HANA Cloud y necesitas saber qué desarrollos van a doler.
Consejo: Hazlo desarrollo a desarrollo, no con todo el paquete Z a la vez. Los resultados alimentan muy bien una hoja de cálculo de remediation.
El usuario pide algo en tres líneas confusas y tú necesitas una spec que un desarrollador pueda implementar.
Consejo: La sección 4 (preguntas abiertas) es oro: mándasela al usuario tal cual antes de tocar nada y te ahorras dos iteraciones.
Si la repites: Si tu equipo escribe specs con una plantilla fija, esa plantilla debería ser una Skill. Así todos escriben igual sin copiar nada. Cómo se hace →
Resolviste algo muy técnico y tienes que explicárselo a quien abrió el ticket sin marearlo.
Consejo: Funciona igual de bien para las notas de versión de tus transportes mensuales: pega la lista técnica y pide "notas de versión para usuarios".
Si la repites: Cierras incidencias todos los días. Una Skill con el tono de tu empresa y dos ejemplos reales tuyos te ahorra pegar esto cada vez. Cómo se hace →
Te piden "¿cuánto llevaría esto?" y quieres una estimación defendible, no un número al aire.
Consejo: Las secciones de supuestos y riesgos te cubren las espaldas: inclúyelas siempre en la propuesta que envíes.
Exportaste pedidos, stocks o facturas a Excel y quieres una primera lectura con patrones y acciones.
Consejo: Anonimiza clientes y precios antes de subirlo. Y dile siempre tu rol y para qué lo miras: el análisis para un comercial y para un técnico de MM no se parecen en nada.
Te piden un informe y quieres el esqueleto de la vista CDS con anotaciones, no empezar de cero.
Consejo: Dale las vistas CDS estándar (I_SalesOrder, etc.) como base si estás en S/4HANA: el resultado sale mucho más limpio que partiendo de tablas.
Acabas de configurar algo en la SPRO y la documentación es para ayer.
Consejo: Vale con notas tipo telegrama ("clase doc ZF1, asigné rango 09, ojo con ejercicio fiscal"). El modelo ordena; tú solo revisa los valores.
Si la repites: Esto es exactamente lo que se pierde cuando alguien se jubila. Como Skill, atada al cierre del ticket, deja de depender de que te acuerdes. Cómo se hace →
Necesitas un paso a paso para usuarios finales y no quieres redactarlo a mano.
Consejo: Después pídele "versión de chuleta en media página" — la chuleta es lo que el usuario imprime y pega al lado de la pantalla.
Hay que comunicar un retraso o un problema a cliente o dirección y las palabras no salen.
Consejo: Pide dos variantes (una más formal, otra más cercana) y elige. El primer párrafo es lo único que algunos leerán: revísalo dos veces.
Mañana tienes steering y quieres llegar con el guion, los mensajes y las respuestas preparadas.
Consejo: El punto 4 es el que te salva la reunión. Ensáyalas en voz alta — las respuestas escritas se notan.
Quieres que Claude acceda a datos de tu SAP (vía OData/RFC) y no sabes por dónde empezar.
Consejo: Empieza siempre por solo-lectura y una única tool. Cuando funcione de verdad contra tu sandbox, amplía. Esto funciona aún mejor en Claude Code, que puede crear el proyecto entero.
Quieres montar un asistente (proyecto de Claude o vía API) que responda dudas de tu proyecto o módulo.
Consejo: Los puntos 3 y 4 son tu test de aceptación: pruébalos cada vez que cambies la documentación adjunta. Y revisa el punto 2: ahí es donde se ve si te estabas pasando de reglas.
Si la repites: Esto ya no es un prompt: es contexto. Vive en las instrucciones del proyecto de Claude o en una Skill, y se escribe una vez. Cómo se hace →
