# Equipo por repo y por pedido

> Qué agente y qué modelo hace cada rol de la Software Factory — el equipo del espacio, `.ghosty/factory.md` en el repo y «@build con opus» en el mensaje.

URL: https://www.ghosty.studio/docs/fabrica/equipo-por-repo

Quién hace cada rol se decide en tres niveles. Gana el más específico:

**mensaje > `.ghosty/factory.md` del repo > equipo del espacio**

## Equipo del espacio

En `/factory` → «Equipo del espacio» (sólo el dueño): qué agente de Studio es `@plan`, `@build` y `@check` por defecto, y el `@eval` opcional. Es lo que usan todos los repos que no dicen otra cosa.

## `.ghosty/factory.md` en el repo

Un archivo en el repo con frontmatter por rol y, debajo, las **convenciones** que deben saber los tres roles:

```markdown
---
plan: { agent: Planeador }
build: { agent: Constructor, model: opus }
check: { agent: Revisor, model: flash }
---
Convenciones de este repo que deben saber @plan, @build y @check:
- Las pruebas se corren con `pnpm test` y usan Vitest.
- No se tocan las migraciones ya aplicadas en `prisma/migrations/`.
```

- `agent`: nombre o id de un agente de Studio de tu espacio.
- `model`: alias (`opus`, `sonnet`, `fable`, `pro`, `flash`, `sol`, `terra`, `luna`) o id completo. Tiene que ser del **motor** de ese agente: cambiar de motor es cambiar de agente.
- Un rol que no aparece usa el del espacio. El cuerpo viaja en cada turno de la fábrica y **le gana a lo genérico**.
- Se lee con caché de 5 minutos; en `/factory`, «Equipo en este repo» → ↻ la refresca y dice de dónde sale cada rol («del repo» o «del espacio»).

## En el mensaje

```text
@build con opus
@plan en agenda
@plan en blissito/agenda con sonnet
```

- «con \<modelo\>» cambia el modelo de ese rol **en ese hilo**: los relevos siguientes del mismo pedido lo heredan.
- «en \<repo\>» elige el repo cuando el room tiene varios.
- Un modelo de otro motor o un agente que no existe no se corre: el hilo dice por qué.

El pie de cada respuesta dice **el modelo que corrió ese turno**, no sólo el configurado.