Prompts de programación para Grok

Estoy usando [lenguaje o framework y versión]. Explica este error en palabras sencillas, lista sus tres causas más probables en orden de probabilidad y dime qué revisar primero en cada una: [pegar error completo y stack trace]

Esta función devuelve [resultado real] al llamarla con [entrada], pero espero [resultado esperado]. Recorre la ejecución línea por línea con esa entrada, rastreando cada variable, y detente en la primera línea donde el estado difiera de lo que debería ser: [pegar código]

Este código en [lenguaje] a veces produce [síntoma] bajo carga, pero nunca cuando lo pruebo de forma aislada: [pegar código]. Busca condiciones de carrera, estado compartido y suposiciones sobre el orden de ejecución. Para cada sospechoso, describe el entrelazado exacto que causaría el error y cómo solucionarlo.

Revisa este diff como un desarrollador senior exigente en un proyecto de [lenguaje]. Agrupa los comentarios en errores, riesgos, legibilidad y pruebas, incluye referencias de línea y concluye con un veredicto: aprobar, aprobar con cambios o solicitar cambios, junto con el motivo en una sola oración: [pegar diff]

Para la siguiente función, lista cada caso límite que probarías y por qué, luego escribe las pruebas en [framework de pruebas]. Incluye al menos una prueba que deba fallar con el código actual y dime cuál es: [pegar función]

Crea fixtures de prueba realistas para este modelo de datos en [formato, ej. JSON o una función factory]: [pegar modelo]. Incluye diez registros normales y cinco casos difíciles, como cadenas vacías, nombres muy largos, caracteres no latinos y fechas límite, e indica cuáles son cuáles.

Usando este esquema: [pegar esquema], escribe una consulta para [base de datos] que devuelva [lo que necesitas]. Explica la consulta cláusula por cláusula y muestra una variante que también maneje [caso límite, ej. clientes sin pedidos].

Esta expresión regular debería [comportamiento esperado] en [lenguaje o herramienta], pero [qué sale mal]: [pegar regex]. Desglósala en partes y explica cada una, muestra una entrada que evidencie el problema y proporciona una versión corregida junto con tres cadenas que deba rechazar.

Escribe un script en [bash o PowerShell] que [tarea, ej. archive archivos de log de más de 30 días en un zip]. Hazlo seguro: incluye un modo de prueba (dry-run) que solo imprima lo que haría, mensajes de error claros y un comentario en cada línea que elimine o sobrescriba archivos.

Escribe la documentación de referencia para este endpoint: [pega el código del handler o la ruta]. Incluye el método y la ruta, los parámetros con sus tipos y si son obligatorios, un ejemplo de solicitud, ejemplos de respuestas de éxito y error, y cada código de estado que puede devolver.

Mi repositorio de Git está en este estado: [pega git status y las últimas líneas de git log]. Mi objetivo era [meta]. Explica qué pasó en palabras sencillas y dame los comandos exactos para arreglarlo, empezando por uno que haga una copia de seguridad de mi trabajo actual. Avísame antes de cualquier comando que reescriba el historial.

Domino [lenguaje que conozco] y estoy aprendiendo [nuevo lenguaje]. Toma este fragmento escrito en mi estilo habitual, [pega el fragmento], y reescríbelo como lo haría un desarrollador experimentado en [nuevo lenguaje]. Luego explica los modismos que usaste y que no tienen un equivalente directo en mi lenguaje de origen.

Adjunté una captura de pantalla de mi página. El problema: [qué se ve mal]. Aquí está el HTML y CSS de esa sección: [pega el código]. Encuentra la causa, dame la solución mínima en CSS y explica por qué ocurrió para que no vuelva a cometer el error.

Adjunté una foto de un boceto en una pizarra del modelo de datos para [app]. Conviértelo en definiciones de tablas para [base de datos] con claves primarias, claves foráneas y tipos de datos adecuados. Lista cualquier relación que el boceto deje ambigua y pregúntame antes de asumir.

¿Cuál es la complejidad temporal y de memoria de esta función y por qué? [pega el código] Si existe un enfoque más rápido para entradas de aproximadamente [tamaño], muéstralo y explica qué sacrifica en legibilidad.

Refactoriza esta función para que sea más fácil de leer sin cambiar lo que hace: [pega el código]. Trabaja en pasos pequeños con nombre, explica cada cambio en una línea y lista cualquier comportamiento sobre el que no estés seguro para que pueda confirmarlo antes de hacer merge.

Escribe un README para mi proyecto [nombre], que [qué hace]. Secciones: qué es, inicio rápido con comandos listos para copiar y pegar, opciones de configuración en una tabla, problemas comunes y cómo contribuir. Aquí están los archivos y comandos clave: [pega los detalles]

Explica qué hace este código en [lenguaje] a alguien que sabe programar pero no conoce esta base de código. Empieza con un resumen de dos frases, revísalo bloque por bloque y señala cualquier cosa que parezca un bug o un parche temporal: [pega el código]

Pienso construir [funcionalidad] así: [describe el enfoque]. Haz de abogado del diablo. Nombra las tres formas más probables en que este diseño fallará en producción, qué vería cuando falle y una alternativa más económica si existe. Sé directo; prefiero saberlo ahora que a las 3 a.m.

Convierte este código en [lenguaje de origen] a [lenguaje de destino] de forma idiomática, no como una copia línea por línea: [pega el código]. Usa la biblioteca estándar del lenguaje de destino siempre que sea posible, mantén el mismo comportamiento y lista cualquier aspecto en el que ambos lenguajes se comporten distinto, como la división de enteros o la codificación de cadenas.