A FONDO· 3 min de lectura

Un bot autónomo para GitHub que sabe cuándo no actuar

La receta del agente de GitHub del cookbook conecta triaje, revisión de PRs y corrección de bugs a GitHub Actions con OpenCode y Muse Spark. Lo más valioso que puedes llevarte son sus barreras de seguridad.

#github-actions#automation#agents#code-review

Qué hace el bot

La receta construye un bot autónomo sobre GitHub Actions con cuatro trabajos: triaje de issues, revisión de pull requests, detección de “AI slop” y PRs de corrección de bugs. Todo corre sobre OpenCode con Muse Spark como modelo, gracias a la compatibilidad directa del Model API con las CLIs de agentes que ya existen. Y todo se ejecuta dentro de las Actions de tu propio repositorio, no en la infraestructura de un tercero.

La contención como requisito de diseño

Lo que separa esta receta de un proyecto ingenuo de “conecta un LLM a unos webhooks” es cuánto de ella trata sobre no actuar. El agente de revisión lleva una lista explícita de “NOT slop”: criterios de cambios que no debe señalar, para no gritar “¡lobo!” ante patrones perfectamente legítimos. El triaje nunca cierra issues; esa decisión sigue siendo humana. Y el agente de bugs no abre ningún PR si antes no consigue reproducir el fallo. Meta lo plantea sin rodeos: dispararse de más se trata como un modo de fallo, no como un detalle menor.

También hay disciplina de citación: la función de preguntas y respuestas solo puede responder a partir de los archivos del repositorio, debe adjuntar una cita de archivo y sección a cada afirmación, y tiene que negarse a inventar cuando la respuesta no está en el repo. Para un bot que habla en público con la voz de tu proyecto, “con fuentes o en silencio” es la única política defendible.

AGENTS.md: un archivo para gobernarlos a todos

Cada agente de la receta carga automáticamente un AGENTS.md compartido con el contexto del repositorio —para que ningún agente tenga que adivinar tus convenciones— y las reglas de seguridad que todos heredan. Meta lo describe como el archivo más importante que debes adaptar a tu propio proyecto: la versión que se distribuye es un ejemplo resuelto para un stack de Python/pytest/uv, pensado para que lo reescribas para el tuyo manteniendo intacta, palabra por palabra, la sección SECURITY.

Despliega por fases, gana el permiso de escritura

La guía de despliegue es una escalera de confianza en cuatro fases. Fase uno: revisión de PRs y triaje, en modo solo lectura — validas la calidad con tráfico real y radio de daño cero. Fase dos: comandos /oc explícitos, para que los mantenedores invoquen al agente de forma deliberada. Fase tres: corrección automática de bugs, controlada por etiquetas. Fase cuatro: endurecimiento — protección de ramas, CODEOWNERS, puertas de CI. El acceso de escritura se gana con historial, nunca se concede el primer día. Es la misma filosofía que la propia historia de auditabilidad de Muse Code: la autonomía solo crece al ritmo al que crece la verificación.

Cómo lo validó Meta

Un detalle que merece la pena copiar: la receta se validó ejecutando los agentes reales en modo headless contra escenarios guionizados de issues y PRs — reconstruyendo el prompt de la Action con un gh falso en el PATH para que nada tocara un repositorio en producción — y leyendo después lo que produjeron. Prueba tu bot como probarías cualquier automatización en la que no confías: en un frasco, antes de soltarlo en producción. La receta ejecutable está en el cookbook, en la sección de casos de uso.

Sigue leyendo