Documentación
Software Factory

Software Factory — PRs que se revisan en dos minutos

Tres agentes (@plan, @build, @check) trabajan tu repo desde el chat de Teams; tú firmas el plan y el PR. Cómo se instala, cómo se pide y qué trae cada PR.

Actualizado 2026-09-28

Abrir en Claude ↗Abrir en ChatGPT ↗?
Pídeselo a tu agente de código

Léete https://www.ghosty.studio/docs/fabrica.md y dime cómo instalo la Software Factory de Ghosty en mi espacio de Teams y cómo le pido mi primer cambio.

Pégalo en Claude Code, Cursor o Codex con la skill ghosty-agent instalada.

La Software Factory es un equipo de tres agentes que trabaja tu repositorio de GitHub desde un room de . Tú escribes lo que necesitas como se lo dirías a una persona y firmas dos veces: el plan y el PR. Lo demás lo hacen ellos.

Escribir código ya es barato; revisarlo no. Por eso la fábrica no se mide por cuántos PRs abre, sino por cuántos apruebas a la primera: cada PR llega con su riesgo, qué leer primero y cómo se ve.

Los roles

RolQué haceQué no hace
@planLee el repo y escribe el plan: historia con criterios de aceptación, brief técnico, riesgos y lo que no se hará.No edita, no crea ramas.
@buildConstruye el plan firmado: rama nueva, código, pruebas, PR en borrador.No improvisa otro diseño.
@checkRevisa el PR contra el plan con otro modelo: escribe sus propias pruebas de aceptación, prueba la preview y mira que el código siga siendo fácil de cambiar.Nunca edita ni empuja: si algo falta, se lo regresa a @build (hasta 3 vueltas).
@evalOpcional. Juez de los .No participa en los pedidos.

Cada rol es un agente de Studio que eliges tú (motor, modelo y llaves se cambian en /app/agents). El mismo agente puede ser @ghosty en otro room y @build aquí: el rol le llega por turno. Un @check de otro motor que @build revisa mejor, porque no comparte sus puntos ciegos.

Instalar

  1. Teams → Ajustes → Apps → Software Factory (sólo el dueño del espacio).
  2. Elige el repo y qué agente de Studio hace cada rol. Conecta tu GitHub para firmar.
  3. Se crean el room de la fábrica y su tablero de Tasks. Todo room con repos es una fábrica: puedes ligar más repos a otros rooms.
  4. En /factory, «Listo para agentes» califica el repo y «Preparar repo» abre un solo PR con lo que falta: CI, AGENTS.md, CODEOWNERS y Dependabot. Con GitHub Pro o Team (o repo público), «Proteger main» activa la regla de que nada entra sin aprobación.

Pedir un cambio

text
@plan agrega exportar citas a CSV desde la agenda
  1. @plan publica la tarjeta del plan. Fírmala con el botón, con «✅» en el hilo, o pide ajustes con «cambios: …».
  2. Al firmar, @build construye con tu GitHub y abre el PR en borrador.
  3. @check lo revisa. Si pasa, la plataforma saca el PR de borrador y publica la tarjeta del veredicto.
  4. Tú revisas y haces merge (desde la tarjeta o en GitHub). El pedido se cierra solo al mezclarse.

Otras entradas: asignar una tarea a @plan en Tasks, «¿Qué quieres lograr?» en /factory (lo parte en un sprint de 3 a 8 tickets), «Sugerir pedidos» y revisiones programadas en «Automático».

La tarjeta del veredicto

Lo que necesitas para revisar en dos minutos, sin reconstruir el cambio:

  • Riesgo. La plataforma lo marca por lo que toca el PR, no por la palabra del agente: autenticación, migraciones, dependencias, API pública, .github/ o más de 400 líneas → alto. @check puede subirlo por lógica delicada, nunca bajarlo.
  • Lee primero. Hasta cinco archivo:líneas con el porqué, lo más delicado arriba.
  • Capturas. Si el repo tiene preview, la pantalla que cambió en escritorio y móvil.
  • Cambios, CI y revisión: archivos y líneas, estado del CI (verificado en GitHub) y cuántas vueltas dio con @check.
  • Detalle: lo que dijo @check, plegado.

Qué se mide

En /factory, por room:

NúmeroQué es
Pasan a la primeraDe los PRs que ya revisó una persona, cuántos aprobó sin pedir cambios (o mezcló directo). La métrica que importa.
Tiempo de revisiónMediana de «PR listo» a la primera revisión humana.
Se concretanMezclados entre los pedidos cerrados.
Correcciones de @checkVueltas promedio antes de aprobar.
Del pedido al PRMediana del pedido al PR listo.

Siguiente

  • : .ghosty/factory.md y «@build con opus».
  • : lo que los agentes deben saber de tu repo, en tu repo.
  • : comparar agentes y modelos con tus propios pedidos.
← Anterior
Conectores
Siguiente →
Equipo por repo y por pedido