Crear un Bug

¿Qué hace Crear un Bug?

Convierte síntomas, registros o una regresión observada en un bug que otro ingeniero pueda reproducir y corregir sin conjeturas.

Flujo de Trabajo

1. Identificar el repositorio objetivo y el proveedor de issues a partir de la solicitud, el control remoto del repositorio o las herramientas de proveedor disponibles. Si no hay un proveedor con permisos de escritura, producir un borrador en Markdown neutral al proveedor.
2. Buscar en issues abiertos y cerrados el comportamiento, componente y texto de error distintivo. Enlazar un duplicado real en lugar de crear otro issue.
3. Inspeccionar el código relevante, las pruebas, la configuración y los cambios recientes. Separar la evidencia observada de las hipótesis.
4. Reproducir el bug cuando sea seguro y práctico. Registrar los pasos deterministas más pequeños, las entradas, el entorno, el resultado real y el resultado esperado. Nunca afirmar una reproducción que no se haya ejecutado.
5. Evaluar el impacto: usuarios o flujos de trabajo afectados, severidad, estado de regresión, solución alternativa y riesgo de datos/seguridad. Marcar explícitamente las incógnitas.
6. Exigir una prueba de regresión que falle antes de la corrección y pase después de ella. Nombrar la capa de prueba y el fixture adecuados cuando la evidencia del repositorio lo respalde.
7. Redactar el bug usando la plantilla a continuación. Mostrar el borrador final antes de crear o mutar un ticket externo a menos que el usuario ya haya autorizado explícitamente la creación.
8. Crear el issue con la capacidad nativa del proveedor cuando esté disponible, luego devolver su URL. De lo contrario, devolver el borrador completo en Markdown y la acción de proveedor faltante.

Plantilla de Bug

## Resumen
<una oración que nombre el comportamiento roto y el usuario afectado>

## Reproducción
1. <paso determinista mínimo>
2. <siguiente paso>
3. <resultado observado>

## Comportamiento esperado
<lo que debería suceder, basado en un requisito, prueba o comportamiento establecido>

## Comportamiento real
<lo que sucede, incluyendo el texto de error exacto cuando sea útil>

## Impacto
<quiénes están afectados, severidad, frecuencia, solución alternativa, estado de regresión>

## Evidencia
- <ruta de código, prueba, registro, captura de pantalla, revisión o issue enlazado>

## Prueba de regresión
- [ ] <prueba específica que falla antes de la corrección y pasa después de ella>

## Entorno
- Versión/revisión:
- SO/entorno de ejecución/navegador:
- Configuración:

## Preguntas abiertas
- <solo hechos no resueltos que puedan cambiar el alcance o la severidad>

Reglas de seguridad

• No pegar tokens de acceso, credenciales, datos personales o contenido innecesario del cliente en un issue público.
• Redactar secretos en los registros mientras se preserva la estructura útil del error.
• No convertir una causa sospechada en un hecho sin evidencia.
• No implementar la corrección, hacer commit, hacer push o cambiar el estado del issue a menos que el usuario lo solicite.

---

Construido por aictrl.dev. Este skill enseña el flujo de trabajo; aictrl lo operacionaliza — basado en tu backlog, estándares de equipo y grafo de conocimiento del código fuente. Ver cómo →