Browse the documentation

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.

On this page
  1. When to use it
  2. What is installed
  3. Quick start
  4. Copyable examples
  5. What it writes and where
  6. Data flows and prerequisites
  7. Limits and gotchas

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.

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.

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.

The six personas

Personas and the workflows each one owns
PersonaRoleOwns
Miriam (מרים)Business Analystproduct-brief, prfaq, market-research, domain-research, technical-research, party-mode, brainstorming, advanced-elicitation, bmad-help
Huldah (חולדה)Technical Writerdocument-project, distillator, editorial-review-prose, editorial-review-structure, shard-doc, index-docs
Yosef (יוסף)Product Managercreate-prd, prd, edit-prd, validate-prd, adversarial-review
Rachel (רחל)UX Designercreate-ux-design
Bezalel (בצלאל)System Architectcreate-architecture, create-epics-stories, implementation-readiness, generate-project-context, edge-case-hunter
Oholiab (אהליאב)Senior Engineersprint-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.

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.

Analysis (6)

Analysis workflows
WorkflowPersonaInputExpected result
product-briefMiriamrequestProduct problem, audience and first useful scope
prfaqMiriamrequestProposed launch narrative and the questions that challenge it
document-projectHuldahprojectDocumentation grounded in inspected project files
market-researchMiriamrequestSourced market and alternative analysis
domain-researchMiriamrequestDomain concepts, constraints and evidence gaps
technical-researchMiriamrequestFeasibility options and a concrete next check

Planning (5)

Planning workflows
WorkflowPersonaInputExpected result
create-prdYosefrequestTestable requirements and scope
prdYosefrequestChoice between PRD creation, editing and validation
edit-prdYosefartifactTraceable requirements changes
validate-prdYosefartifactEvidence-based requirements findings
create-ux-designRachelrequestUser flows, interaction states and acceptance checks

Architecture (4)

Architecture workflows
WorkflowPersonaInputExpected result
create-architectureBezalelrequestTechnical decisions, boundaries and trade-offs
create-epics-storiesBezalelartifactDeliverable increments and implementable stories
implementation-readinessBezalelartifactAlignment gaps and readiness evidence
generate-project-contextBezalelprojectCurrent project constraints with provenance

Implementation (11)

Implementation workflows
WorkflowPersonaInputExpected result
sprint-planningOholiabartifactScoped work, dependencies and capacity assumptions
create-storyOholiabartifactA story with context and acceptance criteria
dev-storyOholiabartifactImplementation and verification against a story
code-reviewOholiabprojectSubstantiated findings or a scoped zero-finding report
quick-devOholiabprojectA bounded change with proportionate checks
sprint-statusOholiabprojectProgress and blockers supported by current evidence
retrospectiveOholiabartifactLessons and actionable process changes
correct-courseOholiabprojectA reasoned response to a material change
investigateOholiabprojectHypotheses, reproduction evidence and next action
checkpoint-previewOholiabprojectA reviewable explanation of a change
qa-e2e-testsOholiabprojectRelevant automated checks and actual run evidence

Utilities (12)

Utility workflows
WorkflowPersonaInputExpected result
distillatorHuldahartifactA compact brief with sources and disclosed omissions
party-modeMiriamrequestCompared perspectives and a decision record
brainstormingMiriamrequestDistinct options and a small experiment
adversarial-reviewYosefartifactSupported objections, refutations and open questions
edge-case-hunterBezalelrequestConcrete boundary and failure scenarios
editorial-review-proseHuldahartifactPrecise wording improvements
editorial-review-structureHuldahartifactA reader-oriented outline and section mapping
advanced-elicitationMiriamrequestResolved uncertainties and testable requirements
shard-docHuldahartifactLinked sections with source coverage checks
index-docsHuldahprojectAn index of inspected documents
bmad-helpMiriamnoneRelevant routes and a justified next step
customizeOholiabprojectVerified configuration or explicit instruction changes

Quick start

  1. Install the pack

    Core is added automatically; naming it as well is harmless. Only Node.js 20 is needed.

    In your project terminal
    npx bmad-plus install --packs core,dev-studio

  2. Ask a persona to run a workflow

    Name the persona and the workflow id.

    In your project terminal
    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.

    In your project terminal
    npx bmad-plus studio list --json

Copyable examples

Miriam: define a product with product-brief

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

In your AI assistant
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.

Huldah: document an existing project

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

In your AI assistant
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.

Yosef: validate a PRD

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

In your AI assistant
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.

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
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.

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
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.

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
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.

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
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.

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
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.

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)
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.

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.

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