Team per repo and per request

Who plays each role is decided at three levels. The most specific wins:

message > the repo's .ghosty/factory.md > workspace team

Workspace team

In /factory → "Workspace team" (owner only): which Studio agent is @plan, @build and @check by default, plus the optional @eval. Every repo that doesn't say otherwise uses it.

.ghosty/factory.md in the repo

A file in the repo with frontmatter per role and, below it, the conventions all three roles must know:

---plan: { agent: Planner }build: { agent: Builder, model: opus }check: { agent: Reviewer, model: flash }---Conventions of this repo that @plan, @build and @check must know:- Tests run with `pnpm test` and use Vitest.- Already-applied migrations in `prisma/migrations/` are never touched.

• agent: name or id of a Studio agent in your workspace.
• model: alias (opus, sonnet, fable, pro, flash, sol, terra, luna) or full id. It must belong to that agent's engine: changing engine means changing agent.
• A role that isn't listed uses the workspace's. The body travels with every factory turn and overrides the generic rules.
• It's read with a 5-minute cache; in /factory, "Team in this repo" → ↻ refreshes it and shows where each role comes from ("from the repo" or "from the workspace").

In the message

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

The keywords stay in Spanish (con = with, en = in):

• "con <model>" changes that role's model in that thread: later hand-offs of the same request inherit it.
• "en <repo>" picks the repo when the room has several.
• A model from another engine or an agent that doesn't exist won't run: the thread says why.

Each reply's footer shows the model that ran that turn, not just the configured one.