docs(fr): apply French typography and table formatting pass
Continuation of 27002100. Systematic pass across all French documentation
assisted by an automated French typography linter:
- Replace regular space with NBSP (U+00A0) before colons per French
typographic convention
- Align table separator rows to match column widths
- Fix thousands separator in install-bmad.md (5000 → 5 000)
- Correct glossary example code block rendering in _STYLE_GUIDE.md
This commit is contained in:
parent
30f1339671
commit
2d2b6b83a3
|
|
@ -50,7 +50,7 @@ Avertissements critiques uniquement — perte de données, problèmes de sécuri
|
|||
|
||||
## Formats de tableau standards
|
||||
|
||||
**Phases :**
|
||||
**Phases :**
|
||||
|
||||
```md
|
||||
| Phase | Nom | Ce qui se passe |
|
||||
|
|
@ -59,7 +59,7 @@ Avertissements critiques uniquement — perte de données, problèmes de sécuri
|
|||
| 2 | Planification | Exigences — PRD ou spécification technique *(requis)* |
|
||||
```
|
||||
|
||||
**Skills :**
|
||||
**Skills :**
|
||||
|
||||
```md
|
||||
| Skill | Agent | Objectif |
|
||||
|
|
@ -243,7 +243,7 @@ votre-projet/
|
|||
1. Titre + Accroche
|
||||
2. Éléments (## pour chaque élément)
|
||||
- Brève description (une phrase)
|
||||
- **Skills :** ou **Infos clés :** sous forme de liste simple
|
||||
- **Skills :** ou **Infos clés :** sous forme de liste simple
|
||||
3. Universel/Partagé (## section) (optionnel)
|
||||
```
|
||||
|
||||
|
|
@ -304,9 +304,9 @@ Starlight génère la navigation « Sur cette page » à droite à partir de
|
|||
### Format de tableau
|
||||
|
||||
|
||||
```md
|
||||
## Nom de catégorie
|
||||
|
||||
```md
|
||||
| Terme | Définition |
|
||||
|--------------|------------------------------------------------------------------------------------------------------------|
|
||||
| **Agent** | Personnalité IA spécialisée avec une expertise spécifique qui guide les utilisateurs dans les workflows. |
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ Une technique de revue où le réviseur *doit* trouver des problèmes. Pas de «
|
|||
|
||||
Il ne s’agit pas d’être négatif. Il s’agit de forcer une analyse authentique au lieu d’un coup d’œil superficiel qui valide automatiquement ce qui a été soumis.
|
||||
|
||||
**La règle fondamentale :** Il doit trouver des problèmes. Zéro constatation déclenche un arrêt - réanalyse ou explique pourquoi.
|
||||
**La règle fondamentale :** Il doit trouver des problèmes. Zéro constatation déclenche un arrêt - réanalyse ou explique pourquoi.
|
||||
|
||||
## Pourquoi Cela Fonctionne
|
||||
|
||||
|
|
@ -30,7 +30,7 @@ La revue contradictoire apparaît dans tous les workflows BMad - revue de code,
|
|||
|
||||
## Filtrage Humain Requis
|
||||
|
||||
Parce que l’IA est *instruite* de trouver des problèmes, elle trouvera des problèmes - même lorsqu’ils n’existent pas. Attendez-vous à des faux positifs : des détails présentés comme des problèmes, des malentendus sur l’intention, ou des préoccupations purement hallucinées[^3].
|
||||
Parce que l’IA est *instruite* de trouver des problèmes, elle trouvera des problèmes - même lorsqu’ils n’existent pas. Attendez-vous à des faux positifs : des détails présentés comme des problèmes, des malentendus sur l’intention, ou des préoccupations purement hallucinées[^3].
|
||||
|
||||
**C’est vous qui décidez ce qui est réel.** Examinez chaque constatation, ignorez le bruit, corrigez ce qui compte.
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ Libérez votre créativité grâce à une exploration guidée.
|
|||
|
||||
Lancez `bmad-brainstorming` et vous obtenez un facilitateur créatif qui fait émerger vos idées - pas qui les génère pour vous. L’IA agit comme coach et guide, utilisant des techniques éprouvées pour créer les conditions où votre meilleure réflexion émerge.
|
||||
|
||||
**Idéal pour :**
|
||||
**Idéal pour :**
|
||||
|
||||
- Surmonter les blocages créatifs
|
||||
- Générer des idées de produits ou de fonctionnalités
|
||||
|
|
|
|||
|
|
@ -31,12 +31,12 @@ BMad embarque six agents nommés, chacun ancré à une phase de la méthode BMad
|
|||
|
||||
| Agent | Phase | Module |
|
||||
|------------------------------------|----------------|-------------------------------------------------------------------------------------------------------------------------|
|
||||
| 📊 **Mary**, Analyste d’affaires | Analyse | étude de marché, brainstorming, product briefs, PRFAQs |
|
||||
| 📚 **Paige**, Rédactrice technique | Analyse | documentation de projet, diagrammes, validation de docs |
|
||||
| 📋 **John**, Chef de produit | Planification | création de PRD, décomposition epic/story, vérification de la préparation à l’implémentation |
|
||||
| 🎨 **Sally**, Designer UX | Planification | spécifications de design UX |
|
||||
| 🏗️ **Winston**, Architecte système | Solutioning | architecture technique, vérifications d’alignement |
|
||||
| 💻 **Amelia**, Ingénieure senior | Implémentation | exécution de stories, quick-dev, revue de code, planification de sprint, [enquête de code](./forensic-investigation.md) |
|
||||
| 📊 **Mary**, Analyste d’affaires | Analyse | étude de marché, brainstorming, product briefs, PRFAQs |
|
||||
| 📚 **Paige**, Rédactrice technique | Analyse | documentation de projet, diagrammes, validation de docs |
|
||||
| 📋 **John**, Chef de produit | Planification | création de PRD, décomposition epic/story, vérification de la préparation à l’implémentation |
|
||||
| 🎨 **Sally**, Designer UX | Planification | spécifications de design UX |
|
||||
| 🏗️ **Winston**, Architecte système | Solutioning | architecture technique, vérifications d’alignement |
|
||||
| 💻 **Amelia**, Ingénieure senior | Implémentation | exécution de stories, quick-dev, revue de code, planification de sprint, [enquête de code](./forensic-investigation.md) |
|
||||
|
||||
Chacun possède une identité codée en dur (nom, titre, domaine) et une couche personnalisable (rôle, principes, style de communication, icône, menu). Vous pouvez réécrire les principes de Mary ou ajouter des éléments de menu ; vous ne pouvez pas la renommer — c’est délibéré. La reconnaissance de marque persiste après personnalisation pour que « hey Mary » active toujours l’analyste, indépendamment de la façon dont une équipe a façonné son comportement.
|
||||
|
||||
|
|
|
|||
|
|
@ -24,35 +24,35 @@ La conversation continue aussi longtemps que vous le souhaitez. Posez des questi
|
|||
|
||||
### Remettre en question une mauvaise architecture
|
||||
|
||||
**Vous :** « Ok l’équipe, notre dernier sprint a été un désastre. Le service d’authentification est tombé trois fois. Qui a cafouillé ? »
|
||||
**Vous :** « Ok l’équipe, notre dernier sprint a été un désastre. Le service d’authentification est tombé trois fois. Qui a cafouillé ? »
|
||||
|
||||
**Architecte :** « Le design était solide - authentification distribuée avec des fallbacks appropriés. Si l’implémentation a dévié des specs... »
|
||||
**Architecte :** « Le design était solide - authentification distribuée avec des fallbacks appropriés. Si l’implémentation a dévié des specs... »
|
||||
|
||||
**Développeur :** « J’ai suivi le document d’architecture à la lettre. Les specs ne prenaient pas en compte les race conditions lors de l’invalidation de sessions concurrentes. »
|
||||
**Développeur :** « J’ai suivi le document d’architecture à la lettre. Les specs ne prenaient pas en compte les race conditions lors de l’invalidation de sessions concurrentes. »
|
||||
|
||||
**PM :** « Vous avez tous les deux raté le vrai problème - nous n’avons pas validé les exigences de gestion des sessions dans le PRD. C’est de ma faute de ne pas l’avoir repéré. »
|
||||
**PM :** « Vous avez tous les deux raté le vrai problème - nous n’avons pas validé les exigences de gestion des sessions dans le PRD. C’est de ma faute de ne pas l’avoir repéré. »
|
||||
|
||||
**TEA :** « Et j’aurais dû le repérer dans les tests d’intégration. Les scénarios de test ne couvraient pas l’invalidation concurrente. »
|
||||
**TEA :** « Et j’aurais dû le repérer dans les tests d’intégration. Les scénarios de test ne couvraient pas l’invalidation concurrente. »
|
||||
|
||||
### Brainstorming créatif
|
||||
|
||||
**Vous :** « Comment rendre l’onboarding magique au lieu d’ennuyeux ? »
|
||||
**Vous :** « Comment rendre l’onboarding magique au lieu d’ennuyeux ? »
|
||||
|
||||
**Designer UX :** « Commençons par la divulgation progressive - révélons les fonctionnalités au fur et à mesure que les utilisateurs en ont besoin, pas d’un coup dans un tutoriel. »
|
||||
**Designer UX :** « Commençons par la divulgation progressive - révélons les fonctionnalités au fur et à mesure que les utilisateurs en ont besoin, pas d’un coup dans un tutoriel. »
|
||||
|
||||
**Storyteller :** « Et si l’onboarding était une histoire ? Chaque étape révèle le parcours d’un personnage - l’utilisateur EST le héros. »
|
||||
**Storyteller :** « Et si l’onboarding était une histoire ? Chaque étape révèle le parcours d’un personnage - l’utilisateur EST le héros. »
|
||||
|
||||
**Game Designer :** « En partant de là - et si la première « quête » consistait à résoudre un vrai problème utilisateur ? Ils apprennent en faisant quelque chose d’utile. »
|
||||
**Game Designer :** « En partant de là - et si la première « quête » consistait à résoudre un vrai problème utilisateur ? Ils apprennent en faisant quelque chose d’utile. »
|
||||
|
||||
### Décision technique
|
||||
|
||||
**Vous :** « Monolithe ou microservices pour le MVP[^1] ? »
|
||||
**Vous :** « Monolithe ou microservices pour le MVP[^1] ? »
|
||||
|
||||
**Architecte :** « Commencez en monolithe. Les microservices ajoutent une complexité dont vous n’avez pas besoin à 1 000 utilisateurs. »
|
||||
**Architecte :** « Commencez en monolithe. Les microservices ajoutent une complexité dont vous n’avez pas besoin à 1 000 utilisateurs. »
|
||||
|
||||
**PM :** « D’accord. Le time-to-market[^2] compte plus que la scalabilité théorique. »
|
||||
**PM :** « D’accord. Le time-to-market[^2] compte plus que la scalabilité théorique. »
|
||||
|
||||
**Développeur :** « Monolithe avec des frontières de modules claires. On pourra extraire des services plus tard si nécessaire. »
|
||||
**Développeur :** « Monolithe avec des frontières de modules claires. On pourra extraire des services plus tard si nécessaire. »
|
||||
|
||||
:::tip[Meilleures décisions]
|
||||
De meilleures décisions grâce à des perspectives diverses. Bienvenue dans le party mode.
|
||||
|
|
|
|||
|
|
@ -14,10 +14,10 @@ Lorsque plusieurs agents IA implémentent différentes parties d’un système,
|
|||
Sans architecture :
|
||||
- L’agent A utilise REST avec `/users/{id}`
|
||||
- L’agent B utilise des mutations GraphQL
|
||||
- Résultat : Patterns d’API incohérents, consommateurs confus
|
||||
- Résultat : Patterns d’API incohérents, consommateurs confus
|
||||
|
||||
Avec architecture :
|
||||
- L’ADR[^1] spécifie : « Utiliser GraphQL pour toute communication client-serveur »
|
||||
- L’ADR[^1] spécifie : « Utiliser GraphQL pour toute communication client-serveur »
|
||||
- Tous les agents suivent le même pattern
|
||||
|
||||
### Conflits de conception de base de données
|
||||
|
|
@ -25,7 +25,7 @@ Avec architecture :
|
|||
Sans architecture :
|
||||
- L’agent A utilise des noms de colonnes en snake_case
|
||||
- L’agent B utilise des noms de colonnes en camelCase
|
||||
- Résultat : Schéma incohérent, requêtes illisibles
|
||||
- Résultat : Schéma incohérent, requêtes illisibles
|
||||
|
||||
Avec architecture :
|
||||
- Un document de standards spécifie les conventions de nommage
|
||||
|
|
@ -36,7 +36,7 @@ Avec architecture :
|
|||
Sans architecture :
|
||||
- L’agent A utilise Redux pour l’état global
|
||||
- L’agent B utilise React Context
|
||||
- Résultat : Multiples approches de gestion d’état, complexité
|
||||
- Résultat : Multiples approches de gestion d’état, complexité
|
||||
|
||||
Avec architecture :
|
||||
- L’ADR spécifie l’approche de gestion d’état
|
||||
|
|
@ -56,8 +56,8 @@ Chaque choix technologique significatif est documenté avec :
|
|||
### 2. Guidance spécifique aux FR/NFR[^2]
|
||||
|
||||
L’architecture associe chaque exigence fonctionnelle à une approche technique :
|
||||
- FR-001 : Gestion des utilisateurs → Mutations GraphQL
|
||||
- FR-002 : Application mobile → Requêtes optimisées
|
||||
- FR-001 : Gestion des utilisateurs → Mutations GraphQL
|
||||
- FR-002 : Application mobile → Requêtes optimisées
|
||||
|
||||
### 3. Standards et conventions
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ Le fichier `project-context.md` résout ce problème en documentant ce que les a
|
|||
|
||||
Chaque workflow d’implémentation charge automatiquement `project-context.md` s’il existe. Le workflow architecte le charge également pour respecter vos préférences techniques lors de la conception de l’architecture.
|
||||
|
||||
**Chargé par ces workflows :**
|
||||
**Chargé par ces workflows :**
|
||||
- `bmad-create-architecture` — respecte les préférences techniques pendant la phase de solutioning
|
||||
- `bmad-create-story` — informe la création de stories avec les patterns du projet
|
||||
- `bmad-dev-story` — guide les décisions d’implémentation
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ Il permet au modèle de s’exécuter plus longtemps entre les points de contrô
|
|||
|
||||
Les interactions humaines dans la boucle sont nécessaires et coûteuses.
|
||||
|
||||
Les LLM actuels échouent encore de manière prévisible : ils interprètent mal l’intention, comblent les lacunes avec des suppositions assurées, dérivent vers du travail non lié, et génèrent des résultats à réviser bruyants. En même temps, l’intervention humaine constante limite la fluidité du développement. L’attention humaine est le goulot d’étranglement.
|
||||
Les LLM actuels échouent encore de manière prévisible : ils interprètent mal l’intention, comblent les lacunes avec des suppositions assurées, dérivent vers du travail non lié, et génèrent des résultats à réviser bruyants. En même temps, l’intervention humaine constante limite la fluidité du développement. L’attention humaine est le goulot d’étranglement.
|
||||
|
||||
`bmad-quick-dev` rééquilibre ce compromis. Il fait confiance au modèle pour s’exécuter sans surveillance sur de plus longues périodes, mais seulement après que le workflow ait créé une frontière suffisamment solide pour rendre cela sûr.
|
||||
|
||||
|
|
@ -25,7 +25,7 @@ Les LLM actuels échouent encore de manière prévisible : ils interprètent mal
|
|||
|
||||
Le workflow commence par compresser l’interaction de la personne et du modèle à partir de la requête en un objectif cohérent. L’entrée peut commencer sous forme d’une expression grossière de l’intention, mais avant que le workflow ne s’exécute de manière autonome, elle doit devenir suffisamment petite, claire et sans contradiction pour être exécutable.
|
||||
|
||||
L’intention peut prendre plusieurs formes : quelques phrases, un lien vers un outil de suivi de bugs, une sortie du mode planification, du texte copié depuis une session de chat, ou même un numéro de story depuis un fichier `epics.md` de BMAD. Dans ce dernier cas, le workflow ne comprendra pas la sémantique de suivi des stories de BMAD, mais il peut quand même prendre la story elle-même et l’exécuter.
|
||||
L’intention peut prendre plusieurs formes : quelques phrases, un lien vers un outil de suivi de bugs, une sortie du mode planification, du texte copié depuis une session de chat, ou même un numéro de story depuis un fichier `epics.md` de BMAD. Dans ce dernier cas, le workflow ne comprendra pas la sémantique de suivi des stories de BMAD, mais il peut quand même prendre la story elle-même et l’exécuter.
|
||||
|
||||
Ce workflow n’élimine pas le contrôle humain. Il le déplace vers un nombre réduit d’étapes à forte valeur :
|
||||
|
||||
|
|
|
|||
|
|
@ -44,12 +44,12 @@ Le dossier `_bmad/custom/` est initialement vide. Les fichiers n’apparaissent
|
|||
|
||||
Le résolveur applique quatre règles structurelles. Les noms de champ n’ont pas de traitement particulier — le comportement est déterminé uniquement par la forme de la valeur :
|
||||
|
||||
| Forme | Règle |
|
||||
|---|---|
|
||||
| Scalaire (chaîne, entier, booléen, flottant) | L’override prévaut |
|
||||
| Table | Fusion profonde (application récursive des mêmes règles) |
|
||||
| Forme | Règle |
|
||||
|-------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------|
|
||||
| Scalaire (chaîne, entier, booléen, flottant) | L’override prévaut |
|
||||
| Table | Fusion profonde (application récursive des mêmes règles) |
|
||||
| Tableau de tables où chaque élément partage le **même** champ identifiant (chaque élément a `code`, ou chaque élément a `id`) | Fusionner par cette clé — les clés correspondantes **remplacent sur place**, les nouvelles clés **s’ajoutent** |
|
||||
| Tout autre tableau (scalaires ; tables sans identifiant ; tableaux qui mélangent `code` et `id` entre les éléments) | **Ajouter** — éléments de base en premier, puis éléments d’équipe, puis éléments utilisateur |
|
||||
| Tout autre tableau (scalaires ; tables sans identifiant ; tableaux qui mélangent `code` et `id` entre les éléments) | **Ajouter** — éléments de base en premier, puis éléments d’équipe, puis éléments utilisateur |
|
||||
|
||||
**Pas de mécanisme de suppression.** Les overrides ne peuvent pas effacer les éléments de base. Si vous devez supprimer un élément de menu par défaut, surchargez-le via son `code` avec une description ou un prompt sans effet. Si vous devez restructurer un tableau plus en profondeur, forkez le skill.
|
||||
|
||||
|
|
@ -86,10 +86,10 @@ _bmad/custom/
|
|||
:::caution[Ne copiez PAS le `customize.toml` complet]
|
||||
Les fichiers d’override sont **allégés**. Incluez uniquement les champs que vous modifiez — rien d’autre. Chaque champ omis est hérité automatiquement de la couche inférieure (l’équipe hérite des valeurs par défaut, l’utilisateur de l’équipe ou des valeurs par défaut).
|
||||
|
||||
Copier le `customize.toml` complet dans un override est contre-productif : la prochaine mise à jour livrera de nouvelles valeurs par défaut, mais votre fichier d’override figera les anciennes valeurs. Votre configuration s’éloignera silencieusement des valeurs par défaut à chaque mise à jour.
|
||||
Copier le `customize.toml` complet dans un override est contre-productif : la prochaine mise à jour livrera de nouvelles valeurs par défaut, mais votre fichier d’override figera les anciennes valeurs. Votre configuration s’éloignera silencieusement des valeurs par défaut à chaque mise à jour.
|
||||
:::
|
||||
|
||||
**Exemple — changer l’icône et ajouter un principe :**
|
||||
**Exemple — changer l’icône et ajouter un principe :**
|
||||
|
||||
```toml
|
||||
# _bmad/custom/bmad-agent-pm.toml
|
||||
|
|
@ -158,7 +158,7 @@ activation_steps_append = [
|
|||
|
||||
**Pourquoi deux hooks ?** Le préfixe s’exécute avant la salutation pour que l’agent puisse charger le contexte dont il a besoin pour personnaliser la salutation elle-même. Le suffixe s’exécute après la salutation pour que l’utilisateur ne reste pas devant un terminal vide pendant les scans lourds.
|
||||
|
||||
**Personnalisation du menu (fusion par `code`).** Le menu est un tableau de tables. Chaque élément possède un champ `code` (convention BMad). Le résolveur fusionne donc par code : les codes correspondants remplacent sur place, les nouveaux codes s’ajoutent.
|
||||
**Personnalisation du menu (fusion par `code`).** Le menu est un tableau de tables. Chaque élément possède un champ `code` (convention BMad). Le résolveur fusionne donc par code : les codes correspondants remplacent sur place, les nouveaux codes s’ajoutent.
|
||||
|
||||
La syntaxe TOML pour les tableaux de tables utilise `[[agent.menu]]` pour chaque élément :
|
||||
|
||||
|
|
@ -182,13 +182,13 @@ Signaler tout écart et citer la section réglementaire pertinente.
|
|||
|
||||
Chaque élément de menu possède exactement un `skill` (invoque un skill enregistré) ou `prompt` (exécute le texte directement). Les éléments non listés dans votre override conservent leurs valeurs par défaut.
|
||||
|
||||
**Référencer des fichiers.** Quand le texte d’un champ doit pointer vers un fichier (dans `persistent_facts`, `activation_steps_prepend`/`activation_steps_append`, ou le `prompt` d’un élément de menu), utilisez un chemin complet partant de `{project-root}`. Même si le fichier se trouve à côté de votre override dans `_bmad/custom/`, écrivez le chemin complet : `{project-root}/_bmad/custom/info.md`. L’agent résout `{project-root}` à l’exécution.
|
||||
**Référencer des fichiers.** Quand le texte d’un champ doit pointer vers un fichier (dans `persistent_facts`, `activation_steps_prepend`/`activation_steps_append`, ou le `prompt` d’un élément de menu), utilisez un chemin complet partant de `{project-root}`. Même si le fichier se trouve à côté de votre override dans `_bmad/custom/`, écrivez le chemin complet : `{project-root}/_bmad/custom/info.md`. L’agent résout `{project-root}` à l’exécution.
|
||||
|
||||
### 4. Personnel vs Équipe
|
||||
|
||||
**Fichier d’équipe** (`bmad-agent-pm.toml`) : Versionné dans git. Partagé au sein de l’organisation. À utiliser pour les règles de conformité, le persona de l’entreprise, les capacités personnalisées.
|
||||
**Fichier d’équipe** (`bmad-agent-pm.toml`) : Versionné dans git. Partagé au sein de l’organisation. À utiliser pour les règles de conformité, le persona de l’entreprise, les capacités personnalisées.
|
||||
|
||||
**Fichier personnel** (`bmad-agent-pm.user.toml`) : Automatiquement ignoré par git. À utiliser pour les ajustements de ton, les préférences de workflow personnelles et les faits privés que l’agent doit garder en tête.
|
||||
**Fichier personnel** (`bmad-agent-pm.user.toml`) : Automatiquement ignoré par git. À utiliser pour les ajustements de ton, les préférences de workflow personnelles et les faits privés que l’agent doit garder en tête.
|
||||
|
||||
```toml
|
||||
# _bmad/custom/bmad-agent-pm.user.toml
|
||||
|
|
@ -209,7 +209,7 @@ python3 {project-root}/_bmad/scripts/resolve_customization.py \
|
|||
--key agent
|
||||
```
|
||||
|
||||
**Prérequis** : Python 3.11+ (les versions antérieures n’incluent pas `tomllib`). Pas de `pip install`, pas de `uv`, pas de virtualenv. Vérifiez avec `python3 --version`. Certaines plateformes (macOS sans Homebrew, Ubuntu 22.04) ont `python3` par défaut en 3.10 ou antérieur, vous devrez peut-être installer 3.11+ séparément.
|
||||
**Prérequis** : Python 3.11+ (les versions antérieures n’incluent pas `tomllib`). Pas de `pip install`, pas de `uv`, pas de virtualenv. Vérifiez avec `python3 --version`. Certaines plateformes (macOS sans Homebrew, Ubuntu 22.04) ont `python3` par défaut en 3.10 ou antérieur, vous devrez peut-être installer 3.11+ séparément.
|
||||
|
||||
`--skill` pointe vers le répertoire installé du skill (où se trouve `customize.toml`). Le nom du skill est déduit du basename du répertoire, et le script cherche automatiquement `_bmad/custom/{skill-name}.toml` et `{skill-name}.user.toml`.
|
||||
|
||||
|
|
@ -260,7 +260,7 @@ persistent_facts = [
|
|||
on_complete = "Résumer le brief en trois points et proposer de l'envoyer par email via le skill gws-gmail-send."
|
||||
```
|
||||
|
||||
Les mêmes conventions de champs s’appliquent indifféremment aux agents et aux workflows : `activation_steps_prepend`/`activation_steps_append`, `persistent_facts` (avec refs `file:`) et les tables `[[…]]` de style menu avec `code`/`id` pour la fusion par clé. Le résolveur applique les mêmes quatre règles structurelles quelle que soit la clé de premier niveau. Les références dans SKILL.md suivent l’espace de noms : `{workflow.activation_steps_prepend}`, `{workflow.persistent_facts}`, `{workflow.on_complete}`. Tout champ supplémentaire qu’un workflow expose (chemins de sortie, bascules, paramètres de revue, drapeaux d’étape) suit les mêmes règles de fusion basées sur la forme. Lisez le `customize.toml` du workflow pour voir ce qui est personnalisable.
|
||||
Les mêmes conventions de champs s’appliquent indifféremment aux agents et aux workflows : `activation_steps_prepend`/`activation_steps_append`, `persistent_facts` (avec refs `file:`) et les tables `[[…]]` de style menu avec `code`/`id` pour la fusion par clé. Le résolveur applique les mêmes quatre règles structurelles quelle que soit la clé de premier niveau. Les références dans SKILL.md suivent l’espace de noms : `{workflow.activation_steps_prepend}`, `{workflow.persistent_facts}`, `{workflow.on_complete}`. Tout champ supplémentaire qu’un workflow expose (chemins de sortie, bascules, paramètres de revue, drapeaux d’étape) suit les mêmes règles de fusion basées sur la forme. Lisez le `customize.toml` du workflow pour voir ce qui est personnalisable.
|
||||
|
||||
### Ordre d’activation
|
||||
|
||||
|
|
@ -277,7 +277,7 @@ Après l’étape 6, le corps du workflow commence. Utilisez `activation_steps_p
|
|||
|
||||
### Périmètre de cette première passe
|
||||
|
||||
La personnalisation est déployée de manière incrémentale. Les champs documentés ci-dessus — `activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, `on_complete` — sont la **surface de base** que chaque workflow personnalisable expose, et ils resteront stables d’une version à l’autre. Ils vous donnent un contrôle à grands traits dès aujourd’hui : injecter des étapes pré/post, épingler du contexte fondamental, déclencher des actions de suivi.
|
||||
La personnalisation est déployée de manière incrémentale. Les champs documentés ci-dessus — `activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, `on_complete` — sont la **surface de base** que chaque workflow personnalisable expose, et ils resteront stables d’une version à l’autre. Ils vous donnent un contrôle à grands traits dès aujourd’hui : injecter des étapes pré/post, épingler du contexte fondamental, déclencher des actions de suivi.
|
||||
|
||||
Au fil du temps, les workflows individuels exposeront des **points de personnalisation plus ciblés** adaptés à ce que le workflow fait réellement — par exemple des bascules par étape, des drapeaux d’étape, des chemins de templates de sortie ou des jalons de revue. Quand ils arriveront, ils viendront s’ajouter aux champs de base plutôt que de les remplacer, pour que les personnalisations que vous rédigez aujourd’hui continuent de fonctionner.
|
||||
|
||||
|
|
@ -359,12 +359,12 @@ L’override prévaut sur ce que chaque développeur a répondu lors de son inst
|
|||
|
||||
| Besoin | Utiliser |
|
||||
|----------------------------------------------------------|-------------------------------------------------------------------------------|
|
||||
| Ajouter des appels d’outils MCP à chaque workflow de dev | Par skill : `_bmad/custom/bmad-agent-dev.toml` `persistent_facts` |
|
||||
| Ajouter un élément de menu à un agent | Par skill : `_bmad/custom/bmad-agent-{role}.toml` `[[agent.menu]]` |
|
||||
| Remplacer le template de sortie d’un workflow | Par skill : `_bmad/custom/{workflow}.toml` override scalaire |
|
||||
| Renommer le descripteur public d’un agent | **Centrale** : `_bmad/custom/config.toml` `[agents.<code>]` |
|
||||
| Ajouter un agent personnalisé ou fictif au registre | **Centrale** : `_bmad/custom/config.*.toml` nouvelle entrée `[agents.<code>]` |
|
||||
| Figer les paramètres d’installation pour l’équipe | **Centrale** : `_bmad/custom/config.toml` `[modules.<code>]` ou `[core]` |
|
||||
| Ajouter des appels d’outils MCP à chaque workflow de dev | Par skill : `_bmad/custom/bmad-agent-dev.toml` `persistent_facts` |
|
||||
| Ajouter un élément de menu à un agent | Par skill : `_bmad/custom/bmad-agent-{role}.toml` `[[agent.menu]]` |
|
||||
| Remplacer le template de sortie d’un workflow | Par skill : `_bmad/custom/{workflow}.toml` override scalaire |
|
||||
| Renommer le descripteur public d’un agent | **Centrale** : `_bmad/custom/config.toml` `[agents.<code>]` |
|
||||
| Ajouter un agent personnalisé ou fictif au registre | **Centrale** : `_bmad/custom/config.*.toml` nouvelle entrée `[agents.<code>]` |
|
||||
| Figer les paramètres d’installation pour l’équipe | **Centrale** : `_bmad/custom/config.toml` `[modules.<code>]` ou `[core]` |
|
||||
|
||||
Utilisez les deux espaces dans le même projet selon vos besoins.
|
||||
|
||||
|
|
@ -377,7 +377,7 @@ Pour des recettes orientées entreprise (façonner un agent à travers tous les
|
|||
**La personnalisation n’apparaît pas ?**
|
||||
|
||||
- Vérifiez que votre fichier se trouve dans `_bmad/custom/` avec le nom de skill correct
|
||||
- Vérifiez la syntaxe TOML : les chaînes doivent être entre guillemets, les en-têtes de table utilisent `[section]`, les tableaux de tables utilisent `[[section]]`, et toute clé scalaire ou de tableau pour une table doit apparaître *avant* toute `[[sous-table]]` de cette table dans le fichier
|
||||
- Vérifiez la syntaxe TOML : les chaînes doivent être entre guillemets, les en-têtes de table utilisent `[section]`, les tableaux de tables utilisent `[[section]]`, et toute clé scalaire ou de tableau pour une table doit apparaître *avant* toute `[[sous-table]]` de cette table dans le fichier
|
||||
- Pour les agents, la personnalisation se trouve sous `[agent]` — les champs écrits sous cet en-tête appartiennent à `agent` jusqu’à ce qu’un autre en-tête de table commence
|
||||
- Rappelez-vous que `agent.name` et `agent.title` sont en lecture seule ; les overrides n’ont aucun effet
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ Ce guide couvre le flux de travail essentiel pour l’intégration à des projet
|
|||
- Accès à un IDE IA (Claude Code ou Cursor)
|
||||
:::
|
||||
|
||||
## Étape 1 : Nettoyer les artefacts de planification terminés
|
||||
## Étape 1 : Nettoyer les artefacts de planification terminés
|
||||
|
||||
Si vous avez terminé tous les epics et stories du PRD[^1] via le processus BMad, nettoyez ces fichiers. Archivez-les, supprimez-les, ou appuyez-vous sur l’historique des versions si nécessaire. Ne conservez pas ces fichiers dans :
|
||||
|
||||
|
|
@ -23,7 +23,7 @@ Si vous avez terminé tous les epics et stories du PRD[^1] via le processus BMad
|
|||
- `_bmad-output/planning-artifacts/`
|
||||
- `_bmad-output/implementation-artifacts/`
|
||||
|
||||
## Étape 2 : Créer le contexte du projet
|
||||
## Étape 2 : Créer le contexte du projet
|
||||
|
||||
:::tip[Recommandé pour les projets existants]
|
||||
Générez `project-context.md` pour capturer les patterns et conventions de votre base de code existante. Cela garantit que les agents IA suivent vos pratiques établies lors de l’implémentation des modifications.
|
||||
|
|
@ -46,7 +46,7 @@ Vous pouvez examiner et affiner le fichier généré, ou le créer manuellement
|
|||
|
||||
[En savoir plus sur le contexte du projet](../explanation/project-context.md)
|
||||
|
||||
## Étape 3 : Maintenir une documentation de projet de qualité
|
||||
## Étape 3 : Maintenir une documentation de projet de qualité
|
||||
|
||||
Votre dossier `docs/` doit contenir une documentation succincte et bien organisée qui représente fidèlement votre projet :
|
||||
|
||||
|
|
@ -57,9 +57,9 @@ Votre dossier `docs/` doit contenir une documentation succincte et bien organis
|
|||
|
||||
Pour les projets complexes, envisagez d’utiliser le workflow `bmad-document-project`. Il offre des variantes d’exécution qui analyseront l’ensemble de votre projet et documenteront son état actuel réel.
|
||||
|
||||
## Étape 4 : Obtenir de l’aide
|
||||
## Étape 4 : Obtenir de l’aide
|
||||
|
||||
### BMad-Help : Votre point de départ
|
||||
### BMad-Help : Votre point de départ
|
||||
|
||||
**Exécutez `bmad-help` chaque fois que vous n’êtes pas sûr de la prochaine étape.** Ce guide intelligent :
|
||||
|
||||
|
|
@ -79,10 +79,10 @@ BMad-Help s’exécute également **automatiquement à la fin de chaque workflow
|
|||
|
||||
Vous avez deux options principales selon l’ampleur des modifications :
|
||||
|
||||
| Portée | Approche recommandée |
|
||||
| ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| **Petites mises à jour ou ajouts** | Exécutez `bmad-quick-dev` pour clarifier l’intention, planifier, implémenter et réviser dans un seul workflow. La méthode BMad complète en quatre phases est probablement excessive. |
|
||||
| **Modifications ou ajouts majeurs** | Commencez avec la méthode BMad, en appliquant autant ou aussi peu de rigueur que nécessaire. |
|
||||
| Portée | Approche recommandée |
|
||||
|-------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| **Petites mises à jour ou ajouts** | Exécutez `bmad-quick-dev` pour clarifier l’intention, planifier, implémenter et réviser dans un seul workflow. La méthode BMad complète en quatre phases est probablement excessive. |
|
||||
| **Modifications ou ajouts majeurs** | Commencez avec la méthode BMad, en appliquant autant ou aussi peu de rigueur que nécessaire. |
|
||||
|
||||
### Pendant la création du PRD
|
||||
|
||||
|
|
|
|||
|
|
@ -28,13 +28,13 @@ Avant de choisir une recette, comprenez où votre override se situe :
|
|||
| **Workflow** (ex. product-brief, create-prd) | Section `[workflow]` de `_bmad/custom/{workflow-name}.toml` | S’applique uniquement à l’exécution de ce workflow |
|
||||
| **Configuration centrale** | `[agents.*]`, `[core]`, `[modules.*]` dans `_bmad/custom/config.toml` | Registre des agents (qui est disponible pour party-mode, retrospective, elicitation), paramètres d’installation figés pour toute l’organisation |
|
||||
|
||||
En règle générale : si la règle doit s’appliquer partout où un ingénieur travaille sur le développement, personnalisez l'**agent dev**. Si elle s’applique uniquement quand quelqu’un rédige un product brief, personnalisez le **workflow product-brief**. Si elle change *qui participe* (renommer un agent, ajouter une voix personnalisée, imposer un chemin d’artefact partagé), modifiez la **configuration centrale**.
|
||||
En règle générale : si la règle doit s’appliquer partout où un ingénieur travaille sur le développement, personnalisez l'**agent dev**. Si elle s’applique uniquement quand quelqu’un rédige un product brief, personnalisez le **workflow product-brief**. Si elle change *qui participe* (renommer un agent, ajouter une voix personnalisée, imposer un chemin d’artefact partagé), modifiez la **configuration centrale**.
|
||||
|
||||
## Recette 1 : Façonner un agent à travers tous les workflows qu’il dispatche
|
||||
## Recette 1 : Façonner un agent à travers tous les workflows qu’il dispatche
|
||||
|
||||
**Cas d’usage :** Standardiser l’utilisation des outils et les intégrations avec les systèmes externes pour que chaque workflow dispatché par un agent hérite du comportement. C’est le pattern le plus impactant.
|
||||
**Cas d’usage :** Standardiser l’utilisation des outils et les intégrations avec les systèmes externes pour que chaque workflow dispatché par un agent hérite du comportement. C’est le pattern le plus impactant.
|
||||
|
||||
**Exemple : Amelia (agent dev) utilise toujours Context7 pour la documentation des bibliothèques, et se rabat sur Linear quand une story n’est pas trouvée dans la liste des epics.**
|
||||
**Exemple : Amelia (agent dev) utilise toujours Context7 pour la documentation des bibliothèques, et se rabat sur Linear quand une story n’est pas trouvée dans la liste des epics.**
|
||||
|
||||
```toml
|
||||
# _bmad/custom/bmad-agent-dev.toml
|
||||
|
|
@ -49,17 +49,17 @@ persistent_facts = [
|
|||
]
|
||||
```
|
||||
|
||||
**Pourquoi ça marche :** Deux phrases suffisent à reconfigurer tous les workflows de dev de l’organisation, sans duplication par workflow ni modification du code source. Chaque nouvel ingénieur qui clone le dépôt hérite automatiquement des conventions.
|
||||
**Pourquoi ça marche :** Deux phrases suffisent à reconfigurer tous les workflows de dev de l’organisation, sans duplication par workflow ni modification du code source. Chaque nouvel ingénieur qui clone le dépôt hérite automatiquement des conventions.
|
||||
|
||||
**Fichier d’équipe vs fichier personnel :**
|
||||
- `bmad-agent-dev.toml` : versionné dans git ; s’applique à toute l’équipe
|
||||
- `bmad-agent-dev.user.toml` : ignoré par git ; préférences personnelles ajoutées par-dessus
|
||||
**Fichier d’équipe vs fichier personnel :**
|
||||
- `bmad-agent-dev.toml` : versionné dans git ; s’applique à toute l’équipe
|
||||
- `bmad-agent-dev.user.toml` : ignoré par git ; préférences personnelles ajoutées par-dessus
|
||||
|
||||
## Recette 2 : Imposer les conventions de l’organisation dans un workflow spécifique
|
||||
## Recette 2 : Imposer les conventions de l’organisation dans un workflow spécifique
|
||||
|
||||
**Cas d’usage :** Façonner le *contenu* de la sortie d’un workflow pour qu’il réponde aux exigences de conformité, d’audit ou des consommateurs en aval.
|
||||
**Cas d’usage :** Façonner le *contenu* de la sortie d’un workflow pour qu’il réponde aux exigences de conformité, d’audit ou des consommateurs en aval.
|
||||
|
||||
**Exemple : chaque product brief doit inclure des champs de conformité, et l’agent connaît les conventions de publication de l’organisation.**
|
||||
**Exemple : chaque product brief doit inclure des champs de conformité, et l’agent connaît les conventions de publication de l’organisation.**
|
||||
|
||||
```toml
|
||||
# _bmad/custom/bmad-product-brief.toml
|
||||
|
|
@ -73,13 +73,13 @@ persistent_facts = [
|
|||
]
|
||||
```
|
||||
|
||||
**Ce qui se passe :** Les faits sont chargés durant l’étape 3 de l’activation du workflow. Quand l’agent rédige le brief, il connaît les champs requis et le document de conventions enterprise. La valeur par défaut livrée (`file:{project-root}/**/project-context.md`) se charge toujours, car il s’agit d’un ajout.
|
||||
**Ce qui se passe :** Les faits sont chargés durant l’étape 3 de l’activation du workflow. Quand l’agent rédige le brief, il connaît les champs requis et le document de conventions enterprise. La valeur par défaut livrée (`file:{project-root}/**/project-context.md`) se charge toujours, car il s’agit d’un ajout.
|
||||
|
||||
## Recette 3 : Publier les livrables finis vers des systèmes externes
|
||||
## Recette 3 : Publier les livrables finis vers des systèmes externes
|
||||
|
||||
**Cas d’usage :** Une fois le livrable produit, le publier automatiquement vers les systèmes de référence de l’entreprise (Confluence, Notion, SharePoint) et créer des tickets de suivi (Jira, Linear, Asana).
|
||||
**Cas d’usage :** Une fois le livrable produit, le publier automatiquement vers les systèmes de référence de l’entreprise (Confluence, Notion, SharePoint) et créer des tickets de suivi (Jira, Linear, Asana).
|
||||
|
||||
**Exemple : les briefs sont automatiquement publiés vers Confluence et proposent la création facultative d’un epic Jira.**
|
||||
**Exemple : les briefs sont automatiquement publiés vers Confluence et proposent la création facultative d’un epic Jira.**
|
||||
|
||||
```toml
|
||||
# _bmad/custom/bmad-product-brief.toml
|
||||
|
|
@ -112,18 +112,18 @@ et demander à l'utilisateur de publier manuellement.
|
|||
"""
|
||||
```
|
||||
|
||||
**Pourquoi `on_complete` et pas `activation_steps_append` :** `on_complete` s’exécute exactement une fois, au stade terminal, après que le workflow a écrit sa sortie principale. C’est le bon moment pour publier des artefacts. `activation_steps_append` s’exécute à chaque activation, avant que le workflow ne fasse son travail.
|
||||
**Pourquoi `on_complete` et pas `activation_steps_append` :** `on_complete` s’exécute exactement une fois, au stade terminal, après que le workflow a écrit sa sortie principale. C’est le bon moment pour publier des artefacts. `activation_steps_append` s’exécute à chaque activation, avant que le workflow ne fasse son travail.
|
||||
|
||||
**Arbitrages :**
|
||||
**Arbitrages :**
|
||||
- **La publication Confluence est non-destructive** et s’exécute toujours à la fin
|
||||
- **La création d’epic Jira est visible par toute l’équipe** et déclenche un processus de planification de sprint, conditionnez-la donc à la confirmation de l’utilisateur
|
||||
- **Dégradation gracieuse :** si les outils MCP échouent, passer la main à l’utilisateur plutôt que de silencieusement abandonner le livrable
|
||||
- **Dégradation gracieuse :** si les outils MCP échouent, passer la main à l’utilisateur plutôt que de silencieusement abandonner le livrable
|
||||
|
||||
## Recette 4 : Remplacer le template de sortie par le vôtre
|
||||
## Recette 4 : Remplacer le template de sortie par le vôtre
|
||||
|
||||
**Cas d’usage :** La structure de sortie par défaut ne correspond pas au format attendu par votre organisation, ou différentes organisations dans le même dépôt ont besoin de templates différents.
|
||||
**Cas d’usage :** La structure de sortie par défaut ne correspond pas au format attendu par votre organisation, ou différentes organisations dans le même dépôt ont besoin de templates différents.
|
||||
|
||||
**Exemple : pointer le workflow product-brief vers un template appartenant à l’entreprise.**
|
||||
**Exemple : pointer le workflow product-brief vers un template appartenant à l’entreprise.**
|
||||
|
||||
```toml
|
||||
# _bmad/custom/bmad-product-brief.toml
|
||||
|
|
@ -132,16 +132,16 @@ et demander à l'utilisateur de publier manuellement.
|
|||
brief_template = "{project-root}/docs/enterprise/brief-template.md"
|
||||
```
|
||||
|
||||
**Comment ça marche :** Le `customize.toml` du workflow est fourni avec `brief_template = "resources/brief-template.md"` (chemin relatif, résolu depuis la racine du skill). Votre override pointe vers un fichier sous `{project-root}`, donc l’agent lit votre template à l’étape 4 au lieu de celui livré par défaut.
|
||||
**Comment ça marche :** Le `customize.toml` du workflow est fourni avec `brief_template = "resources/brief-template.md"` (chemin relatif, résolu depuis la racine du skill). Votre override pointe vers un fichier sous `{project-root}`, donc l’agent lit votre template à l’étape 4 au lieu de celui livré par défaut.
|
||||
|
||||
**Conseils pour la rédaction de templates :**
|
||||
**Conseils pour la rédaction de templates :**
|
||||
- Gardez les templates dans `{project-root}/docs/` ou `{project-root}/_bmad/custom/templates/` pour qu’ils soient versionnés avec le fichier d’override
|
||||
- Utilisez les mêmes conventions structurelles que le template livré (titres de sections, frontmatter) ; l’agent s’adapte à ce qu’il trouve
|
||||
- Pour les dépôts multi-organisations, utilisez `.user.toml` pour permettre à chaque équipe de pointer vers ses propres templates sans toucher au fichier d’équipe versionné dans git
|
||||
|
||||
## Recette 5 : Personnaliser le registre des agents
|
||||
## Recette 5 : Personnaliser le registre des agents
|
||||
|
||||
**Cas d’usage :** Changer *qui sera présent dans la pièce* pour les skills basés sur le registre comme `bmad-party-mode`, `bmad-retrospective` et `bmad-advanced-elicitation`, sans modifier le code source ni forker. Voici trois variantes courantes.
|
||||
**Cas d’usage :** Changer *qui sera présent dans la pièce* pour les skills basés sur le registre comme `bmad-party-mode`, `bmad-retrospective` et `bmad-advanced-elicitation`, sans modifier le code source ni forker. Voici trois variantes courantes.
|
||||
|
||||
### 5a. Renommer un agent BMad pour toute l’organisation
|
||||
|
||||
|
|
@ -197,18 +197,18 @@ document_output_language = "English"
|
|||
|
||||
Les paramètres personnels comme `user_name`, `communication_language` ou `user_skill_level` restent dans leur propre fichier `_bmad/config.user.toml` de chaque développeur. Le fichier d’équipe ne doit pas les modifier.
|
||||
|
||||
**Pourquoi la configuration centrale vs le customize.toml par agent :** Les fichiers par agent façonnent la façon dont *un seul* agent se comporte quand il s’active. La configuration centrale façonne ce que les consommateurs du registre *voient* : quels agents existent, comment ils s’appellent, à quelle équipe ils appartiennent, et les paramètres d’installation partagés sur lesquels tout le dépôt s’accorde. Deux surfaces, des rôles différents.
|
||||
**Pourquoi la configuration centrale vs le customize.toml par agent :** Les fichiers par agent façonnent la façon dont *un seul* agent se comporte quand il s’active. La configuration centrale façonne ce que les consommateurs du registre *voient* : quels agents existent, comment ils s’appellent, à quelle équipe ils appartiennent, et les paramètres d’installation partagés sur lesquels tout le dépôt s’accorde. Deux surfaces, des rôles différents.
|
||||
|
||||
## Renforcer les règles globales dans le fichier de session de votre IDE
|
||||
|
||||
Les personnalisations BMad se chargent quand un skill est activé. Beaucoup d’outils IDE chargent aussi un fichier d’instructions global au **début de chaque session**, avant tout skill (`CLAUDE.md`, `AGENTS.md`, `.cursor/rules/`, `.github/copilot-instructions.md`, etc.). Pour les règles qui doivent s’appliquer même en dehors des skills BMad, reproduisez-y les plus critiques.
|
||||
|
||||
**Quand les utiliser ensemble :**
|
||||
**Quand les utiliser ensemble :**
|
||||
- Une règle est suffisamment importante pour qu’une conversation simple (sans skill actif) doive la respecter
|
||||
- Vous voulez une double sécurisation parce que les défauts des données d’entraînement pourraient autrement détourner le modèle
|
||||
- La règle est assez concise pour être répétée sans alourdir le fichier de session
|
||||
|
||||
**Exemple : une ligne dans le `CLAUDE.md` du dépôt renforçant la règle de l’agent dev de la Recette 1.**
|
||||
**Exemple : une ligne dans le `CLAUDE.md` du dépôt renforçant la règle de l’agent dev de la Recette 1.**
|
||||
|
||||
```markdown
|
||||
<!-- Toute lecture de documentation de bibliothèque passe par l'outil MCP context7
|
||||
|
|
@ -227,7 +227,7 @@ Une phrase, chargée à chaque session. Elle s’associe à la personnalisation
|
|||
|
||||
Gardez le fichier IDE **concis**. Une douzaine de lignes bien choisies sont plus efficaces qu’une liste étendue. Les modèles le lisent à chaque tour, et le superflu noie l’information utile.
|
||||
|
||||
## Recette 6 : Patterns d’intégration avancés
|
||||
## Recette 6 : Patterns d’intégration avancés
|
||||
|
||||
Plusieurs workflows BMad exposent une surface de configuration plus riche au-delà des bases couvertes dans les Recettes 1–5. Ces patterns — sources de connaissance à la demande, publication automatique des livrables, standards de documentation à la finalisation et templates interchangeables — apparaissent dans plusieurs workflows. Consultez le `customize.toml` d’un workflow pour voir quels champs il expose ; les exemples ci-dessous utilisent `bmad-prd` car il les expose tous, mais les mêmes patterns s’appliquent partout où le champ apparaît.
|
||||
|
||||
|
|
@ -317,7 +317,7 @@ on_complete = """ ... """
|
|||
persistent_facts = ["Toujours inclure une section 'Revue réglementaire' quand le domaine implique la santé, la finance ou les données d'enfants."]
|
||||
```
|
||||
|
||||
Résultat : Mary charge la règle de revue réglementaire à l’activation de son persona. Quand l’utilisateur choisit le product brief dans le menu, le workflow charge ses propres conventions par-dessus, écrit avec le template enterprise et publie vers Confluence à la fin. Chaque couche contribue, et aucune n’a nécessité de modifier le code source de BMad.
|
||||
Résultat : Mary charge la règle de revue réglementaire à l’activation de son persona. Quand l’utilisateur choisit le product brief dans le menu, le workflow charge ses propres conventions par-dessus, écrit avec le template enterprise et publie vers Confluence à la fin. Chaque couche contribue, et aucune n’a nécessité de modifier le code source de BMad.
|
||||
|
||||
## Dépannage
|
||||
|
||||
|
|
|
|||
|
|
@ -28,12 +28,12 @@ BMad-Help s’appuie sur votre configuration installée. Pour les questions sur
|
|||
Clonez ou ouvrez le [dépôt BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD) et posez vos questions à votre IA. Tout outil capable d’utiliser des agents (Claude Code, Cursor, Windsurf, etc.) peut lire les sources et répondre directement à vos questions.
|
||||
|
||||
:::note[Exemple]
|
||||
**Q :** « Quel est le moyen le plus rapide de construire quelque chose avec BMad ? »
|
||||
**Q :** « Quel est le moyen le plus rapide de construire quelque chose avec BMad ? »
|
||||
|
||||
**R :** Utilisez le flux rapide : Lancez `bmad-quick-dev` — il clarifie votre intention, planifie, implémente, révise et présente les résultats dans un seul workflow, en sautant les phases de planification complètes.
|
||||
**R :** Utilisez le flux rapide : Lancez `bmad-quick-dev` — il clarifie votre intention, planifie, implémente, révise et présente les résultats dans un seul workflow, en sautant les phases de planification complètes.
|
||||
:::
|
||||
|
||||
**Conseils pour de meilleures réponses :**
|
||||
**Conseils pour de meilleures réponses :**
|
||||
|
||||
- **Soyez précis** — « Que fait l’étape 3 du workflow PRD ? » est mieux que « Comment fonctionne le PRD ? »
|
||||
- **Vérifiez les affirmations surprenantes** — Les LLM font parfois des erreurs. Consultez le fichier source ou posez la question sur Discord.
|
||||
|
|
@ -46,14 +46,14 @@ Si votre IA ne peut pas lire des fichiers locaux (ChatGPT, Claude.ai, etc.), imp
|
|||
|
||||
Si ni BMad-Help ni la source n’ont répondu à votre question, vous avez maintenant une bien meilleure question à poser.
|
||||
|
||||
| Canal | Utilisé pour |
|
||||
| ------------------------- | ------------------------------------------- |
|
||||
| Forum `help-requests` | Questions |
|
||||
| `#suggestions-feedback` | Idées et demandes de fonctionnalités |
|
||||
| Canal | Utilisé pour |
|
||||
|-------------------------|--------------------------------------|
|
||||
| Forum `help-requests` | Questions |
|
||||
| `#suggestions-feedback` | Idées et demandes de fonctionnalités |
|
||||
|
||||
**Discord :** [discord.gg/gk8jAdXWmj](https://discord.gg/gk8jAdXWmj)
|
||||
**Discord :** [discord.gg/gk8jAdXWmj](https://discord.gg/gk8jAdXWmj)
|
||||
|
||||
**GitHub Issues :** [github.com/bmad-code-org/BMAD-METHOD/issues](https://github.com/bmad-code-org/BMAD-METHOD/issues)
|
||||
**GitHub Issues :** [github.com/bmad-code-org/BMAD-METHOD/issues](https://github.com/bmad-code-org/BMAD-METHOD/issues)
|
||||
*Toi !*
|
||||
*Bloqué*
|
||||
*dans la file d’attente—*
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ Exécute l’installateur de préversion, qui fournit un snapshot plus récent d
|
|||
|
||||
Deux axes indépendants contrôlent ce qui se retrouve sur le disque.
|
||||
|
||||
### Axe 1 : canaux des modules externes
|
||||
### Axe 1 : canaux des modules externes
|
||||
|
||||
Chaque module externe — bmb, cis, gds, tea, et tout module communautaire — s’installe via l’un des trois canaux suivants :
|
||||
|
||||
|
|
@ -63,7 +63,7 @@ Chaque module externe — bmb, cis, gds, tea, et tout module communautaire — s
|
|||
|
||||
Les canaux sont définis module par module. Vous pouvez exécuter bmb sur `next` tout en laissant cis sur `stable` — les options ci-dessous permettent de les combiner librement.
|
||||
|
||||
### Axe 2 : version du binaire de l’installateur
|
||||
### Axe 2 : version du binaire de l’installateur
|
||||
|
||||
Le paquet npm `bmad-method` lui-même a deux dist-tags :
|
||||
|
||||
|
|
@ -88,10 +88,10 @@ Ils sont liés au binaire de l’installateur que vous avez exécuté :
|
|||
|
||||
Exécuter `npx bmad-method install` dans un répertoire contenant déjà `_bmad/` affiche un menu :
|
||||
|
||||
| Choix | Ce qu’il fait |
|
||||
| --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| **Quick Update** | Réexécute l’installation avec vos paramètres existants. Rafraîchit les fichiers, applique les correctifs et les mises à niveau mineures du canal stable, refuse les mises à niveau majeures. Rapide, non interactif. |
|
||||
| **Modify Install** | Flux interactif complet. Ajoutez ou retirez des modules, reconfigurez les paramètres, examinez et, si besoin, modifiez les canaux des modules existants. |
|
||||
| Choix | Ce qu’il fait |
|
||||
|--------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| **Quick Update** | Réexécute l’installation avec vos paramètres existants. Rafraîchit les fichiers, applique les correctifs et les mises à niveau mineures du canal stable, refuse les mises à niveau majeures. Rapide, non interactif. |
|
||||
| **Modify Install** | Flux interactif complet. Ajoutez ou retirez des modules, reconfigurez les paramètres, examinez et, si besoin, modifiez les canaux des modules existants. |
|
||||
|
||||
### Invites de mise à niveau
|
||||
|
||||
|
|
@ -109,9 +109,9 @@ Avec `--yes`, les mises à niveau patch et mineure s’appliquent automatiquemen
|
|||
|
||||
### Changer le canal d’un module
|
||||
|
||||
**En mode interactif :** choisissez Modify → répondez **Oui** à « Review channel assignments? » → chaque module externe offre Conserver, Basculer vers stable, Basculer vers next, ou Épingler à un tag.
|
||||
**En mode interactif :** choisissez Modify → répondez **Oui** à « Review channel assignments? » → chaque module externe offre Conserver, Basculer vers stable, Basculer vers next, ou Épingler à un tag.
|
||||
|
||||
**En ligne de commande :** les recettes dans la section suivante couvrent les cas courants.
|
||||
**En ligne de commande :** les recettes dans la section suivante couvrent les cas courants.
|
||||
|
||||
## Installations CI non interactives
|
||||
|
||||
|
|
@ -120,7 +120,7 @@ Avec `--yes`, les mises à niveau patch et mineure s’appliquent automatiquemen
|
|||
| Option | Objectif |
|
||||
|--------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| `--yes`, `-y` | Ignorer toutes les invites ; accepter les valeurs des options + les défauts |
|
||||
| `--directory <chemin>` | Installer dans ce répertoire (défaut : répertoire de travail courant) |
|
||||
| `--directory <chemin>` | Installer dans ce répertoire (défaut : répertoire de travail courant) |
|
||||
| `--modules <a,b,c>` | Ensemble exact de modules. Core est ajouté automatiquement. Ce n’est pas un delta — listez tout ce que vous voulez conserver. |
|
||||
| `--tools <a,b>` | Sélection d’IDE/outil. Requis pour les nouvelles installations `--yes`. Exécutez `--list-tools` pour les IDs valides. |
|
||||
| `--list-tools` | Afficher tous les IDs d’outils/IDE supportés (avec les répertoires cibles) et quitter. |
|
||||
|
|
@ -135,7 +135,7 @@ Avec `--yes`, les mises à niveau patch et mineure s’appliquent automatiquemen
|
|||
| `--list-options [module]` | Afficher chaque clé `--set` pour les modules intégrés et officiels en cache local, puis quitter. Passez un code de module pour limiter à un seul module. |
|
||||
| `--user-name`, `--communication-language`, `--document-output-language`, `--output-folder` | Raccourcis historiques équivalents à `--set core.<clé>=<valeur>` (toujours supportés) |
|
||||
|
||||
Priorité en cas de chevauchement des options : `--pin` bat `--next=` bat `--channel` / `--all-*` bat le défaut du registre (`stable`).
|
||||
Priorité en cas de chevauchement des options : `--pin` bat `--next=` bat `--channel` / `--all-*` bat le défaut du registre (`stable`).
|
||||
|
||||
:::note[Exemple de résolution]
|
||||
`--all-next --pin cis=v0.2.0` met bmb, gds et tea sur next tout en épinglant cis à v0.2.0.
|
||||
|
|
@ -143,13 +143,13 @@ Priorité en cas de chevauchement des options : `--pin` bat `--next=` bat `--cha
|
|||
|
||||
### Recettes
|
||||
|
||||
**Installation par défaut — dernière version stable pour tout :**
|
||||
**Installation par défaut — dernière version stable pour tout :**
|
||||
|
||||
```bash
|
||||
npx bmad-method install --yes --modules bmm,bmb,cis --tools claude-code
|
||||
```
|
||||
|
||||
**Installation entreprise verrouillée — reproductible à l’octet près :**
|
||||
**Installation entreprise verrouillée — reproductible à l’octet près :**
|
||||
|
||||
```bash
|
||||
npx bmad-method install --yes \
|
||||
|
|
@ -158,7 +158,7 @@ npx bmad-method install --yes \
|
|||
--tools claude-code
|
||||
```
|
||||
|
||||
**Bleeding edge — externes sur le HEAD de main :**
|
||||
**Bleeding edge — externes sur le HEAD de main :**
|
||||
|
||||
```bash
|
||||
npx bmad-method install --yes --modules bmm,bmb --all-next --tools claude-code
|
||||
|
|
@ -173,7 +173,7 @@ npx bmad-method install --yes --action update \
|
|||
|
||||
`--tools` est omis intentionnellement — `--action update` réutilise les outils configurés lors de la première installation.
|
||||
|
||||
**Mixer les canaux — bmb sur next, gds sur stable :**
|
||||
**Mixer les canaux — bmb sur next, gds sur stable :**
|
||||
|
||||
```bash
|
||||
npx bmad-method install --yes --action update \
|
||||
|
|
@ -183,9 +183,9 @@ npx bmad-method install --yes --action update \
|
|||
|
||||
### Substitutions de config de module
|
||||
|
||||
`--set <module>.<clé>=<valeur>` vous permet de définir toute option de config de module de manière non interactive. Cette option est répétable et s’adapte à chaque module — présent et futur. L’option est appliquée comme un correctif post-installation : l’installateur exécute d’abord son flux normal, puis `--set` insère ou met à jour chaque valeur dans `_bmad/config.toml` (portée équipe) ou `_bmad/config.user.toml` (portée utilisateur), et dans `_bmad/<module>/config.yaml` pour que les valeurs déclarées soient conservées à la prochaine installation.
|
||||
`--set <module>.<clé>=<valeur>` vous permet de définir toute option de config de module de manière non interactive. Cette option est répétable et s’adapte à chaque module — présent et futur. L’option est appliquée comme un correctif post-installation : l’installateur exécute d’abord son flux normal, puis `--set` insère ou met à jour chaque valeur dans `_bmad/config.toml` (portée équipe) ou `_bmad/config.user.toml` (portée utilisateur), et dans `_bmad/<module>/config.yaml` pour que les valeurs déclarées soient conservées à la prochaine installation.
|
||||
|
||||
**Exemple — installer bmm avec des connaissances projet et un niveau de compétence explicites :**
|
||||
**Exemple — installer bmm avec des connaissances projet et un niveau de compétence explicites :**
|
||||
|
||||
```bash
|
||||
npx bmad-method install --yes \
|
||||
|
|
@ -195,7 +195,7 @@ npx bmad-method install --yes \
|
|||
--set bmm.user_skill_level=expert
|
||||
```
|
||||
|
||||
**Découvrir les clés disponibles pour un module :**
|
||||
**Découvrir les clés disponibles pour un module :**
|
||||
|
||||
```bash
|
||||
npx bmad-method install --list-options bmm
|
||||
|
|
@ -203,10 +203,10 @@ npx bmad-method install --list-options bmm
|
|||
|
||||
`--list-options` (sans argument) liste chaque clé que l’installateur peut trouver localement — modules intégrés (`core`, `bmm`) plus tous les modules officiels actuellement en cache. Le cache est par machine et peut être vidé, donc les modules officiels précédemment installés n’apparaîtront pas sur un nouveau checkout ou un worker CI éphémère tant qu’ils ne sont pas réinstallés. Les modules communautaires et personnalisés ne sont pas énumérés ici ; lisez directement le `module.yaml` du module pour voir les clés qu’il déclare.
|
||||
|
||||
**Comment ça fonctionne :**
|
||||
**Comment ça fonctionne :**
|
||||
|
||||
- **Routage.** L’étape de correctif cherche `[modules.<module>] <clé>` (ou `[core] <clé>`) dans `config.user.toml` en premier ; si elle y est trouvée, elle met à jour ce fichier. Sinon elle écrit dans le `config.toml` de portée équipe. Ainsi, les clés de portée utilisateur (ex. `core.user_name`, `bmm.user_skill_level`) finissent dans `config.user.toml` et les clés de portée équipe dans `config.toml`, correspondant à la partition utilisée par l’installateur.
|
||||
- **Valeurs littérales.** La valeur est écrite exactement comme vous l’avez fournie — aucun rendu de template `result:`. Pour obtenir la valeur résolue (ex. `{project-root}/research`), passez-la explicitement : `--set bmm.project_knowledge='{project-root}/research'`.
|
||||
- **Valeurs littérales.** La valeur est écrite exactement comme vous l’avez fournie — aucun rendu de template `result:`. Pour obtenir la valeur résolue (ex. `{project-root}/research`), passez-la explicitement : `--set bmm.project_knowledge='{project-root}/research'`.
|
||||
- **Persistance, clés déclarées.** Les valeurs pour les clés déclarées dans `module.yaml` sont conservées entre les installations car elles sont aussi écrites dans `_bmad/<module>/config.yaml`, que l’installateur lit comme valeur par défaut de l’invite lors de la prochaine exécution.
|
||||
- **Persistance, clés non déclarées.** Une valeur pour une clé que le schéma du module ne déclare pas est enregistrée dans `config.toml` pour l’installation courante mais ne sera pas réécrite à la prochaine installation (le partitionneur strict au schéma du manifeste ignore les clés inconnues). Repassez `--set` pour qu’elle soit persistante, ou éditez `_bmad/config.toml` directement.
|
||||
- **Pas de validation.** Les valeurs `single-select` ne sont pas vérifiées contre les choix autorisés, et les clés inconnues ne sont pas rejetées — la valeur fournie est écrite telle quelle.
|
||||
|
|
@ -221,7 +221,7 @@ Les raccourcis historiques de core (`--user-name`, `--output-folder`, etc.) fonc
|
|||
:::caution[Limitation de débit sur les IPs partagées]
|
||||
Les appels anonymes à l’API GitHub sont limités à 60/heure par IP. Une seule installation fait un appel API par module externe pour résoudre le tag stable. Les bureaux derrière NAT, les pools de runners CI et les VPN peuvent collectivement épuiser cette limite.
|
||||
|
||||
Définissez `GITHUB_TOKEN=<personal access token>` dans l’environnement pour augmenter la limite à 5000/heure par compte. Tout PAT avec accès en lecture aux dépôts publics fonctionne ; aucune portée spécifique n’est requise.
|
||||
Définissez `GITHUB_TOKEN=<personal access token>` dans l’environnement pour augmenter la limite à 5 000/heure par compte. Tout PAT avec accès en lecture aux dépôts publics fonctionne ; aucune portée spécifique n’est requise.
|
||||
:::
|
||||
|
||||
## Ce qui a été installé
|
||||
|
|
|
|||
|
|
@ -109,10 +109,10 @@ Plusieurs sources peuvent être séparées par des virgules :
|
|||
|
||||
L’installateur utilise deux modes pour trouver les modules installables dans une source :
|
||||
|
||||
| Mode | Déclencheur | Comportement |
|
||||
| ----------- | ------------------------------------------------- | -------------------------------------------------------------------------------------------- |
|
||||
| Découverte | La source contient `.claude-plugin/marketplace.json` | Liste tous les plugins du manifeste ; vous choisissez lesquels installer |
|
||||
| Direct | Aucun `marketplace.json` trouvé | Analyse le répertoire pour trouver des skills (sous-répertoires avec `SKILL.md`), les résout en un module unique |
|
||||
| Mode | Déclencheur | Comportement |
|
||||
|------------|------------------------------------------------------|------------------------------------------------------------------------------------------------------------------|
|
||||
| Découverte | La source contient `.claude-plugin/marketplace.json` | Liste tous les plugins du manifeste ; vous choisissez lesquels installer |
|
||||
| Direct | Aucun `marketplace.json` trouvé | Analyse le répertoire pour trouver des skills (sous-répertoires avec `SKILL.md`), les résout en un module unique |
|
||||
|
||||
Le mode découverte est typique des modules publiés. Le mode direct est pratique pour pointer vers un répertoire de skills pendant le développement local.
|
||||
|
||||
|
|
@ -162,8 +162,8 @@ Le manifeste enregistre la source de chaque module personnalisé (`repoUrl` pour
|
|||
|
||||
Les modules personnalisés participent au flux de mise à jour normal :
|
||||
|
||||
- **Mise à jour rapide** (`--action quick-update`) : Rafraîchit tous les modules depuis leurs sources d’origine. Les modules Git sont re-téléchargés ; les modules locaux sont relus depuis leur chemin source.
|
||||
- **Mise à jour complète** : Relance la sélection de modules pour que vous puissiez ajouter ou retirer des modules personnalisés.
|
||||
- **Mise à jour rapide** (`--action quick-update`) : Rafraîchit tous les modules depuis leurs sources d’origine. Les modules Git sont re-téléchargés ; les modules locaux sont relus depuis leur chemin source.
|
||||
- **Mise à jour complète** : Relance la sélection de modules pour que vous puissiez ajouter ou retirer des modules personnalisés.
|
||||
|
||||
## Créer vos propres modules
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ Utilisez le fichier `project-context.md` pour garantir que les agents IA respect
|
|||
- Vous travaillez sur une base de code existante avec des patterns établis
|
||||
- Vous remarquez que les agents prennent des décisions incohérentes entre les stories
|
||||
|
||||
## Étape 1 : Choisissez votre approche
|
||||
## Étape 1 : Choisissez votre approche
|
||||
|
||||
**Création manuelle** — Idéal lorsque vous savez exactement quelles règles vous souhaitez documenter
|
||||
|
||||
|
|
@ -27,9 +27,9 @@ Utilisez le fichier `project-context.md` pour garantir que les agents IA respect
|
|||
|
||||
**Génération pour les projets existants** — Idéal pour découvrir les patterns dans les bases de code existantes
|
||||
|
||||
## Étape 2 : Créez le fichier
|
||||
## Étape 2 : Créez le fichier
|
||||
|
||||
### Option A : Création manuelle
|
||||
### Option A : Création manuelle
|
||||
|
||||
Créez le fichier à l’emplacement `_bmad-output/project-context.md` :
|
||||
|
||||
|
|
@ -72,7 +72,7 @@ sections_completed: ['technology_stack', 'critical_rules']
|
|||
- Tests d'intégration utilisent MSW pour le mock API
|
||||
```
|
||||
|
||||
### Option B : Génération après l’architecture
|
||||
### Option B : Génération après l’architecture
|
||||
|
||||
Exécutez le workflow dans une nouvelle conversation :
|
||||
|
||||
|
|
@ -82,7 +82,7 @@ bmad-generate-project-context
|
|||
|
||||
Le workflow analyse votre document d’architecture et vos fichiers projet pour générer un fichier de contexte qui capture les décisions prises.
|
||||
|
||||
### Option C : Génération pour les projets existants
|
||||
### Option C : Génération pour les projets existants
|
||||
|
||||
Pour les projets existants, exécutez :
|
||||
|
||||
|
|
@ -92,7 +92,7 @@ bmad-generate-project-context
|
|||
|
||||
Le workflow analyse votre base de code pour identifier les conventions, puis génère un fichier de contexte que vous pouvez réviser et affiner.
|
||||
|
||||
## Étape 3 : Vérifiez le contenu
|
||||
## Étape 3 : Vérifiez le contenu
|
||||
|
||||
Révisez le fichier généré et assurez-vous qu’il capture :
|
||||
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ Les nouveaux skills v6 sont installés dans :
|
|||
|
||||
### 4. Migrer les artefacts de planification
|
||||
|
||||
**Si vous avez des documents de planification (Brief/PRD/UX/Architecture) :**
|
||||
**Si vous avez des documents de planification (Brief/PRD/UX/Architecture) :**
|
||||
|
||||
Déplacez-les dans `_bmad-output/planning-artifacts/` avec des noms descriptifs :
|
||||
|
||||
|
|
@ -53,7 +53,7 @@ Déplacez-les dans `_bmad-output/planning-artifacts/` avec des noms descriptifs
|
|||
- Incluez `brief`, `architecture`, ou `ux-design` selon le cas
|
||||
- Les documents divisés peuvent être dans des sous-dossiers au nom descriptif
|
||||
|
||||
**Si vous êtes en cours de planification :** Envisagez de recommencer avec les workflows v6. Utilisez vos documents existants comme entrées — les nouveaux workflows de découverte progressive avec recherche web et le mode plan de l’IDE produisent de meilleurs résultats.
|
||||
**Si vous êtes en cours de planification :** Envisagez de recommencer avec les workflows v6. Utilisez vos documents existants comme entrées — les nouveaux workflows de découverte progressive avec recherche web et le mode plan de l’IDE produisent de meilleurs résultats.
|
||||
|
||||
### 5. Migrer le développement en cours
|
||||
|
||||
|
|
@ -66,7 +66,7 @@ Si vous avez des stories[^3] créées ou implémentées :
|
|||
|
||||
## Résultat de la migration
|
||||
|
||||
**Structure unifiée v6 :**
|
||||
**Structure unifiée v6 :**
|
||||
|
||||
```text
|
||||
votre-projet/
|
||||
|
|
@ -82,22 +82,22 @@ votre-projet/
|
|||
|
||||
## Migration des modules
|
||||
|
||||
| Module v4 | Statut v6 |
|
||||
| ----------------------------- | ------------------------------------------------------ |
|
||||
| `.bmad-2d-phaser-game-dev` | Intégré dans le Module BMGD |
|
||||
| `.bmad-2d-unity-game-dev` | Intégré dans le Module BMGD |
|
||||
| `.bmad-godot-game-dev` | Intégré dans le Module BMGD |
|
||||
| `.bmad-infrastructure-devops` | Obsolète — nouvel agent DevOps bientôt disponible |
|
||||
| `.bmad-creative-writing` | Non migré — nouveau module v6 bientôt disponible |
|
||||
| Module v4 | Statut v6 |
|
||||
|-------------------------------|---------------------------------------------------|
|
||||
| `.bmad-2d-phaser-game-dev` | Intégré dans le Module BMGD |
|
||||
| `.bmad-2d-unity-game-dev` | Intégré dans le Module BMGD |
|
||||
| `.bmad-godot-game-dev` | Intégré dans le Module BMGD |
|
||||
| `.bmad-infrastructure-devops` | Obsolète — nouvel agent DevOps bientôt disponible |
|
||||
| `.bmad-creative-writing` | Non migré — nouveau module v6 bientôt disponible |
|
||||
|
||||
## Changements clés
|
||||
|
||||
| Concept | v4 | v6 |
|
||||
| ------------- | ------------------------------------- | ------------------------------------ |
|
||||
| Concept | v4 | v6 |
|
||||
|---------------|---------------------------------------------------------|------------------------------------------|
|
||||
| **Core** | `_bmad-core` correspondait en réalité à la méthode BMad | `_bmad/core/` est le framework universel |
|
||||
| **Method** | `_bmad-method` | `_bmad/bmm/` |
|
||||
| **Config** | Fichiers modifiés directement | `config.yaml` par module |
|
||||
| **Documents** | Division en fragments obligatoire ou optionnelle | Totalement flexible, analyse automatique |
|
||||
| **Method** | `_bmad-method` | `_bmad/bmm/` |
|
||||
| **Config** | Fichiers modifiés directement | `config.yaml` par module |
|
||||
| **Documents** | Division en fragments obligatoire ou optionnelle | Totalement flexible, analyse automatique |
|
||||
|
||||
|
||||
## Glossaire
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ BMad fonctionne avec tout assistant de codage IA qui prend en charge les prompts
|
|||
- **[Cursor](https://cursor.sh)** — Éditeur de code propulsé par l’IA
|
||||
- **[Codex CLI](https://github.com/openai/codex)** — Agent de codage en ligne de commande d’OpenAI
|
||||
|
||||
Vous devriez être à l’aise avec les concepts de base du développement logiciel : gestion de versions, structure de projet et méthodologies agiles. Aucune expérience préalable des systèmes d’agents de type BMad n’est requise — c’est précisément l’objet de cette documentation.
|
||||
Vous devriez être à l’aise avec les concepts de base du développement logiciel : gestion de versions, structure de projet et méthodologies agiles. Aucune expérience préalable des systèmes d’agents de type BMad n’est requise — c’est précisément l’objet de cette documentation.
|
||||
|
||||
## Rejoindre la communauté
|
||||
|
||||
|
|
|
|||
|
|
@ -32,21 +32,21 @@ Les déclencheurs de menu d’agent utilisent deux types d’invocation différe
|
|||
|
||||
La plupart des déclencheurs chargent un fichier de workflow structuré. Tapez le code du déclencheur et l’agent démarre le workflow, vous demandant de saisir les informations à chaque étape.
|
||||
|
||||
Exemples : `CP` (Create PRD), `DS` (Dev Story), `CA` (Create Architecture), `QD` (Quick Dev)
|
||||
Exemples : `CP` (Create PRD), `DS` (Dev Story), `CA` (Create Architecture), `QD` (Quick Dev)
|
||||
|
||||
### Déclencheurs conversationnels (arguments requis)
|
||||
|
||||
Certains déclencheurs lancent une conversation libre au lieu d’un workflow structuré. Ils s’attendent à ce que vous décriviez ce dont vous avez besoin à côté du code du déclencheur.
|
||||
|
||||
| Agent | Déclencheur | Ce qu’il faut fournir |
|
||||
| --- | --- | --- |
|
||||
| Rédacteur Technique (Paige) | `WD` | Description du document à rédiger |
|
||||
| Rédacteur Technique (Paige) | `US` | Préférences ou conventions à ajouter aux standards |
|
||||
| Rédacteur Technique (Paige) | `MG` | Description et type de diagramme (séquence, organigramme, etc.) |
|
||||
| Rédacteur Technique (Paige) | `VD` | Document à valider et domaines à examiner |
|
||||
| Rédacteur Technique (Paige) | `EC` | Nom du concept à expliquer |
|
||||
| Agent | Déclencheur | Ce qu’il faut fournir |
|
||||
|-----------------------------|-------------|-----------------------------------------------------------------|
|
||||
| Rédacteur Technique (Paige) | `WD` | Description du document à rédiger |
|
||||
| Rédacteur Technique (Paige) | `US` | Préférences ou conventions à ajouter aux standards |
|
||||
| Rédacteur Technique (Paige) | `MG` | Description et type de diagramme (séquence, organigramme, etc.) |
|
||||
| Rédacteur Technique (Paige) | `VD` | Document à valider et domaines à examiner |
|
||||
| Rédacteur Technique (Paige) | `EC` | Nom du concept à expliquer |
|
||||
|
||||
**Exemple :**
|
||||
**Exemple :**
|
||||
|
||||
```text
|
||||
WD Rédige un guide de déploiement pour notre configuration Docker
|
||||
|
|
|
|||
|
|
@ -11,9 +11,9 @@ Les skills sont des prompts pré-construits qui chargent des agents, exécutent
|
|||
|
||||
BMad offre deux façons de démarrer un travail, chacune ayant un usage différent.
|
||||
|
||||
| Mécanisme | Comment l’invoquer | Ce qui se passe |
|
||||
| --- | --- | --- |
|
||||
| **Skill** | Tapez le nom du skill (ex. `bmad-help`) dans votre IDE | Charge directement un agent, exécute un workflow ou lance une tâche |
|
||||
| Mécanisme | Comment l’invoquer | Ce qui se passe |
|
||||
|-------------------------------|---------------------------------------------------------------|------------------------------------------------------------------------------------------------|
|
||||
| **Skill** | Tapez le nom du skill (ex. `bmad-help`) dans votre IDE | Charge directement un agent, exécute un workflow ou lance une tâche |
|
||||
| **Déclencheur du menu agent** | Chargez d’abord un agent, puis tapez un code court (ex. `DS`) | L’agent interprète le code et démarre le workflow correspondant tout en préservant son persona |
|
||||
|
||||
Les déclencheurs du menu agent nécessitent une session agent active. Utilisez les skills lorsque vous savez quel workflow vous voulez. Utilisez les déclencheurs lorsque vous travaillez déjà avec un agent et souhaitez changer de tâche sans quitter la conversation.
|
||||
|
|
@ -24,12 +24,12 @@ Lorsque vous exécutez `npx bmad-method install`, l’installateur lit les manif
|
|||
|
||||
L’installateur utilise des modèles pour chaque type de skill :
|
||||
|
||||
| Type de skill | Ce que fait le fichier généré |
|
||||
| --- | --- |
|
||||
| **Lanceur d’agent** | Charge le fichier de persona de l’agent, active son menu et reste en caractère |
|
||||
| **Skill de workflow** | Charge la configuration du workflow et suit ses étapes |
|
||||
| **Skill de tâche** | Charge un fichier de tâche autonome et suit ses instructions |
|
||||
| **Skill d’outil** | Charge un fichier d’outil autonome et suit ses instructions |
|
||||
| Type de skill | Ce que fait le fichier généré |
|
||||
|-----------------------|--------------------------------------------------------------------------------|
|
||||
| **Lanceur d’agent** | Charge le fichier de persona de l’agent, active son menu et reste en caractère |
|
||||
| **Skill de workflow** | Charge la configuration du workflow et suit ses étapes |
|
||||
| **Skill de tâche** | Charge un fichier de tâche autonome et suit ses instructions |
|
||||
| **Skill d’outil** | Charge un fichier d’outil autonome et suit ses instructions |
|
||||
|
||||
:::note[Relancer l’installateur]
|
||||
Si vous ajoutez ou supprimez des modules, relancez l’installateur. Il régénère tous les fichiers de skill pour correspondre à votre sélection actuelle de modules.
|
||||
|
|
@ -39,12 +39,12 @@ Si vous ajoutez ou supprimez des modules, relancez l’installateur. Il régén
|
|||
|
||||
L’installateur écrit les fichiers de skill dans un répertoire spécifique à l’IDE à l’intérieur de votre projet. Le chemin exact dépend de l’IDE que vous avez sélectionné lors de l’installation.
|
||||
|
||||
| IDE / CLI | Répertoire des skills |
|
||||
| --- | --- |
|
||||
| Claude Code | `.claude/skills/` |
|
||||
| Cursor | `.cursor/skills/` |
|
||||
| Windsurf | `.windsurf/skills/` |
|
||||
| Autres IDE | Consultez la sortie de l’installateur pour le chemin cible |
|
||||
| IDE / CLI | Répertoire des skills |
|
||||
|-------------|------------------------------------------------------------|
|
||||
| Claude Code | `.claude/skills/` |
|
||||
| Cursor | `.cursor/skills/` |
|
||||
| Windsurf | `.windsurf/skills/` |
|
||||
| Autres IDE | Consultez la sortie de l’installateur pour le chemin cible |
|
||||
|
||||
Chaque skill est un répertoire contenant un fichier `SKILL.md`. Par exemple, une installation Claude Code ressemble à :
|
||||
|
||||
|
|
@ -89,16 +89,16 @@ Consultez [Agents](./agents.md) pour la liste complète des agents par défaut e
|
|||
|
||||
Les skills de workflow exécutent un processus structuré en plusieurs étapes sans charger d’abord un persona d’agent. Ils chargent une configuration de workflow et suivent ses étapes.
|
||||
|
||||
| Exemple de skill | Objectif |
|
||||
| --- | --- |
|
||||
| `bmad-product-brief` | Créer ou mettre à jour un product brief[^3] — découverte guidée lorsque votre concept est clair |
|
||||
| `bmad-prfaq` | Défi [PRFAQ Working Backwards](../explanation/analysis-phase.md#prfaq-working-backwards) pour éprouver votre concept produit |
|
||||
| `bmad-prd` | Créer, mettre à jour ou valider un PRD[^1] |
|
||||
| `bmad-create-architecture` | Concevoir l’architecture système |
|
||||
| `bmad-create-epics-and-stories` | Créer des epics et des stories |
|
||||
| `bmad-dev-story` | Implémenter une story |
|
||||
| `bmad-code-review` | Effectuer une revue de code |
|
||||
| `bmad-quick-dev` | Flux rapide unifié — clarifier l’intention, planifier, implémenter, réviser, présenter |
|
||||
| Exemple de skill | Objectif |
|
||||
|---------------------------------|------------------------------------------------------------------------------------------------------------------------------|
|
||||
| `bmad-product-brief` | Créer ou mettre à jour un product brief[^3] — découverte guidée lorsque votre concept est clair |
|
||||
| `bmad-prfaq` | Défi [PRFAQ Working Backwards](../explanation/analysis-phase.md#prfaq-working-backwards) pour éprouver votre concept produit |
|
||||
| `bmad-prd` | Créer, mettre à jour ou valider un PRD[^1] |
|
||||
| `bmad-create-architecture` | Concevoir l’architecture système |
|
||||
| `bmad-create-epics-and-stories` | Créer des epics et des stories |
|
||||
| `bmad-dev-story` | Implémenter une story |
|
||||
| `bmad-code-review` | Effectuer une revue de code |
|
||||
| `bmad-quick-dev` | Flux rapide unifié — clarifier l’intention, planifier, implémenter, réviser, présenter |
|
||||
|
||||
Consultez la [Carte des workflows](./workflow-map.md) pour la référence complète des workflows organisés par phase.
|
||||
|
||||
|
|
@ -106,7 +106,7 @@ Consultez la [Carte des workflows](./workflow-map.md) pour la référence compl
|
|||
|
||||
Les tâches et outils sont des opérations autonomes qui ne nécessitent pas de contexte d’agent ou de workflow.
|
||||
|
||||
**BMad-Help : Votre guide intelligent**
|
||||
**BMad-Help : Votre guide intelligent**
|
||||
|
||||
`bmad-help` est votre interface principale pour découvrir quoi faire ensuite. Il inspecte votre projet, comprend les requêtes en langage naturel et recommande la prochaine étape requise ou optionnelle en fonction de vos modules installés.
|
||||
|
||||
|
|
|
|||
|
|
@ -15,11 +15,11 @@ Exécutez `npx bmad-method install` et sélectionnez les modules souhaités. L
|
|||
|
||||
Créez des agents personnalisés, des workflows et des modules spécifiques à un domaine avec une assistance guidée. BMad Builder est le méta-module pour étendre le framework lui-même.
|
||||
|
||||
- **Code :** `bmb`
|
||||
- **npm :** [`bmad-builder`](https://www.npmjs.com/package/bmad-builder)
|
||||
- **GitHub :** [bmad-code-org/bmad-builder](https://github.com/bmad-code-org/bmad-builder)
|
||||
- **Code :** `bmb`
|
||||
- **npm :** [`bmad-builder`](https://www.npmjs.com/package/bmad-builder)
|
||||
- **GitHub :** [bmad-code-org/bmad-builder](https://github.com/bmad-code-org/bmad-builder)
|
||||
|
||||
**Fournit :**
|
||||
**Fournit :**
|
||||
|
||||
- Agent Builder — créez des agents IA spécialisés avec une expertise et un accès aux outils personnalisés
|
||||
- Workflow Builder — concevez des processus structurés avec des étapes et des points de décision
|
||||
|
|
@ -30,11 +30,11 @@ Créez des agents personnalisés, des workflows et des modules spécifiques à u
|
|||
|
||||
Outils basés sur l’IA pour la créativité structurée, l’idéation et l’innovation pendant le développement en phase amont. La suite fournit plusieurs agents qui facilitent le brainstorming, le design thinking et la résolution de problèmes en utilisant des cadres éprouvés.
|
||||
|
||||
- **Code :** `cis`
|
||||
- **npm :** [`bmad-creative-intelligence-suite`](https://www.npmjs.com/package/bmad-creative-intelligence-suite)
|
||||
- **GitHub :** [bmad-code-org/bmad-module-creative-intelligence-suite](https://github.com/bmad-code-org/bmad-module-creative-intelligence-suite)
|
||||
- **Code :** `cis`
|
||||
- **npm :** [`bmad-creative-intelligence-suite`](https://www.npmjs.com/package/bmad-creative-intelligence-suite)
|
||||
- **GitHub :** [bmad-code-org/bmad-module-creative-intelligence-suite](https://github.com/bmad-code-org/bmad-module-creative-intelligence-suite)
|
||||
|
||||
**Fournit :**
|
||||
**Fournit :**
|
||||
|
||||
- Agents Innovation Strategist, Design Thinking Coach et Brainstorming Coach
|
||||
- Problem Solver et Creative Problem Solver pour la pensée systématique et latérale
|
||||
|
|
@ -45,11 +45,11 @@ Outils basés sur l’IA pour la créativité structurée, l’idéation et l’
|
|||
|
||||
Workflows de développement de jeux structurés adaptés pour Unity, Unreal, Godot et moteurs personnalisés. Supporte le prototypage rapide via Quick Dev et la production à grande échelle avec des sprints propulsés par epics.
|
||||
|
||||
- **Code :** `gds`
|
||||
- **npm :** [`bmad-game-dev-studio`](https://www.npmjs.com/package/bmad-game-dev-studio)
|
||||
- **GitHub :** [bmad-code-org/bmad-module-game-dev-studio](https://github.com/bmad-code-org/bmad-module-game-dev-studio)
|
||||
- **Code :** `gds`
|
||||
- **npm :** [`bmad-game-dev-studio`](https://www.npmjs.com/package/bmad-game-dev-studio)
|
||||
- **GitHub :** [bmad-code-org/bmad-module-game-dev-studio](https://github.com/bmad-code-org/bmad-module-game-dev-studio)
|
||||
|
||||
**Fournit :**
|
||||
**Fournit :**
|
||||
|
||||
- Workflow de génération de Document de Design de Jeu (GDD[^3])
|
||||
- Mode Quick Dev pour le prototypage rapide
|
||||
|
|
@ -60,11 +60,11 @@ Workflows de développement de jeux structurés adaptés pour Unity, Unreal, God
|
|||
|
||||
Stratégie de test de niveau entreprise, conseils d’automatisation et décisions de porte de release via un agent expert et neuf workflows structurés. TEA va bien au-delà du workflow QA intégré avec une priorisation basée sur les risques et une traçabilité des exigences.
|
||||
|
||||
- **Code :** `tea`
|
||||
- **npm :** [`bmad-method-test-architecture-enterprise`](https://www.npmjs.com/package/bmad-method-test-architecture-enterprise)
|
||||
- **GitHub :** [bmad-code-org/bmad-method-test-architecture-enterprise](https://github.com/bmad-code-org/bmad-method-test-architecture-enterprise)
|
||||
- **Code :** `tea`
|
||||
- **npm :** [`bmad-method-test-architecture-enterprise`](https://www.npmjs.com/package/bmad-method-test-architecture-enterprise)
|
||||
- **GitHub :** [bmad-code-org/bmad-method-test-architecture-enterprise](https://github.com/bmad-code-org/bmad-method-test-architecture-enterprise)
|
||||
|
||||
**Fournit :**
|
||||
**Fournit :**
|
||||
|
||||
- Agent Murat (Master Test Architect and Quality Advisor)
|
||||
- Workflows pour la conception de tests, ATDD, l’automatisation, la revue de tests et la traçabilité
|
||||
|
|
|
|||
|
|
@ -5,14 +5,14 @@ sidebar:
|
|||
order: 6
|
||||
---
|
||||
|
||||
BMad propose deux approches de test : un workflow QA[^1] intégré pour une génération rapide de tests et un module Test Architect installable pour une stratégie de test de qualité entreprise.
|
||||
BMad propose deux approches de test : un workflow QA[^1] intégré pour une génération rapide de tests et un module Test Architect installable pour une stratégie de test de qualité entreprise.
|
||||
|
||||
## Lequel Choisir ?
|
||||
|
||||
| Facteur | QA Intégré | Module TEA |
|
||||
| Facteur | QA Intégré | Module TEA |
|
||||
|-------------------------|----------------------------------------------|---------------------------------------------------------------------|
|
||||
| **Idéal pour** | Projets petits et moyens, couverture rapide | Grands projets, domaines réglementés ou complexes |
|
||||
| **Installation** | Rien à installer — inclus dans BMM | Installer séparément via `npx bmad-method install` |
|
||||
| **Installation** | Rien à installer — inclus dans BMM | Installer séparément via `npx bmad-method install` |
|
||||
| **Approche** | Générer les tests rapidement, itérer ensuite | Planifier d’abord, puis générer avec traçabilité |
|
||||
| **Types de tests** | Tests API et E2E | API, E2E, ATDD[^2], NFR, et plus |
|
||||
| **Stratégie** | Chemin nominal + cas limites critiques | Priorisation basée sur les risques (P0-P3) |
|
||||
|
|
@ -26,7 +26,7 @@ La plupart des projets devraient commencer avec le workflow QA intégré. Si vou
|
|||
|
||||
Le workflow QA intégré (`bmad-qa-generate-e2e-tests`) fait partie du module BMM (suite Agile), disponible via l’agent Developer. Il génère rapidement des tests fonctionnels en utilisant le framework de test existant de votre projet — aucune configuration ni installation supplémentaire requise.
|
||||
|
||||
**Déclencheur :** `QA` (via l’agent Developer) ou `bmad-qa-generate-e2e-tests`
|
||||
**Déclencheur :** `QA` (via l’agent Developer) ou `bmad-qa-generate-e2e-tests`
|
||||
|
||||
### Ce que le Workflow QA Fait
|
||||
|
||||
|
|
@ -65,9 +65,9 @@ Le workflow QA génère uniquement des tests. Pour la revue de code et la valida
|
|||
|
||||
TEA est un module autonome qui fournit un agent expert (Murat) et neuf workflows structurés pour des tests de qualité entreprise. Il va au-delà de la génération de tests pour inclure la stratégie de test, la planification basée sur les risques, les murs de qualité et la traçabilité des exigences.
|
||||
|
||||
- **Documentation :** [TEA Module Docs](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/)
|
||||
- **Installation :** `npx bmad-method install` et sélectionnez le module TEA
|
||||
- **npm :** [`bmad-method-test-architecture-enterprise`](https://www.npmjs.com/package/bmad-method-test-architecture-enterprise)
|
||||
- **Documentation :** [TEA Module Docs](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/)
|
||||
- **Installation :** `npx bmad-method install` et sélectionnez le module TEA
|
||||
- **npm :** [`bmad-method-test-architecture-enterprise`](https://www.npmjs.com/package/bmad-method-test-architecture-enterprise)
|
||||
|
||||
### Ce que TEA Fournit
|
||||
|
||||
|
|
@ -97,8 +97,8 @@ TEA supporte également la priorisation basée sur les risques P0-P3 et des int
|
|||
|
||||
Le workflow Automate du QA intégré apparaît dans la Phase 4 (Implémentation) de la carte de workflow méthode BMad. Il est conçu pour s’exécuter **après qu’un epic complet soit terminé** — une fois que toutes les stories d’un epic ont été implémentées et revues. Une séquence typique :
|
||||
|
||||
1. Pour chaque story de l’epic : implémenter avec Dev Story (`DS`), puis valider avec Code Review (`CR`)
|
||||
2. Après la fin de l’epic : générer les tests avec `QA` (via l’agent Developer) ou le workflow Automate de TEA
|
||||
1. Pour chaque story de l’epic : implémenter avec Dev Story (`DS`), puis valider avec Code Review (`CR`)
|
||||
2. Après la fin de l’epic : générer les tests avec `QA` (via l’agent Developer) ou le workflow Automate de TEA
|
||||
3. Lancer la rétrospective (`bmad-retrospective`) pour capturer les leçons apprises
|
||||
|
||||
Le workflow QA travaille directement à partir du code source sans charger les documents de planification (PRD, architecture). Les workflows TEA peuvent s’intégrer avec les artefacts de planification en amont pour la traçabilité.
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ la méthode BMad. Par ailleurs, si vous utilisez des modules ayant étendu la m
|
|||
complémentaires non extensibles, `bmad-help` s’adapte automatiquement pour couvrir tout ce qui est disponible et vous
|
||||
fournir les meilleurs conseils en temps réel.
|
||||
|
||||
Note importante : chaque workflow ci-dessous peut être exécuté directement via un skill avec l’outil de votre choix, ou
|
||||
Note importante : chaque workflow ci-dessous peut être exécuté directement via un skill avec l’outil de votre choix, ou
|
||||
en chargeant d’abord un agent depuis le menu des agents.
|
||||
|
||||
<iframe src="/workflow-map-diagram-fr.html" title="Diagramme de la carte des workflows de la méthode BMad" width="100%" height="100%" style="border-radius: 8px; border: 1px solid #334155; min-height: 900px;"></iframe>
|
||||
|
|
@ -29,7 +29,7 @@ en chargeant d’abord un agent depuis le menu des agents.
|
|||
<a href="/workflow-map-diagram-fr.html" target="_blank" rel="noopener noreferrer">Ouvrir le diagramme dans un nouvel onglet ↗</a>
|
||||
</p>
|
||||
|
||||
## Phase 1 : Analyse (Optionnelle)
|
||||
## Phase 1 : Analyse (Optionnelle)
|
||||
|
||||
Explorez l’espace problème et validez vos idées avant de vous lancer dans la planification. [**Découvrez ce que fait
|
||||
chaque outil et quand l’utiliser**](../explanation/analysis-phase.md).
|
||||
|
|
@ -41,13 +41,13 @@ chaque outil et quand l’utiliser**](../explanation/analysis-phase.md).
|
|||
| `bmad-product-brief` | Formalisez la vision stratégique — idéal lorsque votre concept est bien défini | `product-brief.md` |
|
||||
| `bmad-prfaq` | Working Backwards — mettez à l’épreuve et affinez votre concept produit | `prfaq-{project}.md` |
|
||||
|
||||
## Phase 2 : Planification
|
||||
## Phase 2 : Planification
|
||||
|
||||
Définissez ce qu’il faut construire et pour qui.
|
||||
|
||||
| Workflow | Objectif | Livrable |
|
||||
|------------|--------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------|
|
||||
| `bmad-prd` | Créez, mettez à jour ou validez un PRD[^1] — découverte accompagnée, trois intentions en un seul skill | Création/Mise à jour : `prd.md`, `addendum.md`, `decision-log.md` ; Validation : `validation-report.html` + `.md` |
|
||||
| `bmad-prd` | Créez, mettez à jour ou validez un PRD[^1] — découverte accompagnée, trois intentions en un seul skill | Création/Mise à jour : `prd.md`, `addendum.md`, `decision-log.md` ; Validation : `validation-report.html` + `.md` |
|
||||
| `bmad-ux` | Concevez l’expérience utilisateur (lorsque l’UX compte) | `DESIGN.md`, `EXPERIENCE.md` |
|
||||
|
||||
:::tip[Trois intentions en un seul skill]
|
||||
|
|
@ -58,21 +58,21 @@ Définissez ce qu’il faut construire et pour qui.
|
|||
- **Valider** — évalue un PRD à l’aide d’une liste de contrôle configurable et produit un rapport de constats structuré au format HTML
|
||||
:::
|
||||
|
||||
:::tip[En amont : `bmad-product-brief`]
|
||||
:::tip[En amont : `bmad-product-brief`]
|
||||
`bmad-product-brief` (Phase 1) produit un `product-brief.md` que `bmad-prd` peut exploiter lors de la découverte, réduisant les redondances et gardant les deux documents alignés. Aucun des deux skills ne nécessite l’autre — commencez directement par `bmad-prd` si vous savez déjà ce que vous construisez.
|
||||
:::
|
||||
|
||||
## Phase 3 : Conception de la Solution
|
||||
## Phase 3 : Conception de la Solution
|
||||
|
||||
Décidez comment le construire et décomposez le travail en stories.
|
||||
|
||||
| Workflow | Objectif | Livrable |
|
||||
|---------------------------------------|---------------------------------------------------|--------------------------------|
|
||||
| `bmad-create-architecture` | Rendez explicites les décisions techniques | `architecture.md` avec ADRs[^2] |
|
||||
| `bmad-create-epics-and-stories` | Décomposez les exigences en tâches implémentables | Fichiers d’epic avec stories |
|
||||
| `bmad-check-implementation-readiness` | Jalon de validation avant implémentation | Décision OK / RÉSERVES / ÉCHEC |
|
||||
| Workflow | Objectif | Livrable |
|
||||
|---------------------------------------|---------------------------------------------------|---------------------------------|
|
||||
| `bmad-create-architecture` | Rendez explicites les décisions techniques | `architecture.md` avec ADRs[^2] |
|
||||
| `bmad-create-epics-and-stories` | Décomposez les exigences en tâches implémentables | Fichiers d’epic avec stories |
|
||||
| `bmad-check-implementation-readiness` | Jalon de validation avant implémentation | Décision OK / RÉSERVES / ÉCHEC |
|
||||
|
||||
## Phase 4 : Implémentation
|
||||
## Phase 4 : Implémentation
|
||||
|
||||
Construisez, une story à la fois. L’automatisation complète de la phase 4 arrive bientôt !
|
||||
|
||||
|
|
@ -110,7 +110,7 @@ optionnel peut être généré à la fin de la création de l’architecture, ou
|
|||
éléments clés et les garder alignés avec les conventions en vigueur.
|
||||
:::
|
||||
|
||||
**Comment le créer :**
|
||||
**Comment le créer :**
|
||||
|
||||
- **Manuellement** — Créez `_bmad-output/project-context.md` avec votre stack technique et vos règles d’implémentation
|
||||
- **Générez-le** — Exécutez `bmad-generate-project-context` pour l’auto-générer à partir de votre architecture ou de votre codebase
|
||||
|
|
|
|||
|
|
@ -26,14 +26,14 @@ Accélérez le développement de vos applications grâce à des workflows alimen
|
|||
**Développez** → Laissez BMad-Help vous guider, workflow par workflow
|
||||
:::
|
||||
|
||||
## Découvrez BMad-Help : votre guide intelligent
|
||||
## Découvrez BMad-Help : votre guide intelligent
|
||||
|
||||
**BMad-Help est le moyen le plus rapide de démarrer avec BMad.** Pas besoin de mémoriser les workflows ou les phases — posez simplement votre question et BMad-Help saura :
|
||||
|
||||
- **Inspecter votre projet** pour voir ce qui a déjà été fait
|
||||
- **Vous présenter vos options** en fonction des modules installés
|
||||
- **Vous recommander la prochaine étape** — y compris la première tâche obligatoire
|
||||
- **Répondre à vos questions**, par exemple : « J’ai une idée de SaaS, par où commencer ? »
|
||||
- **Répondre à vos questions**, par exemple : « J’ai une idée de SaaS, par où commencer ? »
|
||||
|
||||
### Comment utiliser BMad-Help
|
||||
|
||||
|
|
@ -57,7 +57,7 @@ BMad-Help vous indiquera :
|
|||
|
||||
### Il intervient aussi dans les workflows
|
||||
|
||||
BMad-Help ne se contente pas de répondre aux questions — **il se lance automatiquement à la fin de chaque workflow** pour vous indiquer exactement la suite. Finies les devinettes et les recherches dans la doc : vous recevez des instructions claires sur le prochain workflow à exécuter.
|
||||
BMad-Help ne se contente pas de répondre aux questions — **il se lance automatiquement à la fin de chaque workflow** pour vous indiquer exactement la suite. Finies les devinettes et les recherches dans la doc : vous recevez des instructions claires sur le prochain workflow à exécuter.
|
||||
|
||||
:::tip[Commencez ici]
|
||||
Après avoir installé BMad, invoquez immédiatement le skill `bmad-help`. Il détectera les modules que vous avez installés et vous orientera vers le bon point de départ pour votre projet.
|
||||
|
|
@ -123,7 +123,7 @@ Chaque workflow possède une **skill** que vous invoquez par son nom dans votre
|
|||
Démarrez toujours un nouveau chat pour chaque workflow. Cela évite les problèmes liés aux limites de contexte de l’IA.
|
||||
:::
|
||||
|
||||
## Étape 1 : Élaborer votre plan
|
||||
## Étape 1 : Élaborer votre plan
|
||||
|
||||
Parcourez les phases 1 à 3. **Utilisez un nouveau chat pour chaque workflow.**
|
||||
|
||||
|
|
@ -133,7 +133,7 @@ Avant de commencer, pensez à créer `project-context.md` pour documenter vos pr
|
|||
Créez-le manuellement à l’emplacement `_bmad-output/project-context.md`, ou générez-le après l’architecture avec `bmad-generate-project-context`. [En savoir plus](../explanation/project-context.md).
|
||||
:::
|
||||
|
||||
### Phase 1 : Analyse (optionnelle)
|
||||
### Phase 1 : Analyse (optionnelle)
|
||||
|
||||
Tous les workflows de cette phase sont optionnels. [**Vous ne savez pas lequel choisir ?**](../explanation/analysis-phase.md)
|
||||
|
||||
|
|
@ -142,12 +142,12 @@ Tous les workflows de cette phase sont optionnels. [**Vous ne savez pas lequel c
|
|||
- **product-brief** (`bmad-product-brief`) — Document fondateur recommandé une fois votre concept bien défini
|
||||
- **prfaq** (`bmad-prfaq`) — Exercice Working Backwards pour tester et affiner votre concept produit
|
||||
|
||||
### Phase 2 : Planification (requise)
|
||||
### Phase 2 : Planification (requise)
|
||||
|
||||
**Pour les voies BMad Method et Enterprise :**
|
||||
**Pour les voies BMad Method et Enterprise :**
|
||||
|
||||
1. Exécutez `bmad-prd` dans un nouveau chat — précisez votre intention (Create / Update / Validate) ou laissez le skill vous la demander
|
||||
2. Résultat : `prd.md`, `addendum.md`, `decision-log.md`
|
||||
2. Résultat : `prd.md`, `addendum.md`, `decision-log.md`
|
||||
|
||||
:::note[Intentions de `bmad-prd`]
|
||||
|
||||
|
|
@ -157,7 +157,7 @@ Tous les workflows de cette phase sont optionnels. [**Vous ne savez pas lequel c
|
|||
:::
|
||||
|
||||
|
||||
**Pour la voie Quick Dev :**
|
||||
**Pour la voie Quick Dev :**
|
||||
|
||||
- Exécutez `bmad-quick-dev` — ce workflow couvre la planification et l’implémentation en une seule fois ; vous pouvez passer directement à l’implémentation
|
||||
|
||||
|
|
@ -165,13 +165,13 @@ Tous les workflows de cette phase sont optionnels. [**Vous ne savez pas lequel c
|
|||
Si votre projet comporte une interface utilisateur, invoquez l'**agent UX Designer** (`bmad-agent-ux-designer`) et lancez le workflow de design UX (`bmad-ux`) après avoir créé votre PRD.
|
||||
:::
|
||||
|
||||
### Phase 3 : Solutioning (BMad Method/Enterprise)
|
||||
### Phase 3 : Solutioning (BMad Method/Enterprise)
|
||||
|
||||
**Créer l’architecture**
|
||||
|
||||
1. Invoquez l'**agent Architecte** (`bmad-agent-architect`) dans un nouveau chat
|
||||
2. Exécutez `bmad-create-architecture` (`bmad-create-architecture`)
|
||||
3. Résultat : document d’architecture avec les décisions techniques
|
||||
3. Résultat : document d’architecture avec les décisions techniques
|
||||
|
||||
**Créer les epics et les stories**
|
||||
|
||||
|
|
@ -189,7 +189,7 @@ Les epics et stories sont désormais créés *après* l’architecture. Cela pro
|
|||
2. Exécutez `bmad-check-implementation-readiness` (`bmad-check-implementation-readiness`)
|
||||
3. Valide la cohérence de l’ensemble des documents de planification
|
||||
|
||||
## Étape 2 : Développer votre projet
|
||||
## Étape 2 : Développer votre projet
|
||||
|
||||
Une fois la planification terminée, passez à l’implémentation. **Chaque workflow doit être exécuté dans un nouveau chat.**
|
||||
|
||||
|
|
@ -205,7 +205,7 @@ Pour chaque story, répétez ce cycle dans de nouveaux chats :
|
|||
|-------|-------|---------------------|---------------------|--------------------------------------|
|
||||
| 1 | DEV | `bmad-create-story` | `bmad-create-story` | Créer le fichier story depuis l’epic |
|
||||
| 2 | DEV | `bmad-dev-story` | `bmad-dev-story` | Implémenter la story |
|
||||
| 3 | DEV | `bmad-code-review` | `bmad-code-review` | Validation qualité *(recommandée)* |
|
||||
| 3 | DEV | `bmad-code-review` | `bmad-code-review` | Validation qualité *(recommandée)* |
|
||||
|
||||
Après avoir terminé toutes les stories d’un epic, invoquez l'**agent Développeur** (`bmad-agent-dev`) et exécutez `bmad-retrospective` (`bmad-retrospective`).
|
||||
|
||||
|
|
@ -238,7 +238,7 @@ your-project/
|
|||
|
||||
| Workflow | Commande | Agent | Objectif |
|
||||
|---------------------------------------|---------------------------------------|-----------|-----------------------------------------------------------------|
|
||||
| **`bmad-help`** ⭐ | `bmad-help` | Tous | **Votre guide intelligent — posez n’importe quelle question !** |
|
||||
| **`bmad-help`** ⭐ | `bmad-help` | Tous | **Votre guide intelligent — posez n’importe quelle question !** |
|
||||
| `bmad-prd` | `bmad-prd` | Tous | Créer, mettre à jour ou valider un PRD |
|
||||
| `bmad-create-architecture` | `bmad-create-architecture` | Architect | Créer le document d’architecture |
|
||||
| `bmad-generate-project-context` | `bmad-generate-project-context` | Analyst | Créer le fichier de contexte projet |
|
||||
|
|
@ -265,7 +265,7 @@ Pas strictement. Une fois le flux maîtrisé, vous pouvez exécuter les workflow
|
|||
|
||||
## Obtenir de l’aide
|
||||
|
||||
:::tip[Premier réflexe : BMad-Help]
|
||||
:::tip[Premier réflexe : BMad-Help]
|
||||
**Invoquez `bmad-help` à tout moment** — c’est le moyen le plus rapide de vous débloquer. Posez-lui n’importe quelle question :
|
||||
|
||||
- « Que dois-je faire après l’installation ? »
|
||||
|
|
|
|||
|
|
@ -132,7 +132,7 @@
|
|||
<div class="header">
|
||||
<div class="header-badge">⚡ Carte des Workflows V6</div>
|
||||
<h1>Méthode BMad</h1>
|
||||
<p class="subtitle">Ingénierie du contexte pour le développement piloté par l'IA</p>
|
||||
<p class="subtitle">Ingénierie du contexte pour le développement piloté par l’IA</p>
|
||||
</div>
|
||||
|
||||
<div class="flow-legend">→ les flèches montrent le flux des artefacts entre les workflows</div>
|
||||
|
|
@ -206,7 +206,7 @@
|
|||
<span class="output">prd.md →</span>
|
||||
</div>
|
||||
</div>
|
||||
<div class="decision">Interface utilisateur ?</div>
|
||||
<div class="decision">Interface utilisateur ?</div>
|
||||
<div class="workflow">
|
||||
<div class="workflow-header">
|
||||
<span class="workflow-name">create-ux-design</span>
|
||||
|
|
@ -329,7 +329,7 @@
|
|||
</div>
|
||||
<div class="workflow-meta">
|
||||
<div class="agent"><div class="agent-icon amelia">A</div><span class="agent-name">Amelia</span></div>
|
||||
<span class="output">rapport d'investigation</span>
|
||||
<span class="output">rapport d’investigation</span>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
|
|
|||
Loading…
Reference in New Issue