# Le registre et les compétences

> registry.yaml, source unique de vérité : champs d’un pack, uses_skills, external_module, pipelines, intake, les contrôles, le généré, et comment une équipe ajoute un agent ou un pack avec Maker.

Canonical: https://bmad-plus.rochetta.fr/fr/docs/concepts/registry-and-skills/
Language: fr
BMAD+ version: 0.23.1
Documentation reviewed: 2026-10-19
Author: Laurent Rochetta
License: MIT

Documentation BMAD+ › [Concepts](https://bmad-plus.rochetta.fr/fr/docs/concepts/) › Le registre et les compétences

Derrière chaque liste, chaque nombre et chaque fichier d’instructions généré de BMAD+, il y a un seul fichier : `registry.yaml`, à la racine du dépôt source de BMAD+. Il déclare les packs, leurs agents, compétences, fichiers de données, disposition d’installation, runtimes et étiquettes de conformité, les adaptateurs, la doctrine de traitement des données et plus encore. Tout ce qui en aval est généré à partir de lui : une liste, un nombre ou un adaptateur ne peut donc pas s’écarter des déclarations. Cette page s’adresse à qui veut comprendre ce contrat, lire les fichiers générés en confiance, ou étendre BMAD+ dans un fork ou une distribution d’équipe.

> **Remarque · Un fichier du dépôt source** Le paquet npm livre les résultats générés (les définitions de packs dans la CLI, `module.yaml`, les adaptateurs) et les scripts de génération `tools/build/generate.js`, `generate-adapters.js` et `intake-contract.js`, mais pas `registry.yaml` lui-même. Un projet installé ne contient donc jamais le registre ; il contient `AGENTS.md`, `_bmad/module.yaml` et les compétences. Pour changer le registre, on travaille dans un clone du dépôt BMAD+.

<a id="what-it-declares"></a>
## Ce que déclare le registre

**Sections de premier niveau de registry.yaml**

| Section | Contenu |
| --- | --- |
| `product` | Nom de code, nom d’affichage, version (contrôlée par rapport à `package.json`), version de BMAD-METHOD dont il dérive, obligation de conserver ou non la mention amont. |
| `targets` | Le fichier socle, le contrat d’intégration (`execution: host-managed`, `lifecycle_events: not-integrated`), le backend de processus facultatif (`command`, `codex-exec`, superviseur au premier plan, pas de planification), les sept adaptateurs et les familles de modèles prises en charge (`claude`, `gpt`, `gemini`, `local`). |
| `runtimes` | Node.js 20 ou plus récent ; Python 3.11 ou plus récent avec `uv` et un repli `pipx` pour le provisionnement à la demande. |
| `memory` | Les portées de mémoire (fichiers de projet, portefeuille) et les quatre garde-fous. |
| `eval` | Les portes d’évaluation (rejeu sur les pull requests ; exécutions avec l’hôte natif pour les changements de modèle). |
| `data_handling` | La doctrine derrière la page de traitement des données : chaque flux qui peut quitter la machine, avec sa base de consentement. |
| `packs` | Les dix packs et tout ce que contient le tableau suivant. |

**Champs d’un pack**

| Champ | Ce qu’il déclare |
| --- | --- |
| `order`, `display_name`, `cli`, `summary` | Ordre d’installation et d’affichage, noms, chaînes exactes affichées par l’installateur. Les nombres d’un résumé sont dérivés par des marqueurs : le générateur refuse un nombre d’agents, de compétences, de workflows ou de packs saisi à la main dans ces champs. |
| `required`, `runtime` | Core vaut `required: true`. Les runtimes dont un pack a besoin (`node`, et `python` pour SEO). |
| `agents`, `personas` | Les ids d’agents que l’installateur enregistre, et la persona visible de chacun (nom, rôle, description). |
| `skills`, `data` | Les dossiers de compétences et fichiers de données que le pack installe. |
| `install_layout`, `pack_dir`, `doctor` | `loose` copie des dossiers d’agents dans `.agents/skills/` ; `packaged` copie un dossier de pack (`pack-<name>`) qui contient ses agents. `doctor` liste les fichiers d’agents et les ressources requises que `bmad-plus doctor` contrôle. |
| `uses_skills` | Les ids de compétences qu’un pack ou une persona pilote (voir plus bas). |
| `external_module` | Des compétences prises dans un paquet npm épinglé (voir plus bas). |
| `pipelines` | Des étapes ordonnées avec une porte chacune (voir plus bas). |
| `intake` | Le fichier de questionnaire du pack (voir la page intake). |
| `governance`, `required_keys`, `optional_keys` | Pour OSINT : la porte de base légale et ses gabarits, et les clés d’API. |
| `cohabitation_warning` | Une phrase sur le recoupement du pack avec un autre. Elle est affichée par l’installateur et rendue en `- Cohabitation (<pack>): ...` sous les faits du registre du socle et des adaptateurs. |
| `compliance_tags` | Les référentiels auxquels un pack se rapporte (par exemple GDPR et EU-AI-Act pour OSINT). |

<a id="uses-skills"></a>
## uses_skills : ce qu’un agent pilote

Un pack ou une persona liste les ids de compétences qu’il pilote. Le générateur résout chaque id : ce doit être une compétence de n’importe quel pack, d’un `external_module` ou de Core, et un id que personne ne livre fait échouer le build. La liste du socle affiche alors `- drives: design, design-review, redesign` après la persona, et les instructions générées disent à l’agent de lire le `SKILL.md` de chaque compétence listée avant d’agir. Voici la déclaration réelle de la persona du pack Design.

**registry.yaml, pack design (extrait)**

```yaml
  design:
    order: 9
    display_name: "Design"
    required: false
    runtime: [node]
    agents: [design-engine]
    personas:
      - { id: design-engine, name: Atelier, role: Design Engine, description: "Senior product designer and design engineer: surfaces, tokens, accessibility, audits, redesigns", uses_skills: [design, design-review, redesign] }
    skills: []
    external_module: { package: design-skill, version: "0.2.1", skills: [design, design-review, redesign] }
    pack_dir: pack-design
    install_layout: packaged
    doctor:
      pack_agents: [design-engine.md]
      required_resources: [SKILL.md]
    intake: intake.yaml
    cohabitation_warning: "Overlaps Sentinel's UX-review role and Dev Studio's Rachel (UX Designer); ..."
```

<a id="external-module"></a>
## external_module : des compétences venues d’un paquet npm

Un pack peut prendre ses compétences dans un paquet publié plutôt que dans l’arbre de BMAD+. Le pack Design est le premier : ses trois compétences viennent de `design-skill`, épinglé à la version exacte `0.2.1`. Le paquet est une dépendance exacte de BMAD+ et figure dans la doctrine de traitement des données. À la construction, le générateur résout le paquet, vérifie que sa version égale celle qui est déclarée et que `skills/<id>/SKILL.md` existe pour chaque compétence listée. À l’installation, BMAD+ résout le paquet depuis sa propre installation, refuse une version différente et ne copie que le dossier `skills/` du paquet dans `.agents/skills/<id>/`, par la même copie gérée et inventoriée par hash que tout autre fichier (aucun lien symbolique n’est suivi). Le tarball livre aussi un outil en ligne de commande de liaison que BMAD+ n’exécute jamais. `bmad-plus doctor` exige les trois `SKILL.md` ; la désinstallation retire les compétences copiées avec le reste des fichiers gérés.

<a id="pipelines"></a>
## pipelines : des étapes ordonnées avec une porte

Un pack peut déclarer des pipelines : un enchaînement ordonné de ses propres workflows ou agents, chaque étape avec une porte (`require_approval`, `notify_only` ou `auto`). Nexus déroule un pipeline déclaré étape par étape avec le comportement de point de contrôle configuré, après l’intake du pack. Les ids de pipeline doivent être uniques dans le pack et chaque étape nomme exactement un `workflow` ou un `agent` existant dans le pack. Aucun pack ne déclare de pipeline en 0.23.0 : le champ existe, est validé et compris par autopilot, et sert aux packs qui en ont besoin. L’exemple est le format de la spécification, pas un contenu livré.

**Format d’un pipeline, d’après la spécification docs/specs/core-orchestration.md (un fichier du dépôt source, non livré dans le paquet npm)**

```yaml
pipelines:
  - id: full-build
    title: From interview to private preview
    steps:
      - { workflow: discovery, gate: require_approval }
      - { workflow: positioning, gate: require_approval }
      - { agent: brandsite-art, gate: notify_only }
      - { workflow: preview, gate: require_approval }
```

<a id="triggers"></a>
## Des déclencheurs qui doivent viser des choses réelles

`.agents/data/role-triggers.yaml` pilote le changement de rôle. Le contrôle `npm run check:triggers` (dans le dépôt source) le valide par rapport au registre : une clé de premier niveau doit être un nom court d’agent Core (`strategist`, `architect-dev`, `quality`, `orchestrator`) ou un id de pack ; `default_role` doit être l’un des `auto_triggers` de la clé ; chaque rôle a une liste non vide de `patterns` ; `contexts` et `reasoning`, quand ils existent, sont des listes d’identifiants en `snake_case` ; sous une clé de pack, chaque id de rôle est un id de persona ou de pipeline de ce pack ; et un motif exact répété dans deux rôles de la même clé est une erreur. Trois contextes de Core renvoient aux fonctions de cette page : `swarm_declared` et `panel_requested` (Parallel Supervisor), et `pack_pipeline_declared` (autopilot).

<a id="generated"></a>
## Ce qui est généré, et les contrôles qui le gardent honnête

**Commandes dans une copie de travail source de BMAD+**

| Commande | Ce qu’elle fait |
| --- | --- |
| `npm run build` | Exécute `tools/build/generate.js` et écrit les définitions de packs dans `tools/cli/lib/packs.js` et `src/bmad-plus/module.yaml` à partir du registre. |
| `npm run build:check` | Échoue quand le registre ne reproduit plus ces deux fichiers, quand `product.version` diffère de `package.json`, ou quand un chemin, une compétence, un module externe ou un intake déclaré est faux. |
| `node tools/build/generate-adapters.js --adopt` | Régénère `AGENTS.md` et les fichiers d’adaptateurs (CLAUDE.md, GEMINI.md, règles .cursor, fichiers .codex et .opencode, CONVENTIONS.md). `--check` les vérifie sans écrire. |
| `npm run check:counts` | Parcourt les surfaces livrées à la recherche de nombres saisis à la main (« N agents », « N workflows », « N packs ») et échoue sur tout nombre qui contredit ce que le registre et les fichiers établissent. Un nombre est contrôlé par rapport à son sujet : 38 est juste pour les workflows de Dev Studio et faux pour des agents. |
| `npm run check:triggers` | Valide les déclencheurs de rôle comme décrit plus haut. |

<a id="skills-anatomy"></a>
## Ce qu’est une compétence

Une compétence est un dossier avec un `SKILL.md` : un en-tête avec un `name` et une `description` (qui dit quand l’utiliser, avec des mots que votre assistant peut reconnaître), puis la procédure. Les contenus plus longs sont dans un dossier `ref/` à côté, les gabarits dans `templates/`. Chaque agent est aussi une compétence : `agent-strategist/SKILL.md` est Atlas. L’hôte charge le `SKILL.md` dont il a besoin, d’où l’importance de la description : c’est elle qui fait qu’un assistant choisit la compétence. Les six compétences Core ci-dessous sont livrées avec chaque installation.

**Les compétences Core**

| Compétence | Ce qu’elle fait | Pilotée par |
| --- | --- | --- |
| `bmad-plus-autopilot` | Nexus déroule Discovery, Build et Ship avec points de contrôle ; intake de chaque pack concerné d’abord. | Nexus (AP) |
| `bmad-plus-parallel` | Détecte les tâches indépendantes, les supervise (lancer, suivre, mettre en pause, relancer, réallouer, escalader) ; contient la section sur les essaims. | Nexus (PL) |
| `bmad-plus-swarm` | Protocole de modérateur pour les essaims panel, jury et fanout sous budget. | Nexus Parallel Supervisor |
| `bmad-plus-intake` | Protocole de `bmad-plus intake` : planifier, poser quelques questions, enregistrer, rédiger. | Tout pack avec un intake ; autopilot |
| `bmad-plus-uat` | Recette humaine : écrire la spec, construire la page, lire, trier, passer la porte. | Sentinel (RB, RR, RG) ; autopilot |
| `bmad-plus-sync` | Protocole de vérification du framework installé une fois par session ; pour les mainteneurs, des dossiers pour examiner les changements amont (aucune fusion amont automatique). | Tout le monde ; mainteneurs |

D’autres compétences viennent avec leurs packs : `dev-studio` (le répartiteur du pack), les compétences `design`, `design-review` et `redesign` copiées depuis `design-skill`, les compétences `bmad-osint-investigate` et `bmad-osint-investigator` du paquet OSINT. Les packs SEO et Design portent aussi un `SKILL.md` de routage qui réagit quand vous écrivez `/seo` ou `/design` dans un message ; ce sont des mots-clés de demande, pas des commandes slash enregistrées par votre client.

<a id="extend-with-maker"></a>
## Ajouter un agent ou un pack avec Maker

Maker est l’Agent Creator du pack Maker. Il conçoit un agent avec vous en quatre phases (découverte, conception avec votre validation, génération, validation) et écrit un paquet sous `_bmad-output/ready-to-integrate/`. Ses capacités : `CA` créer un agent, `QA` agent rapide avec moins de questions, `EA` modifier sur place le `SKILL.md` d’un agent existant (sans passer par ce dossier), `VA` valider un paquet d’agent (format, manifeste, codes de capacité uniques, qualité des déclencheurs), `PA` empaqueter pour l’intégration, `TP` afficher le gabarit.

**Ce que Maker écrit**

| Fichier | Contenu |
| --- | --- |
| `agents/agent-<name>/SKILL.md` | L’agent : vue d’ensemble, identité, style de communication, principes, tableau de capacités avec codes de deux lettres, étapes d’activation. |
| `agents/agent-<name>/bmad-skill-manifest.yaml` | Nom, nom d’affichage, titre, icône, capacités, rôle, identité, pack, id canonique. |
| `pack-definition.yaml` | Un extrait prêt à fusionner pour la table `packs:` de `registry.yaml` (ordre, nom d’affichage, icône, entrée CLI, runtime, résumé, agents, personas, compétences, disposition d’installation, étiquettes de conformité, clés requises). |
| `INTEGRATION.md` | Instructions d’intégration : fichiers à copier, entrée de registre à ajouter, ligne de l’index d’aide, séquence de régénération et de contrôle, installation d’essai. |

> **Remarque · La note d’intégration de Maker suit le registre** Le `INTEGRATION.md` que Maker écrit passe d’abord par le registre : il demande d’ajouter l’entrée de `pack-definition.yaml` sous `packs:` dans `registry.yaml`, de ne jamais modifier les fichiers qui en sont générés (`tools/cli/lib/packs.js`, les métadonnées de pack de `src/bmad-plus/module.yaml`, `AGENTS.md` et les autres adaptateurs), d’ajouter à la main une ligne à `src/bmad-plus/module-help.csv`, de régénérer, puis de lancer les contrôles de dérive. Les étapes ci-dessous suivent la même séquence.

1. **Créer et valider l’agent** Demandez `CA` à Maker, répondez à ses questions de découverte, validez le tableau de conception, puis lancez `VA` sur le résultat.
2. **Le copier dans un clone du dépôt** Placez le dossier de l’agent sous `src/bmad-plus/agents/` (agent « loose ») ou dans un dossier de pack (pack « packaged »).
3. **Le déclarer dans registry.yaml** Ajoutez ou étendez un pack : `agents`, `personas` (avec `uses_skills` s’il pilote des compétences), `skills`, `install_layout`, `doctor`, et si besoin `intake`, `pipelines`, `cohabitation_warning`. Ajoutez des déclencheurs de rôle dans `role-triggers.yaml` sous l’id du pack si vous voulez l’activation automatique.
4. **Régénérer et contrôler** Lancez `npm run build`, `node tools/build/generate-adapters.js --adopt`, puis `npm run build:check`, `npm run check:counts` et `npm run check:triggers`. Chaque échec nomme le champ à corriger.
5. **L’installer dans un projet jetable** Lancez l’installateur depuis votre clone avec `--packs core,<your-pack>` puis `doctor` : il ne doit signaler aucune erreur. Le contrat d’installation du dépôt (`npm run test:install-contract`) vérifie la même chose pour chaque pack.

Dans un projet installé, sans clone, vous pouvez quand même placer vos propres dossiers de compétences sous `.agents/skills/`. BMAD+ traite les fichiers qu’il n’a pas installés comme les vôtres : `bmad-plus doctor` les signale comme non possédés (un avertissement, pas une erreur), et la mise à jour comme la désinstallation les laissent en place. Ils ne sont pas inscrits dans la liste des agents, donc le socle ne les mentionne pas ; ajoutez une ligne à votre propre fichier d’instructions ou à l’adaptateur si vous voulez que l’assistant les trouve.

<a id="example-registry-ask-maker-agent"></a>
### Concevoir un agent d’équipe avec Maker

À utiliser avec le pack Maker installé. Le paquet est écrit dans `_bmad-output/ready-to-integrate/` ; rien d’autre n’est modifié.

**Dans votre assistant IA**

```text
Maker, crée un agent de support client pour notre équipe : il trie les tickets entrants, rédige des réponses dans notre ton et escalade à un humain tout ce qui touche à la facturation. Pose-moi tes questions de découverte en un seul lot, montre-moi le tableau de conception (nom, rôles, capacités avec codes de deux lettres, déclencheurs, dépendances) et attends ma validation avant de générer. Puis valide le paquet et dis-moi ce qu’il reste à déclarer dans le registre.
```

**Ce que vous devriez obtenir** Un lot de questions, un aperçu de conception que vous approuvez, puis `_bmad-output/ready-to-integrate/` avec le `SKILL.md` de l’agent, son manifeste, un extrait de pack et une note d’intégration, suivis de la liste de validation (format, champs du manifeste, codes de capacité uniques, qualité des déclencheurs). Rien n’est installé ni enregistré tant que vous ne le faites pas.

**Voir aussi**

- [Comment fonctionne BMAD+](https://bmad-plus.rochetta.fr/fr/docs/concepts/how-bmad-plus-works/)
- [Intake : demander d’abord](https://bmad-plus.rochetta.fr/fr/docs/concepts/intake/)
- [Le pack Maker](https://bmad-plus.rochetta.fr/fr/docs/packs/maker/)
- [Le pack Design](https://bmad-plus.rochetta.fr/fr/docs/packs/design/)
- [Référence : adaptateurs](https://bmad-plus.rochetta.fr/fr/docs/reference/adapters/)
- [Traitement des données](https://bmad-plus.rochetta.fr/fr/docs/security/data-handling/)

[Documentation BMAD+](https://bmad-plus.rochetta.fr/fr/docs/) · [Concepts](https://bmad-plus.rochetta.fr/fr/docs/concepts/)

[Code sur GitHub](https://github.com/lrochetta/BMAD-PLUS)