# Dev Studio pack: six personas and 38 workflows

> Dev Studio covers the software lifecycle with six personas and 38 named workflows, from product brief to code review. Install, the full catalogue by phase, eight prompts, studio CLI, limits.

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

BMAD+ documentation › [Packs](https://bmad-plus.rochetta.fr/docs/packs/) › Dev Studio pack: six personas and 38 workflows

Dev Studio gives you a full software team as written procedures. Six personas, each with a role, run 38 named workflows across five phases: analysis, planning, architecture, implementation and utilities. You name the persona or the workflow, and your AI coding tool reads the instructions and carries them out with its own tools. It is the pack to pick when you want a specific, repeatable procedure (validate a PRD, write an architecture, investigate a failure) rather than a free-form conversation.

<a id="when-to-use"></a>
## When to use it

- You want a named procedure with a defined input and a documented expected result, run the same way every time.
- You already use Core and want finer-grained roles: for example a dedicated UX designer (Rachel) or a technical writer (Huldah).
- A narrow fix does not need the whole pipeline: the orchestrator picks the smallest workflow that produces the result you asked for.

<a id="installed"></a>
## What is installed

Dev Studio is a packaged pack in `.agents/skills/pack-dev-studio/`, plus the dispatcher skill `dev-studio` in `.agents/skills/dev-studio/`. The pack holds the orchestrator `dev-studio-orchestrator.md`, the machine-readable `shared/catalog.json` (personas, workflows, aliases, input kinds, required resources), the execution guide `shared/execution.md`, a README and `categories/` with one Markdown file per persona and workflow. Every workflow answers to at least three names: `<id>`, `bmad-<id>` and `bmad-plus-<id>`, so `bmad-plus-validate-prd` and `validate-prd` reach the same procedure.

<a id="personas"></a>
### The six personas

**Personas and the workflows each one owns**

| Persona | Role | Owns |
| --- | --- | --- |
| 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` |

A persona is a set of instructions, not a running process. Choose the role you need for the task; Core’s Atlas, Forge, Sentinel and Nexus can coexist with these six.

<a id="catalogue"></a>
### The 38 workflows by phase

The Input column tells what a workflow needs. A request workflow needs your request or a file. An artifact workflow needs at least one existing file, for example the PRD to validate. A project workflow needs a request or a file and works on the project. The bmad-help workflow needs nothing. Missing context is reported as needing input rather than guessed.

<a id="phase-analysis"></a>
### Analysis (6)

**Analysis workflows**

| Workflow | Persona | Input | Expected result |
| --- | --- | --- | --- |
| `product-brief` | Miriam | request | Product problem, audience and first useful scope |
| `prfaq` | Miriam | request | Proposed launch narrative and the questions that challenge it |
| `document-project` | Huldah | project | Documentation grounded in inspected project files |
| `market-research` | Miriam | request | Sourced market and alternative analysis |
| `domain-research` | Miriam | request | Domain concepts, constraints and evidence gaps |
| `technical-research` | Miriam | request | Feasibility options and a concrete next check |

<a id="phase-planning"></a>
### Planning (5)

**Planning workflows**

| Workflow | Persona | Input | Expected result |
| --- | --- | --- | --- |
| `create-prd` | Yosef | request | Testable requirements and scope |
| `prd` | Yosef | request | Choice between PRD creation, editing and validation |
| `edit-prd` | Yosef | artifact | Traceable requirements changes |
| `validate-prd` | Yosef | artifact | Evidence-based requirements findings |
| `create-ux-design` | Rachel | request | User flows, interaction states and acceptance checks |

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

**Architecture workflows**

| Workflow | Persona | Input | Expected result |
| --- | --- | --- | --- |
| `create-architecture` | Bezalel | request | Technical decisions, boundaries and trade-offs |
| `create-epics-stories` | Bezalel | artifact | Deliverable increments and implementable stories |
| `implementation-readiness` | Bezalel | artifact | Alignment gaps and readiness evidence |
| `generate-project-context` | Bezalel | project | Current project constraints with provenance |

<a id="phase-implementation"></a>
### Implementation (11)

**Implementation workflows**

| Workflow | Persona | Input | Expected result |
| --- | --- | --- | --- |
| `sprint-planning` | Oholiab | artifact | Scoped work, dependencies and capacity assumptions |
| `create-story` | Oholiab | artifact | A story with context and acceptance criteria |
| `dev-story` | Oholiab | artifact | Implementation and verification against a story |
| `code-review` | Oholiab | project | Substantiated findings or a scoped zero-finding report |
| `quick-dev` | Oholiab | project | A bounded change with proportionate checks |
| `sprint-status` | Oholiab | project | Progress and blockers supported by current evidence |
| `retrospective` | Oholiab | artifact | Lessons and actionable process changes |
| `correct-course` | Oholiab | project | A reasoned response to a material change |
| `investigate` | Oholiab | project | Hypotheses, reproduction evidence and next action |
| `checkpoint-preview` | Oholiab | project | A reviewable explanation of a change |
| `qa-e2e-tests` | Oholiab | project | Relevant automated checks and actual run evidence |

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

**Utility workflows**

| Workflow | Persona | Input | Expected result |
| --- | --- | --- | --- |
| `distillator` | Huldah | artifact | A compact brief with sources and disclosed omissions |
| `party-mode` | Miriam | request | Compared perspectives and a decision record |
| `brainstorming` | Miriam | request | Distinct options and a small experiment |
| `adversarial-review` | Yosef | artifact | Supported objections, refutations and open questions |
| `edge-case-hunter` | Bezalel | request | Concrete boundary and failure scenarios |
| `editorial-review-prose` | Huldah | artifact | Precise wording improvements |
| `editorial-review-structure` | Huldah | artifact | A reader-oriented outline and section mapping |
| `advanced-elicitation` | Miriam | request | Resolved uncertainties and testable requirements |
| `shard-doc` | Huldah | artifact | Linked sections with source coverage checks |
| `index-docs` | Huldah | project | An index of inspected documents |
| `bmad-help` | Miriam | none | Relevant routes and a justified next step |
| `customize` | Oholiab | project | Verified configuration or explicit instruction changes |

<a id="quick-start"></a>
## Quick start

1. **Install the pack** Core is added automatically; naming it as well is harmless. Only Node.js 20 is needed.

   ```sh
   npx bmad-plus install --packs core,dev-studio
   ```
2. **Ask a persona to run a workflow** Name the persona and the workflow id.

   ```sh
   Miriam, use product-brief to define a small issue triage tool for our support team.
   ```
3. **Optionally list the catalogue from the terminal** The CLI lists every workflow with its persona and input kind and changes nothing.

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

<a id="examples"></a>
## Copyable examples

<a id="example-dev-studio-product-brief"></a>
### Miriam: define a product with product-brief

Use it at the very start of an idea. Input kind: request.

**In your AI assistant**

```text
Miriam, use product-brief to define an inspection checklist app for our field technicians. They often work in basements with no network, so say what that implies for the first scope.
```

**What you should get** A report with the product problem, the audience and the first useful scope, written to `_bmad-output/dev-studio/product-brief.md` by default.

<a id="example-dev-studio-document-project"></a>
### Huldah: document an existing project

Use it when a codebase has no usable documentation. Input kind: project.

**In your AI assistant**

```text
Huldah, run document-project on this repo. Document only what you can ground in files you actually opened, and list what you could not verify.
```

**What you should get** Documentation grounded in inspected project files, with unverified points disclosed, saved as `_bmad-output/dev-studio/document-project.md` unless you set another output folder.

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

Use it before architecture starts. Input kind: artifact, so the file is required.

**In your AI assistant**

```text
Yosef, validate-prd on docs/prd.md.
```

**What you should get** Evidence-based findings on the requirements, each tied to what the file actually says, in `_bmad-output/dev-studio/validate-prd.md`. If the file is missing, the workflow reports that it needs input.

<a id="example-dev-studio-ux-design"></a>
### Rachel: design the flows of an onboarding

Use it before the visual layer. If the Design pack is installed, Atelier owns the visual and accessibility rules and Rachel’s flows feed its intake.

**In your AI assistant**

```text
Rachel, create-ux-design for the onboarding of new users: from account creation to their first saved invoice. Cover empty, error and offline states.
```

**What you should get** User flows, interaction states and acceptance checks in `_bmad-output/dev-studio/create-ux-design.md`.

<a id="example-dev-studio-architecture"></a>
### Bezalel: design the architecture

Use it once the requirements are settled. The workflow is stepwise and can resume from an earlier report.

**In your AI assistant**

```text
Bezalel, design the architecture for the appointment-booking app described in docs/prd.md. Record each decision with its alternatives and trade-offs.
```

**What you should get** Technical decisions, boundaries and trade-offs, recorded in `_bmad-output/dev-studio/create-architecture.md` with the architecture decision template. Follow with `create-epics-stories` and `implementation-readiness` to check that the plan hangs together.

<a id="example-dev-studio-investigate"></a>
### Oholiab: reproduce a failure before fixing it

Use it for failures whose cause is unclear. Input kind: project, with the description as the request or a file.

**In your AI assistant**

```text
Oholiab, use investigate to reproduce the failing import described in docs/issue.md.
```

**What you should get** Hypotheses, reproduction evidence and the next action, in `_bmad-output/dev-studio/investigate.md`. Only then does a fix make sense, for example with `quick-dev`.

<a id="example-dev-studio-prepare-cli"></a>
### Prepare a read-only context bundle from the terminal

Use it to see exactly what a workflow will be given. It prepares, it does not execute: your assistant still does the work.

**In your AI assistant**

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

**What you should get** A read-only bundle: the resolved configuration, the shipped instruction texts with their SHA-256 hashes, the contents and hashes of the input files, and the proposed report path. Input files must exist inside the project and `--input` can be repeated. If a required input is not supplied (no `--input` for an artifact workflow) the command exits with code 2 and the status needs-input, while an `--input` path that does not exist is an error (exit code 1); it never writes the deliverable, runs tests or certifies that a model followed the workflow.

<a id="example-dev-studio-help"></a>
### Ask which workflow fits

Use it when you know the goal but not the workflow name. bmad-help needs no input.

**In your AI assistant**

```text
Miriam, run bmad-help: I have a half-written PRD and a deadline. Which Dev Studio workflows should I run, in which order, and which can I skip?
```

**What you should get** Relevant routes and a justified next step. For a half-written PRD that usually means finishing the requirements first (`prd` or `edit-prd`), then `validate-prd`, then `create-architecture`. Workflow ids in the answer are suggestions, not automatic triggers.

<a id="outputs"></a>
## What it writes and where

Reports default to `_bmad-output/dev-studio/<workflow-id>.md`, adjusted to the configured output folder. Code changes stay in the real project. A report records scope, inputs, decisions, completed work, checks, open questions and the next action. On resume the workflow reads the previous report and revalidates inputs that changed. A report is never permission to overwrite your changes or to repeat a publication.

**Settings read from _bmad/config.yaml (every key has a default; project_name falls back to the folder name, here demo-app)**

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

```

A missing file is valid. A malformed file, or an invalid known field, is an error. `project_name` defaults to the folder name. Your current request and your host’s instructions take precedence over language preferences in the configuration.

<a id="data-and-prerequisites"></a>
## Data flows and prerequisites

Node.js 20 for the installer and the optional `studio` command. No Python, no key, and no flow of its own that leaves your machine: `studio list` and `studio prepare` read local files only. What your assistant sends to its model is up to your host tool. Research workflows need accessible sources to support current factual claims, and say so when they have none.

<a id="limits"></a>
## Limits and gotchas

> **Warning · A role, not a scheduler** The orchestrator is an instruction role. It sends no notification, makes no commit and publishes nothing by itself. Independent parallel agents, browsing and command execution depend on your host; when one assistant plays several perspectives it must say so, and unavailable checks stay visible. No workflow guarantees defect-free code or a lossless summary.

> **Note · No BWML interpreter** Older XML-style workflow notation (BWML) and TOML customisation have no interpreter or resolver in this pack. A migration note in the pack describes the supported replacement behaviour: plain Markdown procedures, the catalogue and `_bmad/config.yaml`.

> **Tip · Overlap with Core and Design** Dev Studio overlaps with Atlas, Forge, Sentinel and Nexus; both can coexist, so pick the persona whose workflow you want. For screens, one of Rachel or Atelier owns a given screen and the handoff says which.

> **Note · Provenance** Dev Studio is an original pack written by Laurent Rochetta: six specialised SDLC agents and 38 workflows, written as original BMAD+ instructions. The persona names and the workflow lineage acknowledge BMAD-METHOD by BMad Code, LLC (MIT licence, baseline v6.6.0); no upstream runtime is bundled.

**See also**

- [All ten packs side by side](https://bmad-plus.rochetta.fr/docs/packs/packs-overview/)
- [Core pack](https://bmad-plus.rochetta.fr/docs/packs/core/)
- [Design pack (Atelier)](https://bmad-plus.rochetta.fr/docs/packs/design/)
- [studio command reference](https://bmad-plus.rochetta.fr/docs/reference/cli-studio/)
- [Roster of all 48 agents](https://bmad-plus.rochetta.fr/docs/agents/agents-roster/)

[BMAD+ documentation](https://bmad-plus.rochetta.fr/docs/) · [Packs](https://bmad-plus.rochetta.fr/docs/packs/)

[Source on GitHub](https://github.com/lrochetta/BMAD-PLUS)