Recetario
Recetas listas para copiar, pegar en Claude y rellenar los huecos en mayúsculas. Probadas, en español y pensadas para tareas SAP reales.
16 recetas · el recetario crece con el tiempo — 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.
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.
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.
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".
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: el análisis para un comercial y para un técnico de MM no se parecen.
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.
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. Este prompt 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/módulo.
Consejo: Las preguntas-trampa del punto 3 son tu test de aceptación: pruébalas cada vez que cambies la documentación adjunta.
