Plantilla de bug report para Claude Code: convierte errores vagos en arreglos reproducibles

El debugging con Claude Code empieza con un buen bug report

Si solo escribes “no funciona”, Claude Code tendrá que adivinar. Un buen bug report reúne síntoma, pasos de reproducción, resultado esperado, resultado real, restricciones y verificación.

Úsalo después del runbook de primera tarea y antes de pasar contexto con la plantilla de handoff.

Plantilla para copiar

Objetivo:
- Bug a corregir:
- Fuera de alcance:

Entorno:
- OS / browser / runtime:
- branch:
- comandos relacionados:

Pasos para reproducir:
1.
2.
3.

Resultado esperado:
-

Resultado real:
-

Logs o screenshots:
-

Restricciones:
- archivos permitidos:
- archivos prohibidos:
- no enviar a servicios externos:

Verificación:
- build/test a ejecutar:
- URL a revisar visualmente:

Solicitud para Claude Code:
Primero reduce la causa a 3 hipótesis, devuelve el cambio mínimo,
archivos tocados y pasos de verificación. No edites hasta aprobación.

Buen ejemplo

Bug:
En móvil, el CTA de pricing se sale hacia la derecha.

Reproducción:
1. Abrir /en/products/ con 390px de ancho
2. Bajar hasta pricing card
3. El borde derecho del CTA supera el viewport

Verificación:
npm.cmd run build
Screenshot con Playwright a 390px

Mal ejemplo

La web está rara. Arréglala.

No tiene alcance, criterio de éxito ni restricciones.

Checklist antes de enviarlo

• ¿Los pasos se ejecutan en menos de 3 minutos?
• ¿La verificación usa comando o screenshot?
• ¿Están claros los archivos que no se tocan?
• ¿Incluye logs, URL o imagen?

Siguiente paso

Anota comandos en el cheatsheet gratuito. Para estandarizar prompts de debugging, usa 50 Prompt Templates. Para proceso de equipo, revisa consultoría.

En trabajo real, separa investigación y corrección

El error habitual es pedir un patch antes de reducir la causa. El orden estable es reproducir, proponer hipótesis y luego aplicar el cambio mínimo. Así puedes revisar cada paso.

Con este bug report, investiga sin editar todavía.
1. confirma si se reproduce
2. lista 3 hipótesis
3. señala la zona de código más probable
4. indica archivos que debes leer antes de corregir
5. decide si basta un cambio mínimo o hace falta diseño

Si aparece “no se reproduce”, “faltan logs” o “alcance demasiado amplio”, no avances al fix. Un buen bug report no acelera respuestas; crea un camino de investigación verificable.