12 patrones de prompting que sí merecen la pena

Quiero añadir un nuevo endpoint a este proyecto.
Antes de escribirlo, revisa estos tres endpoints existentes: [A], [B] y [C].
Usa como referencia su estructura, naming, validación y manejo de errores.
Después implementa el nuevo endpoint siguiendo ese patrón.

Antes de decirme cuál es la causa, investiga primero.
Abre los archivos relevantes y basa cada conclusión en lo que encuentres.
Si no tienes evidencia suficiente para afirmar algo, dilo explícitamente.

Imagina que mañana este cambio ha roto producción.
Dame cinco posibles causas y, para cada una, qué puedo comprobar ahora para reducir ese riesgo.

Olvida por un momento cómo está resuelto ahora.
1. ¿Qué objetivo necesitamos conseguir de verdad?
2. ¿Qué restricciones son realmente obligatorias?
3. ¿Qué cosas estamos dando por hechas solo porque ya se hacen así?
Con eso, reconstruye la solución más simple desde cero.

Estoy inclinándome por [OPCIÓN A].
Antes de recomendar nada, construye el mejor argumento posible a favor de [OPCIÓN B].
No inventes datos. Señala qué tendría que ser cierto para que B fuese la mejor decisión.

Haz únicamente el cambio necesario para resolver esta tarea.
No añadas features, no refactorices código no relacionado y no crees abstracciones para necesidades hipotéticas.
Si detectas otra mejora, señálala aparte sin implementarla.

Quiero que el resultado tenga exactamente:
- diagnóstico en 3–5 frases
- archivos afectados
- cambio mínimo recomendado
- riesgos
- cómo verificarlo
No implementes todavía.

No cambies el esquema de respuesta de esta API.
Motivo: hay dos clientes antiguos que dependen exactamente de ese contrato.
Puedes cambiar la implementación interna, pero la forma externa debe permanecer compatible.

<instructions>
Analiza el bug y propón el cambio mínimo.
</instructions>

<context>
La API debe mantener compatibilidad hacia atrás.
</context>

<logs>
[PEGA AQUÍ LOS LOGS]
</logs>

Revisa este cambio como un senior backend engineer centrado en fiabilidad.
Prioriza regresiones, condiciones de carrera, manejo de errores y observabilidad.
No evalúes estilo visual ni producto salvo que afecten al backend.

Antes de implementar, define las pruebas que demostrarían que esta tarea está resuelta.
Incluye happy path, edge cases y regresiones relevantes.
Después implementa el cambio y ejecuta esas pruebas.
No cambies las pruebas solo para hacerlas pasar.

Haz de red team de este plan.
Busca supuestos débiles, casos límite, formas en las que podría fallar y qué evidencia falta.
Para cada crítica, propone una comprobación concreta.
No inventes vulnerabilidades ni hechos que no puedas sostener.