Clasificar incidencias y abrir correcciones con un bot de GitHub

A quién le sirve. Responsables de proyectos de código abierto y equipos pequeños con muchas incidencias y cambios que revisar. Pide conocimientos de GitHub.

Qué hicieron

El bot funciona sobre OpenCode en GitHub Actions con Muse Spark. Cada agente es un archivo markdown con su propia lista de herramientas permitidas. Los eventos se reparten entre agentes: una solicitud de cambios lanza la revisión, una incidencia nueva lanza la clasificación y la etiqueta agent-fix lanza la corrección de errores. Un comentario /oc de un responsable va a un agente orquestador. El de corrección reproduce el error, lo parchea, añade una prueba, ejecuta pytest y abre una solicitud de cambios. No puede incorporarla.

Cómo salió

Los ejemplos de salida muestran la clasificación pidiendo cómo reproducir el fallo, la revisión señalando como basura un lote de cambios de emojis y un intento de inyección de instrucciones detectado. Aún no hay mediciones. A veces los turnos de revisión largos devuelven un resultado vacío, y entonces hay que repetirlos.

Conviene saber

Las instrucciones están ajustadas a Python, pytest y uv, así que adapta AGENTS.md y los archivos de los agentes. Las listas de permitidos no son un entorno aislado: el límite real son las puertas humanas y la protección de ramas.

Qué necesitas

• Un repositorio de GitHub con GitHub Actions (el sistema de GitHub que ejecuta tareas automáticas) habilitado.
• OpenCode y acceso a un modelo. El caso usa Muse Spark.
• Un archivo AGENTS.md con las normas del proyecto y un archivo markdown por cada agente, con su lista de herramientas permitidas.
• Protección de ramas (reglas de GitHub que impiden cambiar la rama principal sin revisión) y revisión humana obligatoria para incorporar cambios.

Cómo hacerlo tú, paso a paso

1. Escribe AGENTS.md con las normas del proyecto: lenguaje, pruebas y herramientas.
2. Crea un agente por tarea, cada uno en su archivo markdown con su lista de herramientas permitidas: revisión, clasificación, corrección de errores y orquestador.
3. Reparte los eventos: una solicitud de cambios lanza la revisión, una incidencia nueva lanza la clasificación, la etiqueta agent-fix lanza la corrección y un comentario /oc de un responsable va al orquestador.
4. Haz que el agente de corrección reproduzca el error, lo parchee, añada una prueba, ejecute las pruebas y abra una solicitud de cambios.
5. Impide que pueda incorporarla. Eso lo hace solo una persona.
6. Pruébalo en modo simulado con algunas incidencias existentes antes de dejar que comente o abra nada.
7. Activa la protección de ramas y revisa los primeros resultados.

Ayúdame a montar un bot de GitHub para [propietario/repositorio] que clasifique con etiquetas las incidencias nuevas, revise solicitudes de cambios, responda preguntas citando la documentación o el código del repositorio y señale contribuciones generadas con IA de poco esfuerzo. Para errores pequeños y claros, que abra una solicitud de cambios con un parche solo para revisión humana. Constrúyelo, pruébalo con algunas incidencias existentes en modo simulado y enséñame el resultado antes de que publique ningún comentario o abra ninguna solicitud de cambios.

Consejos

• Las listas de herramientas permitidas no son un entorno aislado. El límite real son las puertas humanas y la protección de ramas.
• Las instrucciones del caso están ajustadas a Python, pytest y uv. Adáptalas a tu proyecto.
• A veces los turnos de revisión largos devuelven un resultado vacío. Si pasa, repítelos.

Preguntas frecuentes

Fuentes

• dev.meta.ai ↗

En el directorio desde el 3 de octubre de 2026.