Redactar reporte de bug con pasos de reproducción

Convierte un reporte vago de un usuario en un ticket técnico listo para desarrollo

Prompt · 3 variables

Actúa como un QA Engineer que reporta incidencias al equipo de desarrollo. Tu objetivo es redactar un reporte tan claro que los desarrolladores puedan reproducir el error de inmediato sin tener que hacer preguntas adicionales.

Quiero convertir los comentarios de un usuario en un reporte estructurado para el equipo técnico. El entorno donde ocurrió es: {{entorno de uso}}, y el comportamiento esperado es: {{comportamiento esperado}}.

Reescribe las siguientes notas en un reporte de bug formal. Organiza la información dispersa por secciones y desglosa los pasos de reproducción en acciones atómicas que un desarrollador pueda seguir paso a paso.

Usa exactamente esta estructura: - Título (una línea: qué falla y cuándo) - Pasos para reproducir (numerados, una sola acción por línea) - Resultado esperado - Resultado actual - Entorno - Frecuencia (elegir entre: Siempre / Intermitente / Una sola vez; solo si las notas lo justifican) - Archivos o información adicional recomendada

Si falta algún dato en las notas, no inventes nada: escribe "No especificado en el reporte original". No incluyas suposiciones sobre la causa raíz técnica. Al final, añade una sección con hasta 3 preguntas clave que el equipo de soporte debería hacerle al usuario para aclarar el caso. Si aparecen nombres personales, datos de contacto o IDs reales, anonimízalos (ej. "Cliente A", "Pedido 1").

Notas del síntoma: """ {{notas del sintoma}} """

Copia y pégalo aquí · ChatGPT y Claude se abren con el prompt ya cargado Abrir en ChatGPT ↗Abrir en Claude ↗Abrir en Gemini ↗ Editar en el constructor Descargar tarjeta para clase

Algunas variables pueden contener datos personales. Sustituye nombres, números y empresas reales por datos ficticios.

Por qué está escrito así

Rol
Actúa como un QA Engineer que reporta incidencias al equipo de desarrollo. Tu objetivo es redactar un reporte tan claro que los desarrolladores puedan reproducir el error de inmediato sin tener que hacer preguntas adicionales.
Contexto
Quiero convertir los comentarios de un usuario en un reporte estructurado para el equipo técnico. El entorno donde ocurrió es: {{entorno de uso}}, y el comportamiento esperado es: {{comportamiento esperado}}.
Tarea
Reescribe las siguientes notas en un reporte de bug formal. Organiza la información dispersa por secciones y desglosa los pasos de reproducción en acciones atómicas que un desarrollador pueda seguir paso a paso.
Formato
Usa exactamente esta estructura: - Título (una línea: qué falla y cuándo) - Pasos para reproducir (numerados, una sola acción por línea) - Resultado esperado - Resultado actual - Entorno - Frecuencia (elegir entre: Siempre / Intermitente / Una sola vez; solo si las notas lo justifican) - Archivos o información adicional recomendada
Restricciones
Si falta algún dato en las notas, no inventes nada: escribe "No especificado en el reporte original". No incluyas suposiciones sobre la causa raíz técnica. Al final, añade una sección con hasta 3 preguntas clave que el equipo de soporte debería hacerle al usuario para aclarar el caso. Si aparecen nombres personales, datos de contacto o IDs reales, anonimízalos (ej. "Cliente A", "Pedido 1").
Material
Notas del síntoma: """ {{notas del sintoma}} """

El principal obstáculo al reportar bugs no es la redacción, sino la estructura de la información. Si un ticket solo dice "el pago no funciona", el desarrollador no logra reproducirlo y se pierde tiempo en mensajes de ida y vuelta. Para cuando se aclara, el usuario ya no recuerda los detalles.

El núcleo de este prompt es fijar un formato estricto. Separar el "Resultado esperado" del "Resultado actual" transforma un vago "no funciona" en "debía redirigir a la pasarela de pagos pero la pantalla se queda congelada", delimitando de inmediato qué parte del código revisar. Asimismo, limitar los pasos a una sola acción por línea evita ambigüedades sobre en qué punto exacto ocurre la falla.

Las restricciones eliminan el ruido habitual de la IA: prohibir inventar datos ("No especificado") evita versiones de navegador o mensajes de error ficticios; prohibir especulaciones técnicas evita diagnósticos erróneos que desvíen al programador; y solicitar preguntas de seguimiento permite recopilar información faltante en una sola interacción.

Delimitar las notas con """ evita que frases del usuario (como "¡resuelvan esto urgente!") se interpreten como instrucciones para el modelo, mientras que la regla de anonimización protege los datos personales en los registros de incidencias.

¿Términos desconocidos? Consulta Aha AI: output-format, prompt-injection

Comparado con un mal ejemplo

Mal ejemplo habitual

El cliente dice que no puede pagar, hazme un reporte de bug. Ayer funcionaba y hoy no.

La IA tenderá a inventar detalles inexistentes, como códigos de error inventados o versiones específicas de navegador. Los pasos de reproducción quedarán reducidos a un genérico "Intentar pagar", obligando al equipo a preguntar de nuevo en qué pantalla o botón se detuvo el proceso.

Variaciones

Para reportar un bug que experimentaste tú mismo

Para reportar un bug que experimentaste tú mismo

Voy a crear un ticket para un error que acabo de experimentar yo mismo. Mi entorno es {{entorno de uso}} y el comportamiento esperado es {{comportamiento esperado}}. Organiza las siguientes notas en la descripción de un ticket, separando claramente lo que ya intenté de lo que aún no he probado. Antes de crear el ticket, sugiéreme 3 comprobaciones rápidas que debería hacer para descartar problemas locales.

""" {{notas del sintoma}} """

Ideal cuando tú eres quien detecta el fallo. Te ayuda a delimitar las condiciones antes de registrarlo, evitando tickets que se cierren con "no reproducible en mi máquina".

Para agrupar y sintetizar múltiples reportes de usuarios

Para agrupar y sintetizar múltiples reportes de usuarios

A continuación tienes varios reportes de usuarios recopilados en los últimos días. Agrúpalos según la posible causa común. Para cada grupo, genera un título representativo, sus puntos en común y sus diferencias. Si hay reportes aislados difíciles de clasificar, colócalos en una sección aparte. No hagas suposiciones: cita fragmentos textuales de las notas como evidencia para cada agrupación.

""" {{notas del sintoma}} """

Útil cuando se acumulan muchas quejas de usuarios. Permite consolidar incidencias duplicadas en un único reporte consistente.

Notas por modelo

Si tienes capturas de pantalla o fotos del error, adjúntalas junto con el prompt. Los modelos multimodales pueden extraer nombres exactos de pantallas y textos de error que a menudo se omiten en las notas escritas.

Prompts relacionados

Última actualización 2026-09-02 · ¿Has visto un error? Avísanos