Dev Studio couvre le cycle de vie logiciel avec six personas et 38 workflows nommés, du brief produit à la revue de code. Installation, catalogue par phase, huit exemples, CLI studio, limites.
Dev Studio vous donne une équipe logicielle complète sous forme de procédures écrites. Six personas, chacune avec un rôle, exécutent 38 workflows nommés répartis en cinq phases : analyse, planification, architecture, implémentation et utilitaires. Vous nommez la persona ou le workflow, et votre outil de codage IA lit les instructions et les exécute avec ses propres outils. C’est le pack à choisir quand vous voulez une procédure précise et reproductible (valider un PRD, écrire une architecture, enquêter sur une défaillance) plutôt qu’une conversation libre.
Dev Studio est un pack empaqueté dans .agents/skills/pack-dev-studio/, plus la compétence de dispatch dev-studio dans .agents/skills/dev-studio/. Le pack contient l’orchestrateur dev-studio-orchestrator.md, le shared/catalog.json lisible par machine (personas, workflows, alias, types d’entrée, ressources requises), le guide d’exécution shared/execution.md, un README et categories/ avec un fichier Markdown par persona et par workflow. Chaque workflow répond à au moins trois noms : <id>, bmad-<id> et bmad-plus-<id>, si bien que bmad-plus-validate-prd et validate-prd mènent à la même procédure.
Une persona est un ensemble d’instructions, pas un processus en cours d’exécution. Choisissez le rôle dont la tâche a besoin ; Atlas, Forge, Sentinel et Nexus de Core peuvent coexister avec ces six personas.
La colonne Entrée dit ce dont un workflow a besoin. Un workflow de type demande attend votre demande ou un fichier. Un workflow de type artefact attend au moins un fichier existant, par exemple le PRD à valider. Un workflow de type projet attend une demande ou un fichier et travaille sur le projet. Le workflow bmad-help n’attend rien. Un contexte manquant est signalé comme besoin d’entrée, pas deviné.
À utiliser tout au début d’une idée. Type d’entrée : demande.
Dans votre assistant IA
Miriam, utilise product-brief pour définir une application de listes de contrôle d’inspection pour nos techniciens de terrain. Ils travaillent souvent en sous-sol sans réseau : dis ce que cela implique pour le premier périmètre.
Ce que vous devriez obtenir Un rapport avec le problème produit, le public et le premier périmètre utile, écrit par défaut dans _bmad-output/dev-studio/product-brief.md.
À utiliser quand un code n’a pas de documentation exploitable. Type d’entrée : projet.
Dans votre assistant IA
Huldah, lance document-project sur ce dépôt. Documente seulement ce que tu peux fonder sur des fichiers réellement ouverts et liste ce que tu n’as pas pu vérifier.
Ce que vous devriez obtenir Une documentation fondée sur des fichiers de projet inspectés, avec les points non vérifiés signalés, enregistrée dans _bmad-output/dev-studio/document-project.md sauf autre dossier de sortie.
À utiliser avant le début de l’architecture. Type d’entrée : artefact, le fichier est donc obligatoire.
Dans votre assistant IA
Yosef, lance validate-prd sur docs/prd.md.
Ce que vous devriez obtenir Des constats sur les exigences fondés sur des preuves, chacun relié à ce que le fichier dit réellement, dans _bmad-output/dev-studio/validate-prd.md. Si le fichier manque, le workflow indique qu’il a besoin d’une entrée.
À utiliser avant la couche visuelle. Si le pack Design est installé, Atelier gère les règles visuelles et d’accessibilité et les parcours de Rachel alimentent son intake.
Dans votre assistant IA
Rachel, lance create-ux-design pour l’onboarding des nouveaux utilisateurs : de la création du compte à leur première facture enregistrée. Couvre les états vide, erreur et hors ligne.
Ce que vous devriez obtenir Des parcours utilisateur, des états d’interaction et des contrôles d’acceptation dans _bmad-output/dev-studio/create-ux-design.md.
À utiliser une fois les exigences arrêtées. Le workflow procède par étapes et peut reprendre à partir d’un rapport antérieur.
Dans votre assistant IA
Bezalel, conçois l’architecture de l’application de prise de rendez-vous décrite dans docs/prd.md. Consigne chaque décision avec ses alternatives et ses compromis.
Ce que vous devriez obtenir Des décisions techniques, des frontières et des compromis, consignés dans _bmad-output/dev-studio/create-architecture.md avec le modèle de décision d’architecture. Enchaînez avec create-epics-stories et implementation-readiness pour vérifier la cohérence du plan.
Oholiab : reproduire une défaillance avant de la corriger#
À utiliser pour les défaillances dont la cause est floue. Type d’entrée : projet, avec la description en demande ou en fichier.
Dans votre assistant IA
Oholiab, utilise investigate pour reproduire l’import en échec décrit dans docs/issue.md.
Ce que vous devriez obtenir Des hypothèses, des preuves de reproduction et l’action suivante, dans _bmad-output/dev-studio/investigate.md. Ensuite seulement un correctif a du sens, par exemple avec quick-dev.
Préparer un lot de contexte en lecture seule depuis le terminal#
À utiliser pour voir exactement ce qu’un workflow recevra. Cela prépare, cela n’exécute pas : c’est toujours votre assistant qui travaille.
Dans votre assistant IA
npx bmad-plus studio prepare validate-prd --input docs/prd.md --json
Ce que vous devriez obtenir Un lot en lecture seule : la configuration résolue, les textes d’instructions livrés avec leurs empreintes SHA-256, le contenu et les empreintes des fichiers d’entrée, et le chemin de rapport proposé. Les fichiers d’entrée doivent exister dans le projet et --input peut être répété. Si une entrée requise n’est pas fournie (pas de --input pour un workflow de type artefact), la commande sort avec le code 2 et le statut needs-input, tandis qu’un chemin --input inexistant est une erreur (code de sortie 1) ; elle n’écrit jamais le livrable, ne lance pas de tests et ne certifie pas qu’un modèle a suivi le workflow.
À utiliser quand vous connaissez l’objectif mais pas le nom du workflow. bmad-help n’exige aucune entrée.
Dans votre assistant IA
Miriam, lance bmad-help : j’ai un PRD à moitié rédigé et une échéance. Quels workflows Dev Studio dois-je lancer, dans quel ordre, et lesquels puis-je sauter ?
Ce que vous devriez obtenir Les parcours pertinents et une prochaine étape justifiée. Pour un PRD à moitié rédigé, cela veut généralement dire terminer d’abord les exigences (prd ou edit-prd), puis validate-prd, puis create-architecture. Les identifiants de workflow dans la réponse sont des suggestions, pas des déclencheurs automatiques.
Les rapports vont par défaut dans _bmad-output/dev-studio/<workflow-id>.md, ajusté au dossier de sortie configuré. Les changements de code restent dans le vrai projet. Un rapport consigne le périmètre, les entrées, les décisions, le travail accompli, les contrôles, les questions ouvertes et l’action suivante. À la reprise, le workflow relit le rapport précédent et revalide les entrées qui ont changé. Un rapport n’autorise jamais à écraser vos changements ni à répéter une publication.
Réglages lus dans _bmad/config.yaml (chaque clé a une valeur par défaut ; project_name retombe sur le nom du dossier, ici demo-app)
user_name: user
communication_language: English
document_output_language: English
output_folder: _bmad-output
project_name: demo-app
Un fichier absent est valide. Un fichier mal formé, ou un champ connu invalide, est une erreur. project_name vaut par défaut le nom du dossier. Votre demande actuelle et les instructions de votre hôte priment sur les préférences de langue de la configuration.
Node.js 20 pour l’installateur et la commande facultative studio. Ni Python, ni clé, ni flux propre qui quitte votre machine : studio list et studio prepare ne lisent que des fichiers locaux. Ce que votre assistant envoie à son modèle dépend de votre outil hôte. Les workflows de recherche exigent des sources accessibles pour étayer les affirmations factuelles actuelles, et le disent quand ils n’en ont pas.
L’orchestrateur est un rôle d’instructions. Il n’envoie aucune notification, ne fait aucun commit et ne publie rien de lui-même. Les agents parallèles indépendants, la navigation et l’exécution de commandes dépendent de votre hôte ; quand un seul assistant joue plusieurs points de vue, il doit le dire, et les contrôles indisponibles restent visibles. Aucun workflow ne garantit un code sans défaut ni un résumé sans perte.
Remarque· Pas d’interpréteur BWML
L’ancienne notation de workflow de style XML (BWML) et la personnalisation TOML n’ont ni interpréteur ni résolveur dans ce pack. Une note de migration du pack décrit le comportement de remplacement pris en charge : des procédures Markdown simples, le catalogue et _bmad/config.yaml.
Astuce· Recoupement avec Core et Design
Dev Studio recoupe Atlas, Forge, Sentinel et Nexus ; les deux peuvent coexister, choisissez donc la persona dont vous voulez le workflow. Pour les écrans, soit Rachel soit Atelier a la charge d’un écran donné, et la passation dit lequel.
Remarque· Provenance
Dev Studio est un pack original écrit par Laurent Rochetta : six agents spécialisés du cycle de vie logiciel et 38 workflows, rédigés comme des instructions BMAD+ originales. Les noms de personas et la lignée des workflows reconnaissent BMAD-METHOD de BMad Code, LLC (licence MIT, base v6.6.0) ; aucun runtime amont n’est embarqué.