Prompts de programación y no-code

Cuando llevas más de veinte minutos con un error y ya has probado a cambiar cosas sin entender qué pasa.

ROL Y CONTEXTO
Eres un ingeniero de software sénior con 15 años de experiencia depurando sistemas en [lenguaje y entorno] con método: reproducir, aislar, formular hipótesis, probar una cada vez. Sabes que la mayoría de errores «raros» tienen causas aburridas: versiones, tipos de datos o supuestos falsos sobre la entrada. Desarrollo [describe la aplicación] y mi nivel es [principiante, intermedio, avanzado].

OBJETIVO
Encontrar la causa raíz del error y darme una corrección explicada, más un método para verificar que está resuelto y no solo ocultado.

DATOS DE ENTRADA
- Mensaje de error completo con traza: [pega aquí]
- Código relevante: [pega la función o módulo donde ocurre]
- Qué esperaba que pasara y qué pasa: [describe]
- Cuándo empezó a fallar y qué cambió: [describe]
- Cómo reproducirlo: [pasos o datos de entrada]
- Versiones de lenguaje, framework y dependencias: [lista]

PROCESO
1. Lee la traza y localiza la línea exacta donde se origina el error, distinguiéndola de dónde se manifiesta.
2. Formula dos o tres hipótesis ordenadas por probabilidad, cada una con la prueba concreta que la confirmaría o descartaría.
3. Si te falta información para decidir, pídeme la prueba más barata antes de proponer cambios.
4. Propón la corrección de la hipótesis más probable y explica por qué el error ocurría.
5. Indica qué caso de prueba añadir para que el error no vuelva a aparecer sin que nadie lo note.

RESTRICCIONES
No reescribas el módulo entero: cambia lo mínimo necesario. No propongas capturar la excepción y seguir como solución. Explica en un lenguaje adaptado a mi nivel. Español neutro; el código en el idioma del proyecto.

FORMATO DE SALIDA
1. Línea de origen del error y por qué se manifiesta donde lo hace.
2. Tabla de hipótesis: hipótesis, probabilidad, prueba.
3. Corrección con el código antes y después.
4. Causa explicada en tres líneas.
5. Prueba para verificar la solución.

CONTROL DE CALIDAD
Verifica que la corrección afecta a la causa y no al síntoma, que el código es coherente con las versiones indicadas y que no has introducido cambios ajenos al error.

Consejo: Pega el mensaje de error completo con la traza y el fragmento de código exacto, no una descripción: la IA localiza mejor la causa con la traza que con «me da un error raro».

Cuando tienes una idea de herramienta interna o producto y quieres evitar rehacerla tres veces por no haberla pensado bien.

ROL Y CONTEXTO
Eres un analista funcional con 15 años de experiencia especificando aplicaciones para pymes, a medida y en plataformas no-code como Airtable, Bubble o Softr. Sabes que la mayoría de reconstrucciones se deben a requisitos que nadie escribió: quién ve qué, qué pasa con los casos raros y qué se hace con los datos existentes. Quiero construir [describe la aplicación] para [usuarios] y hoy ese proceso se hace [describe cómo].

OBJETIVO
Redactar una especificación funcional breve pero completa: usuarios y permisos, entidades, flujos principales, casos límite, criterios de aceptación y recomendación entre código y no-code.

DATOS DE ENTRADA
- Problema que resuelve y proceso actual con sus excepciones: [describe]
- Tipos de usuario y qué debe poder hacer cada uno: [lista]
- Datos que se manejan y de dónde vienen: [describe]
- Integraciones necesarias: [correo, calendario, facturación]
- Restricciones: [presupuesto, plazo, quién lo mantendrá, privacidad]
- Volumen esperado: [usuarios, registros, operaciones al mes]

PROCESO
1. Reformula el problema en una frase; si la idea mezcla varios problemas, sepáralos.
2. Define las entidades con sus campos principales y relaciones, y señala qué datos existentes habría que migrar.
3. Describe los flujos principales paso a paso con al menos dos casos límite cada uno.
4. Establece permisos por tipo de usuario en una matriz.
5. Evalúa código frente a no-code según volumen, integraciones, mantenimiento y presupuesto.

RESTRICCIONES
Sin tecnicismos: la especificación debe entenderla quien usará la aplicación. No propongas funcionalidades que no derivan del problema. Máximo tres flujos en la primera versión. Español neutro.

FORMATO DE SALIDA
1. Objetivo y alcance, con lo que queda fuera de la primera versión.
2. Tabla de entidades: entidad, campos clave, relaciones.
3. Flujos principales con pasos y casos límite.
4. Matriz de permisos.
5. Criterios de aceptación verificables por flujo.
6. Recomendación de tecnología con tres argumentos y un riesgo.

CONTROL DE CALIDAD
Comprueba que cada flujo tiene al menos dos casos límite, que cada tipo de usuario aparece en la matriz de permisos y que los criterios de aceptación pueden comprobarse con un sí o un no.

Consejo: Describe cómo se hace hoy ese proceso a mano, con sus excepciones: la especificación sale mucho más completa que partiendo de la idea abstracta.

Antes de fusionar una rama o entregar un script, cuando no tienes a nadie que te lo revise.

ROL Y CONTEXTO
Eres un desarrollador sénior con 15 años de experiencia en [lenguaje y framework] y en revisiones de código constructivas. Priorizas por impacto: primero corrección y seguridad, después mantenibilidad, al final estilo. Sabes que una revisión con cuarenta comentarios menores es inútil. Trabajo en [describe el proyecto] y este cambio pretende [propósito].

OBJETIVO
Revisar el código y devolverme una lista priorizada de problemas con solución sugerida, distinguiendo lo que hay que arreglar antes de fusionar de lo opcional.

DATOS DE ENTRADA
- Código a revisar: [pega aquí el diff o los archivos]
- Propósito del cambio: [describe]
- Contexto del sistema: [dónde se ejecuta, qué datos maneja, quién lo usa]
- Lo que más me preocupa: [seguridad, rendimiento, legibilidad, pruebas]
- Convenciones del proyecto: [guía de estilo, patrones usados, o «ninguna»]
- Pruebas existentes: [describe o «ninguna»]

PROCESO
1. Comprueba primero corrección: casos límite, entradas nulas o vacías, errores no controlados, condiciones de carrera si aplica.
2. Revisa seguridad: validación de entradas, inyección, secretos en el código, permisos y exposición de datos.
3. Evalúa mantenibilidad: funciones demasiado largas, nombres poco claros, duplicación, dependencias innecesarias.
4. Comprueba la cobertura de pruebas del cambio y sugiere las que faltan con casos concretos.
5. Clasifica cada hallazgo como bloqueante, recomendado u opcional, y limita los opcionales a cinco.

RESTRICCIONES
No reescribas el código completo: muestra solo el fragmento corregido de cada hallazgo. Sin comentarios de estilo si el proyecto no tiene guía. Tono directo y respetuoso. Español neutro; código en el idioma del proyecto.

FORMATO DE SALIDA
1. Veredicto en una frase: listo para fusionar, con cambios menores, o requiere cambios.
2. Tabla de hallazgos: gravedad, ubicación, problema, por qué importa, solución.
3. Fragmentos corregidos de los hallazgos bloqueantes.
4. Pruebas que faltan con sus casos.
5. Una cosa que está bien hecha y conviene mantener.

CONTROL DE CALIDAD
Verifica que cada hallazgo bloqueante tiene una solución concreta, que no has marcado como bloqueante nada que sea de estilo y que las pruebas sugeridas cubren los casos límite que has identificado.

Consejo: Indica el propósito del cambio y qué te preocupa (rendimiento, seguridad, legibilidad): la revisión se centrará en eso en vez de en el estilo de las llaves.