Paquete de prompts de código para Claude: depuración, refactors y revisiones de arquitectura

Las cuatro restricciones que hacen funcionar cada prompt de abajo

Antes de los prompts, las reglas que todos comparten. Añadir esto a cualquier prompt de código mejora el resultado más que cambiar de modelo.

Indica tu versión. Los datos de entrenamiento se inclinan hacia la versión mayor sobre la que más se ha escrito, que a menudo no es la que usas tú. Usamos [framework] [versión], [lenguaje] [versión] evita la mayoría de respuestas obsoletas.

Limita el diff. Pide una corrección y a menudo recibes un refactor. Cambia lo mínimo posible, conserva la estructura y los nombres existentes, y enumera cada línea que cambiaste con un motivo de una línea es la frase más útil de todo este documento.

Pide hipótesis antes de soluciones. A un modelo al que se le pregunta qué falla te da una suposición presentada como conclusión. A un modelo al que se le piden causas ordenadas y comprobaciones baratas te da un plan de depuración.

Exige el modo de fallo. ¿Qué podría romper esto, y esto corrige la causa o el síntoma? detecta la clase más costosa de asistencia con IA, que es un cambio que hace desaparecer el síntoma mientras el defecto permanece.

Depuración

1. Hipótesis ordenadas

Aquí tienes el error, el código relevante y lo que ya he descartado. No me des una corrección todavía. Enumera las cuatro causas más probables ordenadas por probabilidad y, para cada una, la comprobación más barata que la confirmaría o la eliminaría. Error: [pega]. Código: [pega]. Ya descartado: [lista]. Stack: [lenguaje, framework, versiones].

2. El error intermitente

Esto falla intermitentemente, aproximadamente [frecuencia], bajo [condiciones]. Enumera las categorías de fallo intermitente que podrían producir este síntoma concreto: temporización, orden, agotamiento de recursos, una dependencia externa, estado que se filtra entre ejecuciones, reloj o zona horaria, caché. Para cada una, di qué en el código la respalda o la contradice, y qué debería registrar exactamente para distinguirlas. Código: [pega].

3. Funciona en local

Esto funciona en local y falla en [entorno]. Enumera cada categoría de diferencia de entorno que podría causar este síntoma concreto: configuración, variables de entorno, versiones, sistema de archivos y sensibilidad a mayúsculas, zona horaria e idioma, red y DNS, permisos, límites de recursos y diferencias de compilación o empaquetado. Ordena por probabilidad según el síntoma y dame el comando de diagnóstico para cada una.

4. Explica la corrección antes de aplicarla

Explica por qué funciona esta corrección, qué no corrige y qué podría romper. Si la causa real está en otra parte y esto es un parche del síntoma, dilo directamente.

Code review

5. Revisa un diff

Revisa este diff como un revisor exigente. Categorías en orden de prioridad: errores de corrección, problemas de seguridad, modos de fallo no gestionados, condiciones de carrera, y luego estilo. Para cada hallazgo, indica la gravedad, la línea concreta y por qué importa en esta base de código en particular y no en general. No comentes sobre el formato. Si el diff es sólido, dilo en lugar de inventar hallazgos. Convenciones: [describe]. Diff: [pega].

6. La pasada de seguridad

Revisa este código específicamente por problemas de seguridad: inyección, huecos de autenticación y autorización, deserialización insegura, secretos en el código o en los logs, entrada no validada que llega a una operación sensible, y riesgo de dependencias. Para cada uno, da la vía de ataque concreta en lugar de nombrar la categoría. Indica claramente qué no puedes evaluar sin ver [despliegue, capa de autenticación, sensibilidad de los datos].

7. La auditoría del modo de fallo

Para cada llamada externa en este código, indica qué ocurre cuando es lenta, cuando falla, cuando devuelve datos inesperados y cuando tiene éxito pero de forma parcial. ¿Cuáles de esos casos no están gestionados actualmente, y cuáles serían silenciosos?

Ese último encuentra más problemas reales de producción que una revisión general, porque pregunta por los caminos para los que nadie escribió una prueba.

Refactorización y arquitectura

8. El plan de refactorización

Propón un plan secuenciado para refactorizar [descripción]. Restricciones: la API pública de [x] no puede cambiar, desplegamos continuamente así que cada paso debe poder publicarse de forma independiente, y las pruebas deben pasar después de cada paso. Para cada paso, da el cambio, el riesgo, cómo verificarlo y cómo revertirlo. Ordena por riesgo, el más bajo primero. No escribas el código todavía.

9. Defiende la otra postura

Estoy eligiendo [enfoque A] sobre [enfoque B] para [contexto y restricciones]. Presenta el argumento más fuerte a favor de B. ¿Qué tendría que ser cierto sobre nuestras restricciones para que B fuera correcto, y es cierto algo de eso aquí? No concluyas que ambos son válidos.

10. Entiende lo que heredaste

Aquí tienes los archivos fuente principales. Produce: los puntos de entrada, el flujo de datos desde la solicitud hasta la respuesta, el estado que se comparte y dónde se muta, las dependencias externas y qué ocurre cuando cada una no está disponible, y las tres áreas con más probabilidad de contener errores según la complejidad y el acoplamiento. Indica explícitamente qué no puedes determinar con lo que te proporcioné.

Esa última instrucción importa. Los modelos describirán el comportamiento de un archivo que no pegaste, inferido de su nombre. Forzar una lista explícita de incógnitas te dice qué ir a leer.

Pruebas

11. Las pruebas que no habrías escrito

Escribe casos de prueba para esta función, centrándote en entradas que probablemente no he considerado: límites, vacío y nulo, unicode, valores muy grandes, llamadas concurrentes y cualquier suposición implícita en la implementación. Para cada prueba, indica la suposición que está comprobando. Función: [pega].

12. Pon a prueba la suite de pruebas

Aquí tienes una función y sus pruebas existentes. ¿Qué comportamiento no está cubierto? Concretamente: rutas de error, valores límite, interacciones entre parámetros, y cualquier cosa que haga la implementación que ninguna prueba compruebe. No reescribas las pruebas existentes.

El segundo es el prompt de mayor valor y rara vez se usa. Los porcentajes de cobertura te dicen qué líneas se ejecutaron, no qué comportamientos están realmente fijados, y la brecha entre ambos es donde viven las regresiones.

El patrón de segunda opinión

El hábito de mayor impacto de todo este paquete, y el único que requiere más de un modelo.

Obtén una respuesta de un modelo. Luego cambia y entrégasela:

Otro ingeniero propuso esta solución a este problema. Encuentra qué falla en ella: corrección en casos límite, concurrencia, manejo de errores, rendimiento a [escala], o un enfoque más simple que se pasó por alto. Si es genuinamente sólida, dilo con claridad en lugar de inventar objeciones. Problema: [pega]. Solución propuesta: [pega].

Hay dos resultados y ambos son útiles. O el segundo modelo encuentra un fallo real, que ahora conoces antes de fusionar, o coincide a pesar de haber sido empujado a discrepar, lo cual es una confirmación significativa. Iterar con el mismo modelo no te da ninguno de los dos, porque un modelo que revisa su propio resultado suele estar de acuerdo consigo mismo.

Úsalo en las decisiones que serían costosas de equivocar: un cambio de esquema, una corrección de concurrencia, cualquier cosa que toque autenticación o dinero. No en el trabajo rutinario. Consulta comparar modelos en paralelo, cambiar de modelo a mitad de conversación y escribir y depurar código con varios modelos para ver todo el flujo en un solo lugar.

Qué vigilar

APIs inventadas. Nombres de métodos, parámetros y claves de configuración presentados con seguridad que no existen, especialmente en librerías que cambiaron recientemente. La firma parecerá correcta. Comprueba la documentación real antes de construir sobre algo poco familiar.

Sin señal de confianza. Una corrección correcta y otra sutilmente incorrecta llegan con la misma seguridad. El tono no te dice nada.

Ampliación de alcance silenciosa. Para esto existe la segunda restricción.

Teatro de seguridad. Nombrar clases de vulnerabilidad en tu código es una primera pasada útil. No es una auditoría, y el modelo no conoce tu modelo de amenazas, tu despliegue ni la sensibilidad de tus datos.

Guarda los prompts que usas cada semana en algún sitio desde el que puedas pegarlos, y pon las restricciones fijas en las instrucciones de un proyecto para que se apliquen automáticamente a cada chat de ese proyecto.