# Usar BMAD+ en equipo

> Qué versionar y qué dejar en local, qué ajustes acordar, un adaptador por compañero sobre una columna común, una política de actualización segura, puertas de CI e incorporación.

Canonical: https://bmad-plus.rochetta.fr/es/docs/guides/for-teams/
Language: es
BMAD+ version: 0.23.1
Documentation reviewed: 2026-10-19
Author: Laurent Rochetta
License: MIT

Documentación de BMAD+ › [Guías](https://bmad-plus.rochetta.fr/es/docs/guides/) › Usar BMAD+ en equipo

BMAD+ vive en el proyecto, así que un equipo lo comparte como cualquier otra parte del repositorio: decidiendo qué se versiona, qué se configura igual para todos y quién lo cambia. Esta página lista esas decisiones y los hechos que hacen segura cada una: hashes de propiedad, ediciones preservadas, una política de actualización por proyecto, adaptadores generados desde una sola columna. Es para responsables técnicos y para quien tenga que incorporar a compañeros que usan herramientas de IA distintas. Cuando una elección es cuestión de gusto y no un hecho, el texto lo dice.

<a id="what-to-version"></a>
## Qué versionar y qué dejar en local

**Los archivos que crea BMAD+ y a quién pertenecen**

| Archivos | Naturaleza | Consideraciones |
| --- | --- | --- |
| `AGENTS.md`, archivos de adaptador, `.agents/skills/`, `.agents/data/` | Generados y copiados por el instalador; con hash en el manifiesto. | Incluirlos en el repositorio da a cada compañero las mismas instrucciones sin ejecutar el instalador. No incluirlos significa que cada uno instala la misma versión. Ambas funcionan; elige una. |
| `_bmad/config.yaml` | Tus ajustes: idioma, modo de ejecución, puntos de control, uat, swarm. Se escribe una vez y se fusiona, nunca se sobrescribe. | El archivo natural para compartir, pues contiene las convenciones del equipo. |
| `_bmad/update-policy.json` | Lo escribe `update-policy` cuando cambias la política. | Compártelo si el equipo quiere una sola política; nombra el rango de versiones permitido. |
| `_bmad/review-rules.yaml` y sus documentos | Reglas de revisión del proyecto. | Compártelo: un archivo de hallazgos responde a un solo conjunto de reglas, así que el equipo debe revisar con el mismo. |
| `_bmad/.bmad-plus-install.json` | El manifiesto: versión, packs, herramientas y un SHA-256 por cada archivo instalado. | Debe seguir siendo coherente con los archivos que describe: versiónalo con ellos, o ninguno de los dos. |
| `.agents/memory/` | Decisiones, lecciones, patrones, contexto, traspasos. | Versiónala si la memoria es del equipo. Instalar y actualizar nunca sobrescriben estos archivos. |
| `.agents/memory/.brain-link` | La ruta absoluta del cerebro enlazado en una máquina. | Propio de la máquina: no lo compartas. |
| `_bmad-output/` | Entregables: briefs, PRD, evidencias de revisión, resultados de aceptación. | Suele versionarse en parte: briefs, PRD, clasificación y resultados son evidencias que vale la pena conservar. |
| `.bmad/`, `.bmad-plus/` | Caché y recibos de actualización, diario de memoria, estado de enjambres y ejecuciones de Nexus. | Estado local. El bloqueo de actualización y los recibos conciernen a una sola copia de trabajo. |

<a id="shared-conventions"></a>
## Convenciones que conviene acordar

**Ajustes y su efecto en el equipo**

| Ajuste | Dónde | Por qué acordarlo |
| --- | --- | --- |
| Packs | `install --packs` | Los packs definen qué agentes existen. `--packs` y `--tools` se suman a una instalación previa, así que se puede añadir un pack más tarde sin perder nada. |
| `communication_language`, `document_output_language` | `_bmad/config.yaml` | El idioma que hablan los agentes y el idioma de los entregables. |
| `execution_mode` | `_bmad/config.yaml` | `manual`, `autopilot` o `hybrid`: cuánto deja el equipo que Nexus avance solo. |
| `checkpoints` | `_bmad/config.yaml` | Quién aprueba qué: `discovery`, `architecture`, `story`, `delivery`, cada uno `require_approval`, `notify_only` o `auto`. |
| `uat.mode` y `uat.environment` | `_bmad/config.yaml` | `advisory`, `gate` u `off`, y el entorno de pruebas al que apunta una receta. |
| `swarm.budget` y `swarm.wave` | `_bmad/config.yaml` | Cuántos subagentes puede usar una ejecución antes de que alguien deba decir sí (26 y 10 por defecto). |
| Reglas de revisión | `_bmad/review-rules.yaml` | El mismo conjunto de reglas para cada revisor, humano o agente. |
| Política de actualización | `_bmad/update-policy.json` | Ver la sección siguiente. |

<a id="adapters"></a>
## Una columna, un adaptador por compañero

Todos los adaptadores se generan a partir del mismo registro que `AGENTS.md`, así que un compañero con Cursor y otro con Claude Code obtienen la misma lista y las mismas reglas; solo cambia el formato de archivo. `--tools` acepta varios ids a la vez (`--tools claude-code,cursor`), `all` o `none`. El instalador detecta las herramientas por sus carpetas (`.claude/`, `.gemini/`, `.cursor/`, `.codex/`, `.opencode/`, `.aider.conf.yml`) cuando no pasas `--tools`; `--yes` sin herramienta detectada no escribe ningún adaptador. Un adaptador de BMAD+ que editaste se conserva. Un archivo de instrucciones que escribiste tú se conserva en una instalación interactiva y con `update`; `install --yes` lo copia primero a `<file>.bak` y luego lo sustituye. Los archivos antiguos del instalador se guardan como `<file>.bak`.

**Adaptadores**

| Id de la herramienta | Archivo escrito | Detectado por |
| --- | --- | --- |
| `claude-code` | `CLAUDE.md` | una carpeta `.claude/` |
| `gemini-cli` | `GEMINI.md` | una carpeta `.gemini/` |
| `antigravity` | `GEMINI.md` (compartido con gemini-cli) | una carpeta `.gemini/antigravity/` |
| `cursor` | `.cursor/rules/bmad-plus.mdc` (siempre aplicado) | una carpeta `.cursor/` |
| `codex-cli` | `.codex/AGENTS.md` | una carpeta `.codex/` |
| `opencode` | `.opencode/AGENTS.md` | una carpeta `.opencode/` |
| `aider` | `CONVENTIONS.md`; añade `read: CONVENTIONS.md` a `.aider.conf.yml` o ejecuta `/read CONVENTIONS.md` en Aider | un archivo `.aider.conf.yml` |

Un compañero que añade una herramienta más tarde vuelve a ejecutar el instalador con esa herramienta: la ejecución conserva lo ya instalado y añade el adaptador que falta. `--tools none` instala agentes, habilidades y memoria sin tocar la configuración de ninguna herramienta, que es la opción adecuada para un proyecto cuyo `CLAUDE.md` o `AGENTS.md` se mantiene a mano.

<a id="update-policy"></a>
## Una política de actualización segura

El valor por defecto es avisar: las instrucciones generadas piden al asistente que ejecute `update-check` una vez por sesión y lo notifique. No se aplica nada. Para un equipo, el patrón práctico es una persona (o un job de CI) que decide cuándo avanzar, aplica `update`, revisa el informe y hace commit; los demás reciben el resultado con su siguiente pull. Si el equipo quiere que las actualizaciones fluyan sin una persona, `auto` exige un rango semver explícito y varias salvaguardas: el resultado del registro debe ser reciente, los archivos gestionados sin cambios, el inventario de hashes de la instalación completo, la versión destino exactamente la registrada en el comando y el requisito de Node cumplido. Una consulta sin conexión, obsoleta o fallida nunca permite una actualización automática.

**Leer y fijar la política**

```text
$ npx bmad-plus update-policy
Update policy: notify; channel=latest; range=none; prereleases=false
$ npx bmad-plus update-policy --json
{"policy":{"mode":"notify","channel":"latest","allowedRange":null,"allowPrerelease":false,"registry":"https://registry.npmjs.org/"},"changed":false}
$ npx bmad-plus update-policy --mode auto --range "^0.23.0"
Update policy saved: auto; channel=latest; range=^0.23.0; prereleases=false
$ npx bmad-plus update-policy --mode notify
Update policy saved: notify; channel=latest; range=^0.23.0; prereleases=false
$ npx bmad-plus update-check --offline --json
{"schemaVersion":1,"installedVersion":"0.23.0","runningVersion":"0.23.0","latestVersion":null,"targetVersion":null,"channel":"latest","status":"unknown","checkedAt":null,"source":"none","stale":false,"updateAvailable":null,"releaseEligible":false,"versionEligible":false,"canAutoApply":false,"engineCompatible":null,"engines":{},"reason":"offline"}
```

Salida capturada de una ejecución real. Fuente: Reproducido en un servidor de pruebas el 2026-10-18 con el código fuente 0.23.0 (tools/cli/bmad-plus-cli.js) en un proyecto Git desechable

- `off` detiene toda consulta. `notify` (por defecto) informa. `auto` exige `--range`; añade `--allow-prerelease` o `--stable-only` para gestionar las preversiones. El registro está fijado a `https://registry.npmjs.org/`.
- Una actualización conserva los archivos cambiados desde su hash registrado y los notifica; un conflicto bloquea la vía automática. Los archivos que una versión nueva ya no incluye se quitan tras una copia de seguridad restaurable. Cada actualización aplicada escribe `.bmad/updates/<receipt-id>/` con `receipt.json` y `backups/`; `update --restore <receipt-id> --yes` vuelve a ella y se niega a sobrescribir ediciones locales posteriores.
- Una instalación anterior a 0.13 (sin hashes de archivos) no se puede actualizar automáticamente; una migración explícita, `npx --yes bmad-plus@0.23.1 update --yes`, guarda copia de lo que reemplaza.
- `install` nunca cambia la versión instalada: se rechaza una bajada de versión y una subida pasa por `update`. Si dos compañeros instalaron versiones distintas, quien tiene la más antigua ejecuta `update`.
- Un bloqueo `.bmad/update.lock` protege el proyecto durante una actualización (se considera obsoleto tras 60 minutos o si su propietario ha muerto); `doctor` informa de un bloqueo que no es suyo.

<a id="ci-and-gates"></a>
## CI y puertas

BMAD+ no instala ningún hook de Git ni de ciclo de vida en tu proyecto, porque una instrucción se puede saltar. Lo que un equipo quiere imponer lo impone con su propia CI, mediante códigos de salida pensados para ello.

**Comprobaciones que un equipo puede conectar a CI**

| Comprobación | Comando | Falla cuando |
| --- | --- | --- |
| Integridad de la instalación | `bmad-plus doctor --json` | Salida 1 ante cualquier error (un archivo requerido que falta, por ejemplo). Los archivos modificados son advertencias. |
| Vigilancia de actualizaciones | `bmad-plus update-check --json` | Salida 1 por un runtime, instalación o política no válidos; un registro inalcanzable es `unknown`, no un fallo. |
| Puerta de revisión en pull requests | Las recetas de `docs/recipes/ci-review/` | La revisión está incompleta (salida 2) o tiene hallazgos abiertos (salida 1). |
| Una versión tiene una ejecución humana aceptada | `uat-release-gate.mjs` de la habilidad uat | Sin ejecución terminada, otra revisión, un fallo sin clasificar, una escritura sin confirmar (salidas 1 a 3; 4 significa que la puerta no pudo ejecutarse). |
| Una versión tiene al menos una receta | `uat-spec-present.mjs` | Ninguna receta nombra la versión de `package.json`. |
| Un archivo de intake del equipo es válido | `bmad-plus intake check FILE` | Salida 1 con todos los problemas listados. |
| Evidencias de Shield | `bmad-plus assurance verify` y `ai-register check` | `assurance verify` sale con 1 cuando una afirmación no está respaldada; `ai-register check` solo avisa. |

<a id="onboarding"></a>
## Incorporar a un compañero

1. **Traer el repositorio y comprobar la instalación** Si los archivos generados están en el repositorio, `doctor` ya funciona. Si no, ejecuta el instalador con la lista de packs del equipo y luego `doctor`.

   ```sh
   npx bmad-plus@0.23.1 install --packs core,memory --tools claude-code
   npx bmad-plus@0.23.1 doctor
   ```
2. **Añadir tu propia herramienta** Instala con el id de tu herramienta; los archivos existentes se conservan y se añade tu adaptador.

   ```sh
   npx bmad-plus@0.23.1 install --packs core,memory --tools cursor
   ```
3. **Leer la columna y preguntar al asistente** Abre `AGENTS.md` para ver la lista de agentes y las reglas del equipo y escribe `bmad-help` en el chat. Lee los ajustes de `_bmad/config.yaml` para saber qué puntos de control se detendrán a preguntarte.
4. **Enlazar la memoria a tu máquina** Con el pack Memory, la instalación detecta un cerebro en tu máquina (`BMAD_PLUS_BRAIN`, una carpeta `_brain/` en un directorio superior, `~/.bmad-plus/brain/`, y por último un `~/.claude/memory/` que no esté vacío) y lo registra en `.agents/memory/.brain-link`. Ese archivo es solo tuyo; los archivos de memoria del proyecto que lo rodean son los del equipo.

<a id="governance"></a>
## Notas de gobernanza para equipos

- Aprobaciones: si el equipo quiere que una persona apruebe la arquitectura y la entrega, mantén `require_approval` en esos puntos de control. Un autopilot con `auto` en todos es una elección deliberada, no un valor por defecto.
- Presupuesto: un enjambre mayor que `swarm.budget` se rechaza hasta que una persona diga sí; la generación de medios de pago se pregunta cada vez. Nadie debería pasar `--approved` en nombre de otro.
- OSINT: investigar a una persona con nombre exige un propósito y una base legal registrados, en cada ejecución. En un equipo eso supone alguien que asuma esa decisión. Consulta la página de confianza.
- Shield: los informes los genera una IA y llevan la marca «not legal advice»; una decisión de cumplimiento sigue en manos de una persona cualificada.
- Secretos: las claves de API van en el entorno de cada persona o de la CI, nunca en el repositorio. El suelo de ocultación de la revisión y el de las notas de aceptación enmascaran formas habituales de credenciales; no sustituyen el no incluir secretos en el repositorio.
- Propiedad: cada archivo escrito por BMAD+ lleva hash. Un archivo que editó un compañero lo conservan la actualización y la desinstalación y `doctor` lo señala como modificado (una advertencia): la personalización local es visible, no se sobrescribe en silencio.

<a id="example-team-conventions-review"></a>
### Auditar las convenciones de BMAD+ del equipo

Úsalo cuando llega un nuevo responsable técnico, o antes de incorporar a un compañero. El asistente solo lee; no se cambia nada.

**En tu asistente de IA**

```text
Lee _bmad/config.yaml, _bmad/update-policy.json si existe, _bmad/review-rules.yaml si existe y el manifiesto _bmad/.bmad-plus-install.json. Resume en una tabla: versión instalada, packs, herramientas, modo de ejecución, comportamiento de cada punto de control, modo uat, presupuesto de enjambre, modo y rango de la política de actualización. Luego lista lo que un compañero nuevo tendría que hacer para tener la misma configuración y señala cualquier ajuste que parezca incoherente con los demás. No cambies nada.
```

**Lo que deberías obtener** Una tabla con los valores reales leídos de los archivos, una lista de incorporación (instalar con los mismos packs, añadir tu herramienta, leer la columna) y una breve lista de incoherencias, por ejemplo `execution_mode: autopilot` con todos los puntos de control en `auto`. No se modifica ningún archivo.

**Véase también**

- [Tu primera hora con BMAD+](https://bmad-plus.rochetta.fr/es/docs/guides/first-hour/)
- [Instalar, actualizar, desinstalar](https://bmad-plus.rochetta.fr/es/docs/guides/install-lifecycle/)
- [Referencia: config.yaml](https://bmad-plus.rochetta.fr/es/docs/reference/config-yaml/)
- [Referencia: adaptadores](https://bmad-plus.rochetta.fr/es/docs/reference/adapters/)
- [Confianza y propiedad](https://bmad-plus.rochetta.fr/es/docs/security/trust-and-ownership/)
- [Tratamiento de datos](https://bmad-plus.rochetta.fr/es/docs/security/data-handling/)

[Documentación de BMAD+](https://bmad-plus.rochetta.fr/es/docs/) · [Guías](https://bmad-plus.rochetta.fr/es/docs/guides/)

[Código en GitHub](https://github.com/lrochetta/BMAD-PLUS)