Salida estructurada
Cada reporte de bug sigue esta estructura:
- Título — resumen conciso (máximo 8 palabras)
- Qué sucede — descripción del comportamiento del bug
- Contexto de git — rama actual y cambios recientes
- Pasos de reproducción — inferidos desde la descripción o placeholders
- Esperado vs Real — formato de comparación
Detección automática de severidad
El sistema infiere la severidad desde tu descripción:
| Severidad | Palabras desencadenantes | Ejemplo |
|---|---|---|
| Critical | crash, data loss, security, down, blocks | «La app se cae al arrancar» |
| High | broken, fails, can’t, regression | «El formulario de login no pasa validación» |
| Medium | wrong, incorrect, unexpected, slow | «La API devuelve datos incorrectos» |
| Low | minor, cosmetic, typo, alignment | «Botón mal alineado en mobile» |
Integración con git
Una sola llamada a Bash captura:
- El nombre de la rama actual
- Un resumen de los cambios recientes (últimos commits)
- Los archivos modificados relevantes para el área del bug
Este contexto se incluye automáticamente en el reporte de bug, así el siguiente desarrollador puede ver qué cambió cerca del bug.
Cuándo usar /note-bug
Usa /note-bug en lugar de /note cuando quieras:
- Etiquetado automático de severidad
- Contexto de git en el reporte
- Formato estructurado de pasos de reproducción
- Codificación por color rosa para identificarlo fácilmente