# Pack Dev Studio: seis perfiles (personas) y 38 workflows

> Dev Studio cubre el ciclo de vida del software con seis perfiles (personas) y 38 workflows con nombre, del brief a la revisión de código. Instalación, catálogo por fase, ejemplos, CLI studio, límites.

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

Documentación de BMAD+ › [Packs](https://bmad-plus.rochetta.fr/es/docs/packs/) › Pack Dev Studio: seis perfiles (personas) y 38 workflows

Dev Studio te da un equipo de software completo en forma de procedimientos escritos. Seis perfiles (personas), cada uno con un rol, ejecutan 38 workflows con nombre repartidos en cinco fases: análisis, planificación, arquitectura, implementación y utilidades. Nombras el perfil o el workflow, y tu herramienta de programación con IA lee las instrucciones y las ejecuta con sus propias herramientas. Es el pack que conviene cuando quieres un procedimiento concreto y repetible (validar un PRD, escribir una arquitectura, investigar un fallo) en lugar de una conversación libre.

<a id="when-to-use"></a>
## Cuándo usarlo

- Quieres un procedimiento con nombre, con entrada definida y resultado esperado documentado, ejecutado igual cada vez.
- Ya usas Core y quieres roles más finos: por ejemplo una diseñadora UX dedicada (Rachel) o una redactora técnica (Huldah).
- Una corrección acotada no necesita el pipeline completo: el orquestador elige el workflow más pequeño que produce el resultado pedido.

<a id="installed"></a>
## Qué se instala

Dev Studio es un pack empaquetado en `.agents/skills/pack-dev-studio/`, más la habilidad de despacho `dev-studio` en `.agents/skills/dev-studio/`. El pack contiene el orquestador `dev-studio-orchestrator.md`, el `shared/catalog.json` legible por máquina (perfiles, workflows, alias, tipos de entrada, recursos requeridos), la guía de ejecución `shared/execution.md`, un README y `categories/` con un archivo Markdown por perfil y por workflow. Cada workflow responde al menos a tres nombres: `<id>`, `bmad-<id>` y `bmad-plus-<id>`, de modo que `bmad-plus-validate-prd` y `validate-prd` llevan al mismo procedimiento.

<a id="personas"></a>
### Los seis perfiles

**Perfiles y workflows de los que se encarga cada uno**

| Perfil | Rol | Se encarga de |
| --- | --- | --- |
| Miriam (מרים) | Business Analyst | `product-brief`, `prfaq`, `market-research`, `domain-research`, `technical-research`, `party-mode`, `brainstorming`, `advanced-elicitation`, `bmad-help` |
| Huldah (חולדה) | Technical Writer | `document-project`, `distillator`, `editorial-review-prose`, `editorial-review-structure`, `shard-doc`, `index-docs` |
| Yosef (יוסף) | Product Manager | `create-prd`, `prd`, `edit-prd`, `validate-prd`, `adversarial-review` |
| Rachel (רחל) | UX Designer | `create-ux-design` |
| Bezalel (בצלאל) | System Architect | `create-architecture`, `create-epics-stories`, `implementation-readiness`, `generate-project-context`, `edge-case-hunter` |
| Oholiab (אהליאב) | Senior Engineer | `sprint-planning`, `create-story`, `dev-story`, `code-review`, `quick-dev`, `sprint-status`, `retrospective`, `correct-course`, `investigate`, `checkpoint-preview`, `qa-e2e-tests`, `customize` |

Un perfil (persona) es un conjunto de instrucciones, no un proceso en ejecución. Elige el rol que necesita la tarea; Atlas, Forge, Sentinel y Nexus de Core pueden coexistir con estas seis.

<a id="catalogue"></a>
### Los 38 workflows por fase

La columna Entrada indica qué necesita un workflow. Uno de tipo petición necesita tu petición o un archivo. Uno de tipo artefacto necesita al menos un archivo existente, por ejemplo el PRD que validar. Uno de tipo proyecto necesita una petición o un archivo y trabaja sobre el proyecto. El workflow bmad-help no necesita nada. El contexto que falta se señala como entrada necesaria en lugar de adivinarse.

<a id="phase-analysis"></a>
### Análisis (6)

**Workflows de análisis**

| Workflow | Perfil | Entrada | Resultado esperado |
| --- | --- | --- | --- |
| `product-brief` | Miriam | petición | Problema de producto, público y primer alcance útil |
| `prfaq` | Miriam | petición | Relato de lanzamiento propuesto y las preguntas que lo ponen a prueba |
| `document-project` | Huldah | proyecto | Documentación basada en archivos del proyecto realmente inspeccionados |
| `market-research` | Miriam | petición | Análisis con fuentes del mercado y de las alternativas |
| `domain-research` | Miriam | petición | Conceptos del dominio, restricciones y lagunas de evidencia |
| `technical-research` | Miriam | petición | Opciones de viabilidad y una próxima comprobación concreta |

<a id="phase-planning"></a>
### Planificación (5)

**Workflows de planificación**

| Workflow | Perfil | Entrada | Resultado esperado |
| --- | --- | --- | --- |
| `create-prd` | Yosef | petición | Requisitos comprobables y alcance |
| `prd` | Yosef | petición | Elección entre crear, editar y validar un PRD |
| `edit-prd` | Yosef | artefacto | Cambios de requisitos trazables |
| `validate-prd` | Yosef | artefacto | Hallazgos sobre los requisitos basados en evidencias |
| `create-ux-design` | Rachel | petición | Flujos de usuario, estados de interacción y comprobaciones de aceptación |

<a id="phase-architecture"></a>
### Arquitectura (4)

**Workflows de arquitectura**

| Workflow | Perfil | Entrada | Resultado esperado |
| --- | --- | --- | --- |
| `create-architecture` | Bezalel | petición | Decisiones técnicas, límites y compromisos |
| `create-epics-stories` | Bezalel | artefacto | Incrementos entregables y stories implementables |
| `implementation-readiness` | Bezalel | artefacto | Brechas de alineación y evidencias de preparación |
| `generate-project-context` | Bezalel | proyecto | Restricciones actuales del proyecto con su procedencia |

<a id="phase-implementation"></a>
### Implementación (11)

**Workflows de implementación**

| Workflow | Perfil | Entrada | Resultado esperado |
| --- | --- | --- | --- |
| `sprint-planning` | Oholiab | artefacto | Trabajo acotado, dependencias y supuestos de capacidad |
| `create-story` | Oholiab | artefacto | Una story con contexto y criterios de aceptación |
| `dev-story` | Oholiab | artefacto | Implementación y verificación frente a una story |
| `code-review` | Oholiab | proyecto | Hallazgos fundamentados o un informe sin hallazgos de alcance definido |
| `quick-dev` | Oholiab | proyecto | Un cambio acotado con comprobaciones proporcionadas |
| `sprint-status` | Oholiab | proyecto | Progreso y bloqueos respaldados por evidencias actuales |
| `retrospective` | Oholiab | artefacto | Lecciones y cambios de proceso accionables |
| `correct-course` | Oholiab | proyecto | Una respuesta razonada a un cambio relevante |
| `investigate` | Oholiab | proyecto | Hipótesis, evidencias de reproducción y siguiente acción |
| `checkpoint-preview` | Oholiab | proyecto | Una explicación revisable de un cambio |
| `qa-e2e-tests` | Oholiab | proyecto | Comprobaciones automáticas pertinentes y evidencias de ejecución real |

<a id="phase-utilities"></a>
### Utilidades (12)

**Workflows de utilidad**

| Workflow | Perfil | Entrada | Resultado esperado |
| --- | --- | --- | --- |
| `distillator` | Huldah | artefacto | Un brief compacto con fuentes y omisiones declaradas |
| `party-mode` | Miriam | petición | Perspectivas comparadas y un registro de decisión |
| `brainstorming` | Miriam | petición | Opciones distintas y un pequeño experimento |
| `adversarial-review` | Yosef | artefacto | Objeciones fundamentadas, refutaciones y preguntas abiertas |
| `edge-case-hunter` | Bezalel | petición | Escenarios concretos de límites y fallos |
| `editorial-review-prose` | Huldah | artefacto | Mejoras precisas de redacción |
| `editorial-review-structure` | Huldah | artefacto | Un esquema orientado al lector y la correspondencia de secciones |
| `advanced-elicitation` | Miriam | petición | Incertidumbres resueltas y requisitos comprobables |
| `shard-doc` | Huldah | artefacto | Secciones enlazadas con comprobación de cobertura de la fuente |
| `index-docs` | Huldah | proyecto | Un índice de los documentos inspeccionados |
| `bmad-help` | Miriam | ninguna | Rutas pertinentes y un siguiente paso justificado |
| `customize` | Oholiab | proyecto | Cambios verificados de configuración o de instrucciones explícitas |

<a id="quick-start"></a>
## Inicio rápido

1. **Instalar el pack** Core se añade automáticamente; nombrarlo también es inocuo. Solo hace falta Node.js 20.

   ```sh
   npx bmad-plus install --packs core,dev-studio
   ```
2. **Pedir a un perfil que ejecute un workflow** Nombra el perfil y el identificador del workflow.

   ```sh
   Miriam, usa product-brief para definir una pequeña herramienta de triaje de incidencias para nuestro equipo de soporte.
   ```
3. **Opcional: listar el catálogo desde el terminal** La CLI lista cada workflow con su perfil y tipo de entrada, sin modificar nada.

   ```sh
   npx bmad-plus studio list --json
   ```

<a id="examples"></a>
## Ejemplos para copiar

<a id="example-dev-studio-product-brief"></a>
### Miriam: definir un producto con product-brief

Úsalo al comienzo de una idea. Tipo de entrada: petición.

**En tu asistente de IA**

```text
Miriam, usa product-brief para definir una aplicación de listas de inspección para nuestros técnicos de campo. Trabajan a menudo en sótanos sin red: di qué implica eso para el primer alcance.
```

**Lo que deberías obtener** Un informe con el problema de producto, el público y el primer alcance útil, escrito por defecto en `_bmad-output/dev-studio/product-brief.md`.

<a id="example-dev-studio-document-project"></a>
### Huldah: documentar un proyecto existente

Úsalo cuando un código no tiene documentación utilizable. Tipo de entrada: proyecto.

**En tu asistente de IA**

```text
Huldah, ejecuta document-project en este repositorio. Documenta solo lo que puedas respaldar con archivos que realmente abriste y enumera lo que no pudiste verificar.
```

**Lo que deberías obtener** Documentación basada en archivos del proyecto inspeccionados, con los puntos sin verificar señalados, guardada en `_bmad-output/dev-studio/document-project.md` salvo que fijes otra carpeta de salida.

<a id="example-dev-studio-validate-prd"></a>
### Yosef: validar un PRD

Úsalo antes de que empiece la arquitectura. Tipo de entrada: artefacto, así que el archivo es obligatorio.

**En tu asistente de IA**

```text
Yosef, ejecuta validate-prd sobre docs/prd.md.
```

**Lo que deberías obtener** Hallazgos sobre los requisitos basados en evidencias, cada uno ligado a lo que el archivo dice realmente, en `_bmad-output/dev-studio/validate-prd.md`. Si falta el archivo, el workflow indica que necesita entrada.

<a id="example-dev-studio-ux-design"></a>
### Rachel: diseñar los flujos de un onboarding

Úsalo antes de la capa visual. Si el pack Design está instalado, Atelier se encarga de las reglas visuales y de accesibilidad y los flujos de Rachel alimentan su intake.

**En tu asistente de IA**

```text
Rachel, ejecuta create-ux-design para el onboarding de nuevos usuarios: desde la creación de la cuenta hasta su primera factura guardada. Cubre los estados vacío, error y sin conexión.
```

**Lo que deberías obtener** Flujos de usuario, estados de interacción y comprobaciones de aceptación en `_bmad-output/dev-studio/create-ux-design.md`.

<a id="example-dev-studio-architecture"></a>
### Bezalel: diseñar la arquitectura

Úsalo cuando los requisitos estén cerrados. El workflow avanza por pasos y puede reanudarse desde un informe anterior.

**En tu asistente de IA**

```text
Bezalel, diseña la arquitectura de la aplicación de reserva de citas descrita en docs/prd.md. Registra cada decisión con sus alternativas y compromisos.
```

**Lo que deberías obtener** Decisiones técnicas, límites y compromisos, registrados en `_bmad-output/dev-studio/create-architecture.md` con la plantilla de decisión de arquitectura. Continúa con `create-epics-stories` e `implementation-readiness` para comprobar que el plan es coherente.

<a id="example-dev-studio-investigate"></a>
### Oholiab: reproducir un fallo antes de corregirlo

Úsalo para fallos de causa poco clara. Tipo de entrada: proyecto, con la descripción como petición o como archivo.

**En tu asistente de IA**

```text
Oholiab, usa investigate para reproducir la importación que falla descrita en docs/issue.md.
```

**Lo que deberías obtener** Hipótesis, evidencias de reproducción y la siguiente acción, en `_bmad-output/dev-studio/investigate.md`. Solo entonces tiene sentido una corrección, por ejemplo con `quick-dev`.

<a id="example-dev-studio-prepare-cli"></a>
### Preparar un lote de contexto de solo lectura desde el terminal

Úsalo para ver exactamente qué recibirá un workflow. Prepara, no ejecuta: sigue siendo tu asistente quien trabaja.

**En tu asistente de IA**

```text
npx bmad-plus studio prepare validate-prd --input docs/prd.md --json
```

**Lo que deberías obtener** Un lote de solo lectura: la configuración resuelta, los textos de instrucciones entregados con sus hashes SHA-256, el contenido y los hashes de los archivos de entrada y la ruta de informe propuesta. Los archivos de entrada deben existir dentro del proyecto y `--input` puede repetirse. Si no se aporta una entrada requerida (ningún `--input` en un workflow de tipo artefacto), el comando termina con código 2 y el estado needs-input, mientras que una ruta `--input` inexistente es un error (código de salida 1); nunca escribe el entregable, ejecuta pruebas ni certifica que un modelo siguiera el workflow.

<a id="example-dev-studio-help"></a>
### Preguntar qué workflow encaja

Úsalo cuando conoces el objetivo pero no el nombre del workflow. bmad-help no requiere entrada.

**En tu asistente de IA**

```text
Miriam, ejecuta bmad-help: tengo un PRD a medio escribir y una fecha límite. ¿Qué workflows de Dev Studio debo ejecutar, en qué orden y cuáles puedo omitir?
```

**Lo que deberías obtener** Las rutas pertinentes y un siguiente paso justificado. Para un PRD a medio escribir, suele significar terminar primero los requisitos (`prd` o `edit-prd`), luego `validate-prd` y después `create-architecture`. Los identificadores de workflow de la respuesta son sugerencias, no disparadores automáticos.

<a id="outputs"></a>
## Qué escribe y dónde

Los informes van por defecto a `_bmad-output/dev-studio/<workflow-id>.md`, ajustado a la carpeta de salida configurada. Los cambios de código se quedan en el proyecto real. Un informe registra el alcance, las entradas, las decisiones, el trabajo hecho, las comprobaciones, las preguntas abiertas y la siguiente acción. Al reanudar, el workflow lee el informe anterior y revalida las entradas que cambiaron. Un informe nunca autoriza a sobrescribir tus cambios ni a repetir una publicación.

**Ajustes leídos de _bmad/config.yaml (cada clave tiene un valor por defecto; project_name recurre al nombre de la carpeta, aquí demo-app)**

```yaml
user_name: user
communication_language: English
document_output_language: English
output_folder: _bmad-output
project_name: demo-app

```

Un archivo ausente es válido. Un archivo mal formado, o un campo conocido no válido, es un error. `project_name` toma por defecto el nombre de la carpeta. Tu petición actual y las instrucciones de tu anfitrión prevalecen sobre las preferencias de idioma de la configuración.

<a id="data-and-prerequisites"></a>
## Flujos de datos y requisitos

Node.js 20 para el instalador y el comando opcional `studio`. Ni Python, ni clave, ni flujo propio que salga de tu máquina: `studio list` y `studio prepare` solo leen archivos locales. Lo que tu asistente envía a su modelo depende de tu herramienta anfitriona. Los workflows de investigación necesitan fuentes accesibles para respaldar afirmaciones factuales actuales, y lo dicen cuando no las tienen.

<a id="limits"></a>
## Límites y trampas

> **Advertencia · Un rol, no un planificador** El orquestador es un rol de instrucciones. No envía notificaciones, no hace commits y no publica nada por sí mismo. Los agentes paralelos independientes, la navegación y la ejecución de comandos dependen de tu anfitrión; cuando un solo asistente interpreta varias perspectivas debe decirlo, y las comprobaciones no disponibles siguen visibles. Ningún workflow garantiza código sin defectos ni un resumen sin pérdidas.

> **Nota · Sin intérprete BWML** La antigua notación de workflow de estilo XML (BWML) y la personalización TOML no tienen intérprete ni resolutor en este pack. Una nota de migración del pack describe el comportamiento sustituto admitido: procedimientos Markdown simples, el catálogo y `_bmad/config.yaml`.

> **Consejo · Solapamiento con Core y Design** Dev Studio se solapa con Atlas, Forge, Sentinel y Nexus; ambos pueden convivir, así que elige el perfil cuyo workflow quieras. Para las pantallas, Rachel o Atelier se encarga de una pantalla concreta y el traspaso dice cuál.

> **Nota · Procedencia** Dev Studio es un pack original escrito por Laurent Rochetta: seis agentes especializados del ciclo de vida del software y 38 workflows, redactados como instrucciones originales de BMAD+. Los nombres de los perfiles y el linaje de los workflows reconocen a BMAD-METHOD, de BMad Code, LLC (licencia MIT, base v6.6.0); no se incluye ningún runtime upstream.

**Véase también**

- [Los diez packs lado a lado](https://bmad-plus.rochetta.fr/es/docs/packs/packs-overview/)
- [Pack Core](https://bmad-plus.rochetta.fr/es/docs/packs/core/)
- [Pack Design (Atelier)](https://bmad-plus.rochetta.fr/es/docs/packs/design/)
- [Referencia del comando studio](https://bmad-plus.rochetta.fr/es/docs/reference/cli-studio/)
- [Lista de los 48 agentes](https://bmad-plus.rochetta.fr/es/docs/agents/agents-roster/)

[Documentación de BMAD+](https://bmad-plus.rochetta.fr/es/docs/) · [Packs](https://bmad-plus.rochetta.fr/es/docs/packs/)

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