Publicado: 2026-07-28 | Por: Carlos Montiel | Lectura: ~4 minutos
No reinventes el prompt cada vez. Estos diez los uso (o los he visto usar) todos los días en equipos de ingeniería reales, y valen más guardados en un snippet manager que en tu memoria.
1. Code review con criterio de severidad
El error más común al pedirle a un modelo que revise código es no decirle qué tan estricto ser. Sin eso, mezcla nits de estilo con bugs reales y el output se vuelve ruido. Este prompt separa hallazgos por severidad y pide evidencia, no opiniones vagas.
Revisa este diff como un ingeniero senior haciendo code review.
Reporta CADA hallazgo que encuentres, incluyendo los que tengas
baja confianza o consideres de severidad baja. No filtres por
importancia en este paso — eso lo hago yo después.
Para cada hallazgo incluye:
- Severidad: bloqueante | importante | menor
- Confianza: alta | media | baja
- Línea y explicación concreta (no "esto podría mejorarse")
- Si aplica, el fix sugerido en una línea
Si no encuentras nada, dilo explícitamente. No inventes
observaciones para parecer exhaustivo.
Diff:
{diff}
Este patrón — pedir cobertura completa y dejar el filtrado para después — es clave en modelos recientes (Sonnet 5, Opus 4.7/4.8): cuando el prompt dice "solo reporta lo importante", el modelo lo obedece literalmente y termina ocultando bugs reales que juzgó "menores". Separar hallazgo de filtrado recupera ese recall.
2. Root cause de un stack trace sin contexto completo
Cuando pegas un stack trace a un modelo, la tentación es pedir "arréglalo". Mejor: pedir primero un diagnóstico estructurado, porque muchas veces el fix obvio ataca el síntoma, no la causa.
Analiza este stack trace y el código relevante. Antes de proponer
un fix, responde:
1. ¿Cuál es la causa raíz más probable? (no el síntoma)
2. ¿Qué otras hipótesis consideraste y por qué las descartaste?
3. ¿Qué evidencia adicional confirmaría o refutaría tu hipótesis
principal? (logs, línea de código, valor de variable)
Solo después de eso, propone el fix mínimo necesario.
Stack trace:
{trace}
Código relevante:
{code}
3. Generador de mensajes de commit desde un diff
Útil como hook de pre-commit o comando manual. La clave es pedir que explique el "por qué", no que narre el diff línea por línea.
Escribe un mensaje de commit para este diff siguiendo Conventional
Commits (feat/fix/refactor/chore/docs).
Título: máximo 72 caracteres, en imperativo.
Cuerpo (opcional, solo si el cambio no es trivial): 1-3 líneas
explicando POR QUÉ se hizo el cambio, no qué archivos se tocaron
— eso ya lo muestra el diff.
No incluyas explicaciones fuera del mensaje de commit.
Diff:
{diff}
4. Generador de tests a partir de una función
Pide casos límite explícitos en vez de dejar que el modelo improvise cobertura genérica.
Genera tests unitarios para esta función usando {framework}.
Incluye obligatoriamente:
- El caso feliz
- Al menos 2 casos límite (valores vacíos, nulos, límites numéricos)
- Un caso de error esperado (excepción o valor de retorno de error)
- Si la función tiene efectos secundarios, un test que los verifique
No generes mocks para dependencias que no existen en el código
mostrado. Si necesitas más contexto para mockear algo, dilo en
vez de inventar la interfaz.
Función:
{code}
5. Explicador de queries SQL complejas
Para onboarding o para entender queries heredadas de 200 líneas.
Explica esta query SQL en tres niveles:
1. Una frase: qué devuelve, en términos de negocio.
2. Paso a paso: qué hace cada CTE/subquery, en orden de ejecución
lógica (no en el orden en que aparece escrito).
3. Riesgos: ¿hay joins que podrían multiplicar filas, funciones
de ventana mal particionadas, o filtros aplicados después de
un agregado que deberían ir antes?
Query:
{sql}
6. Postmortem de incidente a partir de logs y timeline
Con la información de este incidente, redacta un postmortem
en formato blameless.
Estructura:
- Resumen (2 líneas, qué pasó y el impacto medible)
- Timeline (hora, evento, quién/qué lo detectó)
- Causa raíz (técnica, no "error humano" como causa final —
pregúntate qué sistema o proceso permitió ese error humano)
- Qué funcionó bien en la respuesta
- Acciones de seguimiento, cada una con dueño y tipo:
prevención | detección | mitigación
Datos del incidente:
{timeline_y_logs}
7. Documentador de endpoints a partir del código
Genera documentación OpenAPI-style para este endpoint a partir
del código (no inventes campos que no existan en el handler
o el schema de validación).
Incluye: método, ruta, parámetros con tipo y si son requeridos,
posibles códigos de respuesta con su significado, y un ejemplo
de request/response.
Si el código no valida algún caso de error obvio (ej. no
verifica autenticación), señálalo como nota aparte, no lo
documentes como si existiera.
Código del endpoint:
{code}
8. Changelog para usuarios no técnicos
Traduce commits técnicos a lenguaje de producto — útil para release notes que van a clientes.
Convierte esta lista de commits en un changelog para usuarios
finales no técnicos.
Reglas:
- Agrupa por categoría: Nuevo | Mejorado | Corregido
- Cada línea describe el IMPACTO para el usuario, no la
implementación ("Ahora puedes exportar reportes en PDF",
no "se agregó endpoint /export/pdf")
- Omite cambios puramente internos (refactors, tests, CI)
a menos que resuelvan un bug visible
Commits:
{lista_de_commits}
9. Onboarding a un módulo desconocido
Cuando heredas código legacy sin documentación, este prompt genera un mapa mental rápido.
Actúa como un ingeniero que necesita entender este módulo por
primera vez para hacer un cambio urgente.
Responde:
1. ¿Cuál es la responsabilidad principal de este módulo?
2. ¿Qué otros módulos dependen de él y cuáles son sus dependencias?
3. ¿Qué partes del código parecen frágiles o con deuda técnica
evidente (nombres genéricos, funciones muy largas, falta de
manejo de errores)?
4. Si tuviera que agregar {nueva_funcionalidad}, ¿por dónde
empezarías y qué tocarías con más cuidado?
Código del módulo:
{code}
10. Traductor de requisitos ambiguos a criterios de aceptación
Para cuando un ticket llega con una sola línea vaga y necesitas convertirlo en algo implementable.
Este es un ticket tal como lo escribió el usuario/PM. Conviértelo
en criterios de aceptación verificables.
Si hay ambigüedad real (no solo falta de detalle menor), enuméralas
como preguntas abiertas al final — no las resuelvas asumiendo,
porque una suposición incorrecta aquí cuesta más que una pregunta.
Ticket original:
{ticket}
Formato de salida:
- Criterios de aceptación (lista, cada uno verificable con un test)
- Casos fuera de alcance (explícitamente, para evitar scope creep)
- Preguntas abiertas (solo si son bloqueantes)
Guarda estos diez en tu gestor de snippets con variables claras. La inversión de cinco minutos ajustándolos a tu stack se paga la primera semana.