Compare commits
37 Commits
794c317dda
...
281dc2f95c
| Author | SHA1 | Date |
|---|---|---|
|
|
281dc2f95c | |
|
|
ad9cb7a177 | |
|
|
93a1e1dc46 | |
|
|
31ae226bb4 | |
|
|
c28206dca4 | |
|
|
1a6f8d52bc | |
|
|
1cb913523e | |
|
|
a2839cbee0 | |
|
|
6a73623f33 | |
|
|
3ca957e229 | |
|
|
9725b0ae90 | |
|
|
182550407c | |
|
|
4b2389231f | |
|
|
9088d4958b | |
|
|
0d2863f77f | |
|
|
a092209267 | |
|
|
1786d1debc | |
|
|
4cb58ba9f3 | |
|
|
871d921072 | |
|
|
3fad46849f | |
|
|
3bb953f18b | |
|
|
43c59f0cff | |
|
|
3c8d865457 | |
|
|
1b8424cf6d | |
|
|
9973b3c35a | |
|
|
1a0da0278f | |
|
|
52ebc3330d | |
|
|
8b13628496 | |
|
|
642b6a0cf4 | |
|
|
fd1e24c5c2 | |
|
|
84bade9a95 | |
|
|
4f1894908c | |
|
|
7a214cc7d8 | |
|
|
ac5cb552c0 | |
|
|
22035ef015 | |
|
|
5a1f356e2c | |
|
|
b696e9a246 |
|
|
@ -108,3 +108,6 @@ jobs:
|
||||||
|
|
||||||
- name: Validate file references
|
- name: Validate file references
|
||||||
run: npm run validate:refs
|
run: npm run validate:refs
|
||||||
|
|
||||||
|
- name: Validate skills
|
||||||
|
run: npm run validate:skills
|
||||||
|
|
|
||||||
|
|
@ -9,3 +9,4 @@ Open source framework for structured, agent-assisted software delivery.
|
||||||
`quality` mirrors the checks in `.github/workflows/quality.yaml`.
|
`quality` mirrors the checks in `.github/workflows/quality.yaml`.
|
||||||
|
|
||||||
- Skill validation rules are in `tools/skill-validator.md`.
|
- Skill validation rules are in `tools/skill-validator.md`.
|
||||||
|
- Deterministic skill checks run via `npm run validate:skills` (included in `quality`).
|
||||||
|
|
|
||||||
|
|
@ -148,7 +148,7 @@ your-project/
|
||||||
| ----------------- | ----------------------------- |
|
| ----------------- | ----------------------------- |
|
||||||
| **Index/Landing** | `core-concepts/index.md` |
|
| **Index/Landing** | `core-concepts/index.md` |
|
||||||
| **Concept** | `what-are-agents.md` |
|
| **Concept** | `what-are-agents.md` |
|
||||||
| **Feature** | `quick-flow.md` |
|
| **Feature** | `quick-dev.md` |
|
||||||
| **Philosophy** | `why-solutioning-matters.md` |
|
| **Philosophy** | `why-solutioning-matters.md` |
|
||||||
| **FAQ** | `established-projects-faq.md` |
|
| **FAQ** | `established-projects-faq.md` |
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,73 @@
|
||||||
|
---
|
||||||
|
title: "Quick Dev"
|
||||||
|
description: Reduce human-in-the-loop friction without giving up the checkpoints that protect output quality
|
||||||
|
sidebar:
|
||||||
|
order: 2
|
||||||
|
---
|
||||||
|
|
||||||
|
Intent in, code changes out, with as few human-in-the-loop turns as possible — without sacrificing quality.
|
||||||
|
|
||||||
|
It lets the model run longer between checkpoints, then brings the human back only when the task cannot safely continue without human judgment or when it is time to review the end result.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## Why This Exists
|
||||||
|
|
||||||
|
Human-in-the-loop turns are necessary and expensive.
|
||||||
|
|
||||||
|
Current LLMs still fail in predictable ways: they misread intent, fill gaps with confident guesses, drift into unrelated work, and generate noisy review output. At the same time, constant human intervention limits development velocity. Human attention is the bottleneck.
|
||||||
|
|
||||||
|
`bmad-quick-dev` rebalances that tradeoff. It trusts the model to run unsupervised for longer stretches, but only after the workflow has created a strong enough boundary to make that safe.
|
||||||
|
|
||||||
|
## The Core Design
|
||||||
|
|
||||||
|
### 1. Compress intent first
|
||||||
|
|
||||||
|
The workflow starts by having the human and the model compress the request into one coherent goal. The input can begin as a rough expression of intent, but before the workflow runs autonomously it has to become small enough, clear enough, and contradiction-free enough to execute.
|
||||||
|
|
||||||
|
Intent can come in many forms: a couple of phrases, a bug tracker link, output from plan mode, text copied from a chat session, or even a story number from BMAD's own `epics.md`. In that last case, the workflow will not understand BMAD story-tracking semantics, but it can still take the story itself and run with it.
|
||||||
|
|
||||||
|
This workflow does not eliminate human control. It relocates it to a small number of high-value moments:
|
||||||
|
|
||||||
|
- **Intent clarification** - turning a messy request into one coherent goal without hidden contradictions
|
||||||
|
- **Spec approval** - confirming that the frozen understanding is the right thing to build
|
||||||
|
- **Review of the final product** - the primary checkpoint, where the human decides whether the result is acceptable at the end
|
||||||
|
|
||||||
|
### 2. Route to the smallest safe path
|
||||||
|
|
||||||
|
Once the goal is clear, the workflow decides whether this is a true one-shot change or whether it needs the fuller path. Small, zero-blast-radius changes can go straight to implementation. Everything else goes through planning so the model has a stronger boundary before it runs longer on its own.
|
||||||
|
|
||||||
|
### 3. Run longer with less supervision
|
||||||
|
|
||||||
|
After that routing decision, the model can carry more of the work on its own. On the fuller path, the approved spec becomes the boundary the model executes against with less supervision, which is the whole point of the design.
|
||||||
|
|
||||||
|
### 4. Diagnose failure at the right layer
|
||||||
|
|
||||||
|
If the implementation is wrong because the intent was wrong, patching the code is the wrong fix. If the code is wrong because the spec was weak, patching the diff is also the wrong fix. The workflow is designed to diagnose where the failure entered the system, go back to that layer, and regenerate from there.
|
||||||
|
|
||||||
|
Review findings are used to decide whether the problem came from intent, spec generation, or local implementation. Only truly local problems get patched locally.
|
||||||
|
|
||||||
|
### 5. Bring the human back only when needed
|
||||||
|
|
||||||
|
The intent interview is human-in-the-loop, but it is not the same kind of interruption as a recurring checkpoint. The workflow tries to keep those recurring checkpoints to a minimum. After the initial shaping of intent, the human mainly comes back when the workflow cannot safely continue without judgment and at the end, when it is time to review the result.
|
||||||
|
|
||||||
|
- **Intent-gap resolution** - stepping back in when review proves the workflow could not safely infer what was meant
|
||||||
|
|
||||||
|
Everything else is a candidate for longer autonomous execution. That tradeoff is deliberate. Older patterns spend more human attention on continuous supervision. Quick Dev spends more trust on the model, but saves human attention for the moments where human reasoning has the highest leverage.
|
||||||
|
|
||||||
|
## Why the Review System Matters
|
||||||
|
|
||||||
|
The review phase is not just there to find bugs. It is there to route correction without destroying momentum.
|
||||||
|
|
||||||
|
This workflow works best on a platform that can spawn subagents, or at least invoke another LLM through the command line and wait for a result. If your platform does not support that natively, you can add a skill to do it. Context-free subagents are a cornerstone of the review design.
|
||||||
|
|
||||||
|
Agentic reviews often go wrong in two ways:
|
||||||
|
|
||||||
|
- They generate too many findings, forcing the human to sift through noise.
|
||||||
|
- They derail the current change by surfacing unrelated issues and turning every run into an ad hoc cleanup project.
|
||||||
|
|
||||||
|
Quick Dev addresses both by treating review as triage.
|
||||||
|
|
||||||
|
Some findings belong to the current change. Some do not. If a finding is incidental rather than causally tied to the current work, the workflow can defer it instead of forcing the human to handle it immediately. That keeps the run focused and prevents random tangents from consuming the budget of attention.
|
||||||
|
|
||||||
|
That triage will sometimes be imperfect. That is acceptable. It is usually better to misjudge some findings than to flood the human with thousands of low-value review comments. The system is optimizing for signal quality, not exhaustive recall.
|
||||||
|
|
@ -1,75 +0,0 @@
|
||||||
---
|
|
||||||
title: "Quick Flow"
|
|
||||||
description: Fast-track for small changes - skip the full methodology
|
|
||||||
sidebar:
|
|
||||||
order: 1
|
|
||||||
---
|
|
||||||
|
|
||||||
Skip the ceremony. Quick Flow takes you from intent to working code in a single workflow — no Product Brief, no PRD, no Architecture doc.
|
|
||||||
|
|
||||||
## When to Use It
|
|
||||||
|
|
||||||
- Bug fixes and patches
|
|
||||||
- Refactoring existing code
|
|
||||||
- Small, well-understood features
|
|
||||||
- Prototyping and spikes
|
|
||||||
- Single-agent work where one developer can hold the full scope
|
|
||||||
|
|
||||||
## When NOT to Use It
|
|
||||||
|
|
||||||
- New products or platforms that need stakeholder alignment
|
|
||||||
- Major features spanning multiple components or teams
|
|
||||||
- Work that requires architectural decisions (database schema, API contracts, service boundaries)
|
|
||||||
- Anything where requirements are unclear or contested
|
|
||||||
|
|
||||||
:::caution[Scope Creep]
|
|
||||||
If you start a Quick Flow and realize the scope is bigger than expected, `bmad-quick-dev` will detect this and offer to escalate. You can switch to a full PRD workflow at any point without losing your work.
|
|
||||||
:::
|
|
||||||
|
|
||||||
## How It Works
|
|
||||||
|
|
||||||
Run `bmad-quick-dev` and the workflow handles everything — clarifying intent, planning, implementing, reviewing, and presenting results.
|
|
||||||
|
|
||||||
### 1. Clarify intent
|
|
||||||
|
|
||||||
You describe what you want. The workflow compresses your request into one coherent goal — small enough, clear enough, and contradiction-free enough to execute safely. Intent can come from many sources: a few phrases, a bug tracker link, plan mode output, chat session text, or even a story number from your epics.
|
|
||||||
|
|
||||||
### 2. Route to the smallest safe path
|
|
||||||
|
|
||||||
Once the goal is clear, the workflow decides whether this is a true one-shot change or needs the fuller path. Small, zero-blast-radius changes go straight to implementation. Everything else goes through planning so the model has a stronger boundary before running autonomously.
|
|
||||||
|
|
||||||
### 3. Plan and implement
|
|
||||||
|
|
||||||
On the planning path, the workflow produces a complete tech-spec with ordered implementation tasks, acceptance criteria in Given/When/Then format, and testing strategy. After you approve the spec, it becomes the boundary the model executes against with less supervision.
|
|
||||||
|
|
||||||
### 4. Review and present
|
|
||||||
|
|
||||||
After implementation, the workflow runs a self-check audit and adversarial code review of the diff. Review acts as triage — findings tied to the current change are addressed, while incidental findings are deferred to keep the run focused. Results are presented for your sign-off.
|
|
||||||
|
|
||||||
### Human-in-the-loop checkpoints
|
|
||||||
|
|
||||||
The workflow relocates human control to a small number of high-value moments:
|
|
||||||
|
|
||||||
- **Intent clarification** — turning a messy request into one coherent goal
|
|
||||||
- **Spec approval** — confirming the frozen understanding is the right thing to build
|
|
||||||
- **Final review** — deciding whether the result is acceptable
|
|
||||||
|
|
||||||
Between these checkpoints, the model runs longer with less supervision. This is deliberate — it trades continuous supervision for focused human attention at moments with the highest leverage.
|
|
||||||
|
|
||||||
## What Quick Flow Skips
|
|
||||||
|
|
||||||
The full BMad Method produces a Product Brief, PRD, Architecture doc, and Epic/Story breakdown before any code is written. Quick Flow replaces all of that with a single tech-spec. This works because Quick Flow targets changes where:
|
|
||||||
|
|
||||||
- The product direction is already established
|
|
||||||
- Architecture decisions are already made
|
|
||||||
- A single developer can reason about the full scope
|
|
||||||
- Requirements fit in one conversation
|
|
||||||
|
|
||||||
## Escalating to Full BMad Method
|
|
||||||
|
|
||||||
Quick Flow includes built-in guardrails for scope detection. When you run `bmad-quick-dev`, it evaluates signals like multi-component mentions, system-level language, and uncertainty about approach. If it detects the work is bigger than a quick flow:
|
|
||||||
|
|
||||||
- **Light escalation** — Recommends creating a plan before implementation
|
|
||||||
- **Heavy escalation** — Recommends switching to the full BMad Method PRD process
|
|
||||||
|
|
||||||
You can also escalate manually at any time. Your tech-spec work carries forward — it becomes input for the broader planning process rather than being discarded.
|
|
||||||
|
|
@ -0,0 +1,8 @@
|
||||||
|
---
|
||||||
|
title: Page introuvable
|
||||||
|
template: splash
|
||||||
|
---
|
||||||
|
|
||||||
|
La page que vous recherchez n'existe pas ou a été déplacée.
|
||||||
|
|
||||||
|
[Retour à l'accueil](/fr/index.md)
|
||||||
|
|
@ -0,0 +1,370 @@
|
||||||
|
---
|
||||||
|
title: "Guide de style de la documentation"
|
||||||
|
description: Conventions de documentation spécifiques au projet, basées sur le style Google et la structure Diataxis
|
||||||
|
---
|
||||||
|
|
||||||
|
Ce projet suit le [Guide de style de documentation pour développeurs Google](https://developers.google.com/style) et utilise [Diataxis](https://diataxis.fr/) pour structurer le contenu. Seules les conventions spécifiques au projet sont présentées ci-dessous.
|
||||||
|
|
||||||
|
## Règles spécifiques au projet
|
||||||
|
|
||||||
|
| Règle | Spécification |
|
||||||
|
| --------------------------------------- | ------------------------------------------------------ |
|
||||||
|
| Pas de règles horizontales (`---`) | Perturbe le flux de lecture des fragments |
|
||||||
|
| Pas de titres `####` | Utiliser du texte en gras ou des admonitions |
|
||||||
|
| Pas de sections « Related » ou « Next: » | La barre latérale gère la navigation |
|
||||||
|
| Pas de listes profondément imbriquées | Diviser en sections à la place |
|
||||||
|
| Pas de blocs de code pour non-code | Utiliser des admonitions pour les exemples de dialogue |
|
||||||
|
| Pas de paragraphes en gras pour les appels | Utiliser des admonitions à la place |
|
||||||
|
| 1-2 admonitions max par section | Les tutoriels permettent 3-4 par section majeure |
|
||||||
|
| Cellules de tableau / éléments de liste | 1-2 phrases maximum |
|
||||||
|
| Budget de titres | 8-12 `##` par doc ; 2-3 `###` par section |
|
||||||
|
|
||||||
|
## Admonitions (Syntaxe Starlight)
|
||||||
|
|
||||||
|
```md
|
||||||
|
:::tip[Titre]
|
||||||
|
Raccourcis, bonnes pratiques
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::note[Titre]
|
||||||
|
Contexte, définitions, exemples, prérequis
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::caution[Titre]
|
||||||
|
Mises en garde, problèmes potentiels
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::danger[Titre]
|
||||||
|
Avertissements critiques uniquement — perte de données, problèmes de sécurité
|
||||||
|
:::
|
||||||
|
```
|
||||||
|
|
||||||
|
### Utilisations standards
|
||||||
|
|
||||||
|
| Admonition | Usage |
|
||||||
|
| -------------------------- | ---------------------------------------- |
|
||||||
|
| `:::note[Pré-requis]` | Dépendances avant de commencer |
|
||||||
|
| `:::tip[Chemin rapide]` | Résumé TL;DR en haut du document |
|
||||||
|
| `:::caution[Important]` | Mises en garde critiques |
|
||||||
|
| `:::note[Exemple]` | Exemples de commandes/réponses |
|
||||||
|
|
||||||
|
## Formats de tableau standards
|
||||||
|
|
||||||
|
**Phases :**
|
||||||
|
|
||||||
|
```md
|
||||||
|
| Phase | Nom | Ce qui se passe |
|
||||||
|
| ----- | ---------- | --------------------------------------------------- |
|
||||||
|
| 1 | Analyse | Brainstorm, recherche *(optionnel)* |
|
||||||
|
| 2 | Planification | Exigences — PRD ou spécification technique *(requis)* |
|
||||||
|
```
|
||||||
|
|
||||||
|
**Skills :**
|
||||||
|
|
||||||
|
```md
|
||||||
|
| Skill | Agent | Objectif |
|
||||||
|
| ------------------- | ------- | ----------------------------------------------- |
|
||||||
|
| `bmad-brainstorming` | Analyste | Brainstorming pour un nouveau projet |
|
||||||
|
| `bmad-create-prd` | PM | Créer un document d'exigences produit |
|
||||||
|
```
|
||||||
|
|
||||||
|
## Blocs de structure de dossiers
|
||||||
|
|
||||||
|
À afficher dans les sections "Ce que vous avez accompli" :
|
||||||
|
|
||||||
|
````md
|
||||||
|
```
|
||||||
|
votre-projet/
|
||||||
|
├── _bmad/ # Configuration BMad
|
||||||
|
├── _bmad-output/
|
||||||
|
│ ├── planning-artifacts/
|
||||||
|
│ │ └── PRD.md # Votre document d'exigences
|
||||||
|
│ ├── implementation-artifacts/
|
||||||
|
│ └── project-context.md # Règles d'implémentation (optionnel)
|
||||||
|
└── ...
|
||||||
|
```
|
||||||
|
````
|
||||||
|
|
||||||
|
## Structure des tutoriels
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Titre + Accroche (1-2 phrases décrivant le résultat)
|
||||||
|
2. Notice de version/module (admonition info ou avertissement) (optionnel)
|
||||||
|
3. Ce que vous allez apprendre (liste à puces des résultats)
|
||||||
|
4. Prérequis (admonition info)
|
||||||
|
5. Chemin rapide (admonition tip - résumé TL;DR)
|
||||||
|
6. Comprendre [Sujet] (contexte avant les étapes - tableaux pour phases/agents)
|
||||||
|
7. Installation (optionnel)
|
||||||
|
8. Étape 1 : [Première tâche majeure]
|
||||||
|
9. Étape 2 : [Deuxième tâche majeure]
|
||||||
|
10. Étape 3 : [Troisième tâche majeure]
|
||||||
|
11. Ce que vous avez accompli (résumé + structure de dossiers)
|
||||||
|
12. Référence rapide (tableau des compétences)
|
||||||
|
13. Questions courantes (format FAQ)
|
||||||
|
14. Obtenir de l'aide (liens communautaires)
|
||||||
|
15. Points clés à retenir (admonition tip)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Liste de vérification des tutoriels
|
||||||
|
|
||||||
|
- [ ] L'accroche décrit le résultat en 1-2 phrases
|
||||||
|
- [ ] Section "Ce que vous allez apprendre" présente
|
||||||
|
- [ ] Prérequis dans une admonition
|
||||||
|
- [ ] Admonition TL;DR de chemin rapide en haut
|
||||||
|
- [ ] Tableaux pour phases, skills, agents
|
||||||
|
- [ ] Section "Ce que vous avez accompli" présente
|
||||||
|
- [ ] Tableau de référence rapide présent
|
||||||
|
- [ ] Section questions courantes présente
|
||||||
|
- [ ] Section obtenir de l'aide présente
|
||||||
|
- [ ] Admonition points clés à retenir à la fin
|
||||||
|
|
||||||
|
## Structure des guides pratiques (How-To)
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Titre + Accroche (une phrase : « Utilisez le workflow `X` pour... »)
|
||||||
|
2. Quand utiliser ce guide (liste à puces de scénarios)
|
||||||
|
3. Quand éviter ce guide (optionnel)
|
||||||
|
4. Prérequis (admonition note)
|
||||||
|
5. Étapes (sous-sections ### numérotées)
|
||||||
|
6. Ce que vous obtenez (produits de sortie/artefacts)
|
||||||
|
7. Exemple (optionnel)
|
||||||
|
8. Conseils (optionnel)
|
||||||
|
9. Prochaines étapes (optionnel)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Liste de vérification des guides pratiques
|
||||||
|
|
||||||
|
- [ ] L'accroche commence par « Utilisez le workflow `X` pour... »
|
||||||
|
- [ ] "Quand utiliser ce guide" contient 3-5 points
|
||||||
|
- [ ] Prérequis listés
|
||||||
|
- [ ] Les étapes sont des sous-sections `###` numérotées avec des verbes d'action
|
||||||
|
- [ ] "Ce que vous obtenez" décrit les artefacts produits
|
||||||
|
|
||||||
|
## Structure des explications
|
||||||
|
|
||||||
|
### Types
|
||||||
|
|
||||||
|
| Type | Exemple |
|
||||||
|
| ----------------------- | ------------------------------------ |
|
||||||
|
| **Index/Page d'accueil** | `core-concepts/index.md` |
|
||||||
|
| **Concept** | `what-are-agents.md` |
|
||||||
|
| **Fonctionnalité** | `quick-dev.md` |
|
||||||
|
| **Philosophie** | `why-solutioning-matters.md` |
|
||||||
|
| **FAQ** | `established-projects-faq.md` |
|
||||||
|
|
||||||
|
### Modèle général
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Titre + Accroche (1-2 phrases)
|
||||||
|
2. Vue d'ensemble/Définition (ce que c'est, pourquoi c'est important)
|
||||||
|
3. Concepts clés (sous-sections ###)
|
||||||
|
4. Tableau comparatif (optionnel)
|
||||||
|
5. Quand utiliser / Quand ne pas utiliser (optionnel)
|
||||||
|
6. Diagramme (optionnel - mermaid, 1 max par doc)
|
||||||
|
7. Prochaines étapes (optionnel)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Pages d'index/d'accueil
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Titre + Accroche (une phrase)
|
||||||
|
2. Tableau de contenu (liens avec descriptions)
|
||||||
|
3. Pour commencer (liste numérotée)
|
||||||
|
4. Choisissez votre parcours (optionnel - arbre de décision)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Explications de concepts
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Titre + Accroche (ce que c'est)
|
||||||
|
2. Types/Catégories (sous-sections ###) (optionnel)
|
||||||
|
3. Tableau des différences clés
|
||||||
|
4. Composants/Parties
|
||||||
|
5. Lequel devriez-vous utiliser ?
|
||||||
|
6. Création/Personnalisation (lien vers les guides pratiques)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Explications de fonctionnalités
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Titre + Accroche (ce que cela fait)
|
||||||
|
2. Faits rapides (optionnel - "Idéal pour :", "Temps :")
|
||||||
|
3. Quand utiliser / Quand ne pas utiliser
|
||||||
|
4. Comment cela fonctionne (diagramme mermaid optionnel)
|
||||||
|
5. Avantages clés
|
||||||
|
6. Tableau comparatif (optionnel)
|
||||||
|
7. Quand évoluer/mettre à niveau (optionnel)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Documents de philosophie/justification
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Titre + Accroche (le principe)
|
||||||
|
2. Le problème
|
||||||
|
3. La solution
|
||||||
|
4. Principes clés (sous-sections ###)
|
||||||
|
5. Avantages
|
||||||
|
6. Quand cela s'applique
|
||||||
|
```
|
||||||
|
|
||||||
|
### Liste de vérification des explications
|
||||||
|
|
||||||
|
- [ ] L'accroche énonce ce que le document explique
|
||||||
|
- [ ] Contenu dans des sections `##` parcourables
|
||||||
|
- [ ] Tableaux comparatifs pour 3+ options
|
||||||
|
- [ ] Les diagrammes ont des étiquettes claires
|
||||||
|
- [ ] Liens vers les guides pratiques pour les questions procédurales
|
||||||
|
- [ ] 2-3 admonitions max par document
|
||||||
|
|
||||||
|
## Structure des références
|
||||||
|
|
||||||
|
### Types
|
||||||
|
|
||||||
|
| Type | Exemple |
|
||||||
|
| ----------------------- | --------------------- |
|
||||||
|
| **Index/Page d'accueil** | `workflows/index.md` |
|
||||||
|
| **Catalogue** | `agents/index.md` |
|
||||||
|
| **Approfondissement** | `document-project.md` |
|
||||||
|
| **Configuration** | `core-tasks.md` |
|
||||||
|
| **Glossaire** | `glossary/index.md` |
|
||||||
|
| **Complet** | `bmgd-workflows.md` |
|
||||||
|
|
||||||
|
### Pages d'index de référence
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Titre + Accroche (une phrase)
|
||||||
|
2. Sections de contenu (## pour chaque catégorie)
|
||||||
|
- Liste à puces avec liens et descriptions
|
||||||
|
```
|
||||||
|
|
||||||
|
### Référence de catalogue
|
||||||
|
|
||||||
|
```text
|
||||||
|
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
|
||||||
|
3. Universel/Partagé (## section) (optionnel)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Référence d'approfondissement d'élément
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Titre + Accroche (objectif en une phrase)
|
||||||
|
2. Faits rapides (admonition note optionnelle)
|
||||||
|
- Module, Skill, Entrée, Sortie sous forme de liste
|
||||||
|
3. Objectif/Vue d'ensemble (## section)
|
||||||
|
4. Comment invoquer (bloc de code)
|
||||||
|
5. Sections clés (## pour chaque aspect)
|
||||||
|
- Utiliser ### pour les sous-options
|
||||||
|
6. Notes/Mises en garde (admonition tip ou caution)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Référence de configuration
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Titre + Accroche
|
||||||
|
2. Table des matières (liens de saut si 4+ éléments)
|
||||||
|
3. Éléments (## pour chaque config/tâche)
|
||||||
|
- **Résumé en gras** — une phrase
|
||||||
|
- **Utilisez-le quand :** liste à puces
|
||||||
|
- **Comment cela fonctionne :** étapes numérotées (3-5 max)
|
||||||
|
- **Sortie :** résultat attendu (optionnel)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Guide de référence complet
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Titre + Accroche
|
||||||
|
2. Vue d'ensemble (## section)
|
||||||
|
- Diagramme ou tableau montrant l'organisation
|
||||||
|
3. Sections majeures (## pour chaque phase/catégorie)
|
||||||
|
- Éléments (### pour chaque élément)
|
||||||
|
- Champs standardisés : Skill, Agent, Entrée, Sortie, Description
|
||||||
|
4. Prochaines étapes (optionnel)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Liste de vérification des références
|
||||||
|
|
||||||
|
- [ ] L'accroche énonce ce que le document référence
|
||||||
|
- [ ] La structure correspond au type de référence
|
||||||
|
- [ ] Les éléments utilisent une structure cohérente
|
||||||
|
- [ ] Tableaux pour les données structurées/comparatives
|
||||||
|
- [ ] Liens vers les documents d'explication pour la profondeur conceptuelle
|
||||||
|
- [ ] 1-2 admonitions max
|
||||||
|
|
||||||
|
## Structure du glossaire
|
||||||
|
|
||||||
|
Starlight génère la navigation "Sur cette page" à droite à partir des titres :
|
||||||
|
|
||||||
|
- Catégories en tant que titres `##` — apparaissent dans la navigation à droite
|
||||||
|
- Termes dans des tableaux — lignes compactes, pas de titres individuels
|
||||||
|
- Pas de TOC en ligne — la barre latérale à droite gère la navigation
|
||||||
|
|
||||||
|
### Format de tableau
|
||||||
|
|
||||||
|
```md
|
||||||
|
## Nom de catégorie
|
||||||
|
|
||||||
|
| Terme | Définition |
|
||||||
|
| ------------ | --------------------------------------------------------------------------------------------- |
|
||||||
|
| **Agent** | Personnalité IA spécialisée avec une expertise spécifique qui guide les utilisateurs dans les workflows. |
|
||||||
|
| **Workflow** | Processus guidé en plusieurs étapes qui orchestre les activités des agents IA pour produire des livrables. |
|
||||||
|
```
|
||||||
|
|
||||||
|
### Règles de définition
|
||||||
|
|
||||||
|
| À faire | À ne pas faire |
|
||||||
|
| --------------------------------- | --------------------------------------------- |
|
||||||
|
| Commencer par ce que c'est ou ce que cela fait | Commencer par « C'est... » ou « Un [terme] est... » |
|
||||||
|
| Se limiter à 1-2 phrases | Écrire des explications de plusieurs paragraphes |
|
||||||
|
| Mettre le nom du terme en gras dans la cellule | Utiliser du texte simple pour les termes |
|
||||||
|
|
||||||
|
### Marqueurs de contexte
|
||||||
|
|
||||||
|
Ajouter un contexte en italique au début de la définition pour les termes à portée limitée :
|
||||||
|
|
||||||
|
- `*Quick Dev uniquement.*`
|
||||||
|
- `*méthode BMad/Enterprise.*`
|
||||||
|
- `*Phase N.*`
|
||||||
|
- `*BMGD.*`
|
||||||
|
- `*Projets établis.*`
|
||||||
|
|
||||||
|
### Liste de vérification du glossaire
|
||||||
|
|
||||||
|
- [ ] Termes dans des tableaux, pas de titres individuels
|
||||||
|
- [ ] Termes alphabétisés au sein des catégories
|
||||||
|
- [ ] Définitions de 1-2 phrases
|
||||||
|
- [ ] Marqueurs de contexte en italique
|
||||||
|
- [ ] Noms des termes en gras dans les cellules
|
||||||
|
- [ ] Pas de définitions « Un [terme] est... »
|
||||||
|
|
||||||
|
## Sections FAQ
|
||||||
|
|
||||||
|
```md
|
||||||
|
## Questions
|
||||||
|
|
||||||
|
- [Ai-je toujours besoin d'architecture ?](#ai-je-toujours-besoin-darchitecture)
|
||||||
|
- [Puis-je modifier mon plan plus tard ?](#puis-je-modifier-mon-plan-plus-tard)
|
||||||
|
|
||||||
|
### Ai-je toujours besoin d'architecture ?
|
||||||
|
|
||||||
|
Uniquement pour les parcours méthode BMad et Enterprise. Quick Dev passe directement à l'implémentation.
|
||||||
|
|
||||||
|
### Puis-je modifier mon plan plus tard ?
|
||||||
|
|
||||||
|
Oui. Utilisez `bmad-correct-course` pour gérer les changements de portée.
|
||||||
|
|
||||||
|
**Une question sans réponse ici ?** [Ouvrez une issue](...) ou posez votre question sur [Discord](...).
|
||||||
|
```
|
||||||
|
|
||||||
|
## Commandes de validation
|
||||||
|
|
||||||
|
Avant de soumettre des modifications de documentation :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npm run docs:fix-links # Prévisualiser les corrections de format de liens
|
||||||
|
npm run docs:fix-links -- --write # Appliquer les corrections
|
||||||
|
npm run docs:validate-links # Vérifier que les liens existent
|
||||||
|
npm run docs:build # Vérifier l'absence d'erreurs de build
|
||||||
|
```
|
||||||
|
|
@ -0,0 +1,49 @@
|
||||||
|
---
|
||||||
|
title: "Élicitation Avancée"
|
||||||
|
description: Pousser le LLM à repenser son travail en utilisant des méthodes de raisonnement structurées
|
||||||
|
sidebar:
|
||||||
|
order: 6
|
||||||
|
---
|
||||||
|
|
||||||
|
Faites repenser au LLM ce qu'il vient de générer. Vous choisissez une méthode de raisonnement, il l'applique à sa propre sortie, et vous décidez de conserver ou non les améliorations.
|
||||||
|
|
||||||
|
## Qu'est-ce que l’Élicitation Avancée ?
|
||||||
|
|
||||||
|
Un second passage structuré. Au lieu de demander à l'IA de "réessayer" ou de "faire mieux", vous sélectionnez une méthode de raisonnement spécifique et l'IA réexamine sa propre sortie à travers ce prisme.
|
||||||
|
|
||||||
|
La différence est importante. Les demandes vagues produisent des révisions vagues. Une méthode nommée impose un angle d'attaque particulier, mettant en lumière des perspectives qu'un simple réajustement générique aurait manquées.
|
||||||
|
|
||||||
|
## Quand l'utiliser
|
||||||
|
|
||||||
|
- Après qu'un workflow a généré du contenu et vous souhaitez des alternatives
|
||||||
|
- Lorsque la sortie semble correcte mais que vous soupçonnez qu'il y a davantage de profondeur
|
||||||
|
- Pour tester les hypothèses ou trouver des faiblesses
|
||||||
|
- Pour du contenu à enjeux élevés où la réflexion approfondie aide
|
||||||
|
|
||||||
|
Les workflows offrent l'élicitation aux points de décision - après que le LLM ait généré quelque chose, on vous demandera si vous souhaitez l'exécuter.
|
||||||
|
|
||||||
|
## Comment ça fonctionne
|
||||||
|
|
||||||
|
1. Le LLM suggère 5 méthodes pertinentes pour votre contenu
|
||||||
|
2. Vous en choisissez une (ou remélangez pour différentes options)
|
||||||
|
3. La méthode est appliquée, les améliorations sont affichées
|
||||||
|
4. Acceptez ou rejetez, répétez ou continuez
|
||||||
|
|
||||||
|
## Méthodes intégrées
|
||||||
|
|
||||||
|
Des dizaines de méthodes de raisonnement sont disponibles. Quelques exemples :
|
||||||
|
|
||||||
|
- **Analyse Pré-mortem** - Suppose que le projet a déjà échoué, revient en arrière pour trouver pourquoi
|
||||||
|
- **Pensée de Premier Principe** - Élimine les hypothèses, reconstruit à partir de la vérité de terrain
|
||||||
|
- **Inversion** - Demande comment garantir l'échec, puis les évite
|
||||||
|
- **Équipe Rouge vs Équipe Bleue** - Attaque votre propre travail, puis le défend
|
||||||
|
- **Questionnement Socratique** - Conteste chaque affirmation avec "pourquoi ?" et "comment le savez-vous ?"
|
||||||
|
- **Suppression des Contraintes** - Abandonne toutes les contraintes, voit ce qui change, les réajoute sélectivement
|
||||||
|
- **Cartographie des Parties Prenantes** - Réévalue depuis la perspective de chaque partie prenante
|
||||||
|
- **Raisonnement Analogique** - Trouve des parallèles dans d'autres domaines et applique leurs leçons
|
||||||
|
|
||||||
|
Et bien d'autres. L'IA choisit les options les plus pertinentes pour votre contenu - vous choisissez lesquelles exécuter.
|
||||||
|
|
||||||
|
:::tip[Commencez Ici]
|
||||||
|
L'Analyse Pré-mortem est un bon premier choix pour toute spécification ou tout plan. Elle trouve systématiquement des lacunes qu'une révision standard manque.
|
||||||
|
:::
|
||||||
|
|
@ -0,0 +1,66 @@
|
||||||
|
---
|
||||||
|
title: "Revue Contradictoire"
|
||||||
|
description: Technique de raisonnement forcée qui empêche les revues paresseuses du style "ça à l'air bon"
|
||||||
|
sidebar:
|
||||||
|
order: 5
|
||||||
|
---
|
||||||
|
|
||||||
|
Forcez une analyse plus approfondie en exigeant que des problèmes soient trouvés.
|
||||||
|
|
||||||
|
## Qu'est-ce que la Revue Contradictoire ?
|
||||||
|
|
||||||
|
Une technique de revue où le réviseur *doit* trouver des problèmes. Pas de "ça a l'air bon" autorisé. Le réviseur adopte une posture cynique - suppose que des problèmes existent et les trouve.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
## Pourquoi Cela Fonctionne
|
||||||
|
|
||||||
|
Les revues normales souffrent du biais de confirmation[^1]. Il parcourt le travail rapidement, rien ne lui saute aux yeux, il l'approuve. L'obligation de "trouver des problèmes" brise ce schéma :
|
||||||
|
|
||||||
|
- **Force la rigueur** - Impossible d'approuver tant qu’il n'a pas examiné suffisamment en profondeur pour trouver des problèmes
|
||||||
|
- **Détecte les oublis** - "Qu'est-ce qui manque ici ?" devient une question naturelle
|
||||||
|
- **Améliore la qualité du signal** - Les constatations sont spécifiques et actionnables, pas des préoccupations vagues
|
||||||
|
- **Asymétrie d'information**[^2] - Effectue les revues avec un contexte frais (sans accès au raisonnement original) pour évaluer l'artefact, pas l'intention
|
||||||
|
|
||||||
|
## Où Elle Est Utilisée
|
||||||
|
|
||||||
|
La revue contradictoire apparaît dans tous les workflows BMad - revue de code, vérifications de préparation à l'implémentation, validation de spécifications, et d'autres. Parfois c'est une étape obligatoire, parfois optionnelle (comme l'élicitation avancée ou le mode party). Le pattern s'adapte à n'importe quel artefact nécessitant un examen.
|
||||||
|
|
||||||
|
## 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].
|
||||||
|
|
||||||
|
**C'est vous qui décidez ce qui est réel.** Examinez chaque constatation, ignorez le bruit, corrigez ce qui compte.
|
||||||
|
|
||||||
|
## Exemple
|
||||||
|
|
||||||
|
Au lieu de :
|
||||||
|
|
||||||
|
> "L'implémentation de l'authentification semble raisonnable. Approuvé."
|
||||||
|
|
||||||
|
Une revue contradictoire produit :
|
||||||
|
|
||||||
|
> 1. **ÉLEVÉ** - `login.ts:47` - Pas de limitation de débit sur les tentatives échouées
|
||||||
|
> 2. **ÉLEVÉ** - Jeton de session stocké dans localStorage (vulnérable au XSS)
|
||||||
|
> 3. **MOYEN** - La validation du mot de passe se fait côté client uniquement
|
||||||
|
> 4. **MOYEN** - Pas de journalisation d'audit pour les tentatives de connexion échouées
|
||||||
|
> 5. **FAIBLE** - Le nombre magique `3600` devrait être `SESSION_TIMEOUT_SECONDS`
|
||||||
|
|
||||||
|
La première revue pourrait manquer une vulnérabilité de sécurité. La seconde en a attrapé quatre.
|
||||||
|
|
||||||
|
## Itération et Rendements Décroissants
|
||||||
|
|
||||||
|
Après avoir traité les constatations, envisagez de relancer la revue. Une deuxième passe détecte généralement plus de problèmes. Une troisième n'est pas toujours inutile non plus. Mais chaque passe prend du temps, et vous finissez par atteindre des rendements décroissants[^4] - juste des détails et des faux problèmes.
|
||||||
|
|
||||||
|
:::tip[Meilleures Revues]
|
||||||
|
Supposez que des problèmes existent. Cherchez ce qui manque, pas seulement ce qui ne va pas.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Glossaire
|
||||||
|
|
||||||
|
[^1]: **Biais de confirmation** : tendance cognitive à rechercher, interpréter et favoriser les informations qui confirment nos croyances préexistantes, tout en ignorant ou minimisant celles qui les contredisent.
|
||||||
|
[^2]: **Asymétrie d'information** : situation où une partie dispose de plus ou de meilleures informations qu'une autre, conduisant potentiellement à des décisions ou jugements biaisés.
|
||||||
|
[^3]: **Hallucination (IA)** : phénomène où un modèle d'IA génère des informations plausibles mais factuellement incorrectes ou inventées, présentées avec confiance comme si elles étaient vraies.
|
||||||
|
[^4]: **Rendements décroissants** : principe selon lequel l'augmentation continue d'un investissement (temps, effort, ressources) finit par produire des bénéfices de plus en plus faibles proportionnellement.
|
||||||
|
|
@ -0,0 +1,33 @@
|
||||||
|
---
|
||||||
|
title: "Brainstorming"
|
||||||
|
description: Sessions interactives créatives utilisant plus de 60 techniques d'idéation éprouvées
|
||||||
|
sidebar:
|
||||||
|
order: 2
|
||||||
|
---
|
||||||
|
|
||||||
|
Libérez votre créativité grâce à une exploration guidée.
|
||||||
|
|
||||||
|
## Qu'est-ce que le Brainstorming ?
|
||||||
|
|
||||||
|
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 :**
|
||||||
|
|
||||||
|
- Surmonter les blocages créatifs
|
||||||
|
- Générer des idées de produits ou de fonctionnalités
|
||||||
|
- Explorer des problèmes sous de nouveaux angles
|
||||||
|
- Développer des concepts bruts en plans d'action
|
||||||
|
|
||||||
|
## Comment ça fonctionne
|
||||||
|
|
||||||
|
1. **Configuration** - Définir le sujet, les objectifs, les contraintes
|
||||||
|
2. **Choisir l'approche** - Choisir vous-même les techniques, obtenir des recommandations de l'IA, aller au hasard, ou suivre un flux progressif
|
||||||
|
3. **Facilitation** - Travailler à travers les techniques avec des questions approfondies et un coaching collaboratif
|
||||||
|
4. **Organiser** - Idées regroupées par thèmes et priorisées
|
||||||
|
5. **Action** - Les meilleures idées reçoivent des prochaines étapes et des indicateurs de succès
|
||||||
|
|
||||||
|
Tout est capturé dans un document de session que vous pouvez consulter ultérieurement ou partager avec les parties prenantes.
|
||||||
|
|
||||||
|
:::note[Vos Idées]
|
||||||
|
Chaque idée vient de vous. Le workflow crée les conditions propices à une vision nouvelle - vous en êtes la source.
|
||||||
|
:::
|
||||||
|
|
@ -0,0 +1,50 @@
|
||||||
|
---
|
||||||
|
title: "FAQ Projets Existants"
|
||||||
|
description: Questions courantes sur l'utilisation de la méthode BMad sur des projets existants
|
||||||
|
sidebar:
|
||||||
|
order: 8
|
||||||
|
---
|
||||||
|
Réponses rapides aux questions courantes sur l'utilisation de la méthode BMad (BMM) sur des projets existants.
|
||||||
|
|
||||||
|
## Questions
|
||||||
|
|
||||||
|
- [Dois-je d'abord exécuter document-project ?](#dois-je-dabord-exécuter-document-project)
|
||||||
|
- [Que faire si j'oublie d'exécuter document-project ?](#que-faire-si-joublie-dexécuter-document-project)
|
||||||
|
- [Puis-je utiliser Quick Dev pour les projets existants ?](#puis-je-utiliser-quick-dev-pour-les-projets-existants)
|
||||||
|
- [Que faire si mon code existant ne suit pas les bonnes pratiques ?](#que-faire-si-mon-code-existant-ne-suit-pas-les-bonnes-pratiques)
|
||||||
|
|
||||||
|
### Dois-je d'abord exécuter `document-project` ?
|
||||||
|
|
||||||
|
Hautement recommandé, surtout si :
|
||||||
|
|
||||||
|
- Aucune documentation existante
|
||||||
|
- La documentation est obsolète
|
||||||
|
- Les agents IA ont besoin de contexte sur le code existant
|
||||||
|
|
||||||
|
Vous pouvez l'ignorer si vous disposez d'une documentation complète et à jour incluant `docs/index.md` ou si vous utiliserez d'autres outils ou techniques pour aider à la découverte afin que l'agent puisse construire sur un système existant.
|
||||||
|
|
||||||
|
### Que faire si j'oublie d'exécuter `document-project` ?
|
||||||
|
|
||||||
|
Ne vous inquiétez pas — vous pouvez le faire à tout moment. Vous pouvez même le faire pendant ou après un projet pour aider à maintenir la documentation à jour.
|
||||||
|
|
||||||
|
### Puis-je utiliser Quick Dev pour les projets existants ?
|
||||||
|
|
||||||
|
Oui ! Quick Dev fonctionne très bien pour les projets existants. Il va :
|
||||||
|
|
||||||
|
- Détecter automatiquement votre pile technologique existante
|
||||||
|
- Analyser les patterns de code existants
|
||||||
|
- Détecter les conventions et demander confirmation
|
||||||
|
- Générer une spécification technique riche en contexte qui respecte le code existant
|
||||||
|
|
||||||
|
Parfait pour les corrections de bugs et les petites fonctionnalités dans des bases de code existantes.
|
||||||
|
|
||||||
|
### Que faire si mon code existant ne suit pas les bonnes pratiques ?
|
||||||
|
|
||||||
|
Quick Dev détecte vos conventions et demande : « Dois-je suivre ces conventions existantes ? » Vous décidez :
|
||||||
|
|
||||||
|
- **Oui** → Maintenir la cohérence avec la base de code actuelle
|
||||||
|
- **Non** → Établir de nouvelles normes (documenter pourquoi dans la spécification technique)
|
||||||
|
|
||||||
|
BMM respecte votre choix — il ne forcera pas la modernisation, mais la proposera.
|
||||||
|
|
||||||
|
**Une question sans réponse ici ?** Veuillez [ouvrir un ticket](https://github.com/bmad-code-org/BMAD-METHOD/issues) ou poser votre question sur [Discord](https://discord.gg/gk8jAdXWmj) afin que nous puissions l'ajouter !
|
||||||
|
|
@ -0,0 +1,64 @@
|
||||||
|
---
|
||||||
|
title: "Party Mode"
|
||||||
|
description: Collaboration multi-agents - regroupez tous vos agents IA dans une seule conversation
|
||||||
|
sidebar:
|
||||||
|
order: 7
|
||||||
|
---
|
||||||
|
|
||||||
|
Regroupez tous vos agents IA dans une seule conversation.
|
||||||
|
|
||||||
|
## Qu'est-ce que le Party Mode ?
|
||||||
|
|
||||||
|
Lancez `bmad-party-mode` et vous avez toute votre équipe IA dans une même pièce - PM, Architecte, Développeur, Designer UX, selon vos besoins. BMad Master orchestre, en sélectionnant les agents pertinents à chaque message. Les agents répondent en personnage, sont en accord ou désaccord, et construisent sur les idées des autres.
|
||||||
|
|
||||||
|
La conversation continue aussi longtemps que vous le souhaitez. Posez des questions de suivi, remettez en question les réponses, redirigez la discussion - c'est un véritable échange avec vos agents jusqu'à ce que vous ayez terminé.
|
||||||
|
|
||||||
|
**Idéal pour :**
|
||||||
|
|
||||||
|
- Les grandes décisions avec des compromis
|
||||||
|
- Les sessions de brainstorming
|
||||||
|
- Les rétrospectives post-incident quand les choses tournent mal
|
||||||
|
- Les rétrospectives de sprint et la planification
|
||||||
|
|
||||||
|
## Exemples
|
||||||
|
|
||||||
|
### 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é ? »
|
||||||
|
|
||||||
|
**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. »
|
||||||
|
|
||||||
|
**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. »
|
||||||
|
|
||||||
|
### Brainstorming créatif
|
||||||
|
|
||||||
|
**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. »
|
||||||
|
|
||||||
|
**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. »
|
||||||
|
|
||||||
|
### Décision technique
|
||||||
|
|
||||||
|
**Vous :** « Monolithe ou microservices pour le MVP[^1] ? »
|
||||||
|
|
||||||
|
**Architecte :** « Commencez en monolithe. Les microservices ajoutent une complexité dont vous n'avez pas besoin à 1000 utilisateurs. »
|
||||||
|
|
||||||
|
**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. »
|
||||||
|
|
||||||
|
:::tip[Meilleures décisions]
|
||||||
|
De meilleures décisions grâce à des perspectives diverses. Bienvenue dans le party mode.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Glossaire
|
||||||
|
|
||||||
|
[^1]: MVP (Minimum Viable Product) : version minimale d'un produit contenant juste assez de fonctionnalités pour être utilisée par des utilisateurs précoces et valider les hypothèses de marché avant d'investir dans un développement plus complet.
|
||||||
|
[^2]: Time-to-market : délai nécessaire pour concevoir, développer et lancer un produit sur le marché. Plus ce délai est court, plus l'entreprise peut prendre de l'avance sur ses concurrents.
|
||||||
|
|
@ -0,0 +1,117 @@
|
||||||
|
---
|
||||||
|
title: "Prévention des conflits entre agents"
|
||||||
|
description: Comment l'architecture empêche les conflits lorsque plusieurs agents implémentent un système
|
||||||
|
sidebar:
|
||||||
|
order: 4
|
||||||
|
---
|
||||||
|
|
||||||
|
Lorsque plusieurs agents IA implémentent différentes parties d'un système, ils peuvent prendre des décisions techniques contradictoires. La documentation d'architecture prévient cela en établissant des standards partagés.
|
||||||
|
|
||||||
|
## Types de conflits courants
|
||||||
|
|
||||||
|
### Conflits de style d'API
|
||||||
|
|
||||||
|
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
|
||||||
|
|
||||||
|
Avec architecture :
|
||||||
|
- 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
|
||||||
|
|
||||||
|
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
|
||||||
|
|
||||||
|
Avec architecture :
|
||||||
|
- Un document de standards spécifie les conventions de nommage
|
||||||
|
- Tous les agents suivent les mêmes patterns
|
||||||
|
|
||||||
|
### Conflits de gestion d'état
|
||||||
|
|
||||||
|
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é
|
||||||
|
|
||||||
|
Avec architecture :
|
||||||
|
- L'ADR spécifie l'approche de gestion d'état
|
||||||
|
- Tous les agents implémentent de manière cohérente
|
||||||
|
|
||||||
|
## Comment l'architecture prévient les conflits
|
||||||
|
|
||||||
|
### 1. Décisions explicites via les ADR[^1]
|
||||||
|
|
||||||
|
Chaque choix technologique significatif est documenté avec :
|
||||||
|
- Contexte (pourquoi cette décision est importante)
|
||||||
|
- Options considérées (quelles alternatives existent)
|
||||||
|
- Décision (ce qui a été choisi)
|
||||||
|
- Justification (pourquoi cela a-t-il été choisi)
|
||||||
|
- Conséquences (compromis acceptés)
|
||||||
|
|
||||||
|
### 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
|
||||||
|
|
||||||
|
### 3. Standards et conventions
|
||||||
|
|
||||||
|
Documentation explicite de :
|
||||||
|
- La structure des répertoires
|
||||||
|
- Les conventions de nommage
|
||||||
|
- L'organisation du code
|
||||||
|
- Les patterns de test
|
||||||
|
|
||||||
|
## L'architecture comme contexte partagé
|
||||||
|
|
||||||
|
Considérez l'architecture comme le contexte partagé que tous les agents lisent avant d'implémenter :
|
||||||
|
|
||||||
|
```text
|
||||||
|
PRD : "Que construire"
|
||||||
|
↓
|
||||||
|
Architecture : "Comment le construire"
|
||||||
|
↓
|
||||||
|
L'agent A lit l'architecture → implémente l'Epic 1
|
||||||
|
L'agent B lit l'architecture → implémente l'Epic 2
|
||||||
|
L'agent C lit l'architecture → implémente l'Epic 3
|
||||||
|
↓
|
||||||
|
Résultat : Implémentation cohérente
|
||||||
|
```
|
||||||
|
|
||||||
|
## Sujets clés des ADR
|
||||||
|
|
||||||
|
Décisions courantes qui préviennent les conflits :
|
||||||
|
|
||||||
|
| Sujet | Exemple de décision |
|
||||||
|
| ---------------- | -------------------------------------------- |
|
||||||
|
| Style d'API | GraphQL vs REST vs gRPC |
|
||||||
|
| Base de données | PostgreSQL vs MongoDB |
|
||||||
|
| Authentification | JWT vs Sessions |
|
||||||
|
| Gestion d'état | Redux vs Context vs Zustand |
|
||||||
|
| Styling | CSS Modules vs Tailwind vs Styled Components |
|
||||||
|
| Tests | Jest + Playwright vs Vitest + Cypress |
|
||||||
|
|
||||||
|
## Anti-patterns à éviter
|
||||||
|
|
||||||
|
:::caution[Erreurs courantes]
|
||||||
|
- **Décisions implicites** — « On décidera du style d'API au fur et à mesure » mène à l'incohérence
|
||||||
|
- **Sur-documentation** — Documenter chaque choix mineur cause une paralysie analytique
|
||||||
|
- **Architecture obsolète** — Les documents écrits une fois et jamais mis à jour poussent les agents à suivre des patterns dépassés
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::tip[Approche correcte]
|
||||||
|
- Documenter les décisions qui traversent les frontières des epics
|
||||||
|
- Se concentrer sur les zones sujettes aux conflits
|
||||||
|
- Mettre à jour l'architecture au fur et à mesure des apprentissages
|
||||||
|
- Utiliser `bmad-correct-course` pour les changements significatifs
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Glossaire
|
||||||
|
|
||||||
|
[^1]: ADR (Architecture Decision Record) : document qui consigne une décision d’architecture, son contexte, les options envisagées, le choix retenu et ses conséquences, afin d’assurer la traçabilité et la compréhension des décisions techniques dans le temps.
|
||||||
|
[^2]: FR / NFR (Functional / Non-Functional Requirement) : exigences décrivant respectivement **ce que le système doit faire** (fonctionnalités, comportements attendus) et **comment il doit le faire** (contraintes de performance, sécurité, fiabilité, ergonomie, etc.).
|
||||||
|
|
@ -0,0 +1,158 @@
|
||||||
|
---
|
||||||
|
title: "Contexte du Projet"
|
||||||
|
description: Comment project-context.md guide les agents IA avec les règles et préférences de votre projet
|
||||||
|
sidebar:
|
||||||
|
order: 7
|
||||||
|
---
|
||||||
|
|
||||||
|
Le fichier `project-context.md` est le guide d'implémentation de votre projet pour les agents IA. Similaire à une « constitution » dans d'autres systèmes de développement, il capture les règles, les patterns et les préférences qui garantissent une génération de code cohérente à travers tous les workflows.
|
||||||
|
|
||||||
|
## Ce Qu'il Fait
|
||||||
|
|
||||||
|
Les agents IA prennent constamment des décisions d'implémentation — quels patterns suivre, comment structurer le code, quelles conventions utiliser. Sans guidance claire, ils peuvent :
|
||||||
|
- Suivre des bonnes pratiques génériques qui ne correspondent pas à votre codebase
|
||||||
|
- Prendre des décisions incohérentes selon les différentes stories
|
||||||
|
- Passer à côté d'exigences ou de contraintes spécifiques au projet
|
||||||
|
|
||||||
|
Le fichier `project-context.md` résout ce problème en documentant ce que les agents doivent savoir dans un format concis et optimisé pour les LLM.
|
||||||
|
|
||||||
|
## Comment Ça Fonctionne
|
||||||
|
|
||||||
|
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 :**
|
||||||
|
- `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
|
||||||
|
- `bmad-code-review` — valide par rapport aux standards du projet
|
||||||
|
- `bmad-quick-dev` — applique les patterns lors de l'implémentation des spécifications techniques
|
||||||
|
- `bmad-sprint-planning`, `bmad-retrospective`, `bmad-correct-course` — fournit le contexte global du projet
|
||||||
|
|
||||||
|
## Quand Le Créer
|
||||||
|
|
||||||
|
Le fichier `project-context.md` est utile à n'importe quel stade d'un projet :
|
||||||
|
|
||||||
|
| Scénario | Quand Créer | Objectif |
|
||||||
|
|------------------------------------------|-----------------------------------------------------|---------------------------------------------------------------------------------------|
|
||||||
|
| **Nouveau projet, avant l'architecture** | Manuellement, avant `bmad-create-architecture` | Documenter vos préférences techniques pour que l'architecte les respecte |
|
||||||
|
| **Nouveau projet, après l'architecture** | Via `bmad-generate-project-context` ou manuellement | Capturer les décisions d'architecture pour les agents d'implémentation |
|
||||||
|
| **Projet existant** | Via `bmad-generate-project-context` | Découvrir les patterns existants pour que les agents suivent les conventions établies |
|
||||||
|
| **Projet Quick Dev** | Avant ou pendant `bmad-quick-dev` | Garantir que l'implémentation rapide respecte vos patterns |
|
||||||
|
|
||||||
|
:::tip[Recommandé]
|
||||||
|
Pour les nouveaux projets, créez-le manuellement avant l'architecture si vous avez de fortes préférences techniques. Sinon, générez-le après l'architecture pour capturer ces décisions.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Ce Qu'il Contient
|
||||||
|
|
||||||
|
Le fichier a deux sections principales :
|
||||||
|
|
||||||
|
### Pile Technologique & Versions
|
||||||
|
|
||||||
|
Documente les frameworks, langages et outils utilisés par votre projet avec leurs versions spécifiques :
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
## Pile Technologique & Versions
|
||||||
|
|
||||||
|
- Node.js 20.x, TypeScript 5.3, React 18.2
|
||||||
|
- State: Zustand (pas Redux)
|
||||||
|
- Testing: Vitest, Playwright, MSW
|
||||||
|
- Styling: Tailwind CSS avec design tokens personnalisés
|
||||||
|
```
|
||||||
|
|
||||||
|
### Règles Critiques d’Implémentation
|
||||||
|
|
||||||
|
Documente les patterns et conventions que les agents pourraient autrement manquer :
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
|
||||||
|
## Règles Critiques d’Implémentation
|
||||||
|
|
||||||
|
**Configuration TypeScript :**
|
||||||
|
- Mode strict activé — pas de types `any` sans approbation explicite
|
||||||
|
- Utiliser `interface` pour les APIs publiques, `type` pour les unions/intersections
|
||||||
|
|
||||||
|
**Organisation du Code :**
|
||||||
|
- Composants dans `/src/components/` avec fichiers `.test.tsx` co-localisés
|
||||||
|
- Utilitaires dans `/src/lib/` pour les fonctions pures réutilisables
|
||||||
|
- Les appels API utilisent le singleton `apiClient` — jamais de fetch direct
|
||||||
|
|
||||||
|
**Patterns de Tests :**
|
||||||
|
- Les tests unitaires se concentrent sur la logique métier, pas sur les détails d’implémentation
|
||||||
|
- Les tests d’intégration utilisent MSW pour simuler les réponses API
|
||||||
|
- Les tests E2E couvrent uniquement les parcours utilisateurs critiques
|
||||||
|
|
||||||
|
**Spécifique au Framework :**
|
||||||
|
- Toutes les opérations async utilisent le wrapper `handleError` pour une gestion cohérente des erreurs
|
||||||
|
- Les feature flags sont accessibles via `featureFlag()` de `@/lib/flags`
|
||||||
|
- Les nouvelles routes suivent le modèle de routage basé sur les fichiers dans `/src/app/`
|
||||||
|
```
|
||||||
|
|
||||||
|
Concentrez-vous sur ce qui est **non évident** — des choses que les agents pourraient ne pas déduire en lisant des extraits de code. Ne documentez pas les pratiques standard qui s'appliquent universellement.
|
||||||
|
|
||||||
|
## Création du Fichier
|
||||||
|
|
||||||
|
Vous avez trois options :
|
||||||
|
|
||||||
|
### Création Manuelle
|
||||||
|
|
||||||
|
Créez le fichier `_bmad-output/project-context.md` et ajoutez vos règles :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Depuis la racine du projet
|
||||||
|
mkdir -p _bmad-output
|
||||||
|
touch _bmad-output/project-context.md
|
||||||
|
```
|
||||||
|
|
||||||
|
Éditez-le avec votre pile technologique et vos règles d'implémentation. Les workflows architecture et implémentation le trouveront et le chargeront automatiquement.
|
||||||
|
|
||||||
|
### Générer Après L'Architecture
|
||||||
|
|
||||||
|
Exécutez le workflow `bmad-generate-project-context` après avoir terminé votre architecture :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
bmad-generate-project-context
|
||||||
|
```
|
||||||
|
|
||||||
|
Cela analyse votre document d'architecture et vos fichiers projet pour générer un fichier de contexte capturant les décisions prises.
|
||||||
|
|
||||||
|
### Générer Pour Les Projets Existants
|
||||||
|
|
||||||
|
Pour les projets existants, exécutez `bmad-generate-project-context` pour découvrir les patterns existants :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
bmad-generate-project-context
|
||||||
|
```
|
||||||
|
|
||||||
|
Le workflow analyse votre codebase pour identifier les conventions, puis génère un fichier de contexte que vous pouvez examiner et affiner.
|
||||||
|
|
||||||
|
## Pourquoi C'est Important
|
||||||
|
|
||||||
|
Sans `project-context.md`, les agents font des suppositions qui peuvent ne pas correspondre à votre projet :
|
||||||
|
|
||||||
|
| Sans Contexte | Avec Contexte |
|
||||||
|
|----------------------------------------------------|-------------------------------------------------|
|
||||||
|
| Utilise des patterns génériques | Suit vos conventions établies |
|
||||||
|
| Style incohérent selon les stories | Implémentation cohérente |
|
||||||
|
| Peut manquer les contraintes spécifiques au projet | Respecte toutes les exigences techniques |
|
||||||
|
| Chaque agent décide indépendamment | Tous les agents s'alignent sur les mêmes règles |
|
||||||
|
|
||||||
|
C'est particulièrement important pour :
|
||||||
|
- **Quick Dev** — saute le PRD et l'architecture, le fichier de contexte comble le vide
|
||||||
|
- **Projets d'équipe** — garantit que tous les agents suivent les mêmes standards
|
||||||
|
- **Projets existants** — empêche de casser les patterns établis
|
||||||
|
|
||||||
|
## Édition et Mise à Jour
|
||||||
|
|
||||||
|
Le fichier `project-context.md` est un document vivant. Mettez-le à jour quand :
|
||||||
|
|
||||||
|
- Les décisions d'architecture changent
|
||||||
|
- De nouvelles conventions sont établies
|
||||||
|
- Les patterns évoluent pendant l'implémentation
|
||||||
|
- Vous identifiez des lacunes dans le comportement des agents
|
||||||
|
|
||||||
|
Vous pouvez l'éditer manuellement à tout moment, ou réexécuter `bmad-generate-project-context` pour le mettre à jour après des changements significatifs.
|
||||||
|
|
||||||
|
:::note[Emplacement du Fichier]
|
||||||
|
L'emplacement par défaut est `_bmad-output/project-context.md`. Les workflows le recherchent là, et vérifient également `**/project-context.md` n'importe où dans votre projet.
|
||||||
|
:::
|
||||||
|
|
@ -0,0 +1,79 @@
|
||||||
|
---
|
||||||
|
title: "Quick Dev"
|
||||||
|
description: Réduire la friction de l’interaction humaine sans renoncer aux points de contrôle qui protègent la qualité des résultats
|
||||||
|
sidebar:
|
||||||
|
order: 2
|
||||||
|
---
|
||||||
|
|
||||||
|
Intention en entrée, modifications de code en sortie, avec aussi peu d'interactions humaines dans la boucle que possible — sans sacrifier la qualité.
|
||||||
|
|
||||||
|
Il permet au modèle de s'exécuter plus longtemps entre les points de contrôle, puis ne vous fait intervenir que lorsque la tâche ne peut pas se poursuivre en toute sécurité sans jugement humain, ou lorsqu'il est temps de revoir le résultat final.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## Pourquoi cette fonctionnalité existe
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
`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.
|
||||||
|
|
||||||
|
## La conception fondamentale
|
||||||
|
|
||||||
|
### 1. Compresser l'intention d'abord
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
Ce workflow n'élimine pas le contrôle humain. Il le déplace vers un nombre réduit d’étapes à forte valeur :
|
||||||
|
|
||||||
|
- **Clarification de l'intention** - transformer une demande confuse en un objectif cohérent sans contradictions cachées
|
||||||
|
- **Approbation de la spécification** - confirmer que la compréhension figée correspond bien à ce qu'il faut construire
|
||||||
|
- **Revue du produit final** - le point de contrôle principal, où la personne décide si le résultat est acceptable à la fin
|
||||||
|
|
||||||
|
### 2. Router vers le chemin le plus court et sûr
|
||||||
|
|
||||||
|
Une fois l'objectif clair, le workflow décide s'il s'agit d'un véritable changement en une seule étape ou s'il nécessite le chemin complet. Les petits changements à zéro impact peuvent aller directement à l'implémentation. Tout le reste passe par la planification pour que le modèle dispose d'un cadre plus solide avant de s'exécuter plus longtemps de manière autonome.
|
||||||
|
|
||||||
|
### 3. S'exécuter plus longtemps avec moins de supervision
|
||||||
|
|
||||||
|
Après cette décision de routage, le modèle peut prendre en charge une plus grande partie du travail par lui-même. Sur le chemin complet, la spécification approuvée devient le cadre dans lequel le modèle s'exécute avec moins de supervision, ce qui est tout l'intérêt de la conception.
|
||||||
|
|
||||||
|
### 4. Diagnostiquer les échecs au bon niveau
|
||||||
|
|
||||||
|
Si l'implémentation est incorrecte parce que l'intention était mauvaise, corriger le code n'est pas la bonne solution. Si le code est incorrect parce que la spécification était faible, corriger le diff n'est pas non plus la bonne solution. Le workflow est conçu pour diagnostiquer où l'échec est entré dans le système, revenir à ce niveau, et régénérer à partir de ce point.
|
||||||
|
|
||||||
|
Les résultats de la revue sont utilisés pour décider si le problème provenait de l'intention, de la génération de la spécification, ou de l'implémentation locale. Seuls les véritables problèmes locaux sont corrigés localement.
|
||||||
|
|
||||||
|
### 5. Ne faire intervenir l’humain que si nécessaire
|
||||||
|
|
||||||
|
L'entretien sur l'intention implique la personne dans la boucle, mais ce n'est pas le même type d'interruption qu'un point de contrôle récurrent. Le workflow essaie de garder ces points de contrôle récurrents au minimum. Après la mise en forme initiale de l'intention, la personne revient principalement lorsque le workflow ne peut pas continuer en toute sécurité sans jugement, et à la fin, lorsqu'il est temps de revoir le résultat.
|
||||||
|
|
||||||
|
- **Résolution des lacunes d'intention** - intervenir à nouveau lors de la revue prouve que le workflow n'a pas pu déduire correctement ce qui était voulu
|
||||||
|
|
||||||
|
Tout le reste est candidat à une exécution autonome plus longue. Ce compromis est délibéré. Les anciens patterns dépensent plus d'attention humaine en supervision continue. Quick Dev fait davantage confiance au modèle, mais préserve l'attention humaine pour les moments où le raisonnement humain a le plus d'impact.
|
||||||
|
|
||||||
|
## Pourquoi le système de revue est important
|
||||||
|
|
||||||
|
La phase de revue n'est pas seulement là pour trouver des bugs. Elle est là pour router la correction sans détruire l'élan.
|
||||||
|
|
||||||
|
Ce workflow fonctionne mieux sur une plateforme capable de générer des sous-agents[^1], ou au moins d'invoquer un autre LLM via la ligne de commande et d'attendre un résultat. Si votre plateforme ne supporte pas cela nativement, vous pouvez ajouter un skill pour le faire. Les sous-agents sans contexte sont une pierre angulaire de la conception de la revue.
|
||||||
|
|
||||||
|
Les revues agentiques[^2] échouent souvent de deux manières :
|
||||||
|
|
||||||
|
- Elles génèrent trop d’observations, forçant la personne à trier le bruit.
|
||||||
|
- Elles déraillent des modifications actuelles en remontant des problèmes non liés et en transformant chaque exécution en un projet de nettoyage improvisé.
|
||||||
|
|
||||||
|
Quick Dev aborde ces deux problèmes en traitant la revue comme un triage[^3].
|
||||||
|
|
||||||
|
Lorsqu’une observation est fortuite plutôt que directement liée au travail en cours, le processus peut la mettre de côté au lieu d’obliger la personne à s’en occuper immédiatement. Cela permet de rester concentré sur l’exécution et d’éviter que des digressions aléatoires ne viennent épuiser le capital d’attention.
|
||||||
|
|
||||||
|
Ce triage sera parfois imparfait. C’est acceptable. Il est généralement préférable de mal juger certaines observations plutôt que d’inonder la personne de milliers de commentaires de revue à faible valeur. Le système optimise la qualité du rapport, pas d’être exhaustif.
|
||||||
|
|
||||||
|
## Glossaire
|
||||||
|
|
||||||
|
[^1]: Sous-agent : agent IA secondaire créé temporairement pour effectuer une tâche spécifique (comme une revue de code) de manière isolée, sans hériter du contexte complet de l’agent principal, ce qui permet une analyse plus objective et impartiale.
|
||||||
|
[^2]: Revues agentiques (agentic review) : revue de code effectuée par un agent IA de manière autonome, capable d’analyser, d’identifier des problèmes et de formuler des recommandations sans intervention humaine directe.
|
||||||
|
[^3]: Triage : processus de filtrage et de priorisation des observations issues d’une revue, afin de distinguer les problèmes pertinents à traiter immédiatement de ceux qui peuvent être mis de côté pour plus tard.
|
||||||
|
|
@ -0,0 +1,85 @@
|
||||||
|
---
|
||||||
|
title: "Pourquoi le Solutioning est Important"
|
||||||
|
description: Comprendre pourquoi la phase de solutioning est critique pour les projets multi-epics
|
||||||
|
sidebar:
|
||||||
|
order: 3
|
||||||
|
---
|
||||||
|
|
||||||
|
La Phase 3 (Solutioning) traduit le **quoi** construire (issu de la Planification) en **comment** le construire (conception technique). Cette phase évite les conflits entre agents dans les projets multi-epics en documentant les décisions architecturales avant le début de l'implémentation.
|
||||||
|
|
||||||
|
## Le Problème Sans Solutioning
|
||||||
|
|
||||||
|
```text
|
||||||
|
Agent 1 implémente l'Epic 1 avec une API REST
|
||||||
|
Agent 2 implémente l'Epic 2 avec GraphQL
|
||||||
|
Résultat : Conception d'API incohérente, cauchemar d'intégration
|
||||||
|
```
|
||||||
|
|
||||||
|
Lorsque plusieurs agents implémentent différentes parties d'un système sans orientation architecturale partagée, ils prennent des décisions techniques indépendantes qui peuvent entrer en conflit.
|
||||||
|
|
||||||
|
## La Solution Avec le Solutioning
|
||||||
|
|
||||||
|
```text
|
||||||
|
le workflow architecture décide : "Utiliser GraphQL pour toutes les API"
|
||||||
|
Tous les agents suivent les décisions d'architecture
|
||||||
|
Résultat : Implémentation cohérente, pas de conflits
|
||||||
|
```
|
||||||
|
|
||||||
|
En documentant les décisions techniques de manière explicite, tous les agents implémentent de façon cohérente et l'intégration devient simple.
|
||||||
|
|
||||||
|
## Solutioning vs Planification
|
||||||
|
|
||||||
|
| Aspect | Planification (Phase 2) | Solutioning (Phase 3) |
|
||||||
|
|----------|--------------------------|-------------------------------------------------|
|
||||||
|
| Question | Quoi et Pourquoi ? | Comment ? Puis Quelles unités de travail ? |
|
||||||
|
| Sortie | FRs/NFRs (Exigences)[^1] | Architecture + Epics[^2]/Stories[^3] |
|
||||||
|
| Agent | PM | Architect → PM |
|
||||||
|
| Audience | Parties prenantes | Développeurs |
|
||||||
|
| Document | PRD[^4] (FRs/NFRs) | Architecture + Fichiers Epics |
|
||||||
|
| Niveau | Logique métier | Conception technique + Décomposition du travail |
|
||||||
|
|
||||||
|
## Principe Clé
|
||||||
|
|
||||||
|
**Rendre les décisions techniques explicites et documentées** pour que tous les agents implémentent de manière cohérente.
|
||||||
|
|
||||||
|
Cela évite :
|
||||||
|
- Les conflits de style d'API (REST vs GraphQL)
|
||||||
|
- Les incohérences de conception de base de données
|
||||||
|
- Les désaccords sur la gestion du state
|
||||||
|
- Les inadéquations de conventions de nommage
|
||||||
|
- Les variations d'approche de sécurité
|
||||||
|
|
||||||
|
## Quand le Solutioning est Requis
|
||||||
|
|
||||||
|
| Parcours | Solutioning Requis ? |
|
||||||
|
|-----------------------|-----------------------------|
|
||||||
|
| Quick Dev | Non - l’ignore complètement |
|
||||||
|
| Méthode BMad Simple | Optionnel |
|
||||||
|
| Méthode BMad Complexe | Oui |
|
||||||
|
| Enterprise | Oui |
|
||||||
|
|
||||||
|
:::tip[Règle Générale]
|
||||||
|
Si vous avez plusieurs epics qui pourraient être implémentés par différents agents, vous avez besoin de solutioning.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Conséquences de sauter la phase de Solutioning
|
||||||
|
|
||||||
|
Sauter le solutioning sur des projets complexes entraîne :
|
||||||
|
|
||||||
|
- **Des problèmes d'intégration** découverts en milieu de sprint[^5]
|
||||||
|
- **Du travail répété** dû à des implémentations conflictuelles
|
||||||
|
- **Un temps de développement plus long** globalement
|
||||||
|
- **De la dette technique**[^6] due à des patterns incohérents
|
||||||
|
|
||||||
|
:::caution[Coût Multiplié]
|
||||||
|
Détecter les problèmes d'alignement lors du solutioning est 10× plus rapide que de les découvrir pendant l'implémentation.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Glossaire
|
||||||
|
|
||||||
|
[^1]: FR / NFR (Functional / Non-Functional Requirement) : exigences décrivant respectivement **ce que le système doit faire** (fonctionnalités, comportements attendus) et **comment il doit le faire** (contraintes de performance, sécurité, fiabilité, ergonomie, etc.).
|
||||||
|
[^2]: Epic : dans les méthodologies agiles, une unité de travail importante qui peut être décomposée en plusieurs stories plus petites. Un epic représente généralement une fonctionnalité majeure ou un objectif métier.
|
||||||
|
[^3]: Story (User Story) : description courte et simple d'une fonctionnalité du point de vue de l'utilisateur, utilisée dans les méthodologies agiles pour planifier et prioriser le travail.
|
||||||
|
[^4]: PRD (Product Requirements Document) : document de référence qui décrit les objectifs du produit, les besoins utilisateurs, les fonctionnalités attendues, les contraintes et les critères de succès, afin d'aligner les équipes sur ce qui doit être construit et pourquoi.
|
||||||
|
[^5]: Sprint : période de temps fixe (généralement 1 à 4 semaines) dans les méthodologies agiles durant laquelle l'équipe complète un ensemble prédéfini de tâches.
|
||||||
|
[^6]: Dette technique : coût futur supplémentaire de travail résultant de choix de facilité ou de raccourcis pris lors du développement initial, nécessitant souvent une refonte ultérieure.
|
||||||
|
|
@ -0,0 +1,174 @@
|
||||||
|
---
|
||||||
|
title: "Comment personnaliser BMad"
|
||||||
|
description: Personnalisez les agents, les workflows et les modules tout en préservant la compatibilité avec les mises à jour
|
||||||
|
sidebar:
|
||||||
|
order: 7
|
||||||
|
---
|
||||||
|
|
||||||
|
Utilisez les fichiers `.customize.yaml` pour adapter le comportement, les personas[^1] et les menus des agents tout en préservant vos modifications lors des mises à jour.
|
||||||
|
|
||||||
|
## Quand utiliser cette fonctionnalité
|
||||||
|
|
||||||
|
- Vous souhaitez modifier le nom, la personnalité ou le style de communication d'un agent
|
||||||
|
- Vous avez besoin que les agents se souviennent du contexte spécifique au projet
|
||||||
|
- Vous souhaitez ajouter des éléments de menu personnalisés qui déclenchent vos propres workflows ou prompts
|
||||||
|
- Vous voulez que les agents effectuent des actions spécifiques à chaque démarrage
|
||||||
|
|
||||||
|
:::note[Prérequis]
|
||||||
|
- BMad installé dans votre projet (voir [Comment installer BMad](./install-bmad.md))
|
||||||
|
- Un éditeur de texte pour les fichiers YAML
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::caution[Protégez vos personnalisations]
|
||||||
|
Utilisez toujours les fichiers `.customize.yaml` décrits ici plutôt que de modifier directement les fichiers d'agents. L'installateur écrase les fichiers d'agents lors des mises à jour, mais préserve vos modifications dans les fichiers `.customize.yaml`.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Étapes
|
||||||
|
|
||||||
|
### 1. Localiser les fichiers de personnalisation
|
||||||
|
|
||||||
|
Après l'installation, vous trouverez un fichier `.customize.yaml` par agent dans :
|
||||||
|
|
||||||
|
```text
|
||||||
|
_bmad/_config/agents/
|
||||||
|
├── bmm-analyst.customize.yaml
|
||||||
|
├── bmm-architect.customize.yaml
|
||||||
|
└── ... (un fichier par agent installé)
|
||||||
|
```
|
||||||
|
|
||||||
|
### 2. Modifier le fichier de personnalisation
|
||||||
|
|
||||||
|
Ouvrez le fichier `.customize.yaml` de l'agent que vous souhaitez modifier. Chaque section est facultative — personnalisez uniquement ce dont vous avez besoin.
|
||||||
|
|
||||||
|
| Section | Comportement | Objectif |
|
||||||
|
| ------------------ | ------------ | ------------------------------------------------ |
|
||||||
|
| `agent.metadata` | Remplace | Remplacer le nom d'affichage de l'agent |
|
||||||
|
| `persona` | Remplace | Définir le rôle, l'identité, le style et les principes |
|
||||||
|
| `memories` | Ajoute | Ajouter un contexte persistant que l'agent se rappelle toujours |
|
||||||
|
| `menu` | Ajoute | Ajouter des éléments de menu personnalisés pour les workflows ou prompts |
|
||||||
|
| `critical_actions` | Ajoute | Définir les instructions de démarrage de l'agent |
|
||||||
|
| `prompts` | Ajoute | Créer des prompts réutilisables pour les actions du menu |
|
||||||
|
|
||||||
|
Les sections marquées **Remplace** écrasent entièrement les valeurs par défaut de l'agent. Les sections marquées **Ajoute** s'ajoutent à la configuration existante.
|
||||||
|
|
||||||
|
**Nom de l'agent**
|
||||||
|
|
||||||
|
Modifier la façon dont l'agent se présente :
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
agent:
|
||||||
|
metadata:
|
||||||
|
name: 'Bob l’éponge' # Par défaut : "Mary"
|
||||||
|
```
|
||||||
|
|
||||||
|
**Persona**
|
||||||
|
|
||||||
|
Remplacer la personnalité, le rôle et le style de communication de l'agent :
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
persona:
|
||||||
|
role: 'Ingénieur Full-Stack Senior'
|
||||||
|
identity: 'Habite dans un ananas (au fond de la mer)'
|
||||||
|
communication_style: 'Style agaçant de Bob l’Éponge'
|
||||||
|
principles:
|
||||||
|
- 'Jamais de nidification, les devs Bob l’Éponge détestent plus de 2 niveaux d’imbrication'
|
||||||
|
- 'Privilégier la composition à l’héritage'
|
||||||
|
```
|
||||||
|
|
||||||
|
La section `persona`[^1] remplace entièrement le persona par défaut, donc incluez les quatre champs si vous la définissez.
|
||||||
|
|
||||||
|
**Souvenirs**
|
||||||
|
|
||||||
|
Ajouter un contexte persistant que l'agent gardera toujours en mémoire :
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
memories:
|
||||||
|
- 'Travaille au Krusty Krab'
|
||||||
|
- 'Célébrité préférée : David Hasslehoff'
|
||||||
|
- 'Appris dans l’Epic 1 que ce n’est pas cool de faire semblant que les tests ont passé'
|
||||||
|
```
|
||||||
|
|
||||||
|
**Éléments de menu**
|
||||||
|
|
||||||
|
Ajouter des entrées personnalisées au menu d'affichage de l'agent. Chaque élément nécessite un `trigger`, une cible (chemin `workflow` ou référence `action`), et une `description` :
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
menu:
|
||||||
|
- trigger: my-workflow
|
||||||
|
workflow: 'my-custom/workflows/my-workflow.yaml'
|
||||||
|
description: Mon workflow personnalisé
|
||||||
|
- trigger: deploy
|
||||||
|
action: '#deploy-prompt'
|
||||||
|
description: Déployer en production
|
||||||
|
```
|
||||||
|
|
||||||
|
**Actions critiques**
|
||||||
|
|
||||||
|
Définir des instructions qui s'exécutent au démarrage de l'agent :
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
critical_actions:
|
||||||
|
- 'Vérifier les pipelines CI avec le Skill XYZ et alerter l’utilisateur au réveil si quelque chose nécessite une attention urgente'
|
||||||
|
```
|
||||||
|
|
||||||
|
**Prompts personnalisés**
|
||||||
|
|
||||||
|
Créer des prompts réutilisables que les éléments de menu peuvent référencer avec `action="#id"` :
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
prompts:
|
||||||
|
- id: deploy-prompt
|
||||||
|
content: |
|
||||||
|
Déployer la branche actuelle en production :
|
||||||
|
1. Exécuter tous les tests
|
||||||
|
2. Build le projet
|
||||||
|
3. Exécuter le script de déploiement
|
||||||
|
```
|
||||||
|
|
||||||
|
### 3. Appliquer vos modifications
|
||||||
|
|
||||||
|
Après modification, réinstallez pour appliquer les changements :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npx bmad-method install
|
||||||
|
```
|
||||||
|
|
||||||
|
L'installateur détecte l'installation existante et propose ces options :
|
||||||
|
|
||||||
|
| Option | Ce qu'elle fait |
|
||||||
|
| ----------------------------------- | ---------------------------------------------------------------------- |
|
||||||
|
| **Quick Update** | Met à jour tous les modules vers la dernière version et applique les personnalisations |
|
||||||
|
| **Modify BMad Installation** | Flux d'installation complet pour ajouter ou supprimer des modules |
|
||||||
|
|
||||||
|
Pour des modifications de personnalisation uniquement, **Quick Update** est l'option la plus rapide.
|
||||||
|
|
||||||
|
## Résolution des problèmes
|
||||||
|
|
||||||
|
**Les modifications n'apparaissent pas ?**
|
||||||
|
|
||||||
|
- Exécutez `npx bmad-method install` et sélectionnez **Quick Update** pour appliquer les modifications
|
||||||
|
- Vérifiez que votre syntaxe YAML est valide (l'indentation compte)
|
||||||
|
- Assurez-vous d'avoir modifié le bon fichier `.customize.yaml` pour l'agent
|
||||||
|
|
||||||
|
**L'agent ne se charge pas ?**
|
||||||
|
|
||||||
|
- Vérifiez les erreurs de syntaxe YAML à l'aide d'un validateur YAML en ligne
|
||||||
|
- Assurez-vous de ne pas avoir laissé de champs vides après les avoir décommentés
|
||||||
|
- Essayez de revenir au modèle d'origine et de reconstruire
|
||||||
|
|
||||||
|
**Besoin de réinitialiser un agent ?**
|
||||||
|
|
||||||
|
- Effacez ou supprimez le fichier `.customize.yaml` de l'agent
|
||||||
|
- Exécutez `npx bmad-method install` et sélectionnez **Quick Update** pour restaurer les valeurs par défaut
|
||||||
|
|
||||||
|
## Personnalisation des workflows
|
||||||
|
|
||||||
|
La personnalisation des workflows et skills existants de la méthode BMad arrive bientôt.
|
||||||
|
|
||||||
|
## Personnalisation des modules
|
||||||
|
|
||||||
|
Les conseils sur la création de modules d'extension et la personnalisation des modules existants arrivent bientôt.
|
||||||
|
|
||||||
|
## Glossaire
|
||||||
|
|
||||||
|
[^1]: Persona : définition de la personnalité, du rôle et du style de communication d'un agent IA. Permet d'adapter le comportement et les réponses de l'agent selon les besoins du projet.
|
||||||
|
|
@ -0,0 +1,122 @@
|
||||||
|
---
|
||||||
|
title: "Projets existants"
|
||||||
|
description: Comment utiliser la méthode BMad sur des bases de code existantes
|
||||||
|
sidebar:
|
||||||
|
order: 6
|
||||||
|
---
|
||||||
|
|
||||||
|
Utilisez la méthode BMad efficacement lorsque vous travaillez sur des projets existants et des bases de code legacy.
|
||||||
|
|
||||||
|
Ce guide couvre le flux de travail essentiel pour l'intégration à des projets existants avec la méthode BMad.
|
||||||
|
|
||||||
|
:::note[Prérequis]
|
||||||
|
- méthode BMad installée (`npx bmad-method install`)
|
||||||
|
- Une base de code existante sur laquelle vous souhaitez travailler
|
||||||
|
- Accès à un IDE IA (Claude Code ou Cursor)
|
||||||
|
:::
|
||||||
|
|
||||||
|
## É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 :
|
||||||
|
|
||||||
|
- `docs/`
|
||||||
|
- `_bmad-output/planning-artifacts/`
|
||||||
|
- `_bmad-output/implementation-artifacts/`
|
||||||
|
|
||||||
|
## É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.
|
||||||
|
:::
|
||||||
|
|
||||||
|
Exécutez le workflow de génération de contexte du projet :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
bmad-generate-project-context
|
||||||
|
```
|
||||||
|
|
||||||
|
Cela analyse votre base de code pour identifier :
|
||||||
|
- La pile technologique et les versions
|
||||||
|
- Les patterns d'organisation du code
|
||||||
|
- Les conventions de nommage
|
||||||
|
- Les approches de test
|
||||||
|
- Les patterns spécifiques aux frameworks
|
||||||
|
|
||||||
|
Vous pouvez examiner et affiner le fichier généré, ou le créer manuellement à `_bmad-output/project-context.md` si vous préférez.
|
||||||
|
|
||||||
|
[En savoir plus sur le contexte du projet](../explanation/project-context.md)
|
||||||
|
|
||||||
|
## É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 :
|
||||||
|
|
||||||
|
- L'intention et la justification métier
|
||||||
|
- Les règles métier
|
||||||
|
- L'architecture
|
||||||
|
- Toute autre information pertinente sur le projet
|
||||||
|
|
||||||
|
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
|
||||||
|
|
||||||
|
### 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 :
|
||||||
|
|
||||||
|
- Inspecte votre projet pour voir ce qui a déjà été fait
|
||||||
|
- Affiche les options basées sur vos modules installés
|
||||||
|
- Comprend les requêtes en langage naturel
|
||||||
|
|
||||||
|
```
|
||||||
|
bmad-help J'ai une app Rails existante, par où dois-je commencer ?
|
||||||
|
bmad-help Quelle est la différence entre quick-dev et la méthode complète ?
|
||||||
|
bmad-help Montre-moi quels workflows sont disponibles
|
||||||
|
```
|
||||||
|
|
||||||
|
BMad-Help s'exécute également **automatiquement à la fin de chaque workflow**, fournissant des conseils clairs sur exactement quoi faire ensuite.
|
||||||
|
|
||||||
|
### Choisir votre approche
|
||||||
|
|
||||||
|
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. |
|
||||||
|
|
||||||
|
### Pendant la création du PRD
|
||||||
|
|
||||||
|
Lors de la création d'un brief ou en passant directement au PRD[^1], assurez-vous que l'agent :
|
||||||
|
|
||||||
|
- Trouve et analyse votre documentation de projet existante
|
||||||
|
- Lit le contexte approprié sur votre système actuel
|
||||||
|
|
||||||
|
Vous pouvez guider l'agent explicitement, mais l'objectif est de garantir que la nouvelle fonctionnalité s'intègre bien à votre système existant.
|
||||||
|
|
||||||
|
### Considérations UX
|
||||||
|
|
||||||
|
Le travail UX[^2] est optionnel. La décision dépend non pas de savoir si votre projet a une UX, mais de :
|
||||||
|
|
||||||
|
- Si vous allez travailler sur des modifications UX
|
||||||
|
- Si des conceptions ou patterns UX significatifs sont nécessaires
|
||||||
|
|
||||||
|
Si vos modifications se résument à de simples mises à jour d'écrans existants qui vous satisfont, un processus UX complet n'est pas nécessaire.
|
||||||
|
|
||||||
|
### Considérations d'architecture
|
||||||
|
|
||||||
|
Lors de la création de l'architecture, assurez-vous que l'architecte :
|
||||||
|
|
||||||
|
- Utilise les fichiers documentés appropriés
|
||||||
|
- Analyse la base de code existante
|
||||||
|
|
||||||
|
Soyez particulièrement attentif ici pour éviter de réinventer la roue ou de prendre des décisions qui ne s'alignent pas avec votre architecture existante.
|
||||||
|
|
||||||
|
## Plus d'informations
|
||||||
|
|
||||||
|
- **[Corrections rapides](./quick-fixes.md)** - Corrections de bugs et modifications ad-hoc
|
||||||
|
- **[FAQ Projets existants](../explanation/established-projects-faq.md)** - Questions courantes sur le travail sur des projets établis
|
||||||
|
|
||||||
|
## Glossaire
|
||||||
|
|
||||||
|
[^1]: PRD (Product Requirements Document) : document de référence qui décrit les objectifs du produit, les besoins utilisateurs, les fonctionnalités attendues, les contraintes et les critères de succès, afin d'aligner les équipes sur ce qui doit être construit et pourquoi.
|
||||||
|
[^2]: UX (User Experience) : expérience utilisateur, englobant l'ensemble des interactions et perceptions d'un utilisateur face à un produit. Le design UX vise à créer des interfaces intuitives, efficaces et agréables en tenant compte des besoins, comportements et contexte d'utilisation.
|
||||||
|
|
@ -0,0 +1,136 @@
|
||||||
|
---
|
||||||
|
title: "Comment obtenir des réponses à propos de BMad"
|
||||||
|
description: Utiliser un LLM pour répondre rapidement à vos questions sur BMad
|
||||||
|
sidebar:
|
||||||
|
order: 4
|
||||||
|
---
|
||||||
|
|
||||||
|
## Commencez ici : BMad-Help
|
||||||
|
|
||||||
|
**Le moyen le plus rapide d'obtenir des réponses sur BMad est le skill `bmad-help`.** Ce guide intelligent répondra à plus de 80 % de toutes les questions et est disponible directement dans votre IDE pendant que vous travaillez.
|
||||||
|
|
||||||
|
BMad-Help est bien plus qu'un outil de recherche — il :
|
||||||
|
- **Inspecte votre projet** pour voir ce qui a déjà été réalisé
|
||||||
|
- **Comprend le langage naturel** — posez vos questions en français courant
|
||||||
|
- **S'adapte à vos modules installés** — affiche les options pertinentes
|
||||||
|
- **Se lance automatiquement après les workflows** — vous indique exactement quoi faire ensuite
|
||||||
|
- **Recommande la première tâche requise** — plus besoin de deviner par où commencer
|
||||||
|
|
||||||
|
### Comment utiliser BMad-Help
|
||||||
|
|
||||||
|
Appelez-le par son nom dans votre session IA :
|
||||||
|
|
||||||
|
```
|
||||||
|
bmad-help
|
||||||
|
```
|
||||||
|
|
||||||
|
:::tip
|
||||||
|
Vous pouvez également utiliser `/bmad-help` ou `$bmad-help` selon votre plateforme, mais `bmad-help` tout seul devrait fonctionner partout.
|
||||||
|
:::
|
||||||
|
|
||||||
|
Combinez-le avec une requête en langage naturel :
|
||||||
|
|
||||||
|
```
|
||||||
|
bmad-help J'ai une idée de SaaS et je connais toutes les fonctionnalités. Par où commencer ?
|
||||||
|
bmad-help Quelles sont mes options pour le design UX ?
|
||||||
|
bmad-help Je suis bloqué sur le workflow PRD
|
||||||
|
bmad-help Montre-moi ce qui a été fait jusqu'à maintenant
|
||||||
|
```
|
||||||
|
|
||||||
|
BMad-Help répond avec :
|
||||||
|
- Ce qui est recommandé pour votre situation
|
||||||
|
- Quelle est la première tâche requise
|
||||||
|
- À quoi ressemble le reste du processus
|
||||||
|
|
||||||
|
## Quand utiliser ce guide
|
||||||
|
|
||||||
|
Utilisez cette section lorsque :
|
||||||
|
- Vous souhaitez comprendre l'architecture ou les éléments internes de BMad
|
||||||
|
- Vous avez besoin de réponses au-delà de ce que BMad-Help fournit
|
||||||
|
- Vous faites des recherches sur BMad avant l'installation
|
||||||
|
- Vous souhaitez explorer le code source directement
|
||||||
|
|
||||||
|
## Étapes
|
||||||
|
|
||||||
|
### 1. Choisissez votre source
|
||||||
|
|
||||||
|
| Source | Idéal pour | Exemples |
|
||||||
|
|-------------------------|------------------------------------------------------|---------------------------------------|
|
||||||
|
| **Dossier `_bmad`** | Comment fonctionne BMad — agents, workflows, prompts | "Que fait l'agent Analyste ?" |
|
||||||
|
| **Repo GitHub complet** | Historique, installateur, architecture | "Qu'est-ce qui a changé dans la v6 ?" |
|
||||||
|
| **`llms-full.txt`** | Aperçu rapide depuis la documentation | "Expliquez les quatre phases de BMad" |
|
||||||
|
|
||||||
|
Le dossier `_bmad` est créé lorsque vous installez BMad. Si vous ne l'avez pas encore, clonez le repo à la place.
|
||||||
|
|
||||||
|
### 2. Pointez votre IA vers la source
|
||||||
|
|
||||||
|
**Si votre IA peut lire des fichiers (Claude Code, Cursor, etc.) :**
|
||||||
|
|
||||||
|
- **BMad installé :** Pointez vers le dossier `_bmad` et posez vos questions directement
|
||||||
|
- **Vous voulez plus de contexte :** Clonez le [repo complet](https://github.com/bmad-code-org/BMAD-METHOD)
|
||||||
|
|
||||||
|
**Si vous utilisez ChatGPT ou Claude.ai (LLM en ligne) :**
|
||||||
|
|
||||||
|
Importez `llms-full.txt` dans votre session :
|
||||||
|
|
||||||
|
```text
|
||||||
|
https://bmad-code-org.github.io/BMAD-METHOD/llms-full.txt
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
|
### 3. Posez votre question
|
||||||
|
|
||||||
|
:::note[Exemple]
|
||||||
|
**Q :** "Quel est le moyen le plus rapide de construire quelque chose avec BMad ?"
|
||||||
|
|
||||||
|
**R :** Utilisez le workflow Quick Dev : 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.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Ce que vous obtenez
|
||||||
|
|
||||||
|
Des réponses directes sur BMad — comment fonctionnent les agents, ce que font les workflows, pourquoi les choses sont structurées ainsi — sans attendre la réponse de quelqu'un.
|
||||||
|
|
||||||
|
## Conseils
|
||||||
|
|
||||||
|
- **Vérifiez les réponses surprenantes** — Les LLM font parfois des erreurs. Consultez le fichier source ou posez la question sur Discord.
|
||||||
|
- **Soyez précis** — "Que fait l'étape 3 du workflow PRD ?" est mieux que "Comment fonctionne le PRD ?"
|
||||||
|
|
||||||
|
## Toujours bloqué ?
|
||||||
|
|
||||||
|
Avez-vous essayé l'approche LLM et avez encore besoin d'aide ? Vous avez maintenant une bien meilleure question à poser.
|
||||||
|
|
||||||
|
| Canal | Utilisé pour |
|
||||||
|
| ------------------------- | ------------------------------------------- |
|
||||||
|
| `#bmad-method-help` | Questions rapides (chat en temps réel) |
|
||||||
|
| Forum `help-requests` | Questions détaillées (recherchables, persistants) |
|
||||||
|
| `#suggestions-feedback` | Idées et demandes de fonctionnalités |
|
||||||
|
| `#report-bugs-and-issues` | Rapports de bugs |
|
||||||
|
|
||||||
|
**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) (pour les bugs clairs)
|
||||||
|
|
||||||
|
*Toi !*
|
||||||
|
*Bloqué*
|
||||||
|
*dans la file d'attente—*
|
||||||
|
*qui*
|
||||||
|
*attends-tu ?*
|
||||||
|
|
||||||
|
*La source*
|
||||||
|
*est là,*
|
||||||
|
*facile à voir !*
|
||||||
|
|
||||||
|
*Pointez*
|
||||||
|
*votre machine.*
|
||||||
|
*Libérez-la.*
|
||||||
|
|
||||||
|
*Elle lit.*
|
||||||
|
*Elle parle.*
|
||||||
|
*Demandez—*
|
||||||
|
|
||||||
|
*Pourquoi attendre*
|
||||||
|
*demain*
|
||||||
|
*quand tu as déjà*
|
||||||
|
*cette journée ?*
|
||||||
|
|
||||||
|
*—Claude*
|
||||||
|
|
@ -0,0 +1,116 @@
|
||||||
|
---
|
||||||
|
title: "Comment installer BMad"
|
||||||
|
description: Guide étape par étape pour installer BMad dans votre projet
|
||||||
|
sidebar:
|
||||||
|
order: 1
|
||||||
|
---
|
||||||
|
|
||||||
|
Utilisez la commande `npx bmad-method install` pour configurer BMad dans votre projet avec votre choix de modules et d'outils d'IA.
|
||||||
|
|
||||||
|
Si vous souhaitez utiliser un installateur non interactif et fournir toutes les options d'installation en ligne de commande, consultez [ce guide](./non-interactive-installation.md).
|
||||||
|
|
||||||
|
## Quand l'utiliser
|
||||||
|
|
||||||
|
- Démarrer un nouveau projet avec BMad
|
||||||
|
- Ajouter BMad à une base de code existante
|
||||||
|
- Mettre à jour une installation BMad existante
|
||||||
|
|
||||||
|
:::note[Prérequis]
|
||||||
|
- **Node.js** 20+ (requis pour l'installateur)
|
||||||
|
- **Git** (recommandé)
|
||||||
|
- **Outil d'IA** (Claude Code, Cursor, ou similaire)
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Étapes
|
||||||
|
|
||||||
|
### 1. Lancer l'installateur
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npx bmad-method install
|
||||||
|
```
|
||||||
|
|
||||||
|
:::tip[Vous voulez la dernière version préliminaire ?]
|
||||||
|
Utilisez le dist-tag `next` :
|
||||||
|
```bash
|
||||||
|
npx bmad-method@next install
|
||||||
|
```
|
||||||
|
|
||||||
|
Cela vous permet d'obtenir les nouvelles modifications plus tôt, avec un risque plus élevé de changements que l'installation par défaut.
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::tip[Version de développement]
|
||||||
|
Pour installer la dernière version depuis la branche main (peut être instable) :
|
||||||
|
```bash
|
||||||
|
npx github:bmad-code-org/BMAD-METHOD install
|
||||||
|
```
|
||||||
|
:::
|
||||||
|
|
||||||
|
### 2. Choisir l'emplacement d'installation
|
||||||
|
|
||||||
|
L'installateur vous demandera où installer les fichiers BMad :
|
||||||
|
|
||||||
|
- Répertoire courant (recommandé pour les nouveaux projets si vous avez créé le répertoire vous-même et l'exécutez depuis ce répertoire)
|
||||||
|
- Chemin personnalisé
|
||||||
|
|
||||||
|
### 3. Sélectionner vos outils d'IA
|
||||||
|
|
||||||
|
Choisissez les outils d'IA que vous utilisez :
|
||||||
|
|
||||||
|
- Claude Code
|
||||||
|
- Cursor
|
||||||
|
- Autres
|
||||||
|
|
||||||
|
Chaque outil a sa propre façon d'intégrer les skills. L'installateur crée de petits fichiers de prompt pour activer les workflows et les agents — il les place simplement là où votre outil s'attend à les trouver.
|
||||||
|
|
||||||
|
:::note[Activer les skills]
|
||||||
|
Certaines plateformes nécessitent que les skills soient explicitement activés dans les paramètres avant d'apparaître. Si vous installez BMad et ne voyez pas les skills, vérifiez les paramètres de votre plateforme ou demandez à votre assistant IA comment activer les skills.
|
||||||
|
:::
|
||||||
|
|
||||||
|
### 4. Choisir les modules
|
||||||
|
|
||||||
|
L'installateur affiche les modules disponibles. Sélectionnez ceux dont vous avez besoin — la plupart des utilisateurs veulent simplement **méthode BMad** (le module de développement logiciel).
|
||||||
|
|
||||||
|
### 5. Suivre les instructions
|
||||||
|
|
||||||
|
L'installateur vous guide pour le reste — contenu personnalisé, paramètres, etc.
|
||||||
|
|
||||||
|
## Ce que vous obtenez
|
||||||
|
|
||||||
|
```text
|
||||||
|
votre-projet/
|
||||||
|
├── _bmad/
|
||||||
|
│ ├── bmm/ # Vos modules sélectionnés
|
||||||
|
│ │ └── config.yaml # Paramètres du module (si vous devez les modifier)
|
||||||
|
│ ├── core/ # Module core requis
|
||||||
|
│ └── ...
|
||||||
|
├── _bmad-output/ # Artefacts générés
|
||||||
|
├── .claude/ # Skills Claude Code (si vous utilisez Claude Code)
|
||||||
|
│ └── skills/
|
||||||
|
│ ├── bmad-help/
|
||||||
|
│ ├── bmad-persona/
|
||||||
|
│ └── ...
|
||||||
|
└── .cursor/ # Skills Cursor (si vous utilisez Cursor)
|
||||||
|
└── skills/
|
||||||
|
└── ...
|
||||||
|
```
|
||||||
|
|
||||||
|
## Vérifier l'installation
|
||||||
|
|
||||||
|
Exécutez `bmad-help` pour vérifier que tout fonctionne et voir quoi faire ensuite.
|
||||||
|
|
||||||
|
**BMad-Help est votre guide intelligent** qui va :
|
||||||
|
- Confirmer que votre installation fonctionne
|
||||||
|
- Afficher ce qui est disponible en fonction de vos modules installés
|
||||||
|
- Recommander votre première étape
|
||||||
|
|
||||||
|
Vous pouvez aussi lui poser des questions :
|
||||||
|
```
|
||||||
|
bmad-help Je viens d'installer, que dois-je faire en premier ?
|
||||||
|
bmad-help Quelles sont mes options pour un projet SaaS ?
|
||||||
|
```
|
||||||
|
|
||||||
|
## Résolution de problèmes
|
||||||
|
|
||||||
|
**L'installateur affiche une erreur** — Copiez-collez la sortie dans votre assistant IA et laissez-le résoudre le problème.
|
||||||
|
|
||||||
|
**L'installateur a fonctionné mais quelque chose ne fonctionne pas plus tard** — Votre IA a besoin du contexte BMad pour vous aider. Consultez [Comment obtenir des réponses à propos de BMad](./get-answers-about-bmad.md) pour savoir comment diriger votre IA vers les bonnes sources.
|
||||||
|
|
@ -0,0 +1,171 @@
|
||||||
|
---
|
||||||
|
title: Installation non-interactive
|
||||||
|
description: Installer BMad en utilisant des options de ligne de commande pour les pipelines CI/CD et les déploiements automatisés
|
||||||
|
sidebar:
|
||||||
|
order: 2
|
||||||
|
---
|
||||||
|
|
||||||
|
Utilisez les options de ligne de commande pour installer BMad de manière non-interactive. Cela est utile pour :
|
||||||
|
|
||||||
|
## Quand utiliser cette méthode
|
||||||
|
|
||||||
|
- Déploiements automatisés et pipelines CI/CD
|
||||||
|
- Installations scriptées
|
||||||
|
- Installations par lots sur plusieurs projets
|
||||||
|
- Installations rapides avec des configurations connues
|
||||||
|
|
||||||
|
:::note[Prérequis]
|
||||||
|
Nécessite [Node.js](https://nodejs.org) v20+ et `npx` (inclus avec npm).
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Options disponibles
|
||||||
|
|
||||||
|
### Options d'installation
|
||||||
|
|
||||||
|
| Option | Description | Exemple |
|
||||||
|
|------|-------------|---------|
|
||||||
|
| `--directory <chemin>` | Répertoire d'installation | `--directory ~/projects/myapp` |
|
||||||
|
| `--modules <modules>` | IDs de modules séparés par des virgules | `--modules bmm,bmb` |
|
||||||
|
| `--tools <outils>` | IDs d'outils/IDE séparés par des virgules (utilisez `none` pour ignorer) | `--tools claude-code,cursor` ou `--tools none` |
|
||||||
|
| `--custom-content <chemins>` | Chemins vers des modules personnalisés séparés par des virgules | `--custom-content ~/my-module,~/another-module` |
|
||||||
|
| `--action <type>` | Action pour les installations existantes : `install` (par défaut), `update`, ou `quick-update` | `--action quick-update` |
|
||||||
|
|
||||||
|
### Configuration principale
|
||||||
|
|
||||||
|
| Option | Description | Par défaut |
|
||||||
|
|------|-------------|---------|
|
||||||
|
| `--user-name <nom>` | Nom à utiliser par les agents | Nom d'utilisateur système |
|
||||||
|
| `--communication-language <langue>` | Langue de communication des agents | Anglais |
|
||||||
|
| `--document-output-language <langue>` | Langue de sortie des documents | Anglais |
|
||||||
|
| `--output-folder <chemin>` | Chemin du dossier de sortie | _bmad-output |
|
||||||
|
|
||||||
|
### Autres options
|
||||||
|
|
||||||
|
| Option | Description |
|
||||||
|
|------|-------------|
|
||||||
|
| `-y, --yes` | Accepter tous les paramètres par défaut et ignorer les invites |
|
||||||
|
| `-d, --debug` | Activer la sortie de débogage pour la génération du manifeste |
|
||||||
|
|
||||||
|
## IDs de modules
|
||||||
|
|
||||||
|
IDs de modules disponibles pour l’option `--modules` :
|
||||||
|
|
||||||
|
- `bmm` — méthode BMad Master
|
||||||
|
- `bmb` — BMad Builder
|
||||||
|
|
||||||
|
Consultez le [registre BMad](https://github.com/bmad-code-org) pour les modules externes disponibles.
|
||||||
|
|
||||||
|
## IDs d'outils/IDE
|
||||||
|
|
||||||
|
IDs d'outils disponibles pour l’option `--tools` :
|
||||||
|
|
||||||
|
**Recommandés :** `claude-code`, `cursor`
|
||||||
|
|
||||||
|
Exécutez `npx bmad-method install` de manière interactive une fois pour voir la liste complète actuelle des outils pris en charge, ou consultez la [configuration des codes de la plateforme](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/tools/cli/installers/lib/ide/platform-codes.yaml).
|
||||||
|
|
||||||
|
## Modes d'installation
|
||||||
|
|
||||||
|
| Mode | Description | Exemple |
|
||||||
|
|------|-------------|---------|
|
||||||
|
| Entièrement non-interactif | Fournir toutes les options pour ignorer toutes les invites | `npx bmad-method install --directory . --modules bmm --tools claude-code --yes` |
|
||||||
|
| Semi-interactif | Fournir certains options ; BMad demande les autres | `npx bmad-method install --directory . --modules bmm` |
|
||||||
|
| Paramètres par défaut uniquement | Accepter tous les paramètres par défaut avec `-y` | `npx bmad-method install --yes` |
|
||||||
|
| Sans outils | Ignorer la configuration des outils/IDE | `npx bmad-method install --modules bmm --tools none` |
|
||||||
|
|
||||||
|
## Exemples
|
||||||
|
|
||||||
|
### Installation dans un pipeline CI/CD
|
||||||
|
|
||||||
|
```bash
|
||||||
|
#!/bin/bash
|
||||||
|
# install-bmad.sh
|
||||||
|
|
||||||
|
npx bmad-method install \
|
||||||
|
--directory "${GITHUB_WORKSPACE}" \
|
||||||
|
--modules bmm \
|
||||||
|
--tools claude-code \
|
||||||
|
--user-name "CI Bot" \
|
||||||
|
--communication-language Français \
|
||||||
|
--document-output-language Français \
|
||||||
|
--output-folder _bmad-output \
|
||||||
|
--yes
|
||||||
|
```
|
||||||
|
|
||||||
|
### Mettre à jour une installation existante
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npx bmad-method install \
|
||||||
|
--directory ~/projects/myapp \
|
||||||
|
--action update \
|
||||||
|
--modules bmm,bmb,custom-module
|
||||||
|
```
|
||||||
|
|
||||||
|
### Mise à jour rapide (conserver les paramètres)
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npx bmad-method install \
|
||||||
|
--directory ~/projects/myapp \
|
||||||
|
--action quick-update
|
||||||
|
```
|
||||||
|
|
||||||
|
### Installation avec du contenu personnalisé
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npx bmad-method install \
|
||||||
|
--directory ~/projects/myapp \
|
||||||
|
--modules bmm \
|
||||||
|
--custom-content ~/my-custom-module,~/another-module \
|
||||||
|
--tools claude-code
|
||||||
|
```
|
||||||
|
|
||||||
|
## Ce que vous obtenez
|
||||||
|
|
||||||
|
- Un répertoire `_bmad/` entièrement configuré dans votre projet
|
||||||
|
- Des agents et des flux de travail configurés pour vos modules et outils sélectionnés
|
||||||
|
- Un dossier `_bmad-output/` pour les artefacts générés
|
||||||
|
|
||||||
|
## Validation et gestion des erreurs
|
||||||
|
|
||||||
|
BMad valide toutes les options fournis :
|
||||||
|
|
||||||
|
- **Directory** — Doit être un chemin valide avec des permissions d'écriture
|
||||||
|
- **Modules** — Avertit des IDs de modules invalides (mais n'échoue pas)
|
||||||
|
- **Tools** — Avertit des IDs d'outils invalides (mais n'échoue pas)
|
||||||
|
- **Custom Content** — Chaque chemin doit contenir un fichier `module.yaml` valide
|
||||||
|
- **Action** — Doit être l'une des suivantes : `install`, `update`, `quick-update`
|
||||||
|
|
||||||
|
Les valeurs invalides entraîneront soit :
|
||||||
|
1. L’affichage d’un message d'erreur suivi d’un exit (pour les options critiques comme le répertoire)
|
||||||
|
2. Un avertissement puis la continuation de l’installation (pour les éléments optionnels comme le contenu personnalisé)
|
||||||
|
3. Un retour aux invites interactives (pour les valeurs requises manquantes)
|
||||||
|
|
||||||
|
:::tip[Bonnes pratiques]
|
||||||
|
- Utilisez des chemins absolus pour `--directory` pour éviter toute ambiguïté
|
||||||
|
- Testez les options localement avant de les utiliser dans des pipelines CI/CD
|
||||||
|
- Combinez avec `-y` pour des installations vraiment sans surveillance
|
||||||
|
- Utilisez `--debug` si vous rencontrez des problèmes lors de l'installation
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Résolution des problèmes
|
||||||
|
|
||||||
|
### L'installation échoue avec "Invalid directory"
|
||||||
|
|
||||||
|
- Le chemin du répertoire doit exister (ou son parent doit exister)
|
||||||
|
- Vous avez besoin des permissions d'écriture
|
||||||
|
- Le chemin doit être absolu ou correctement relatif au répertoire actuel
|
||||||
|
|
||||||
|
### Module non trouvé
|
||||||
|
|
||||||
|
- Vérifiez que l'ID du module est correct
|
||||||
|
- Les modules externes doivent être disponibles dans le registre
|
||||||
|
|
||||||
|
### Chemin de contenu personnalisé invalide
|
||||||
|
|
||||||
|
Assurez-vous que chaque chemin de contenu personnalisé :
|
||||||
|
- Pointe vers un répertoire
|
||||||
|
- Contient un fichier `module.yaml` à la racine
|
||||||
|
- Possède un champ `code` dans `module.yaml`
|
||||||
|
|
||||||
|
:::note[Toujours bloqué ?]
|
||||||
|
Exécutez avec `--debug` pour une sortie détaillée, essayez le mode interactif pour isoler le problème, ou signalez-le à <https://github.com/bmad-code-org/BMAD-METHOD/issues>.
|
||||||
|
:::
|
||||||
|
|
@ -0,0 +1,127 @@
|
||||||
|
---
|
||||||
|
title: "Gérer le contexte du projet"
|
||||||
|
description: Créer et maintenir project-context.md pour guider les agents IA
|
||||||
|
sidebar:
|
||||||
|
order: 8
|
||||||
|
---
|
||||||
|
|
||||||
|
Utilisez le fichier `project-context.md` pour garantir que les agents IA respectent les préférences techniques et les règles d'implémentation de votre projet tout au long des workflows. Pour vous assurer qu'il est toujours disponible, vous pouvez également ajouter la ligne `Le contexte et les conventions importantes du projet se trouvent dans [chemin vers le contexte du projet]/project-context.md` à votre fichier de contexte ou de règles permanentes (comme `AGENTS.md`).
|
||||||
|
|
||||||
|
:::note[Prérequis]
|
||||||
|
- Méthode BMad installée
|
||||||
|
- Connaissance de la pile technologique et des conventions de votre projet
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Quand utiliser cette fonctionnalité
|
||||||
|
|
||||||
|
- Vous avez des préférences techniques fortes avant de commencer l'architecture
|
||||||
|
- Vous avez terminé l'architecture et souhaitez consigner les décisions pour l'implémentation
|
||||||
|
- 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
|
||||||
|
|
||||||
|
**Création manuelle** — Idéal lorsque vous savez exactement quelles règles vous souhaitez documenter
|
||||||
|
|
||||||
|
**Génération après l'architecture** — Idéal pour capturer les décisions prises lors du solutioning
|
||||||
|
|
||||||
|
**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
|
||||||
|
|
||||||
|
### Option A : Création manuelle
|
||||||
|
|
||||||
|
Créez le fichier à l'emplacement `_bmad-output/project-context.md` :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
mkdir -p _bmad-output
|
||||||
|
touch _bmad-output/project-context.md
|
||||||
|
```
|
||||||
|
|
||||||
|
Ajoutez votre pile technologique et vos règles d'implémentation :
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
---
|
||||||
|
project_name: 'MonProjet'
|
||||||
|
user_name: 'VotreNom'
|
||||||
|
date: '2026-02-15'
|
||||||
|
sections_completed: ['technology_stack', 'critical_rules']
|
||||||
|
---
|
||||||
|
|
||||||
|
# Contexte de Projet pour Agents IA
|
||||||
|
|
||||||
|
## Pile Technologique & Versions
|
||||||
|
|
||||||
|
- Node.js 20.x, TypeScript 5.3, React 18.2
|
||||||
|
- State : Zustand
|
||||||
|
- Tests : Vitest, Playwright
|
||||||
|
- Styles : Tailwind CSS
|
||||||
|
|
||||||
|
## Règles d'Implémentation Critiques
|
||||||
|
|
||||||
|
**TypeScript :**
|
||||||
|
- Mode strict activé, pas de types `any`
|
||||||
|
- Utiliser `interface` pour les API publiques, `type` pour les unions
|
||||||
|
|
||||||
|
**Organisation du Code :**
|
||||||
|
- Composants dans `/src/components/` avec tests co-localisés
|
||||||
|
- Les appels API utilisent le singleton `apiClient` — jamais de fetch direct
|
||||||
|
|
||||||
|
**Tests :**
|
||||||
|
- Tests unitaires axés sur la logique métier
|
||||||
|
- Tests d'intégration utilisent MSW pour le mock API
|
||||||
|
```
|
||||||
|
|
||||||
|
### Option B : Génération après l'architecture
|
||||||
|
|
||||||
|
Exécutez le workflow dans une nouvelle conversation :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
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
|
||||||
|
|
||||||
|
Pour les projets existants, exécutez :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
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
|
||||||
|
|
||||||
|
Révisez le fichier généré et assurez-vous qu'il capture :
|
||||||
|
|
||||||
|
- Les versions correctes des technologies
|
||||||
|
- Vos conventions réelles (pas les bonnes pratiques génériques)
|
||||||
|
- Les règles qui évitent les erreurs courantes
|
||||||
|
- Les patterns spécifiques aux frameworks
|
||||||
|
|
||||||
|
Modifiez manuellement pour ajouter les éléments manquants ou supprimer les inexactitudes.
|
||||||
|
|
||||||
|
## Ce que vous obtenez
|
||||||
|
|
||||||
|
Un fichier `project-context.md` qui :
|
||||||
|
|
||||||
|
- Garantit que tous les agents suivent les mêmes conventions
|
||||||
|
- Évite les décisions incohérentes entre les stories
|
||||||
|
- Capture les décisions d'architecture pour l'implémentation
|
||||||
|
- Sert de référence pour les patterns et règles de votre projet
|
||||||
|
|
||||||
|
## Conseils
|
||||||
|
|
||||||
|
:::tip[Bonnes pratiques]
|
||||||
|
- **Concentrez-vous sur ce qui n'est pas évident** — Documentez les patterns que les agents pourraient manquer (par ex. « Utiliser JSDoc sur chaque classe publique »), et non les pratiques universelles comme « utiliser des noms de variables significatifs ».
|
||||||
|
- **Gardez-le concis** — Ce fichier est chargé par chaque workflow d'implémentation. Les fichiers longs gaspillent le contexte. Excluez le contenu qui ne s'applique qu'à un périmètre restreint ou à des stories spécifiques.
|
||||||
|
- **Mettez à jour si nécessaire** — Modifiez manuellement lorsque les patterns changent, ou régénérez après des changements d'architecture significatifs.
|
||||||
|
- Fonctionne aussi bien pour Quick Dev que pour les projets complets méthode BMad.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Prochaines étapes
|
||||||
|
|
||||||
|
- [**Explication du contexte projet**](../explanation/project-context.md) — En savoir plus sur son fonctionnement
|
||||||
|
- [**Carte des workflows**](../reference/workflow-map.md) — Voir quels workflows chargent le contexte projet
|
||||||
|
|
@ -0,0 +1,98 @@
|
||||||
|
---
|
||||||
|
title: "Corrections Rapides"
|
||||||
|
description: Comment effectuer des corrections rapides et des modifications ciblées
|
||||||
|
sidebar:
|
||||||
|
order: 5
|
||||||
|
---
|
||||||
|
|
||||||
|
Utilisez **Quick Dev** pour les corrections de bugs, les refactorisations ou les petites modifications ciblées qui ne nécessitent pas la méthode BMad complète.
|
||||||
|
|
||||||
|
## Quand Utiliser Cette Approche
|
||||||
|
|
||||||
|
- Corrections de bugs avec une cause claire et connue
|
||||||
|
- Petites refactorisations (renommage, extraction, restructuration) contenues dans quelques fichiers
|
||||||
|
- Ajustements mineurs de fonctionnalités ou modifications de configuration
|
||||||
|
- Mises à jour de dépendances
|
||||||
|
|
||||||
|
:::note[Prérequis]
|
||||||
|
- Méthode BMad installée (`npx bmad-method install`)
|
||||||
|
- Un IDE IA (Claude Code, Cursor, ou similaire)
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Étapes
|
||||||
|
|
||||||
|
### 1. Démarrer une Nouvelle Conversation
|
||||||
|
|
||||||
|
Ouvrez une **nouvelle conversation** dans votre IDE IA. Réutiliser une session d'un workflow précédent peut causer des conflits de contexte.
|
||||||
|
|
||||||
|
### 2. Spécifiez Votre Intention
|
||||||
|
|
||||||
|
Quick Dev accepte l'intention en forme libre — avant, avec, ou après l'invocation. Exemples :
|
||||||
|
|
||||||
|
```text
|
||||||
|
quick-dev — Corrige le bug de validation de connexion qui permet les mots de passe vides.
|
||||||
|
```
|
||||||
|
|
||||||
|
```text
|
||||||
|
quick-dev — corrige https://github.com/org/repo/issues/42
|
||||||
|
```
|
||||||
|
|
||||||
|
```text
|
||||||
|
quick-dev — implémente _bmad-output/implementation-artifacts/my-intent.md
|
||||||
|
```
|
||||||
|
|
||||||
|
```text
|
||||||
|
Je pense que le problème est dans le middleware d'auth, il ne vérifie pas l'expiration du token.
|
||||||
|
Regardons... oui, src/auth/middleware.ts ligne 47 saute complètement la vérification exp. lance quick-dev
|
||||||
|
```
|
||||||
|
|
||||||
|
```text
|
||||||
|
quick-dev
|
||||||
|
> Que voulez-vous faire ?
|
||||||
|
Refactoriser UserService pour utiliser async/await au lieu des callbacks.
|
||||||
|
```
|
||||||
|
|
||||||
|
Texte brut, chemins de fichiers, URLs d'issues GitHub, liens de trackers de bugs — tout ce que le LLM peut résoudre en une intention concrète.
|
||||||
|
|
||||||
|
### 3. Répondre aux Questions et Approuver
|
||||||
|
|
||||||
|
Quick Dev peut poser des questions de clarification ou présenter une courte spécification demandant votre approbation avant l'implémentation. Répondez à ses questions et approuvez lorsque vous êtes satisfait du plan.
|
||||||
|
|
||||||
|
### 4. Réviser et Pousser
|
||||||
|
|
||||||
|
Quick Dev implémente la modification, révise son propre travail, corrige les problèmes et effectue un commit local. Lorsqu'il a terminé, il ouvre les fichiers affectés dans votre éditeur.
|
||||||
|
|
||||||
|
- Parcourez le diff pour confirmer que la modification correspond à votre intention
|
||||||
|
- Si quelque chose semble incorrect, dites à l'agent ce qu'il faut corriger — il peut itérer dans la même session
|
||||||
|
|
||||||
|
Une fois satisfait, poussez le commit. Quick Dev vous proposera de pousser et de créer une PR pour vous.
|
||||||
|
|
||||||
|
:::caution[Si Quelque Chose Casse]
|
||||||
|
Si une modification poussée cause des problèmes inattendus, utilisez `git revert HEAD` pour annuler proprement le dernier commit. Ensuite, démarrez une nouvelle conversation et exécutez Quick Dev à nouveau pour essayer une approche différente.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Ce Que Vous Obtenez
|
||||||
|
|
||||||
|
- Fichiers source modifiés avec la correction ou refactorisation appliquée
|
||||||
|
- Tests passants (si votre projet a une suite de tests)
|
||||||
|
- Un commit prêt à pousser avec un message de commit conventionnel
|
||||||
|
|
||||||
|
## Travail Différé
|
||||||
|
|
||||||
|
Quick Dev garde chaque exécution concentrée sur un seul objectif. Si votre demande contient plusieurs objectifs indépendants, ou si la revue remonte des problèmes préexistants non liés à votre modification, Quick Dev les diffère vers un fichier (`deferred-work.md` dans votre répertoire d'artefacts d'implémentation) plutôt que d'essayer de tout régler en même temps.
|
||||||
|
|
||||||
|
Consultez ce fichier après une exécution — c'est votre backlog[^1] de choses sur lesquelles revenir. Chaque élément différé peut être introduit dans une nouvelle exécution Quick Dev ultérieurement.
|
||||||
|
|
||||||
|
## Quand Passer à une Planification Formelle
|
||||||
|
|
||||||
|
Envisagez d'utiliser la méthode BMad complète lorsque :
|
||||||
|
|
||||||
|
- La modification affecte plusieurs systèmes ou nécessite des mises à jour coordonnées dans de nombreux fichiers
|
||||||
|
- Vous n'êtes pas sûr de la portée et avez besoin d'une découverte des exigences d'abord
|
||||||
|
- Vous avez besoin de documentation ou de décisions architecturales enregistrées pour l'équipe
|
||||||
|
|
||||||
|
Voir [Quick Dev](../explanation/quick-dev.md) pour plus d'informations sur la façon dont Quick Dev s'intègre dans la méthode BMad.
|
||||||
|
|
||||||
|
## Glossaire
|
||||||
|
|
||||||
|
[^1]: Backlog : liste priorisée de tâches ou d'éléments de travail à traiter ultérieurement, issue des méthodologies agiles.
|
||||||
|
|
@ -0,0 +1,78 @@
|
||||||
|
---
|
||||||
|
title: "Guide de Division de Documents"
|
||||||
|
description: Diviser les fichiers markdown volumineux en fichiers plus petits et organisés pour une meilleure gestion du contexte
|
||||||
|
sidebar:
|
||||||
|
order: 9
|
||||||
|
---
|
||||||
|
|
||||||
|
Utilisez l'outil `bmad-shard-doc` si vous avez besoin de diviser des fichiers markdown volumineux en fichiers plus petits et organisés pour une meilleure gestion du contexte.
|
||||||
|
|
||||||
|
:::caution[Déprécié]
|
||||||
|
Ceci n'est plus recommandé, et bientôt avec les workflows mis à jour et la plupart des LLM et outils majeurs supportant les sous-processus, cela deviendra inutile.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Quand l’Utiliser
|
||||||
|
|
||||||
|
Utilisez ceci uniquement si vous remarquez que votre combinaison outil / modèle ne parvient pas à charger et lire tous les documents en entrée lorsque c'est nécessaire.
|
||||||
|
|
||||||
|
## Qu'est-ce que la Division de Documents ?
|
||||||
|
|
||||||
|
La division de documents divise les fichiers markdown volumineux en fichiers plus petits et organisés basés sur les titres de niveau 2 (`## Titre`).
|
||||||
|
|
||||||
|
### Architecture
|
||||||
|
|
||||||
|
```text
|
||||||
|
Avant Division :
|
||||||
|
_bmad-output/planning-artifacts/
|
||||||
|
└── PRD.md (fichier volumineux de 50k tokens)
|
||||||
|
|
||||||
|
Après Division :
|
||||||
|
_bmad-output/planning-artifacts/
|
||||||
|
└── prd/
|
||||||
|
├── index.md # Table des matières avec descriptions
|
||||||
|
├── overview.md # Section 1
|
||||||
|
├── user-requirements.md # Section 2
|
||||||
|
├── technical-requirements.md # Section 3
|
||||||
|
└── ... # Sections supplémentaires
|
||||||
|
```
|
||||||
|
|
||||||
|
## Étapes
|
||||||
|
|
||||||
|
### 1. Exécuter l'Outil Shard-Doc
|
||||||
|
|
||||||
|
```bash
|
||||||
|
/bmad-shard-doc
|
||||||
|
```
|
||||||
|
|
||||||
|
### 2. Suivre le Processus Interactif
|
||||||
|
|
||||||
|
```text
|
||||||
|
Agent : Quel document souhaitez-vous diviser ?
|
||||||
|
Utilisateur : docs/PRD.md
|
||||||
|
|
||||||
|
Agent : Destination par défaut : docs/prd/
|
||||||
|
Accepter la valeur par défaut ? [y/n]
|
||||||
|
Utilisateur : y
|
||||||
|
|
||||||
|
Agent : Division de PRD.md...
|
||||||
|
✓ 12 fichiers de section créés
|
||||||
|
✓ index.md généré
|
||||||
|
✓ Terminé !
|
||||||
|
```
|
||||||
|
|
||||||
|
## Comment Fonctionne la Découverte de Workflow
|
||||||
|
|
||||||
|
Les workflows BMad utilisent un **système de découverte double** :
|
||||||
|
|
||||||
|
1. **Essaye d'abord le document entier** - Rechercher `document-name.md`
|
||||||
|
2. **Vérifie la version divisée** - Rechercher `document-name/index.md`
|
||||||
|
3. **Règle de priorité** - Le document entier a la priorité si les deux existent - supprimez le document entier si vous souhaitez que la version divisée soit utilisée à la place
|
||||||
|
|
||||||
|
## Support des Workflows
|
||||||
|
|
||||||
|
Tous les workflows BMM prennent en charge les deux formats :
|
||||||
|
|
||||||
|
- Documents entiers
|
||||||
|
- Documents divisés
|
||||||
|
- Détection automatique
|
||||||
|
- Transparent pour l'utilisateur
|
||||||
|
|
@ -0,0 +1,106 @@
|
||||||
|
---
|
||||||
|
title: "Comment passer à la v6"
|
||||||
|
description: Migrer de BMad v4 vers v6
|
||||||
|
sidebar:
|
||||||
|
order: 3
|
||||||
|
---
|
||||||
|
|
||||||
|
Utilisez l'installateur BMad pour passer de la v4 à la v6, qui inclut une détection automatique des installations existantes et une assistance à la migration.
|
||||||
|
|
||||||
|
## Quand utiliser ce guide
|
||||||
|
|
||||||
|
- Vous avez BMad v4 installé (dossier `.bmad-method`)
|
||||||
|
- Vous souhaitez migrer vers la nouvelle architecture v6
|
||||||
|
- Vous avez des artefacts de planification existants à préserver
|
||||||
|
|
||||||
|
:::note[Prérequis]
|
||||||
|
- Node.js 20+
|
||||||
|
- Installation BMad v4 existante
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Étapes
|
||||||
|
|
||||||
|
### 1. Lancer l'installateur
|
||||||
|
|
||||||
|
Suivez les [Instructions d'installation](./install-bmad.md).
|
||||||
|
|
||||||
|
### 2. Gérer l'installation existante
|
||||||
|
|
||||||
|
Quand v4 est détecté, vous pouvez :
|
||||||
|
|
||||||
|
- Autoriser l'installateur à sauvegarder et supprimer `.bmad-method`
|
||||||
|
- Quitter et gérer le nettoyage manuellement
|
||||||
|
|
||||||
|
Si vous avez nommé votre dossier de méthode bmad autrement, vous devrez supprimer le dossier vous-même manuellement.
|
||||||
|
|
||||||
|
### 3. Nettoyer les skills IDE
|
||||||
|
|
||||||
|
Supprimez manuellement les commandes/skills IDE v4 existants - par exemple si vous avez Claude Code, recherchez tous les dossiers imbriqués qui commencent par bmad et supprimez-les :
|
||||||
|
|
||||||
|
- `.claude/commands/`
|
||||||
|
|
||||||
|
Les nouveaux skills v6 sont installés dans :
|
||||||
|
|
||||||
|
- `.claude/skills/`
|
||||||
|
|
||||||
|
### 4. Migrer les artefacts de planification
|
||||||
|
|
||||||
|
**Si vous avez des documents de planification (Brief/PRD/UX/Architecture) :**
|
||||||
|
|
||||||
|
Déplacez-les dans `_bmad-output/planning-artifacts/` avec des noms descriptifs :
|
||||||
|
|
||||||
|
- Incluez `PRD` dans le nom de fichier pour les documents PRD[^1]
|
||||||
|
- Incluez `brief`, `architecture`, ou `ux-design` selon le cas
|
||||||
|
- Les documents divisés peuvent être dans des sous-dossiers nommés
|
||||||
|
|
||||||
|
**Si vous êtes en cours de planification :** Envisagez de redémarrer avec les workflows v6. Utilisez vos documents existants comme entrées - les nouveaux workflows de découverte progressive avec recherche web et mode plan IDE produisent de meilleurs résultats.
|
||||||
|
|
||||||
|
### 5. Migrer le développement en cours
|
||||||
|
|
||||||
|
Si vous avez des stories[^3] créées ou implémentées :
|
||||||
|
|
||||||
|
1. Terminez l'installation v6
|
||||||
|
2. Placez `epics.md` ou `epics/epic*.md`[^2] dans `_bmad-output/planning-artifacts/`
|
||||||
|
3. Lancez le workflow `bmad-sprint-planning`[^4]
|
||||||
|
4. Indiquez quels epics/stories sont déjà terminés
|
||||||
|
|
||||||
|
## Ce que vous obtenez
|
||||||
|
|
||||||
|
**Structure unifiée v6 :**
|
||||||
|
|
||||||
|
```text
|
||||||
|
votre-projet/
|
||||||
|
├── _bmad/ # Dossier d'installation unique
|
||||||
|
│ ├── _config/ # Vos personnalisations
|
||||||
|
│ │ └── agents/ # Fichiers de personnalisation des agents
|
||||||
|
│ ├── core/ # Framework core universel
|
||||||
|
│ ├── bmm/ # Module BMad Method
|
||||||
|
│ ├── bmb/ # BMad Builder
|
||||||
|
│ └── cis/ # Creative Intelligence Suite
|
||||||
|
└── _bmad-output/ # Dossier de sortie (était le dossier doc en v4)
|
||||||
|
```
|
||||||
|
|
||||||
|
## 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` | Déprécié - nouvel agent DevOps bientôt disponible |
|
||||||
|
| `.bmad-creative-writing` | Non adapté - nouveau module v6 bientôt disponible |
|
||||||
|
|
||||||
|
## Changements clés
|
||||||
|
|
||||||
|
| Concept | v4 | v6 |
|
||||||
|
| ------------- | ------------------------------------- | ------------------------------------ |
|
||||||
|
| **Core** | `_bmad-core` était en fait 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 ou non division requise | Entièrement flexible, scan automatique |
|
||||||
|
|
||||||
|
## Glossaire
|
||||||
|
[^1]: PRD (Product Requirements Document) : document de référence qui décrit les objectifs du produit, les besoins utilisateurs, les fonctionnalités attendues, les contraintes et les critères de succès, afin d'aligner les équipes sur ce qui doit être construit et pourquoi.
|
||||||
|
[^2]: Epic : dans les méthodologies agiles, une grande unité de travail qui peut être décomposée en plusieurs stories. Un epic représente généralement une fonctionnalité majeure ou un ensemble de capacités livrable sur plusieurs sprints.
|
||||||
|
[^3]: Story (User Story) : une description courte et simple d'une fonctionnalité du point de vue de l'utilisateur. Les stories sont des unités de travail suffisamment petites pour être complétées en un sprint.
|
||||||
|
[^4]: Sprint : dans Scrum, une période de temps fixe (généralement 1 à 4 semaines) pendant laquelle l'équipe travaille à livrer un incrément de produit potentiellement libérable.
|
||||||
|
|
@ -0,0 +1,69 @@
|
||||||
|
---
|
||||||
|
title: Bienvenue dans la méthode BMad
|
||||||
|
description: Framework de développement propulsé par l'IA avec des agents spécialisés, des workflows guidés et une planification intelligente
|
||||||
|
---
|
||||||
|
|
||||||
|
La méthode BMad (**B**uild **M**ore **A**rchitect **D**reams) est un module[^1] de développement assisté par l'IA au sein de l'écosystème BMad, conçu pour vous faciliter la création de logiciels par un processus complet, de l'idéation et de la planification jusqu'à l'implémentation agentique. Elle fournit des agents[^2] IA spécialisés, des workflows guidés et une planification intelligente qui s'adapte à la complexité de votre projet, que vous corrigiez un bug ou construisiez une plateforme d'entreprise.
|
||||||
|
|
||||||
|
Si vous êtes à l'aise avec les assistants de codage IA comme Claude, Cursor ou GitHub Copilot, vous êtes prêt à commencer.
|
||||||
|
|
||||||
|
:::note[🚀 La V6 est là et ce n'est que le début !]
|
||||||
|
Architecture par Skills, BMad Builder v1, automatisation Dev Loop, et bien plus encore en préparation. **[Consultez la Feuille de route →](./roadmap)**
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Première visite ? Commencez par un tutoriel
|
||||||
|
|
||||||
|
La façon la plus rapide de comprendre BMad est de l'essayer.
|
||||||
|
|
||||||
|
- **[Premiers pas avec BMad](./tutorials/getting-started.md)** — Installez et comprenez comment fonctionne BMad
|
||||||
|
- **[Carte des workflows](./reference/workflow-map.md)** — Vue d'ensemble visuelle des phases BMM, des workflows et de la gestion du contexte
|
||||||
|
|
||||||
|
:::tip[Envie de plonger directement ?]
|
||||||
|
Installez BMad et utilisez le skill[^3] `bmad-help` — il vous guidera entièrement en fonction de votre projet et de vos modules installés.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Comment utiliser cette documentation
|
||||||
|
|
||||||
|
Cette documentation est organisée en quatre sections selon ce que vous essayez de faire :
|
||||||
|
|
||||||
|
| Section | Objectif |
|
||||||
|
| ----------------- | ----------------------------------------------------------------------------------------------------------- |
|
||||||
|
| **Tutoriels** | Orientés apprentissage. Guides étape par étape qui vous accompagnent dans la construction de quelque chose. Commencez ici si vous êtes nouveau. |
|
||||||
|
| **Guides pratiques** | Orientés tâches. Guides pratiques pour résoudre des problèmes spécifiques. « Comment personnaliser un agent ? » se trouve ici. |
|
||||||
|
| **Explication** | Orientés compréhension. Explications en profondeur des concepts et de l'architecture. À lire quand vous voulez savoir *pourquoi*. |
|
||||||
|
| **Référence** | Orientés information. Spécifications techniques pour les agents, workflows et configuration. |
|
||||||
|
|
||||||
|
## Étendre et personnaliser
|
||||||
|
|
||||||
|
Vous souhaitez étendre BMad avec vos propres agents, workflows ou modules ? Le **[BMad Builder](https://bmad-builder-docs.bmad-method.org/)** fournit le framework et les outils pour créer des extensions personnalisées, que vous ajoutiez de nouvelles capacités à BMad ou que vous construisiez des modules entièrement nouveaux à partir de zéro.
|
||||||
|
|
||||||
|
## Ce dont vous aurez besoin
|
||||||
|
|
||||||
|
BMad fonctionne avec tout assistant de codage IA qui prend en charge les prompts système personnalisés ou le contexte de projet. Les options populaires incluent :
|
||||||
|
|
||||||
|
- **[Claude Code](https://code.claude.com)** — Outil CLI d'Anthropic (recommandé)
|
||||||
|
- **[Cursor](https://cursor.sh)** — Éditeur de code propulsé par l'IA
|
||||||
|
- **[Codex CLI](https://github.com/openai/codex)** — Agent de codage terminal d'OpenAI
|
||||||
|
|
||||||
|
Vous devriez être à l'aise avec les concepts de base du développement logiciel comme le contrôle de version, la structure de projet et les workflows agiles. Aucune expérience préalable avec les systèmes d'agent de type BMad n'est requise — c'est justement le but de cette documentation.
|
||||||
|
|
||||||
|
## Rejoindre la communauté
|
||||||
|
|
||||||
|
Obtenez de l'aide, partagez ce que vous construisez ou contribuez à BMad :
|
||||||
|
|
||||||
|
- **[Discord](https://discord.gg/gk8jAdXWmj)** — Discutez avec d'autres utilisateurs de BMad, posez des questions, partagez des idées
|
||||||
|
- **[GitHub](https://github.com/bmad-code-org/BMAD-METHOD)** — Code source, issues et contributions
|
||||||
|
- **[YouTube](https://www.youtube.com/@BMadCode)** — Tutoriels vidéo et démonstrations
|
||||||
|
|
||||||
|
## Prochaine étape
|
||||||
|
|
||||||
|
Prêt à vous lancer ? **[Commencez avec BMad](./tutorials/getting-started.md)** et construisez votre premier projet.
|
||||||
|
|
||||||
|
---
|
||||||
|
## Glossaire
|
||||||
|
|
||||||
|
[^1]: **Module** : composant autonome du système BMad qui peut être installé et utilisé indépendamment, offrant des fonctionnalités spécifiques.
|
||||||
|
|
||||||
|
[^2]: **Agent** : assistant IA spécialisé avec une expertise spécifique qui guide les utilisateurs dans les workflows.
|
||||||
|
|
||||||
|
[^3]: **Skill** : capacité ou fonctionnalité invoquable d'un agent pour effectuer une tâche spécifique.
|
||||||
|
|
@ -0,0 +1,58 @@
|
||||||
|
---
|
||||||
|
title: Agents
|
||||||
|
description: Agents BMM par défaut avec leurs identifiants de skill, déclencheurs de menu et workflows principaux (Analyst, Architect, UX Designer, Technical Writer)
|
||||||
|
sidebar:
|
||||||
|
order: 2
|
||||||
|
---
|
||||||
|
|
||||||
|
## Agents par défaut
|
||||||
|
|
||||||
|
Cette page liste les quatre agents BMM (suite Agile) par défaut installés avec la méthode BMad, ainsi que leurs identifiants de skill, déclencheurs de menu et workflows principaux. Chaque agent est invoqué en tant que skill.
|
||||||
|
|
||||||
|
## Notes
|
||||||
|
|
||||||
|
- Chaque agent est disponible en tant que skill, généré par l’installateur. L’identifiant de skill (par exemple, `bmad-analyst`) est utilisé pour invoquer l’agent.
|
||||||
|
- Les déclencheurs sont les codes courts de menu (par exemple, `BP`) et les correspondances approximatives affichés dans chaque menu d’agent.
|
||||||
|
- La génération de tests QA est gérée par le skill de workflow `bmad-qa-generate-e2e-tests`. L’architecte de tests complet (TEA) se trouve dans son propre module.
|
||||||
|
|
||||||
|
| Agent | Identifiant de skill | Déclencheurs | Workflows principaux |
|
||||||
|
|------------------------|----------------------|------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||||
|
| Analyste (Mary) | `bmad-analyst` | `BP`, `MR`, `DR`, `TR`, `CB`, `DP` | Brainstorming du projet, Recherche marché/domaine/technique, Création du brief[^1], Documentation du projet |
|
||||||
|
| Architecte (Winston) | `bmad-architect` | `CA`, `IR` | Créer l’architecture, Préparation à l’implémentation |
|
||||||
|
| Designer UX (Sally) | `bmad-ux-designer` | `CU` | Création du design UX[^2] |
|
||||||
|
| Rédacteur Technique (Paige) | `bmad-tech-writer` | `DP`, `WD`, `US`, `MG`, `VD`, `EC` | Documentation du projet, Rédaction de documents, Mise à jour des standards, Génération de diagrammes Mermaid, Validation de documents, Explication de concepts |
|
||||||
|
|
||||||
|
## Types de déclencheurs
|
||||||
|
|
||||||
|
Les déclencheurs de menu d'agent utilisent deux types d'invocation différents. Connaître le type utilisé par un déclencheur vous aide à fournir la bonne entrée.
|
||||||
|
|
||||||
|
### Déclencheurs de workflow (aucun argument nécessaire)
|
||||||
|
|
||||||
|
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 : `BP` (Brainstorm Project), `CA` (Create Architecture), `CU` (Create UX Design)
|
||||||
|
|
||||||
|
### 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 |
|
||||||
|
|
||||||
|
**Exemple :**
|
||||||
|
|
||||||
|
```text
|
||||||
|
WD Rédige un guide de déploiement pour notre configuration Docker
|
||||||
|
MG Crée un diagramme de séquence montrant le flux d’authentification
|
||||||
|
EC Explique le fonctionnement du système de modules
|
||||||
|
```
|
||||||
|
|
||||||
|
## Glossaire
|
||||||
|
|
||||||
|
[^1]: Brief : document synthétique qui formalise le contexte, les objectifs, le périmètre et les contraintes d’un projet ou d’une demande, afin d’aligner rapidement les parties prenantes avant le travail détaillé.
|
||||||
|
[^2]: UX (User Experience) : expérience utilisateur, englobant l’ensemble des interactions et perceptions d’un utilisateur face à un produit. Le design UX vise à créer des interfaces intuitives, efficaces et agréables en tenant compte des besoins, comportements et contexte d’utilisation.
|
||||||
|
|
@ -0,0 +1,139 @@
|
||||||
|
---
|
||||||
|
title: Skills
|
||||||
|
description: Référence des skills BMad — ce qu'ils sont, comment ils fonctionnent et où les trouver.
|
||||||
|
sidebar:
|
||||||
|
order: 3
|
||||||
|
---
|
||||||
|
|
||||||
|
Les skills sont des prompts pré-construits qui chargent des agents, exécutent des workflows ou lancent des tâches dans votre IDE. L'installateur BMad les génère à partir de vos modules installés au moment de l'installation. Si vous ajoutez, supprimez ou modifiez des modules ultérieurement, relancez l'installateur pour garder les skills synchronisés (voir [Dépannage](#dépannage)).
|
||||||
|
|
||||||
|
## Skills vs. Déclencheurs du menu Agent
|
||||||
|
|
||||||
|
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 |
|
||||||
|
| **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.
|
||||||
|
|
||||||
|
## Comment les skills sont générés
|
||||||
|
|
||||||
|
Lorsque vous exécutez `npx bmad-method install`, l'installateur lit les manifests de chaque module sélectionné et écrit un skill par agent, workflow, tâche et outil. Chaque skill est un répertoire contenant un fichier `SKILL.md` qui indique à l'IA de charger le fichier source correspondant et de suivre ses instructions.
|
||||||
|
|
||||||
|
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 |
|
||||||
|
|
||||||
|
:::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.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Emplacement des fichiers de skill
|
||||||
|
|
||||||
|
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 |
|
||||||
|
|
||||||
|
Chaque skill est un répertoire contenant un fichier `SKILL.md`. Par exemple, une installation Claude Code ressemble à :
|
||||||
|
|
||||||
|
```text
|
||||||
|
.claude/skills/
|
||||||
|
├── bmad-help/
|
||||||
|
│ └── SKILL.md
|
||||||
|
├── bmad-create-prd/
|
||||||
|
│ └── SKILL.md
|
||||||
|
├── bmad-analyst/
|
||||||
|
│ └── SKILL.md
|
||||||
|
└── ...
|
||||||
|
```
|
||||||
|
|
||||||
|
Le nom du répertoire détermine le nom du skill dans votre IDE. Par exemple, le répertoire `bmad-analyst/` enregistre le skill `bmad-analyst`.
|
||||||
|
|
||||||
|
## Comment découvrir vos skills
|
||||||
|
|
||||||
|
Tapez le nom du skill dans votre IDE pour l'invoquer. Certaines plateformes nécessitent d'activer les skills dans les paramètres avant qu'ils n'apparaissent.
|
||||||
|
|
||||||
|
Exécutez `bmad-help` pour obtenir des conseils contextuels sur votre prochaine étape.
|
||||||
|
|
||||||
|
:::tip[Découverte rapide]
|
||||||
|
Les répertoires de skills générés dans votre projet sont la liste de référence. Ouvrez-les dans votre explorateur de fichiers pour voir chaque skill avec sa description.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Catégories de skills
|
||||||
|
|
||||||
|
### Skills d'agent
|
||||||
|
|
||||||
|
Les skills d'agent chargent une persona[^2] IA spécialisée avec un rôle défini, un style de communication et un menu de workflows. Une fois chargé, l'agent reste en caractère et répond aux déclencheurs du menu.
|
||||||
|
|
||||||
|
| Exemple de skill | Agent | Rôle |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| `bmad-analyst` | Mary (Analyste) | Brainstorming de projets, recherche, création de briefs |
|
||||||
|
| `bmad-architect` | Winston (Architecte) | Conçoit l'architecture système |
|
||||||
|
| `bmad-ux-designer` | Sally (Designer UX) | Crée les designs UX |
|
||||||
|
| `bmad-tech-writer` | Paige (Rédacteur Technique) | Documente les projets, rédige des guides, génère des diagrammes |
|
||||||
|
|
||||||
|
Consultez [Agents](./agents.md) pour la liste complète des agents par défaut et leurs déclencheurs.
|
||||||
|
|
||||||
|
### Skills de workflow
|
||||||
|
|
||||||
|
Les skills de workflow exécutent un processus structuré en plusieurs étapes sans charger d'abord une persona d'agent. Ils chargent une configuration de workflow et suivent ses étapes.
|
||||||
|
|
||||||
|
| Exemple de skill | Objectif |
|
||||||
|
| --- | --- |
|
||||||
|
| `bmad-create-prd` | Créer 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.
|
||||||
|
|
||||||
|
### Skills de tâche et d'outil
|
||||||
|
|
||||||
|
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` 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.
|
||||||
|
|
||||||
|
:::note[Exemple]
|
||||||
|
```
|
||||||
|
bmad-help
|
||||||
|
bmad-help J'ai une idée de SaaS et je connais toutes les fonctionnalités. Par où commencer ?
|
||||||
|
bmad-help Quelles sont mes options pour le design UX ?
|
||||||
|
```
|
||||||
|
:::
|
||||||
|
|
||||||
|
**Autres tâches et outils principaux**
|
||||||
|
|
||||||
|
Le module principal inclut 11 outils intégrés — revues, compression, brainstorming, gestion de documents, et plus. Consultez [Outils principaux](./core-tools.md) pour la référence complète.
|
||||||
|
|
||||||
|
## Convention de nommage
|
||||||
|
|
||||||
|
Tous les skills utilisent le préfixe `bmad-` suivi d'un nom descriptif (ex. `bmad-analyst`, `bmad-create-prd`, `bmad-help`). Consultez [Modules](./modules.md) pour les modules disponibles.
|
||||||
|
|
||||||
|
## Dépannage
|
||||||
|
|
||||||
|
**Les skills n'apparaissent pas après l'installation.** Certaines plateformes nécessitent d'activer explicitement les skills dans les paramètres. Consultez la documentation de votre IDE ou demandez à votre assistant IA comment activer les skills. Vous devrez peut-être aussi redémarrer votre IDE ou recharger la fenêtre.
|
||||||
|
|
||||||
|
**Des skills attendus sont manquants.** L'installateur génère uniquement les skills pour les modules que vous avez sélectionnés. Exécutez à nouveau `npx bmad-method install` et vérifiez votre sélection de modules. Vérifiez que les fichiers de skill existent dans le répertoire attendu.
|
||||||
|
|
||||||
|
**Des skills d'un module supprimé apparaissent encore.** L'installateur ne supprime pas automatiquement les anciens fichiers de skill. Supprimez les répertoires obsolètes du répertoire de skills de votre IDE, ou supprimez tout le répertoire de skills et relancez l'installateur pour obtenir un ensemble propre.
|
||||||
|
|
||||||
|
## Glossaire
|
||||||
|
|
||||||
|
[^1]: PRD (Product Requirements Document) : document de référence qui décrit les objectifs du produit, les besoins utilisateurs, les fonctionnalités attendues, les contraintes et les critères de succès, afin d’aligner les équipes sur ce qui doit être construit et pourquoi.
|
||||||
|
[^2]: Persona : dans le contexte de BMad, une persona désigne un agent IA avec un rôle défini, un style de communication et une expertise spécifiques (ex. Mary l'analyste, Winston l'architecte). Chaque persona garde son "caractère" pendant les interactions.
|
||||||
|
|
@ -0,0 +1,298 @@
|
||||||
|
---
|
||||||
|
title: Outils Principaux
|
||||||
|
description: Référence pour toutes les tâches et tous les workflows intégrés disponibles dans chaque installation BMad sans modules supplémentaires.
|
||||||
|
sidebar:
|
||||||
|
order: 2
|
||||||
|
---
|
||||||
|
|
||||||
|
Chaque installation BMad comprend un ensemble de compétences principales qui peuvent être utilisées conjointement avec tout ce que vous faites — des tâches et des workflows autonomes qui fonctionnent dans tous les projets, tous les modules et toutes les phases. Ceux-ci sont toujours disponibles, quels que soient les modules optionnels que vous installez.
|
||||||
|
|
||||||
|
:::tip[Raccourci Rapide]
|
||||||
|
Exécutez n'importe quel outil principal en tapant son nom de compétence (par ex., `bmad-help`) dans votre IDE. Aucune session d'agent requise.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Vue d'ensemble
|
||||||
|
|
||||||
|
| Outil | Type | Objectif |
|
||||||
|
|-----------------------------------------------------------------------|----------|------------------------------------------------------------------------------|
|
||||||
|
| [`bmad-help`](#bmad-help) | Tâche | Obtenir des conseils contextuels sur la prochaine étape |
|
||||||
|
| [`bmad-brainstorming`](#bmad-brainstorming) | Workflow | Faciliter des sessions de brainstorming interactives |
|
||||||
|
| [`bmad-party-mode`](#bmad-party-mode) | Workflow | Orchestrer des discussions de groupe multi-agents |
|
||||||
|
| [`bmad-distillator`](#bmad-distillator) | Tâche | Compression sans perte optimisée pour LLM de documents |
|
||||||
|
| [`bmad-advanced-elicitation`](#bmad-advanced-elicitation) | Tâche | Pousser la sortie LLM à travers des méthodes de raffinement itératives |
|
||||||
|
| [`bmad-review-adversarial-general`](#bmad-review-adversarial-general) | Tâche | Revue cynique qui trouve ce qui manque et ce qui ne va pas |
|
||||||
|
| [`bmad-review-edge-case-hunter`](#bmad-review-edge-case-hunter) | Tâche | Analyse exhaustive des chemins de branchement pour les cas limites non gérés |
|
||||||
|
| [`bmad-editorial-review-prose`](#bmad-editorial-review-prose) | Tâche | Révision de copie clinique pour la clarté de communication |
|
||||||
|
| [`bmad-editorial-review-structure`](#bmad-editorial-review-structure) | Tâche | Édition structurelle — coupes, fusions et réorganisation |
|
||||||
|
| [`bmad-shard-doc`](#bmad-shard-doc) | Tâche | Diviser les fichiers markdown volumineux en sections organisées |
|
||||||
|
| [`bmad-index-docs`](#bmad-index-docs) | Tâche | Générer ou mettre à jour un index de tous les documents dans un dossier |
|
||||||
|
|
||||||
|
## bmad-help
|
||||||
|
|
||||||
|
**Votre guide intelligent pour la suite.** — Inspecte l'état de votre projet, détecte ce qui a été fait et recommande la prochaine étape requise ou facultative.
|
||||||
|
|
||||||
|
**Utilisez-le quand :**
|
||||||
|
|
||||||
|
- Vous avez terminé un workflow et voulez savoir ce qui suit
|
||||||
|
- Vous êtes nouveau sur BMad et avez besoin d'orientation
|
||||||
|
- Vous êtes bloqué et voulez des conseils contextuels
|
||||||
|
- Vous avez installé de nouveaux modules et voulez voir ce qui est disponible
|
||||||
|
|
||||||
|
**Fonctionnement :**
|
||||||
|
|
||||||
|
1. Analyse votre projet pour les artefacts existants (PRD, architecture, stories, etc.)
|
||||||
|
2. Détecte quels modules sont installés et leurs workflows disponibles
|
||||||
|
3. Recommande les prochaines étapes par ordre de priorité — étapes requises d'abord, puis facultatives
|
||||||
|
4. Présente chaque recommandation avec la commande de compétence et une brève description
|
||||||
|
|
||||||
|
**Entrée :** Requête optionnelle en langage naturel (par ex., `bmad-help J'ai une idée de SaaS, par où commencer ?`)
|
||||||
|
|
||||||
|
**Sortie :** Liste priorisée des prochaines étapes recommandées avec les commandes de compétence
|
||||||
|
|
||||||
|
## bmad-brainstorming
|
||||||
|
|
||||||
|
**Génère des idées diverses à travers des techniques créatives interactives.** — Une session de brainstorming facilitée qui charge des méthodes d'idéation éprouvées depuis une bibliothèque de techniques et vous guide vers plus de 100 idées avant organisation.
|
||||||
|
|
||||||
|
**Utilisez-le quand :**
|
||||||
|
|
||||||
|
- Vous commencez un nouveau projet et devez explorer l’espace problème
|
||||||
|
- Vous êtes bloqué dans la génération d'idées et avez besoin de créativité structurée
|
||||||
|
- Vous voulez utiliser des cadres d'idéation éprouvés (SCAMPER, brainstorming inversé, etc.)
|
||||||
|
|
||||||
|
**Fonctionnement :**
|
||||||
|
|
||||||
|
1. Configure une session de brainstorming avec votre sujet
|
||||||
|
2. Charge les techniques créatives depuis une bibliothèque de méthodes
|
||||||
|
3. Vous guide à travers technique après technique, générant des idées
|
||||||
|
4. Applique un protocole anti-biais — change de domaine créatif toutes les 10 idées pour éviter le regroupement
|
||||||
|
5. Produit un document de session en mode ajout uniquement avec toutes les idées organisées par technique
|
||||||
|
|
||||||
|
**Entrée :** Sujet de brainstorming ou énoncé de problème, fichier de contexte optionnel
|
||||||
|
|
||||||
|
**Sortie :** `brainstorming-session-{date}.md` avec toutes les idées générées
|
||||||
|
|
||||||
|
:::note[Cible de Quantité]
|
||||||
|
La magie se produit dans les idées 50–100. Le workflow encourage la génération de plus de 100 idées avant organisation.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## bmad-party-mode
|
||||||
|
|
||||||
|
**Orchestre des discussions de groupe multi-agents.** — Charge tous les agents BMad installés et facilite une conversation naturelle où chaque agent contribue depuis son expertise et personnalité uniques.
|
||||||
|
|
||||||
|
**Utilisez-le quand :**
|
||||||
|
|
||||||
|
- Vous avez besoin de multiples perspectives d'experts sur une décision
|
||||||
|
- Vous voulez que les agents remettent en question les hypothèses des autres
|
||||||
|
- Vous explorez un sujet complexe qui couvre plusieurs domaines
|
||||||
|
|
||||||
|
**Fonctionnement :**
|
||||||
|
|
||||||
|
1. Charge le manifeste d'agents avec toutes les personnalités d'agents installées
|
||||||
|
2. Analyse votre sujet pour sélectionner les 2–3 agents les plus pertinents
|
||||||
|
3. Les agents prennent des tours pour contribuer, avec des échanges naturels et des désaccords
|
||||||
|
4. Fait rouler la participation des agents pour assurer des perspectives diverses au fil du temps
|
||||||
|
5. Quittez avec `goodbye`, `end party` ou `quit`
|
||||||
|
|
||||||
|
**Entrée :** Sujet de discussion ou question, ainsi que la spécification des personas que vous souhaitez faire participer (optionnel)
|
||||||
|
|
||||||
|
**Sortie :** Conversation multi-agents en temps réel avec des personnalités d'agents maintenues
|
||||||
|
|
||||||
|
## bmad-distillator
|
||||||
|
|
||||||
|
**Compression sans perte optimisée pour LLM de documents sources.** — Produit des distillats denses et efficaces en tokens qui préservent toute l'information pour la consommation par des LLM en aval. Vérifiable par reconstruction aller-retour.
|
||||||
|
|
||||||
|
**Utilisez-le quand :**
|
||||||
|
|
||||||
|
- Un document est trop volumineux pour la fenêtre de contexte d'un LLM
|
||||||
|
- Vous avez besoin de versions économes en tokens de recherches, spécifications ou artefacts de planification
|
||||||
|
- Vous voulez vérifier qu'aucune information n'est perdue pendant la compression
|
||||||
|
- Les agents auront besoin de référencer et de trouver fréquemment des informations dedans
|
||||||
|
|
||||||
|
**Fonctionnement :**
|
||||||
|
|
||||||
|
1. **Analyser** — Lit les documents sources, identifie la densité d'information et la structure
|
||||||
|
2. **Compresser** — Convertit la prose en format dense de liste de points, supprime le formatage décoratif
|
||||||
|
3. **Vérifier** — Vérifie l'exhaustivité pour s'assurer que toute l'information originale est préservée
|
||||||
|
4. **Valider** (optionnel) — Le test de reconstruction aller-retour prouve la compression sans perte
|
||||||
|
|
||||||
|
**Entrée :**
|
||||||
|
|
||||||
|
- `source_documents` (requis) — Chemins de fichiers, chemins de dossiers ou motifs glob
|
||||||
|
- `downstream_consumer` (optionnel) — Ce qui va le consommer (par ex., "création de PRD")
|
||||||
|
- `token_budget` (optionnel) — Taille cible approximative
|
||||||
|
- `--validate` (drapeau) — Exécuter le test de reconstruction aller-retour
|
||||||
|
|
||||||
|
**Sortie :** Fichier(s) markdown distillé(s) avec rapport de ratio de compression (par ex., "3.2:1")
|
||||||
|
|
||||||
|
## bmad-advanced-elicitation
|
||||||
|
|
||||||
|
**Passer la sortie du LLM à travers des méthodes de raffinement itératives.** — Sélectionne depuis une bibliothèque de techniques d'élicitation pour améliorer systématiquement le contenu à travers multiples passages.
|
||||||
|
|
||||||
|
**Utilisez-le quand :**
|
||||||
|
|
||||||
|
- La sortie du LLM semble superficielle ou générique
|
||||||
|
- Vous voulez explorer un sujet depuis de multiples angles analytiques
|
||||||
|
- Vous raffinez un document critique et voulez une réflexion plus approfondie
|
||||||
|
|
||||||
|
**Fonctionnement :**
|
||||||
|
|
||||||
|
1. Charge le registre de méthodes avec plus de 5 techniques d'élicitation
|
||||||
|
2. Sélectionne les 5 méthodes les mieux adaptées selon le type de contenu et la complexité
|
||||||
|
3. Présente un menu interactif — choisissez une méthode, remélangez, ou listez tout
|
||||||
|
4. Applique la méthode sélectionnée pour améliorer le contenu
|
||||||
|
5. Re-présente les options pour l'amélioration itérative jusqu'à ce que vous sélectionniez "Procéder"
|
||||||
|
|
||||||
|
**Entrée :** Section de contenu à améliorer
|
||||||
|
|
||||||
|
**Sortie :** Version améliorée du contenu avec les améliorations appliquées
|
||||||
|
|
||||||
|
## bmad-review-adversarial-general
|
||||||
|
|
||||||
|
**Revue contradictoire qui suppose que des problèmes existent et les recherche.** — Adopte une perspective de réviseur sceptique et blasé avec zéro tolérance pour le travail bâclé. Cherche ce qui manque, pas seulement ce qui ne va pas.
|
||||||
|
|
||||||
|
**Utilisez-le quand :**
|
||||||
|
|
||||||
|
- Vous avez besoin d'assurance qualité avant de finaliser un livrable
|
||||||
|
- Vous voulez tester en conditions réelles une spécification, story ou document
|
||||||
|
- Vous voulez trouver des lacunes de couverture que les revues optimistes manquent
|
||||||
|
|
||||||
|
**Fonctionnement :**
|
||||||
|
|
||||||
|
1. Lit le contenu avec une perspective contradictoire et critique
|
||||||
|
2. Identifie les problèmes à travers l'exhaustivité, la justesse et la qualité
|
||||||
|
3. Recherche spécifiquement ce qui manque — pas seulement ce qui est présent et faux
|
||||||
|
4. Doit trouver un minimum de 10 problèmes ou réanalyse plus profondément
|
||||||
|
|
||||||
|
**Entrée :**
|
||||||
|
|
||||||
|
- `content` (requis) — Diff, spécification, story, document ou tout artefact
|
||||||
|
- `also_consider` (optionnel) — Domaines supplémentaires à garder à l'esprit
|
||||||
|
|
||||||
|
**Sortie :** Liste markdown de plus de 10 constatations avec descriptions
|
||||||
|
|
||||||
|
## bmad-review-edge-case-hunter
|
||||||
|
|
||||||
|
**Parcours tous les chemins de branchement et les conditions limites, ne rapporte que les cas non gérés.** — Méthodologie pure de traçage de chemin[^1] qui dérive mécaniquement les classes de cas limites. Orthogonale à la revue contradictoire — centrée sur la méthode, pas sur l'attitude.
|
||||||
|
|
||||||
|
**À utiliser quand :**
|
||||||
|
|
||||||
|
- Vous souhaitez une couverture exhaustive des cas limites pour le code ou la logique
|
||||||
|
- Vous avez besoin d'un complément à la revue contradictoire (méthodologie différente, résultats différents)
|
||||||
|
- Vous révisez un diff ou une fonction pour des conditions limites
|
||||||
|
|
||||||
|
**Fonctionnement :**
|
||||||
|
|
||||||
|
1. Énumère tous les chemins de branchement dans le contenu
|
||||||
|
2. Dérive mécaniquement les classes de cas limites : else/default manquants, entrées non vérifiées, décalage d’unité, overflow arithmétique, coercition implicite des types, conditions de concurrence, écarts de timeout
|
||||||
|
3. Teste chaque chemin contre les protections existantes
|
||||||
|
4. Ne rapporte que les chemins non gérés — ignore silencieusement les chemins gérés
|
||||||
|
|
||||||
|
**Entrée :**
|
||||||
|
|
||||||
|
- `content` (obligatoire) — Diff, fichier complet ou fonction
|
||||||
|
- `also_consider` (facultatif) — Zones supplémentaires à garder à l’esprit
|
||||||
|
|
||||||
|
**Sortie :** Tableau JSON des résultats, chacun avec `location`, `trigger_condition`, `guard_snippet` et `potential_consequence`
|
||||||
|
|
||||||
|
:::note[Revue Complémentaire]
|
||||||
|
Exécutez à la fois `bmad-review-adversarial-general` et `bmad-review-edge-case-hunter` pour une couverture orthogonale. La revue contradictoire détecte les problèmes de qualité et de complétude ; le chasseur de cas limites détecte les chemins non gérés.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## bmad-editorial-review-prose
|
||||||
|
|
||||||
|
**Relecture éditoriale clinique centrée sur la clarté de communication.** — Analyse le texte pour détecter les problèmes qui nuisent à la compréhension. Applique le Microsoft Writing Style Guide baseline. Préserve la voix de l’auteur.
|
||||||
|
|
||||||
|
**À utiliser quand :**
|
||||||
|
|
||||||
|
- Vous avez rédigé un document et souhaitez polir le style
|
||||||
|
- Vous devez assurer la clarté pour un public spécifique
|
||||||
|
- Vous voulez des corrections de communication sans modifier les choix stylistiques
|
||||||
|
|
||||||
|
**Fonctionnement :**
|
||||||
|
|
||||||
|
1. Lit le contenu en ignorant les blocs de code et le frontmatter
|
||||||
|
2. Identifie les problèmes de communication (pas les préférences de style)
|
||||||
|
3. Déduit les doublons du même problème à différents emplacements
|
||||||
|
4. Produit un tableau de corrections en trois colonnes
|
||||||
|
|
||||||
|
**Entrée :**
|
||||||
|
|
||||||
|
- `content` (obligatoire) — Markdown, texte brut ou XML
|
||||||
|
- `style_guide` (facultatif) — Guide de style spécifique au projet
|
||||||
|
- `reader_type` (facultatif) — `humans` (par défaut) pour clarté/fluide, ou `llm` pour précision/consistance
|
||||||
|
|
||||||
|
**Sortie :** Tableau Markdown en trois colonnes : Texte original | Texte révisé | Modifications
|
||||||
|
|
||||||
|
## bmad-editorial-review-structure
|
||||||
|
|
||||||
|
**Édition structurelle — propose des coupes, fusions, déplacements et condensations.** — Révise l'organisation du document et propose des changements substantiels pour améliorer la clarté et le flux avant la révision de copie.
|
||||||
|
|
||||||
|
**Utilisez-le quand :**
|
||||||
|
|
||||||
|
- Un document a été produit depuis de multiples sous-processus et a besoin de cohérence structurelle
|
||||||
|
- Vous voulez réduire la longueur du document tout en préservant la compréhension
|
||||||
|
- Vous devez identifier les violations de portée ou les informations critiques enfouies
|
||||||
|
|
||||||
|
**Fonctionnement :**
|
||||||
|
|
||||||
|
1. Analyse le document contre 5 modèles de structure (Tutoriel, Référence, Explication, Prompt, Stratégique)
|
||||||
|
2. Identifie les redondances, violations de portée et informations enfouies
|
||||||
|
3. Produit des recommandations priorisées : COUPER, FUSIONNER, DÉPLACER, CONDENSER, QUESTIONNER, PRÉSERVER
|
||||||
|
4. Estime la réduction totale en mots et pourcentage
|
||||||
|
|
||||||
|
**Entrée :**
|
||||||
|
|
||||||
|
- `content` (requis) — Document à réviser
|
||||||
|
- `purpose` (optionnel) — Objectif prévu (par ex., "tutoriel de démarrage rapide")
|
||||||
|
- `target_audience` (optionnel) — Qui lit ceci
|
||||||
|
- `reader_type` (optionnel) — `humans` ou `llm`
|
||||||
|
- `length_target` (optionnel) — Réduction cible (par ex., "30% plus court")
|
||||||
|
|
||||||
|
**Sortie :** Résumé du document, liste de recommandations priorisées et réduction estimée
|
||||||
|
|
||||||
|
## bmad-shard-doc
|
||||||
|
|
||||||
|
**Diviser les fichiers markdown volumineux en fichiers de sections organisés.** — Utilise les en-têtes de niveau 2 comme points de division pour créer un dossier de fichiers de sections autonomes avec un index.
|
||||||
|
|
||||||
|
**Utilisez-le quand :**
|
||||||
|
|
||||||
|
- Un document markdown est devenu trop volumineux pour être géré efficacement (plus de 500 lignes)
|
||||||
|
- Vous voulez diviser un document monolithique en sections navigables
|
||||||
|
- Vous avez besoin de fichiers séparés pour l'édition parallèle ou la gestion de contexte LLM
|
||||||
|
|
||||||
|
**Fonctionnement :**
|
||||||
|
|
||||||
|
1. Valide que le fichier source existe et est markdown
|
||||||
|
2. Divise sur les en-têtes de niveau 2 (`##`) en fichiers de sections numérotées
|
||||||
|
3. Crée un `index.md` avec manifeste de sections et liens
|
||||||
|
4. Vous invite à supprimer, archiver ou conserver l'original
|
||||||
|
|
||||||
|
**Entrée :** Chemin du fichier markdown source, dossier de destination optionnel
|
||||||
|
|
||||||
|
**Sortie :** Dossier avec `index.md` et `01-{section}.md`, `02-{section}.md`, etc.
|
||||||
|
|
||||||
|
## bmad-index-docs
|
||||||
|
|
||||||
|
**Générer ou mettre à jour un index de tous les documents dans un dossier.** — Analyse un répertoire, lit chaque fichier pour comprendre son objectif et produit un `index.md` organisé avec liens et descriptions.
|
||||||
|
|
||||||
|
**Utilisez-le quand :**
|
||||||
|
|
||||||
|
- Vous avez besoin d'un index léger pour un scan LLM rapide des documents disponibles
|
||||||
|
- Un dossier de documentation a grandi et a besoin d'une table des matières organisée
|
||||||
|
- Vous voulez un aperçu auto-généré qui reste à jour
|
||||||
|
|
||||||
|
**Fonctionnement :**
|
||||||
|
|
||||||
|
1. Analyse le répertoire cible pour tous les fichiers non cachés
|
||||||
|
2. Lit chaque fichier pour comprendre son objectif réel
|
||||||
|
3. Groupe les fichiers par type, objectif ou sous-répertoire
|
||||||
|
4. Génère des descriptions concises (3–10 mots chacune)
|
||||||
|
|
||||||
|
**Entrée :** Chemin du dossier cible
|
||||||
|
|
||||||
|
**Sortie :** `index.md` avec listes de fichiers organisées, liens relatifs et brèves descriptions
|
||||||
|
|
||||||
|
## Glossaire
|
||||||
|
|
||||||
|
[^1]: Path-tracing : méthode d'analyse qui suit systématiquement tous les chemins d'exécution possibles dans un programme pour identifier les cas non gérés.
|
||||||
|
|
||||||
|
|
@ -0,0 +1,82 @@
|
||||||
|
---
|
||||||
|
title: Modules Officiels
|
||||||
|
description: Modules additionnels pour créer des agents personnalisés, de l'intelligence créative, du développement de jeux et des tests
|
||||||
|
sidebar:
|
||||||
|
order: 4
|
||||||
|
---
|
||||||
|
|
||||||
|
BMad s'étend via des modules officiels que vous sélectionnez lors de l'installation. Ces modules additionnels fournissent des agents, des workflows et des tâches spécialisés pour des domaines spécifiques, au-delà du noyau intégré et de BMM (suite Agile).
|
||||||
|
|
||||||
|
:::tip[Installer des Modules]
|
||||||
|
Exécutez `npx bmad-method install` et sélectionnez les modules souhaités. L'installateur gère automatiquement le téléchargement, la configuration et l'intégration IDE.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## BMad Builder
|
||||||
|
|
||||||
|
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)
|
||||||
|
|
||||||
|
**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
|
||||||
|
- Module Builder — empaquetez des agents et des workflows dans des modules partageables et publiables
|
||||||
|
- Configuration interactive avec support de configuration YAML et publication npm
|
||||||
|
|
||||||
|
## Creative Intelligence Suite
|
||||||
|
|
||||||
|
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)
|
||||||
|
|
||||||
|
**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
|
||||||
|
- Storyteller et Presentation Master pour les récits et les présentations
|
||||||
|
- Cadres d'idéation incluant SCAMPER[^1], Brainstorming inversé et reformulation de problèmes
|
||||||
|
|
||||||
|
## Game Dev Studio
|
||||||
|
|
||||||
|
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)
|
||||||
|
|
||||||
|
**Fournit :**
|
||||||
|
|
||||||
|
- Workflow de génération de Document de Design de Jeu (GDD[^3])
|
||||||
|
- Mode Quick Dev pour le prototypage rapide
|
||||||
|
- Support de design narratif pour les personnages, dialogues et construction de monde
|
||||||
|
- Couverture de plus de 21 types de jeux avec des conseils d'architecture spécifiques au moteur
|
||||||
|
|
||||||
|
## Test Architect (TEA)
|
||||||
|
|
||||||
|
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)
|
||||||
|
|
||||||
|
**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é
|
||||||
|
- Évaluation NFR[^2], configuration CI et scaffolding de framework
|
||||||
|
- Priorisation P0-P3 avec Playwright Utils et intégrations MCP optionnelles
|
||||||
|
|
||||||
|
## Modules Communautaires
|
||||||
|
|
||||||
|
Les modules communautaires et une marketplace de modules sont à venir. Consultez l'[organisation GitHub BMad](https://github.com/bmad-code-org) pour les mises à jour.
|
||||||
|
|
||||||
|
## Glossaire
|
||||||
|
|
||||||
|
[^1]: SCAMPER : acronyme anglais pour une technique de créativité structurée (Substitute, Combine, Adapt, Modify, Put to another use, Eliminate, Reverse) qui permet d'explorer systématiquement les modifications possibles d'un produit ou d'une idée pour générer des innovations.
|
||||||
|
[^2]: NFR (Non-Functional Requirement) : exigence décrivant les contraintes de qualité du système (performance, sécurité, fiabilité, ergonomie) plutôt que ses fonctionnalités.
|
||||||
|
[^3]: GDD (Game Design Document) : document de conception de jeu qui décrit en détail les mécaniques, l'univers, les personnages, les niveaux et tous les aspects du jeu à développer.
|
||||||
|
|
@ -0,0 +1,111 @@
|
||||||
|
---
|
||||||
|
title: Options de Testing
|
||||||
|
description: Comparaison du workflow QA intégré avec le module Test Architect (TEA) pour l'automatisation des tests.
|
||||||
|
sidebar:
|
||||||
|
order: 5
|
||||||
|
---
|
||||||
|
|
||||||
|
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 |
|
||||||
|
|-------------------------|----------------------------------------------|---------------------------------------------------------------------|
|
||||||
|
| **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` |
|
||||||
|
| **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) |
|
||||||
|
| **Nombre de workflows** | 1 (Automate) | 9 (conception, ATDD, automatisation, revue, traçabilité, et autres) |
|
||||||
|
|
||||||
|
:::tip[Commencez avec le QA Intégré]
|
||||||
|
La plupart des projets devraient commencer avec le workflow QA intégré. Si vous avez ensuite besoin d'une stratégie de test, de murs de qualité ou de traçabilité des exigences, installez TEA en complément.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Workflow QA Intégré
|
||||||
|
|
||||||
|
Le workflow QA intégré est inclus dans le module BMM (suite Agile). 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` ou `bmad-qa-generate-e2e-tests`
|
||||||
|
|
||||||
|
### Ce que le Workflow QA Fait
|
||||||
|
|
||||||
|
Le workflow QA exécute un processus unique (Automate) qui parcourt cinq étapes :
|
||||||
|
|
||||||
|
1. **Détecte le framework de test** — analyse `package.json` et les fichiers de test existants pour identifier votre framework (Jest, Vitest, Playwright, Cypress, ou tout runner standard). Si aucun n'existe, analyse la pile technologique du projet et en suggère un.
|
||||||
|
2. **Identifie les fonctionnalités** — demande ce qu'il faut tester ou découvre automatiquement les fonctionnalités dans le codebase.
|
||||||
|
3. **Génère les tests API** — couvre les codes de statut, la structure des réponses, le chemin nominal, et 1-2 cas d'erreur.
|
||||||
|
4. **Génére les tests E2E** — couvre les parcours utilisateur avec des localisateurs sémantiques et des assertions sur les résultats visibles.
|
||||||
|
5. **Exécute et vérifie** — lance les tests générés et corrige immédiatement les échecs.
|
||||||
|
|
||||||
|
Le workflow QA produit un résumé de test sauvegardé dans le dossier des artefacts d'implémentation de votre projet.
|
||||||
|
|
||||||
|
### Patterns de Test
|
||||||
|
|
||||||
|
Les tests générés suivent une philosophie "simple et maintenable" :
|
||||||
|
|
||||||
|
- **APIs standard du framework uniquement** — pas d'utilitaires externes ni d'abstractions personnalisées
|
||||||
|
- **Localisateurs sémantiques** pour les tests UI (rôles, labels, texte plutôt que sélecteurs CSS)
|
||||||
|
- **Tests indépendants** sans dépendances d'ordre
|
||||||
|
- **Pas d'attentes ou de sleeps codés en dur**
|
||||||
|
- **Descriptions claires** qui se lisent comme de la documentation fonctionnelle
|
||||||
|
|
||||||
|
:::note[Portée]
|
||||||
|
Le workflow QA génère uniquement des tests. Pour la revue de code et la validation des stories, utilisez plutôt le workflow Code Review (`CR`).
|
||||||
|
:::
|
||||||
|
|
||||||
|
### Quand Utiliser le QA Intégré
|
||||||
|
|
||||||
|
- Couverture de test rapide pour une fonctionnalité nouvelle ou existante
|
||||||
|
- Automatisation de tests accessible aux débutants sans configuration avancée
|
||||||
|
- Patterns de test standards que tout développeur peut lire et maintenir
|
||||||
|
- Projets petits et moyens où une stratégie de test complète n'est pas nécessaire
|
||||||
|
|
||||||
|
## Module Test Architect (TEA)
|
||||||
|
|
||||||
|
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)
|
||||||
|
|
||||||
|
### Ce que TEA Fournit
|
||||||
|
|
||||||
|
| Workflow | Objectif |
|
||||||
|
|-----------------------|--------------------------------------------------------------------------------------|
|
||||||
|
| Test Design | Créer une stratégie de test complète liée aux exigences |
|
||||||
|
| ATDD | Développement piloté par les tests d'acceptation avec critères des parties prenantes |
|
||||||
|
| Automate | Générer des tests avec des patterns et utilitaires avancés |
|
||||||
|
| Test Review | Valider la qualité et la couverture des tests par rapport à la stratégie |
|
||||||
|
| Traceability | Remonter les tests aux exigences pour l'audit et la conformité |
|
||||||
|
| NFR Assessment | Évaluer les exigences non-fonctionnelles (performance, sécurité) |
|
||||||
|
| CI Setup | Configurer l'exécution des tests dans les pipelines d'intégration continue |
|
||||||
|
| Framework Scaffolding | Configurer l'infrastructure de test et la structure du projet |
|
||||||
|
| Release Gate | Prendre des décisions de livraison go/no-go basées sur les données |
|
||||||
|
|
||||||
|
TEA supporte également la priorisation basée sur les risques P0-P3 et des intégrations optionnelles avec Playwright Utils et les outils MCP.
|
||||||
|
|
||||||
|
### Quand Utiliser TEA
|
||||||
|
|
||||||
|
- Projets nécessitant une traçabilité des exigences ou une documentation de conformité
|
||||||
|
- Équipes ayant besoin d'une priorisation des tests basée sur les risques sur plusieurs fonctionnalités
|
||||||
|
- Environnements entreprise avec des murs de qualité formels avant livraison
|
||||||
|
- Domaines complexes où la stratégie de test doit être planifiée avant d'écrire les tests
|
||||||
|
- Projets ayant dépassé l'approche à workflow unique du QA intégré
|
||||||
|
|
||||||
|
## Comment les Tests S'Intègrent dans les Workflows
|
||||||
|
|
||||||
|
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 le workflow QA (`QA`) 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é.
|
||||||
|
|
||||||
|
Pour en savoir plus sur la place des tests dans le processus global, consultez la [Carte des Workflows](./workflow-map.md).
|
||||||
|
|
||||||
|
## Glossaire
|
||||||
|
|
||||||
|
[^1]: QA (Quality Assurance) : assurance qualité, ensemble des processus et activités visant à garantir que le produit logiciel répond aux exigences de qualité définies.
|
||||||
|
[^2]: ATDD (Acceptance Test-Driven Development) : méthode de développement où les tests d'acceptation sont écrits avant le code, en collaboration avec les parties prenantes pour définir les critères de réussite.
|
||||||
|
|
@ -0,0 +1,94 @@
|
||||||
|
---
|
||||||
|
title: "Carte des Workflows"
|
||||||
|
description: Référence visuelle des phases et des résultats des workflows de la méthode BMad
|
||||||
|
sidebar:
|
||||||
|
order: 1
|
||||||
|
---
|
||||||
|
|
||||||
|
La méthode BMad (BMM) est un module de l'écosystème BMad, conçu pour suivre les meilleures pratiques de l'ingénierie du contexte et de la planification. Les agents IA fonctionnent de manière optimale avec un contexte clair et structuré. Le système BMM construit ce contexte progressivement à travers 4 phases distinctes — chaque phase, et plusieurs workflows optionnels au sein de chaque phase, produisent des documents qui alimentent la phase suivante, afin que les agents sachent toujours quoi construire et pourquoi.
|
||||||
|
|
||||||
|
La logique et les concepts proviennent des méthodologies agiles qui ont été utilisées avec succès dans l'industrie comme cadre mental de référence.
|
||||||
|
|
||||||
|
Si à tout moment vous ne savez pas quoi faire, le skill `bmad-help` vous aidera à rester sur la bonne voie ou à savoir quoi faire ensuite. Vous pouvez toujours vous référer à cette page également — mais `bmad-help` est entièrement interactif et beaucoup plus rapide si vous avez déjà installé la méthode BMad. De plus, si vous utilisez différents modules qui ont étendu la méthode BMad ou ajouté d'autres modules complémentaires non extensifs — `bmad-help` évolue pour connaître tout ce qui est disponible et vous donner les meilleurs conseils du moment.
|
||||||
|
|
||||||
|
Note finale importante : Chaque workflow ci-dessous peut être exécuté directement avec l'outil de votre choix via un skill ou en chargeant d'abord un agent et en utilisant l'entrée du 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>
|
||||||
|
|
||||||
|
<p style="font-size: 0.8rem; text-align: right; margin-top: -0.5rem; margin-bottom: 1rem;">
|
||||||
|
<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)
|
||||||
|
|
||||||
|
Explorez l’espace problème et validez les idées avant de vous engager dans la planification.
|
||||||
|
|
||||||
|
| Workflow | Objectif | Produit |
|
||||||
|
|---------------------------------------------------------------------------|------------------------------------------------------------------------------------------|---------------------------|
|
||||||
|
| `bmad-brainstorming` | Brainstormez des idées de projet avec l'accompagnement guidé d'un coach de brainstorming | `brainstorming-report.md` |
|
||||||
|
| `bmad-domain-research`, `bmad-market-research`, `bmad-technical-research` | Validez les hypothèses de marché, techniques ou de domaine | Rapport de recherches |
|
||||||
|
| `bmad-create-product-brief` | Capturez la vision stratégique | `product-brief.md` |
|
||||||
|
|
||||||
|
## Phase 2 : Planification
|
||||||
|
|
||||||
|
Définissez ce qu'il faut construire et pour qui.
|
||||||
|
|
||||||
|
| Workflow | Objectif | Produit |
|
||||||
|
|-------------------------|---------------------------------------------------------|--------------|
|
||||||
|
| `bmad-create-prd` | Définissez les exigences (FRs/NFRs)[^1] | `PRD.md`[^2] |
|
||||||
|
| `bmad-create-ux-design` | Concevez l'expérience utilisateur (lorsque l'UX compte) | `ux-spec.md` |
|
||||||
|
|
||||||
|
## Phase 3 : Solutioning
|
||||||
|
|
||||||
|
Décidez comment le construire et décomposez le travail en stories.
|
||||||
|
|
||||||
|
| Workflow | Objectif | Produit |
|
||||||
|
|---------------------------------------|---------------------------------------------------|------------------------------|
|
||||||
|
| `bmad-create-architecture` | Rendez les décisions techniques explicites | `architecture.md` avec ADRs[^3] |
|
||||||
|
| `bmad-create-epics-and-stories` | Décomposez les exigences en travail implémentable | Fichiers d'epic avec stories |
|
||||||
|
| `bmad-check-implementation-readiness` | Vérification avant implémentation | Décision Passe/Réserves/Échec |
|
||||||
|
|
||||||
|
## Phase 4 : Implémentation
|
||||||
|
|
||||||
|
Construisez, une story à la fois. Bientôt disponible : automatisation complète de la phase 4 !
|
||||||
|
|
||||||
|
| Workflow | Objectif | Produit |
|
||||||
|
|------------------------|-------------------------------------------------------------------------------------|----------------------------------|
|
||||||
|
| `bmad-sprint-planning` | Initialisez le suivi (une fois par projet pour séquencer le cycle de développement) | `sprint-status.yaml` |
|
||||||
|
| `bmad-create-story` | Préparez la story suivante pour implémentation | `story-[slug].md` |
|
||||||
|
| `bmad-dev-story` | Implémentez la story | Code fonctionnel + tests |
|
||||||
|
| `bmad-code-review` | Validez la qualité de l'implémentation | Approuvé ou changements demandés |
|
||||||
|
| `bmad-correct-course` | Gérez les changements significatifs en cours de sprint | Plan mis à jour ou réorientation |
|
||||||
|
| `bmad-sprint-status` | Suivez la progression du sprint et le statut des stories | Mise à jour du statut du sprint |
|
||||||
|
| `bmad-retrospective` | Revue après complétion d'un epic | Leçons apprises |
|
||||||
|
|
||||||
|
## Quick Dev (Parcours Parallèle)
|
||||||
|
|
||||||
|
Sautez les phases 1-3 pour les travaux de faible envergure et bien compris.
|
||||||
|
|
||||||
|
| Workflow | Objectif | Produit |
|
||||||
|
|------------------|-------------------------------------------------------------------------------------|-----------------------|
|
||||||
|
| `bmad-quick-dev` | Flux rapide unifié — clarifie l'intention, planifie, implémente, révise et présente | `tech-spec.md` + code |
|
||||||
|
|
||||||
|
## Gestion du Contexte
|
||||||
|
|
||||||
|
Chaque document devient le contexte de la phase suivante. Le PRD[^2] indique à l'architecte quelles contraintes sont importantes. L'architecture indique à l'agent de développement quels modèles suivre. Les fichiers de story fournissent un contexte focalisé et complet pour l'implémentation. Sans cette structure, les agents prennent des décisions incohérentes.
|
||||||
|
|
||||||
|
### Contexte du Projet
|
||||||
|
|
||||||
|
:::tip[Recommandé]
|
||||||
|
Créez `project-context.md` pour vous assurer que les agents IA suivent les règles et préférences de votre projet. Ce fichier fonctionne comme une constitution pour votre projet — il guide les décisions d'implémentation à travers tous les workflows. Ce fichier optionnel peut être généré à la fin de la création de l'architecture, ou dans un projet existant il peut également être généré pour capturer ce qui est important de conserver aligné avec les conventions actuelles.
|
||||||
|
:::
|
||||||
|
|
||||||
|
**Comment le créer :**
|
||||||
|
|
||||||
|
- **Manuellement** — Créez `_bmad-output/project-context.md` avec votre pile technologique 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
|
||||||
|
|
||||||
|
[**En savoir plus sur project-context.md**](../explanation/project-context.md)
|
||||||
|
|
||||||
|
## Glossaire
|
||||||
|
|
||||||
|
[^1]: FR / NFR (Functional / Non-Functional Requirement) : exigences décrivant respectivement **ce que le système doit faire** (fonctionnalités, comportements attendus) et **comment il doit le faire** (contraintes de performance, sécurité, fiabilité, ergonomie, etc.).
|
||||||
|
[^2]: PRD (Product Requirements Document) : document de référence qui décrit les objectifs du produit, les besoins utilisateurs, les fonctionnalités attendues, les contraintes et les critères de succès, afin d’aligner les équipes sur ce qui doit être construit et pourquoi.
|
||||||
|
[^3]: ADR (Architecture Decision Record) : document qui consigne une décision d’architecture, son contexte, les options envisagées, le choix retenu et ses conséquences, afin d’assurer la traçabilité et la compréhension des décisions techniques dans le temps.
|
||||||
|
|
@ -0,0 +1,136 @@
|
||||||
|
---
|
||||||
|
title: Feuille de route
|
||||||
|
description: La suite pour BMad - Fonctionnalités, améliorations et contributions de la communauté
|
||||||
|
---
|
||||||
|
|
||||||
|
# La Méthode BMad : Feuille de route publique
|
||||||
|
|
||||||
|
La Méthode BMad, BMad Method Module (BMM) et BMad Builder (BMB) évoluent. Voici ce sur quoi nous travaillons et ce qui arrive prochainement.
|
||||||
|
|
||||||
|
<div class="roadmap-container">
|
||||||
|
|
||||||
|
<h2 class="roadmap-section-title">En cours</h2>
|
||||||
|
|
||||||
|
<div class="roadmap-future">
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🧩</span>
|
||||||
|
<h4>Architecture par Skills Universelle</h4>
|
||||||
|
<p>Un skill, toutes les plateformes. Écrivez une fois, exécutez partout.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🏗️</span>
|
||||||
|
<h4>BMad Builder v1</h4>
|
||||||
|
<p>Créez des agents IA et des workflows prêts pour la production avec des évaluations, des équipes et dégradation gracieuse intégrées.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🧠</span>
|
||||||
|
<h4>Système de Contexte Projet</h4>
|
||||||
|
<p>Votre IA comprend vraiment votre projet. Un contexte adapté au framework qui évolue avec votre base de code.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">📦</span>
|
||||||
|
<h4>Skills Centralisés</h4>
|
||||||
|
<p>Installez une fois, utilisez partout. Partagez des skills entre projets sans l'encombrement de fichiers.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🔄</span>
|
||||||
|
<h4>Skills Adaptatifs</h4>
|
||||||
|
<p>Des skills qui connaissent vos outils. Des variantes optimisées pour Claude, Codex, Kimi et OpenCode, et bien d'autres encore.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">📝</span>
|
||||||
|
<h4>Blog BMad Team Pros</h4>
|
||||||
|
<p>Guides, articles et perspectives de l'équipe. Lancement prochainement.</p>
|
||||||
|
</div>
|
||||||
|
</div>
|
||||||
|
|
||||||
|
<h2 class="roadmap-section-title">Pour bien commencer</h2>
|
||||||
|
|
||||||
|
<div class="roadmap-future">
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🏪</span>
|
||||||
|
<h4>Marketplace de Skills</h4>
|
||||||
|
<p>Découvrez, installez et mettez à jour des skills créés par la communauté. À une commande curl de super-pouvoirs.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🎨</span>
|
||||||
|
<h4>Personnalisation de Workflow</h4>
|
||||||
|
<p>Faites-en le vôtre. Intégrez Jira, Linear, des sorties personnalisées à votre workflow, vos règles.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🚀</span>
|
||||||
|
<h4>Optimisation Phases 1-3</h4>
|
||||||
|
<p>Planification éclair avec collecte de contexte par sous-agents. Le mode YOLO rencontre l'excellence guidée.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🌐</span>
|
||||||
|
<h4>Prêt pour l'Entreprise</h4>
|
||||||
|
<p>SSO, journaux d'audit, espaces de travail d'équipe. Toutes les choses ennuyantes qui feront dire oui aux entreprises.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">💎</span>
|
||||||
|
<h4>Explosion de Modules Communautaires</h4>
|
||||||
|
<p>Divertissement, sécurité, thérapie, jeu de rôle et bien plus encore. Étendez la plateforme de la Méthode BMad.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">⚡</span>
|
||||||
|
<h4>Automatisation de la Boucle de Développement</h4>
|
||||||
|
<p>Pilote automatique optionnel pour le développement. Laissez l'IA gérer le flux tout en maintenant une qualité optimale.</p>
|
||||||
|
</div>
|
||||||
|
</div>
|
||||||
|
|
||||||
|
<h2 class="roadmap-section-title">Communauté et Équipe</h2>
|
||||||
|
|
||||||
|
<div class="roadmap-future">
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🎙️</span>
|
||||||
|
<h4>Le Podcast de la Méthode BMad</h4>
|
||||||
|
<p>Conversations sur le développement natif IA. Lancement le 1er mars 2026 !</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🎓</span>
|
||||||
|
<h4>Le Master Class de la Méthode BMad</h4>
|
||||||
|
<p>Passez d'utilisateur à expert. Approfondissements dans chaque phase, chaque workflow, chaque secret.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🏗️</span>
|
||||||
|
<h4>La Master Class BMad Builder</h4>
|
||||||
|
<p>Construisez vos propres agents. Techniques avancées pour quand vous êtes prêt à créer, pas seulement à utiliser.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">⚡</span>
|
||||||
|
<h4>BMad Prototype First</h4>
|
||||||
|
<p>De l'idée au prototype fonctionnel en une seule session. Créez l'application de vos rêves comme une œuvre d'art.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🌴</span>
|
||||||
|
<h4>BMad BALM !</h4>
|
||||||
|
<p>Gestion de vie native IA. Tâches, habitudes, objectifs : votre copilote IA pour tout.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🖥️</span>
|
||||||
|
<h4>UI Officielle</h4>
|
||||||
|
<p>Une belle interface pour tout l'écosystème BMad. La puissance de la CLI, le polissage de l'interface graphique.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🔒</span>
|
||||||
|
<h4>BMad in a Box</h4>
|
||||||
|
<p>Auto-hébergé, isolé, niveau entreprise. Votre assistant IA, votre infrastructure, votre contrôle.</p>
|
||||||
|
</div>
|
||||||
|
</div>
|
||||||
|
|
||||||
|
<div style="text-align: center; margin-top: 3rem; padding: 2rem; background: var(--color-bg-card); border-radius: 12px; border: 1px solid var(--color-border);">
|
||||||
|
<h3 style="margin: 0 0 1rem;">Envie de contribuer ?</h3>
|
||||||
|
<p style="color: var(--slate-color-400); margin: 0;">
|
||||||
|
Ce n'est qu'une liste partielle de ce qui est prévu. L'équipe Open Source BMad accueille les contributeurs !{" "}<br />
|
||||||
|
<a href="https://github.com/bmad-code-org/BMAD-METHOD" style="color: var(--color-in-progress);">Rejoignez-nous sur GitHub</a> pour aider à façonner l'avenir du développement propulsé par l'IA.
|
||||||
|
</p>
|
||||||
|
<p style="color: var(--slate-color-400); margin: 1.5rem 0 0;">
|
||||||
|
Vous aimez ce que nous construisons ? Nous apprécions le soutien ponctuel et mensuel sur{" "}<a href="https://buymeacoffee.com/bmad" style="color: var(--color-in-progress);">Buy Me a Coffee</a>.
|
||||||
|
</p>
|
||||||
|
<p style="color: var(--slate-color-400); margin: 1rem 0 0;">
|
||||||
|
Pour les parrainages d'entreprise, les demandes de partenariat, les interventions, les formations ou les demandes médias :{" "}
|
||||||
|
<a href="mailto:contact@bmadcode.com" style="color: var(--color-in-progress);">contact@bmadcode.com</a>
|
||||||
|
</p>
|
||||||
|
</div>
|
||||||
|
</div>
|
||||||
|
|
@ -0,0 +1,279 @@
|
||||||
|
---
|
||||||
|
title: "Premiers pas"
|
||||||
|
description: Installer BMad et construire votre premier projet
|
||||||
|
---
|
||||||
|
|
||||||
|
Construisez des logiciels plus rapidement en utilisant des workflows propulsés par l'IA avec des agents spécialisés qui vous guident à travers la planification, l'architecture et l'implémentation.
|
||||||
|
|
||||||
|
## Ce que vous allez apprendre
|
||||||
|
|
||||||
|
- Installer et initialiser la méthode BMad pour un nouveau projet
|
||||||
|
- Utiliser **BMad-Help** — votre guide intelligent qui sait quoi faire ensuite
|
||||||
|
- Choisir la bonne voie de planification selon la taille de votre projet
|
||||||
|
- Progresser à travers les phases, des exigences au code fonctionnel
|
||||||
|
- Utiliser efficacement les agents et les workflows
|
||||||
|
|
||||||
|
:::note[Prérequis]
|
||||||
|
- **Node.js 20+** — Requis pour l'installateur
|
||||||
|
- **Git** — Recommandé pour le contrôle de version
|
||||||
|
- **IDE IA** — Claude Code, Cursor, ou similaire
|
||||||
|
- **Une idée de projet** — Même simple, elle fonctionne pour apprendre
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::tip[Le chemin le plus simple]
|
||||||
|
**Installer** → `npx bmad-method install`
|
||||||
|
**Demander** → `bmad-help que dois-je faire en premier ?`
|
||||||
|
**Construire** → Laissez BMad-Help vous guider workflow par workflow
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Découvrez BMad-Help : votre guide intelligent
|
||||||
|
|
||||||
|
**BMad-Help est le moyen le plus rapide de démarrer avec BMad.** Vous n'avez pas besoin de mémoriser les workflows ou les phases — posez simplement la question, et BMad-Help va :
|
||||||
|
|
||||||
|
- **Inspecter votre projet** pour voir ce qui a déjà été fait
|
||||||
|
- **Vous montrer vos options** en fonction des modules que vous avez installés
|
||||||
|
- **Recommander la prochaine étape** — y compris la première tâche obligatoire
|
||||||
|
- **Répondre aux questions** comme « J'ai une idée de SaaS, par où commencer ? »
|
||||||
|
|
||||||
|
### Comment utiliser BMad-Help
|
||||||
|
|
||||||
|
Exécutez-le dans votre IDE avec IA en invoquant la skill :
|
||||||
|
|
||||||
|
```
|
||||||
|
bmad-help
|
||||||
|
```
|
||||||
|
|
||||||
|
Ou combinez-le avec une question pour obtenir des conseils adaptés au contexte :
|
||||||
|
|
||||||
|
```
|
||||||
|
bmad-help J'ai une idée de produit SaaS, je connais déjà toutes les fonctionnalités que je veux. Par où dois-je commencer ?
|
||||||
|
```
|
||||||
|
|
||||||
|
BMad-Help répondra avec :
|
||||||
|
- Ce qui est recommandé pour votre situation
|
||||||
|
- Quelle est la première tâche obligatoire
|
||||||
|
- À quoi ressemble le reste du processus
|
||||||
|
|
||||||
|
### Il alimente aussi les workflows
|
||||||
|
|
||||||
|
BMad-Help ne se contente pas de répondre aux questions — **il s'exécute automatiquement à la fin de chaque workflow** pour vous dire exactement quoi faire ensuite. Pas de devinettes, pas de recherche dans la documentation — juste des conseils clairs sur le prochain workflow requis.
|
||||||
|
|
||||||
|
:::tip[Commencez ici]
|
||||||
|
Après avoir installé BMad, invoquez immédiatement la skill `bmad-help`. Elle détectera les modules que vous avez installés et vous guidera vers le bon point de départ pour votre projet.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Comprendre BMad
|
||||||
|
|
||||||
|
BMad vous aide à construire des logiciels grâce à des workflows guidés avec des agents IA spécialisés. Le processus suit quatre phases :
|
||||||
|
|
||||||
|
| Phase | Nom | Ce qui se passe |
|
||||||
|
|-------|----------------|----------------------------------------------------------------|
|
||||||
|
| 1 | Analyse | Brainstorming, recherche, product brief *(optionnel)* |
|
||||||
|
| 2 | Planification | Créer les exigences (PRD[^1] ou spécification technique) |
|
||||||
|
| 3 | Solutioning | Concevoir l'architecture *(BMad Method/Enterprise uniquement)* |
|
||||||
|
| 4 | Implémentation | Construire epic[^2] par epic, story[^3] par story |
|
||||||
|
|
||||||
|
**[Ouvrir la carte des workflows](../reference/workflow-map.md)** pour explorer les phases, les workflows et la gestion du contexte.
|
||||||
|
|
||||||
|
Selon la complexité de votre projet, BMad propose trois voies de planification :
|
||||||
|
|
||||||
|
| Voie | Idéal pour | Documents créés |
|
||||||
|
|------------------|------------------------------------------------------------------------------|----------------------------------------|
|
||||||
|
| **Quick Dev** | Corrections de bugs, fonctionnalités simples, périmètre clair (1-15 stories) | Spécification technique uniquement |
|
||||||
|
| **méthode BMad** | Produits, plateformes, fonctionnalités complexes (10-50+ stories) | PRD + Architecture + UX[^4] |
|
||||||
|
| **Enterprise** | Conformité, systèmes multi-tenant[^5] (30+ stories) | PRD + Architecture + Security + DevOps |
|
||||||
|
|
||||||
|
:::note
|
||||||
|
Les comptes de stories sont indicatifs, pas des définitions. Choisissez votre voie en fonction des besoins de planification, pas du calcul des stories.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Installation
|
||||||
|
|
||||||
|
Ouvrez un terminal dans le répertoire de votre projet et exécutez :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npx bmad-method install
|
||||||
|
```
|
||||||
|
|
||||||
|
Si vous souhaitez la version préliminaire la plus récente au lieu du canal de release par défaut, utilisez `npx bmad-method@next install`.
|
||||||
|
|
||||||
|
Lorsque vous êtes invité à sélectionner des modules, choisissez **méthode BMad**.
|
||||||
|
|
||||||
|
L'installateur crée deux dossiers :
|
||||||
|
- `_bmad/` — agents, workflows, tâches et configuration
|
||||||
|
- `_bmad-output/` — vide pour l'instant, mais c'est là que vos artefacts seront enregistrés
|
||||||
|
|
||||||
|
:::tip[Votre prochaine étape]
|
||||||
|
Ouvrez votre IDE avec IA dans le dossier du projet et exécutez :
|
||||||
|
|
||||||
|
```
|
||||||
|
bmad-help
|
||||||
|
```
|
||||||
|
|
||||||
|
BMad-Help détectera ce que vous avez accompli et recommandera exactement quoi faire ensuite. Vous pouvez aussi lui poser des questions comme « Quelles sont mes options ? » ou « J'ai une idée de SaaS, par où devrais-je commencer ? »
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::note[Comment charger les agents et exécuter les workflows]
|
||||||
|
Chaque workflow possède une **skill** que vous invoquez par nom dans votre IDE (par ex., `bmad-create-prd`). Votre outil IA reconnaîtra le nom `bmad-*` et l'exécutera.
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::caution[Nouveaux chats]
|
||||||
|
Démarrez toujours un nouveau chat pour chaque workflow. Cela évite que les limitations de contexte ne causent des problèmes.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Étape 1 : Créer votre plan
|
||||||
|
|
||||||
|
Travaillez à travers les phases 1-3. **Utilisez de nouveaux chats pour chaque workflow.**
|
||||||
|
|
||||||
|
:::tip[Contexte de projet (Optionnel)]
|
||||||
|
Avant de commencer, envisagez de créer `project-context.md` pour documenter vos préférences techniques et règles d'implémentation. Cela garantit que tous les agents IA suivent vos conventions tout au long du projet.
|
||||||
|
|
||||||
|
Créez-le manuellement dans `_bmad-output/project-context.md` ou générez-le après l'architecture en utilisant `bmad-generate-project-context`. [En savoir plus](../explanation/project-context.md).
|
||||||
|
:::
|
||||||
|
|
||||||
|
### Phase 1 : Analyse (Optionnel)
|
||||||
|
|
||||||
|
Tous les workflows de cette phase sont optionnels :
|
||||||
|
- **brainstorming** (`bmad-brainstorming`) — Idéation guidée
|
||||||
|
- **research** (`bmad-research`) — Recherche marché et technique
|
||||||
|
- **create-product-brief** (`bmad-create-product-brief`) — Document de base recommandé
|
||||||
|
|
||||||
|
### Phase 2 : Planification (Requis)
|
||||||
|
|
||||||
|
**Pour les voies BMad Method et Enterprise :**
|
||||||
|
1. Exécutez `bmad-create-prd` dans un nouveau chat
|
||||||
|
2. Sortie : `PRD.md`
|
||||||
|
|
||||||
|
**Pour la voie Quick Dev :**
|
||||||
|
- Utilisez le workflow `bmad-quick-dev` (`bmad-quick-dev`) à la place du PRD, puis passez à l'implémentation
|
||||||
|
|
||||||
|
:::note[Design UX (Optionnel)]
|
||||||
|
Si votre projet a une interface utilisateur, exécutez le workflow de design UX (`bmad-create-ux-design`) après avoir créé votre PRD.
|
||||||
|
:::
|
||||||
|
|
||||||
|
### Phase 3 : Solutioning (méthode BMad/Enterprise)
|
||||||
|
|
||||||
|
**Créer l'Architecture**
|
||||||
|
1. Exécutez `bmad-create-architecture` dans un nouveau chat
|
||||||
|
2. Sortie : Document d'architecture avec les décisions techniques
|
||||||
|
|
||||||
|
**Créer les Epics et Stories**
|
||||||
|
|
||||||
|
:::tip[Amélioration V6]
|
||||||
|
Les epics et stories sont maintenant créés *après* l'architecture. Cela produit des stories de meilleure qualité car les décisions d'architecture (base de données, patterns d'API, pile technologique) affectent directement la façon dont le travail doit être décomposé.
|
||||||
|
:::
|
||||||
|
|
||||||
|
1. Exécutez `bmad-create-epics-and-stories` dans un nouveau chat
|
||||||
|
2. Le workflow utilise à la fois le PRD et l'Architecture pour créer des stories techniquement éclairées
|
||||||
|
|
||||||
|
**Vérification de préparation à l'implémentation** *(Hautement recommandé)*
|
||||||
|
1. Exécutez `bmad-check-implementation-readiness` dans un nouveau chat
|
||||||
|
2. Valide la cohérence entre tous les documents de planification
|
||||||
|
|
||||||
|
## Étape 2 : Construire votre projet
|
||||||
|
|
||||||
|
Une fois la planification terminée, passez à l'implémentation. **Chaque workflow doit s'exécuter dans un nouveau chat.**
|
||||||
|
|
||||||
|
### Initialiser la planification de sprint
|
||||||
|
|
||||||
|
Exécutez `bmad-sprint-planning` dans un nouveau chat. Cela crée `sprint-status.yaml` pour suivre tous les epics et stories.
|
||||||
|
|
||||||
|
### Le cycle de construction
|
||||||
|
|
||||||
|
Pour chaque story, répétez ce cycle avec de nouveaux chats :
|
||||||
|
|
||||||
|
| Étape | Workflow | Commande | Objectif |
|
||||||
|
| ----- | --------------------- | --------------------- | ----------------------------------- |
|
||||||
|
| 1 | `bmad-create-story` | `bmad-create-story` | Créer le fichier story depuis l'epic |
|
||||||
|
| 2 | `bmad-dev-story` | `bmad-dev-story` | Implémenter la story |
|
||||||
|
| 3 | `bmad-code-review` | `bmad-code-review` | Validation de qualité *(recommandé)* |
|
||||||
|
|
||||||
|
Après avoir terminé toutes les stories d'un epic, exécutez `bmad-retrospective` dans un nouveau chat.
|
||||||
|
|
||||||
|
## Ce que vous avez accompli
|
||||||
|
|
||||||
|
Vous avez appris les fondamentaux de la construction avec BMad :
|
||||||
|
|
||||||
|
- Installé BMad et configuré pour votre IDE
|
||||||
|
- Initialisé un projet avec votre voie de planification choisie
|
||||||
|
- Créé des documents de planification (PRD, Architecture, Epics & Stories)
|
||||||
|
- Compris le cycle de construction pour l'implémentation
|
||||||
|
|
||||||
|
Votre projet contient maintenant :
|
||||||
|
|
||||||
|
```text
|
||||||
|
your-project/
|
||||||
|
├── _bmad/ # Configuration BMad
|
||||||
|
├── _bmad-output/
|
||||||
|
│ ├── planning-artifacts/
|
||||||
|
│ │ ├── PRD.md # Votre document d'exigences
|
||||||
|
│ │ ├── architecture.md # Décisions techniques
|
||||||
|
│ │ └── epics/ # Fichiers epic et story
|
||||||
|
│ ├── implementation-artifacts/
|
||||||
|
│ │ └── sprint-status.yaml # Suivi de sprint
|
||||||
|
│ └── project-context.md # Règles d'implémentation (optionnel)
|
||||||
|
└── ...
|
||||||
|
```
|
||||||
|
|
||||||
|
## Référence rapide
|
||||||
|
|
||||||
|
| Workflow | Commande | Objectif |
|
||||||
|
| ------------------------------------- | ------------------------------------------- | ------------------------------------------------ |
|
||||||
|
| **`bmad-help`** ⭐ | `bmad-help` | **Votre guide intelligent — posez n'importe quelle question !** |
|
||||||
|
| `bmad-create-prd` | `bmad-create-prd` | Créer le document d'exigences produit |
|
||||||
|
| `bmad-create-architecture` | `bmad-create-architecture` | Créer le document d'architecture |
|
||||||
|
| `bmad-generate-project-context` | `bmad-generate-project-context` | Créer le fichier de contexte projet |
|
||||||
|
| `bmad-create-epics-and-stories` | `bmad-create-epics-and-stories` | Décomposer le PRD en epics |
|
||||||
|
| `bmad-check-implementation-readiness` | `bmad-check-implementation-readiness` | Valider la cohérence de planification |
|
||||||
|
| `bmad-sprint-planning` | `bmad-sprint-planning` | Initialiser le suivi de sprint |
|
||||||
|
| `bmad-create-story` | `bmad-create-story` | Créer un fichier story |
|
||||||
|
| `bmad-dev-story` | `bmad-dev-story` | Implémenter une story |
|
||||||
|
| `bmad-code-review` | `bmad-code-review` | Revoir le code implémenté |
|
||||||
|
|
||||||
|
## Questions fréquentes
|
||||||
|
|
||||||
|
**Ai-je toujours besoin d'une architecture ?**
|
||||||
|
Uniquement pour les voies méthode BMad et Enterprise. Quick Dev passe directement de la spécification technique (tech-spec) à l'implémentation.
|
||||||
|
|
||||||
|
**Puis-je modifier mon plan plus tard ?**
|
||||||
|
Oui. Utilisez `bmad-correct-course` pour gérer les changements de périmètre.
|
||||||
|
|
||||||
|
**Et si je veux d'abord faire du brainstorming ?**
|
||||||
|
Invoquez l'agent Analyst (`bmad-analyst`) et exécutez `bmad-brainstorming` (`bmad-brainstorming`) avant de commencer votre PRD.
|
||||||
|
|
||||||
|
**Dois-je suivre un ordre strict ?**
|
||||||
|
Pas strictement. Une fois que vous maîtrisez le flux, vous pouvez exécuter les workflows directement en utilisant la référence rapide ci-dessus.
|
||||||
|
|
||||||
|
## Obtenir de l'aide
|
||||||
|
|
||||||
|
:::tip[Premier arrêt : BMad-Help]
|
||||||
|
**Invoquez `bmad-help` à tout moment** — c'est le moyen le plus rapide de se débloquer. Posez n'importe quelle question :
|
||||||
|
- « Que dois-je faire après l'installation ? »
|
||||||
|
- « Je suis bloqué sur le workflow X »
|
||||||
|
- « Quelles sont mes options pour Y ? »
|
||||||
|
- « Montre-moi ce qui a été fait jusqu'ici »
|
||||||
|
|
||||||
|
BMad-Help inspecte votre projet, détecte ce que vous avez accompli et vous dit exactement quoi faire ensuite.
|
||||||
|
:::
|
||||||
|
|
||||||
|
- **Pendant les workflows** — Les agents vous guident avec des questions et des explications
|
||||||
|
- **Communauté** — [Discord](https://discord.gg/gk8jAdXWmj) (#bmad-method-help, #report-bugs-and-issues)
|
||||||
|
|
||||||
|
## Points clés à retenir
|
||||||
|
|
||||||
|
:::tip[Retenez ceci]
|
||||||
|
- **Commencez par `bmad-help`** — Votre guide intelligent qui connaît votre projet et vos options
|
||||||
|
- **Utilisez toujours de nouveaux chats** — Démarrez un nouveau chat pour chaque workflow
|
||||||
|
- **La voie compte** — Quick Dev utilise `bmad-quick-dev` ; La méthode BMad/Enterprise nécessitent PRD et architecture
|
||||||
|
- **BMad-Help s'exécute automatiquement** — Chaque workflow se termine par des conseils sur la prochaine étape
|
||||||
|
:::
|
||||||
|
|
||||||
|
Prêt à commencer ? Installez BMad, invoquez `bmad-help`, et laissez votre guide intelligent vous montrer le chemin.
|
||||||
|
|
||||||
|
## Glossaire
|
||||||
|
|
||||||
|
[^1]: PRD (Product Requirements Document) : document de référence qui décrit les objectifs du produit, les besoins utilisateurs, les fonctionnalités attendues, les contraintes et les critères de succès, afin d'aligner les équipes sur ce qui doit être construit et pourquoi.
|
||||||
|
[^2]: Epic : grand ensemble de fonctionnalités ou de travaux qui peut être décomposé en plusieurs user stories.
|
||||||
|
[^3]: Story (User Story) : description courte et simple d'une fonctionnalité du point de vue de l'utilisateur ou du client. Elle représente une unité de travail implémentable en un court délai.
|
||||||
|
[^4]: UX (User Experience) : expérience utilisateur, englobant l'ensemble des interactions et perceptions d'un utilisateur face à un produit. Le design UX vise à créer des interfaces intuitives, efficaces et agréables en tenant compte des besoins, comportements et contexte d'utilisation.
|
||||||
|
[^5]: Multi-tenant : architecture logicielle où une seule instance de l'application sert plusieurs clients (tenants) tout en maintenant leurs données isolées et sécurisées les unes des autres.
|
||||||
|
|
@ -128,7 +128,7 @@ prompts:
|
||||||
|
|
||||||
### 3. Apply Your Changes
|
### 3. Apply Your Changes
|
||||||
|
|
||||||
After editing, recompile the agent to apply changes:
|
After editing, reinstall to apply changes:
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
npx bmad-method install
|
npx bmad-method install
|
||||||
|
|
@ -138,17 +138,16 @@ The installer detects the existing installation and offers these options:
|
||||||
|
|
||||||
| Option | What It Does |
|
| Option | What It Does |
|
||||||
| ---------------------------- | ------------------------------------------------------------------- |
|
| ---------------------------- | ------------------------------------------------------------------- |
|
||||||
| **Quick Update** | Updates all modules to the latest version and recompiles all agents |
|
| **Quick Update** | Updates all modules to the latest version and applies customizations |
|
||||||
| **Recompile Agents** | Applies customizations only, without updating module files |
|
|
||||||
| **Modify BMad Installation** | Full installation flow for adding or removing modules |
|
| **Modify BMad Installation** | Full installation flow for adding or removing modules |
|
||||||
|
|
||||||
For customization-only changes, **Recompile Agents** is the fastest option.
|
For customization-only changes, **Quick Update** is the fastest option.
|
||||||
|
|
||||||
## Troubleshooting
|
## Troubleshooting
|
||||||
|
|
||||||
**Changes not appearing?**
|
**Changes not appearing?**
|
||||||
|
|
||||||
- Run `npx bmad-method install` and select **Recompile Agents** to apply changes
|
- Run `npx bmad-method install` and select **Quick Update** to apply changes
|
||||||
- Check that your YAML syntax is valid (indentation matters)
|
- Check that your YAML syntax is valid (indentation matters)
|
||||||
- Verify you edited the correct `.customize.yaml` file for the agent
|
- Verify you edited the correct `.customize.yaml` file for the agent
|
||||||
|
|
||||||
|
|
@ -161,7 +160,7 @@ For customization-only changes, **Recompile Agents** is the fastest option.
|
||||||
**Need to reset an agent?**
|
**Need to reset an agent?**
|
||||||
|
|
||||||
- Clear or delete the agent's `.customize.yaml` file
|
- Clear or delete the agent's `.customize.yaml` file
|
||||||
- Run `npx bmad-method install` and select **Recompile Agents** to restore defaults
|
- Run `npx bmad-method install` and select **Quick Update** to restore defaults
|
||||||
|
|
||||||
## Workflow Customization
|
## Workflow Customization
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -28,7 +28,7 @@ Requires [Node.js](https://nodejs.org) v20+ and `npx` (included with npm).
|
||||||
| `--modules <modules>` | Comma-separated module IDs | `--modules bmm,bmb` |
|
| `--modules <modules>` | Comma-separated module IDs | `--modules bmm,bmb` |
|
||||||
| `--tools <tools>` | Comma-separated tool/IDE IDs (use `none` to skip) | `--tools claude-code,cursor` or `--tools none` |
|
| `--tools <tools>` | Comma-separated tool/IDE IDs (use `none` to skip) | `--tools claude-code,cursor` or `--tools none` |
|
||||||
| `--custom-content <paths>` | Comma-separated paths to custom modules | `--custom-content ~/my-module,~/another-module` |
|
| `--custom-content <paths>` | Comma-separated paths to custom modules | `--custom-content ~/my-module,~/another-module` |
|
||||||
| `--action <type>` | Action for existing installations: `install` (default), `update`, `quick-update`, or `compile-agents` | `--action quick-update` |
|
| `--action <type>` | Action for existing installations: `install` (default), `update`, or `quick-update` | `--action quick-update` |
|
||||||
|
|
||||||
### Core Configuration
|
### Core Configuration
|
||||||
|
|
||||||
|
|
@ -121,7 +121,7 @@ npx bmad-method install \
|
||||||
## What You Get
|
## What You Get
|
||||||
|
|
||||||
- A fully configured `_bmad/` directory in your project
|
- A fully configured `_bmad/` directory in your project
|
||||||
- Compiled agents and workflows for your selected modules and tools
|
- Agents and workflows configured for your selected modules and tools
|
||||||
- A `_bmad-output/` folder for generated artifacts
|
- A `_bmad-output/` folder for generated artifacts
|
||||||
|
|
||||||
## Validation and Error Handling
|
## Validation and Error Handling
|
||||||
|
|
@ -132,7 +132,7 @@ BMad validates all provided flags:
|
||||||
- **Modules** — Warns about invalid module IDs (but won't fail)
|
- **Modules** — Warns about invalid module IDs (but won't fail)
|
||||||
- **Tools** — Warns about invalid tool IDs (but won't fail)
|
- **Tools** — Warns about invalid tool IDs (but won't fail)
|
||||||
- **Custom Content** — Each path must contain a valid `module.yaml` file
|
- **Custom Content** — Each path must contain a valid `module.yaml` file
|
||||||
- **Action** — Must be one of: `install`, `update`, `quick-update`, `compile-agents`
|
- **Action** — Must be one of: `install`, `update`, `quick-update`
|
||||||
|
|
||||||
Invalid values will either:
|
Invalid values will either:
|
||||||
1. Show an error and exit (for critical options like directory)
|
1. Show an error and exit (for critical options like directory)
|
||||||
|
|
|
||||||
|
|
@ -2,7 +2,7 @@
|
||||||
title: "Manage Project Context"
|
title: "Manage Project Context"
|
||||||
description: Create and maintain project-context.md to guide AI agents
|
description: Create and maintain project-context.md to guide AI agents
|
||||||
sidebar:
|
sidebar:
|
||||||
order: 7
|
order: 8
|
||||||
---
|
---
|
||||||
|
|
||||||
Use the `project-context.md` file to ensure AI agents follow your project's technical preferences and implementation rules throughout all workflows. To make sure this is always available, you can also add the line `Important project context and conventions are located in [path to project context]/project-context.md` to your tools context or always rules file (such as `AGENTS.md`)
|
Use the `project-context.md` file to ensure AI agents follow your project's technical preferences and implementation rules throughout all workflows. To make sure this is always available, you can also add the line `Important project context and conventions are located in [path to project context]/project-context.md` to your tools context or always rules file (such as `AGENTS.md`)
|
||||||
|
|
|
||||||
|
|
@ -5,119 +5,91 @@ sidebar:
|
||||||
order: 5
|
order: 5
|
||||||
---
|
---
|
||||||
|
|
||||||
Use the **DEV agent** directly for bug fixes, refactorings, or small targeted changes that don't require the full BMad Method or Quick Flow.
|
Use **Quick Dev** for bug fixes, refactorings, or small targeted changes that don't require the full BMad Method.
|
||||||
|
|
||||||
## When to Use This
|
## When to Use This
|
||||||
|
|
||||||
- Bug fixes with a clear, known cause
|
- Bug fixes with a clear, known cause
|
||||||
- Small refactorings (rename, extract, restructure) contained within a few files
|
- Small refactorings (rename, extract, restructure) contained within a few files
|
||||||
- Minor feature tweaks or configuration changes
|
- Minor feature tweaks or configuration changes
|
||||||
- Exploratory work to understand an unfamiliar codebase
|
- Dependency updates
|
||||||
|
|
||||||
:::note[Prerequisites]
|
:::note[Prerequisites]
|
||||||
- BMad Method installed (`npx bmad-method install`)
|
- BMad Method installed (`npx bmad-method install`)
|
||||||
- An AI-powered IDE (Claude Code, Cursor, or similar)
|
- An AI-powered IDE (Claude Code, Cursor, or similar)
|
||||||
:::
|
:::
|
||||||
|
|
||||||
## Choose Your Approach
|
|
||||||
|
|
||||||
| Situation | Agent | Why |
|
|
||||||
| --- | --- | --- |
|
|
||||||
| Fix a specific bug or make a small, scoped change | **DEV agent** | Jumps straight into implementation without planning overhead |
|
|
||||||
| Change touches several files or you want a written plan first | **Quick Flow Solo Dev** | Clarifies intent, plans, implements, and reviews in a single workflow so the agent stays aligned to your standards |
|
|
||||||
|
|
||||||
If you are unsure, start with the DEV agent. You can always escalate to Quick Flow if the change grows.
|
|
||||||
|
|
||||||
## Steps
|
## Steps
|
||||||
|
|
||||||
### 1. Invoke the DEV Agent
|
### 1. Start a Fresh Chat
|
||||||
|
|
||||||
Start a **fresh chat** in your AI IDE and invoke the DEV agent skill:
|
Open a **fresh chat session** in your AI IDE. Reusing a session from a previous workflow can cause context conflicts.
|
||||||
|
|
||||||
|
### 2. Give It Your Intent
|
||||||
|
|
||||||
|
Quick Dev accepts free-form intent — before, with, or after the invocation. Examples:
|
||||||
|
|
||||||
```text
|
```text
|
||||||
bmad-dev
|
run quick-dev — Fix the login validation bug that allows empty passwords.
|
||||||
```
|
```
|
||||||
|
|
||||||
This loads the agent's persona and capabilities into the session. If you decide you need Quick Flow instead, invoke the **Quick Flow Solo Dev** agent skill in a fresh chat:
|
|
||||||
|
|
||||||
```text
|
```text
|
||||||
bmad-quick-flow-solo-dev
|
run quick-dev — fix https://github.com/org/repo/issues/42
|
||||||
```
|
```
|
||||||
|
|
||||||
Once the Solo Dev agent is loaded, describe your change and tell it to run **quick-dev**. The workflow will clarify your intent, create a plan, implement the change, run a code review, and present results — all in a single run.
|
```text
|
||||||
|
run quick-dev — implement the intent in _bmad-output/implementation-artifacts/my-intent.md
|
||||||
|
```
|
||||||
|
|
||||||
:::tip[Fresh Chats]
|
```text
|
||||||
Always start a new chat session when loading an agent. Reusing a session from a previous workflow can cause context conflicts.
|
I think the problem is in the auth middleware, it's not checking token expiry.
|
||||||
:::
|
Let me look at it... yeah, src/auth/middleware.ts line 47 skips
|
||||||
|
the exp check entirely. run quick-dev
|
||||||
|
```
|
||||||
|
|
||||||
### 2. Describe the Change
|
```text
|
||||||
|
run quick-dev
|
||||||
|
> What would you like to do?
|
||||||
|
Refactor UserService to use async/await instead of callbacks.
|
||||||
|
```
|
||||||
|
|
||||||
Tell the agent what you need in plain language. Be specific about the problem and, if you know it, where the relevant code lives.
|
Plain text, file paths, GitHub issue URLs, bug tracker links — anything the LLM can resolve to a concrete intent.
|
||||||
|
|
||||||
:::note[Example Prompts]
|
### 3. Answer Questions and Approve
|
||||||
**Bug fix** -- "Fix the login validation bug that allows empty passwords. The validation logic is in `src/auth/validate.ts`."
|
|
||||||
|
|
||||||
**Refactoring** -- "Refactor the UserService to use async/await instead of callbacks."
|
Quick Dev may ask clarifying questions or present a short spec for your approval before implementing. Answer its questions and approve when you're satisfied with the plan.
|
||||||
|
|
||||||
**Configuration change** -- "Update the CI pipeline to cache node_modules between runs."
|
### 4. Review and Push
|
||||||
|
|
||||||
**Dependency update** -- "Upgrade the express dependency to the latest v5 release and fix any breaking changes."
|
Quick Dev implements the change, reviews its own work, patches issues, and commits locally. When it's done, it opens the affected files in your editor.
|
||||||
:::
|
|
||||||
|
|
||||||
You don't need to provide every detail. The agent will read the relevant source files and ask clarifying questions when needed.
|
- Skim the diff to confirm the change matches your intent
|
||||||
|
- If something looks off, tell the agent what to fix — it can iterate in the same session
|
||||||
|
|
||||||
### 3. Let the Agent Work
|
Once satisfied, push the commit. Quick Dev will offer to push and create a PR for you.
|
||||||
|
|
||||||
The agent will:
|
|
||||||
|
|
||||||
- Read and analyze the relevant source files
|
|
||||||
- Propose a solution and explain its reasoning
|
|
||||||
- Implement the change across the affected files
|
|
||||||
- Run your project's test suite if one exists
|
|
||||||
|
|
||||||
If your project has tests, the agent runs them automatically after making changes and iterates until tests pass. For projects without a test suite, verify the change manually (run the app, hit the endpoint, check the output).
|
|
||||||
|
|
||||||
### 4. Review and Verify
|
|
||||||
|
|
||||||
Before committing, review what changed:
|
|
||||||
|
|
||||||
- Read through the diff to confirm the change matches your intent
|
|
||||||
- Run the application or tests yourself to double-check
|
|
||||||
- If something looks wrong, tell the agent what to fix -- it can iterate in the same session
|
|
||||||
|
|
||||||
Once satisfied, commit the changes with a clear message describing the fix.
|
|
||||||
|
|
||||||
:::caution[If Something Breaks]
|
:::caution[If Something Breaks]
|
||||||
If a committed change causes unexpected issues, use `git revert HEAD` to undo the last commit cleanly. Then start a fresh chat with the DEV agent to try a different approach.
|
If a pushed change causes unexpected issues, use `git revert HEAD` to undo the last commit cleanly. Then start a fresh chat and run Quick Dev again to try a different approach.
|
||||||
:::
|
:::
|
||||||
|
|
||||||
## Learning Your Codebase
|
|
||||||
|
|
||||||
The DEV agent is also useful for exploring unfamiliar code. Load it in a fresh chat and ask questions:
|
|
||||||
|
|
||||||
:::note[Example Prompts]
|
|
||||||
"Explain how the authentication system works in this codebase."
|
|
||||||
|
|
||||||
"Show me where error handling happens in the API layer."
|
|
||||||
|
|
||||||
"What does the `ProcessOrder` function do and what calls it?"
|
|
||||||
:::
|
|
||||||
|
|
||||||
Use the agent to learn about your project, understand how components connect, and explore unfamiliar areas before making changes.
|
|
||||||
|
|
||||||
## What You Get
|
## What You Get
|
||||||
|
|
||||||
- Modified source files with the fix or refactoring applied
|
- Modified source files with the fix or refactoring applied
|
||||||
- Passing tests (if your project has a test suite)
|
- Passing tests (if your project has a test suite)
|
||||||
- A clean commit describing the change
|
- A ready-to-push commit with a conventional commit message
|
||||||
|
|
||||||
No planning artifacts are produced -- that's the point of this approach.
|
## Deferred Work
|
||||||
|
|
||||||
|
Quick Dev keeps each run focused on a single goal. If your request contains multiple independent goals, or if the review surfaces pre-existing issues unrelated to your change, Quick Dev defers them to a file (`deferred-work.md` in your implementation artifacts directory) rather than trying to tackle everything at once.
|
||||||
|
|
||||||
|
Check this file after a run — it's your backlog of things to come back to. Each deferred item can be fed into a fresh Quick Dev run later.
|
||||||
|
|
||||||
## When to Upgrade to Formal Planning
|
## When to Upgrade to Formal Planning
|
||||||
|
|
||||||
Consider using [Quick Flow](../explanation/quick-flow.md) or the full BMad Method when:
|
Consider using the full BMad Method when:
|
||||||
|
|
||||||
- The change affects multiple systems or requires coordinated updates across many files
|
- The change affects multiple systems or requires coordinated updates across many files
|
||||||
- You are unsure about the scope and need a spec to think it through
|
- You are unsure about the scope and need requirements discovery first
|
||||||
- The fix keeps growing in complexity as you work on it
|
|
||||||
- You need documentation or architectural decisions recorded for the team
|
- You need documentation or architectural decisions recorded for the team
|
||||||
|
|
||||||
|
See [Quick Dev](../explanation/quick-dev.md) for more on how Quick Dev fits into the BMad Method.
|
||||||
|
|
|
||||||
|
|
@ -2,7 +2,7 @@
|
||||||
title: "Document Sharding Guide"
|
title: "Document Sharding Guide"
|
||||||
description: Split large markdown files into smaller organized files for better context management
|
description: Split large markdown files into smaller organized files for better context management
|
||||||
sidebar:
|
sidebar:
|
||||||
order: 8
|
order: 9
|
||||||
---
|
---
|
||||||
|
|
||||||
Use the `bmad-shard-doc` tool if you need to split large markdown files into smaller, organized files for better context management.
|
Use the `bmad-shard-doc` tool if you need to split large markdown files into smaller, organized files for better context management.
|
||||||
|
|
|
||||||
|
|
@ -23,7 +23,7 @@ This page lists the default BMM (Agile suite) agents that install with BMad Meth
|
||||||
| Scrum Master (Bob) | `bmad-sm` | `SP`, `CS`, `ER`, `CC` | Sprint Planning, Create Story, Epic Retrospective, Correct Course |
|
| Scrum Master (Bob) | `bmad-sm` | `SP`, `CS`, `ER`, `CC` | Sprint Planning, Create Story, Epic Retrospective, Correct Course |
|
||||||
| Developer (Amelia) | `bmad-dev` | `DS`, `CR` | Dev Story, Code Review |
|
| Developer (Amelia) | `bmad-dev` | `DS`, `CR` | Dev Story, Code Review |
|
||||||
| QA Engineer (Quinn) | `bmad-qa` | `QA` | Automate (generate tests for existing features) |
|
| QA Engineer (Quinn) | `bmad-qa` | `QA` | Automate (generate tests for existing features) |
|
||||||
| Quick Flow Solo Dev (Barry) | `bmad-master` | `QS`, `QD`, `CR` | Quick Spec, Quick Dev, Code Review |
|
| Quick Flow Solo Dev (Barry) | `bmad-master` | `QD`, `CR` | Quick Dev, Code Review |
|
||||||
| UX Designer (Sally) | `bmad-ux-designer` | `CU` | Create UX Design |
|
| UX Designer (Sally) | `bmad-ux-designer` | `CU` | Create UX Design |
|
||||||
| Technical Writer (Paige) | `bmad-tech-writer` | `DP`, `WD`, `US`, `MG`, `VD`, `EC` | Document Project, Write Document, Update Standards, Mermaid Generate, Validate Doc, Explain Concept |
|
| Technical Writer (Paige) | `bmad-tech-writer` | `DP`, `WD`, `US`, `MG`, `VD`, `EC` | Document Project, Write Document, Update Standards, Mermaid Generate, Validate Doc, Explain Concept |
|
||||||
|
|
||||||
|
|
@ -35,7 +35,7 @@ Agent menu triggers use two different invocation types. Knowing which type a tri
|
||||||
|
|
||||||
Most triggers load a structured workflow file. Type the trigger code and the agent starts the workflow, prompting you for input at each step.
|
Most triggers load a structured workflow file. Type the trigger code and the agent starts the workflow, prompting you for input at each step.
|
||||||
|
|
||||||
Examples: `CP` (Create PRD), `DS` (Dev Story), `CA` (Create Architecture), `QS` (Quick Spec)
|
Examples: `CP` (Create PRD), `DS` (Dev Story), `CA` (Create Architecture), `QD` (Quick Dev)
|
||||||
|
|
||||||
### Conversational triggers (arguments required)
|
### Conversational triggers (arguments required)
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -148,7 +148,7 @@ your-project/
|
||||||
| ----------------- | ----------------------------- |
|
| ----------------- | ----------------------------- |
|
||||||
| **Index/Landing** | `core-concepts/index.md` |
|
| **Index/Landing** | `core-concepts/index.md` |
|
||||||
| **Concept** | `what-are-agents.md` |
|
| **Concept** | `what-are-agents.md` |
|
||||||
| **Feature** | `quick-flow.md` |
|
| **Feature** | `quick-dev.md` |
|
||||||
| **Philosophy** | `why-solutioning-matters.md` |
|
| **Philosophy** | `why-solutioning-matters.md` |
|
||||||
| **FAQ** | `established-projects-faq.md` |
|
| **FAQ** | `established-projects-faq.md` |
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -8,10 +8,10 @@ sidebar:
|
||||||
|
|
||||||
## 问题
|
## 问题
|
||||||
|
|
||||||
- [我必须先运行 document-project 吗?](#do-i-have-to-run-document-project-first)
|
- [我必须先运行 document-project 吗?](#我必须先运行-document-project-吗)
|
||||||
- [如果我忘记运行 document-project 怎么办?](#what-if-i-forget-to-run-document-project)
|
- [如果我忘记运行 document-project 怎么办?](#如果我忘记运行-document-project-怎么办)
|
||||||
- [我可以在既有项目上使用快速流程吗?](#can-i-use-quick-flow-for-established-projects)
|
- [我可以在既有项目上使用快速流程吗?](#我可以在既有项目上使用快速流程吗)
|
||||||
- [如果我的现有代码不遵循最佳实践怎么办?](#what-if-my-existing-code-doesnt-follow-best-practices)
|
- [如果我的现有代码不遵循最佳实践怎么办?](#如果我的现有代码不遵循最佳实践怎么办)
|
||||||
|
|
||||||
### 我必须先运行 document-project 吗?
|
### 我必须先运行 document-project 吗?
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,73 @@
|
||||||
|
---
|
||||||
|
title: "快速开发"
|
||||||
|
description: 在不牺牲输出质量检查点的情况下减少人机交互的摩擦
|
||||||
|
sidebar:
|
||||||
|
order: 2
|
||||||
|
---
|
||||||
|
|
||||||
|
输入意图,输出代码变更,尽可能少的人机交互轮次——同时不牺牲质量。
|
||||||
|
|
||||||
|
它让模型在检查点之间运行更长时间,只有在任务无法在没有人类判断的情况下安全继续时,或者需要审查最终结果时,才会让人类介入。
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## 为什么需要这个功能
|
||||||
|
|
||||||
|
人机交互轮次既必要又昂贵。
|
||||||
|
|
||||||
|
当前的 LLM 仍然会以可预测的方式失败:它们误读意图、用自信的猜测填补空白、偏离到不相关的工作中,并生成嘈杂的审查输出。与此同时,持续的人工干预限制了开发速度。人类注意力是瓶颈。
|
||||||
|
|
||||||
|
`bmad-quick-dev` 重新平衡了这种权衡。它信任模型在更长的时间段内无监督运行,但前提是工作流已经创建了足够强的边界来确保安全。
|
||||||
|
|
||||||
|
## 核心设计
|
||||||
|
|
||||||
|
### 1. 首先压缩意图
|
||||||
|
|
||||||
|
工作流首先让人类和模型将请求压缩成一个连贯的目标。输入可以从粗略的意图表达开始,但在工作流自主运行之前,它必须变得足够小、足够清晰、没有矛盾。
|
||||||
|
|
||||||
|
意图可以以多种形式出现:几句话、一个错误追踪器链接、计划模式的输出、从聊天会话复制的文本,甚至来自 BMAD 自己的 `epics.md` 的故事编号。在最后一种情况下,工作流不会理解 BMAD 故事跟踪语义,但它仍然可以获取故事本身并继续执行。
|
||||||
|
|
||||||
|
这个工作流并不会消除人类的控制。它将其重新定位到少数几个高价值时刻:
|
||||||
|
|
||||||
|
- **意图澄清** - 将混乱的请求转化为一个没有隐藏矛盾的连贯目标
|
||||||
|
- **规范审批** - 确认冻结的理解是正确要构建的东西
|
||||||
|
- **最终产品审查** - 主要检查点,人类在最后决定结果是否可接受
|
||||||
|
|
||||||
|
### 2. 路由到最小安全路径
|
||||||
|
|
||||||
|
一旦目标清晰,工作流就会决定这是一个真正的单次变更还是需要更完整的路径。小的、零爆炸半径的变更可以直接进入实现。其他所有内容都需要经过规划,这样模型在独自运行更长时间之前就有更强的边界。
|
||||||
|
|
||||||
|
### 3. 以更少的监督运行更长时间
|
||||||
|
|
||||||
|
在那个路由决策之后,模型可以自己承担更多工作。在更完整的路径上,批准的规范成为模型在较少监督下执行的边界,这正是设计的全部意义。
|
||||||
|
|
||||||
|
### 4. 在正确的层诊断失败
|
||||||
|
|
||||||
|
如果实现是错误的,因为意图是错误的,修补代码是错误的修复。如果代码是错误的,因为规范太弱,修补差异也是错误的修复。工作流旨在诊断失败从系统的哪个层面进入,回到那个层面,并从那里重新生成。
|
||||||
|
|
||||||
|
审查发现用于确定问题来自意图、规范生成还是本地实现。只有真正的本地问题才会在本地修补。
|
||||||
|
|
||||||
|
### 5. 只在需要时让人类回来
|
||||||
|
|
||||||
|
意图访谈是人机交互,但它不是与重复检查点相同类型的中断。工作流试图将那些重复检查点保持在最低限度。在初始意图塑造之后,人类主要在工作流无法在没有判断的情况下安全继续时,以及在最后需要审查结果时才回来。
|
||||||
|
|
||||||
|
- **意图差距解决** - 当审查证明工作流无法安全推断出原本意图时重新介入
|
||||||
|
|
||||||
|
其他一切都是更长自主执行的候选。这种权衡是经过深思熟虑的。旧模式在持续监督上花费更多的人类注意力。快速开发在模型上投入更多信任,但将人类注意力保留在人类推理具有最高杠杆作用的时刻。
|
||||||
|
|
||||||
|
## 为什么审查系统很重要
|
||||||
|
|
||||||
|
审查阶段不仅仅是为了发现错误。它是为了在不破坏动力的情况下路由修正。
|
||||||
|
|
||||||
|
这个工作流在能够生成子智能体的平台上效果最好,或者至少可以通过命令行调用另一个 LLM 并等待结果。如果你的平台本身不支持这一点,你可以添加一个技能来做。无上下文子智能体是审查设计的基石。
|
||||||
|
|
||||||
|
智能体审查经常以两种方式出错:
|
||||||
|
|
||||||
|
- 它们生成太多发现,迫使人类在噪音中筛选
|
||||||
|
- 它们通过提出不相关的问题并使每次运行变成临时清理项目来使当前变更脱轨
|
||||||
|
|
||||||
|
快速开发通过将审查视为分诊来解决这两个问题。
|
||||||
|
|
||||||
|
一些发现属于当前变更。一些不属于。如果一个发现是附带的而不是与当前工作有因果关系,工作流可以推迟它,而不是强迫人类立即处理它。这使运行保持专注,并防止随机的分支话题消耗注意力的预算。
|
||||||
|
|
||||||
|
那个分诊有时会不完美。这是可以接受的。通常,误判一些发现比用成千上万个低价值的审查评论淹没人类要好。系统正在优化信号质量,而不是详尽的召回率。
|
||||||
|
|
@ -1,93 +0,0 @@
|
||||||
---
|
|
||||||
title: "快速流程"
|
|
||||||
description: 小型变更的快速通道 - 跳过完整方法论
|
|
||||||
sidebar:
|
|
||||||
order: 1
|
|
||||||
---
|
|
||||||
|
|
||||||
跳过繁琐流程。快速流程通过单个工作流将你从意图带到可运行的代码 — 无需产品简报、无需 PRD、无需架构文档。
|
|
||||||
|
|
||||||
## 何时使用
|
|
||||||
|
|
||||||
- Bug 修复和补丁
|
|
||||||
- 重构现有代码
|
|
||||||
- 小型、易于理解的功能
|
|
||||||
- 原型设计和探索性开发
|
|
||||||
- 单智能体工作,一名开发者可以掌控完整范围
|
|
||||||
|
|
||||||
## 何时不使用
|
|
||||||
|
|
||||||
- 需要利益相关者对齐的新产品或平台
|
|
||||||
- 跨越多个组件或团队的主要功能
|
|
||||||
- 需要架构决策的工作(数据库架构、API 契约、服务边界)
|
|
||||||
- 需求不明确或有争议的任何工作
|
|
||||||
|
|
||||||
:::caution[Scope Creep]
|
|
||||||
如果你启动快速流程后发现范围超出预期,`bmad-quick-dev` 会检测到并提供升级选项。你可以在任何时间切换到完整的 PRD 工作流程,而不会丢失你的工作。
|
|
||||||
:::
|
|
||||||
|
|
||||||
## 工作原理
|
|
||||||
|
|
||||||
运行 `bmad-quick-dev`,工作流会处理一切 — 澄清意图、规划、实现、审查和呈现结果。
|
|
||||||
|
|
||||||
### 1. 澄清意图
|
|
||||||
|
|
||||||
你描述想要什么。工作流将你的请求压缩成一个连贯的目标 — 足够小、足够清晰、没有矛盾,可以安全执行。意图可以来自多种来源:几句话、一个错误追踪器链接、计划模式输出、聊天会话文本,甚至来自你的史诗的故事编号。
|
|
||||||
|
|
||||||
### 2. 路由到最小安全路径
|
|
||||||
|
|
||||||
一旦目标清晰,工作流就会决定这是一个真正的单次变更还是需要更完整的路径。小的、零爆炸半径的变更可以直接进入实现。其他所有内容都需要经过规划,这样模型在自主运行之前就有更强的边界。
|
|
||||||
|
|
||||||
### 3. 规划和实现
|
|
||||||
|
|
||||||
在规划路径上,工作流生成完整的技术规范,包含有序的实现任务、Given/When/Then 格式的验收标准和测试策略。你批准规范后,它成为模型在较少监督下执行的边界。
|
|
||||||
|
|
||||||
### 4. 审查和呈现
|
|
||||||
|
|
||||||
实现后,工作流运行自检审计和差异的对抗性代码审查。审查充当分诊 — 与当前变更相关的发现会被处理,附带的发现会被推迟以保持运行专注。结果呈现供你确认。
|
|
||||||
|
|
||||||
### 人机交互检查点
|
|
||||||
|
|
||||||
工作流将人类控制重新定位到少数几个高价值时刻:
|
|
||||||
|
|
||||||
- **意图澄清** — 将混乱的请求转化为一个连贯的目标
|
|
||||||
- **规范审批** — 确认冻结的理解是正确要构建的东西
|
|
||||||
- **最终审查** — 决定结果是否可接受
|
|
||||||
|
|
||||||
在这些检查点之间,模型以更少的监督运行更长时间。这是经过深思熟虑的 — 它用持续监督换取在最高杠杆时刻的集中人类注意力。
|
|
||||||
|
|
||||||
## 快速流程跳过的内容
|
|
||||||
|
|
||||||
完整的 BMad 方法在编写任何代码之前会生成产品简报、PRD、架构文档和 Epic/Story 分解。Quick Flow 用单个技术规范替代所有这些。这之所以有效,是因为 Quick Flow 针对以下变更:
|
|
||||||
|
|
||||||
- 产品方向已确立
|
|
||||||
- 架构决策已做出
|
|
||||||
- 单个开发者可以推理完整范围
|
|
||||||
- 需求可以在一次对话中涵盖
|
|
||||||
|
|
||||||
## 升级到完整 BMad 方法
|
|
||||||
|
|
||||||
快速流程包含内置的范围检测护栏。当你运行 `bmad-quick-dev` 时,它会评估多组件提及、系统级语言和方法不确定性等信号。如果检测到工作超出快速流程范围:
|
|
||||||
|
|
||||||
- **轻度升级** — 建议在实现前创建计划
|
|
||||||
- **重度升级** — 建议切换到完整的 BMad 方法 PRD 流程
|
|
||||||
|
|
||||||
你也可以随时手动升级。你的技术规范工作会继续推进 — 它将成为更广泛规划过程的输入,而不是被丢弃。
|
|
||||||
|
|
||||||
---
|
|
||||||
## 术语说明
|
|
||||||
|
|
||||||
- **Quick Flow**:快速流程。BMad 方法中用于小型变更的简化工作流程,跳过完整的产品规划和架构文档阶段。
|
|
||||||
- **PRD**:Product Requirements Document,产品需求文档。详细描述产品功能、需求和验收标准的文档。
|
|
||||||
- **Product Brief**:产品简报。概述产品愿景、目标和范围的高层文档。
|
|
||||||
- **Architecture doc**:架构文档。描述系统架构、组件设计和技术决策的文档。
|
|
||||||
- **Epic/Story**:史诗/故事。敏捷开发中的工作单元,Epic 是大型功能集合,Story 是具体用户故事。
|
|
||||||
- **agent**:智能体。在人工智能与编程文档中,指具备自主决策或执行能力的单元。
|
|
||||||
- **Scope Creep**:范围蔓延。项目范围在开发过程中逐渐扩大,超出原始计划的现象。
|
|
||||||
- **tech-spec**:技术规范。详细描述技术实现方案、任务分解和验收标准的文档。
|
|
||||||
- **Given/When/Then**:一种行为驱动开发(BDD)的测试场景描述格式,用于定义验收标准。
|
|
||||||
- **adversarial review**:对抗性审查。一种代码审查方法,模拟攻击者视角以发现潜在问题和漏洞。
|
|
||||||
- **stakeholder**:利益相关者。对项目有利益或影响的个人或组织。
|
|
||||||
- **API contracts**:API 契约。定义 API 接口规范、请求/响应格式和行为约定的文档。
|
|
||||||
- **service boundaries**:服务边界。定义服务职责范围和边界的架构概念。
|
|
||||||
- **spikes**:探索性开发。用于探索技术可行性或解决方案的短期研究活动。
|
|
||||||
|
|
@ -128,7 +128,7 @@ prompts:
|
||||||
|
|
||||||
### 3. 应用您的更改
|
### 3. 应用您的更改
|
||||||
|
|
||||||
编辑后,重新编译智能体以应用更改:
|
编辑后,重新安装以应用更改:
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
npx bmad-method install
|
npx bmad-method install
|
||||||
|
|
@ -138,17 +138,16 @@ npx bmad-method install
|
||||||
|
|
||||||
| Option | What It Does |
|
| Option | What It Does |
|
||||||
| ---------------------------- | ------------------------------------------------------------------- |
|
| ---------------------------- | ------------------------------------------------------------------- |
|
||||||
| **Quick Update** | 将所有模块更新到最新版本并重新编译所有智能体 |
|
| **Quick Update** | 将所有模块更新到最新版本并应用自定义配置 |
|
||||||
| **Recompile Agents** | 仅应用自定义配置,不更新模块文件 |
|
|
||||||
| **Modify BMad Installation** | 用于添加或删除模块的完整安装流程 |
|
| **Modify BMad Installation** | 用于添加或删除模块的完整安装流程 |
|
||||||
|
|
||||||
对于仅自定义配置的更改,**Recompile Agents** 是最快的选项。
|
对于仅自定义配置的更改,**Quick Update** 是最快的选项。
|
||||||
|
|
||||||
## 故障排除
|
## 故障排除
|
||||||
|
|
||||||
**更改未生效?**
|
**更改未生效?**
|
||||||
|
|
||||||
- 运行 `npx bmad-method install` 并选择 **Recompile Agents** 以应用更改
|
- 运行 `npx bmad-method install` 并选择 **Quick Update** 以应用更改
|
||||||
- 检查您的 YAML 语法是否有效(缩进很重要)
|
- 检查您的 YAML 语法是否有效(缩进很重要)
|
||||||
- 验证您编辑的是该智能体正确的 `.customize.yaml` 文件
|
- 验证您编辑的是该智能体正确的 `.customize.yaml` 文件
|
||||||
|
|
||||||
|
|
@ -161,7 +160,7 @@ npx bmad-method install
|
||||||
**需要重置智能体?**
|
**需要重置智能体?**
|
||||||
|
|
||||||
- 清空或删除智能体的 `.customize.yaml` 文件
|
- 清空或删除智能体的 `.customize.yaml` 文件
|
||||||
- 运行 `npx bmad-method install` 并选择 **Recompile Agents** 以恢复默认设置
|
- 运行 `npx bmad-method install` 并选择 **Quick Update** 以恢复默认设置
|
||||||
|
|
||||||
## 工作流自定义
|
## 工作流自定义
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -28,7 +28,7 @@ sidebar:
|
||||||
| `--modules <modules>` | 逗号分隔的模块 ID | `--modules bmm,bmb` |
|
| `--modules <modules>` | 逗号分隔的模块 ID | `--modules bmm,bmb` |
|
||||||
| `--tools <tools>` | 逗号分隔的工具/IDE ID(使用 `none` 跳过) | `--tools claude-code,cursor` 或 `--tools none` |
|
| `--tools <tools>` | 逗号分隔的工具/IDE ID(使用 `none` 跳过) | `--tools claude-code,cursor` 或 `--tools none` |
|
||||||
| `--custom-content <paths>` | 逗号分隔的自定义模块路径 | `--custom-content ~/my-module,~/another-module` |
|
| `--custom-content <paths>` | 逗号分隔的自定义模块路径 | `--custom-content ~/my-module,~/another-module` |
|
||||||
| `--action <type>` | 对现有安装的操作:`install`(默认)、`update`、`quick-update` 或 `compile-agents` | `--action quick-update` |
|
| `--action <type>` | 对现有安装的操作:`install`(默认)、`update` 或 `quick-update` | `--action quick-update` |
|
||||||
|
|
||||||
### 核心配置
|
### 核心配置
|
||||||
|
|
||||||
|
|
@ -121,7 +121,7 @@ npx bmad-method install \
|
||||||
## 安装结果
|
## 安装结果
|
||||||
|
|
||||||
- 项目中完全配置的 `_bmad/` 目录
|
- 项目中完全配置的 `_bmad/` 目录
|
||||||
- 为所选模块和工具编译的智能体和工作流
|
- 为所选模块和工具配置的智能体和工作流
|
||||||
- 用于生成产物的 `_bmad-output/` 文件夹
|
- 用于生成产物的 `_bmad-output/` 文件夹
|
||||||
|
|
||||||
## 验证和错误处理
|
## 验证和错误处理
|
||||||
|
|
@ -132,7 +132,7 @@ BMad 会验证所有提供的标志:
|
||||||
- **模块** — 对无效的模块 ID 发出警告(但不会失败)
|
- **模块** — 对无效的模块 ID 发出警告(但不会失败)
|
||||||
- **工具** — 对无效的工具 ID 发出警告(但不会失败)
|
- **工具** — 对无效的工具 ID 发出警告(但不会失败)
|
||||||
- **自定义内容** — 每个路径必须包含有效的 `module.yaml` 文件
|
- **自定义内容** — 每个路径必须包含有效的 `module.yaml` 文件
|
||||||
- **操作** — 必须是以下之一:`install`、`update`、`quick-update`、`compile-agents`
|
- **操作** — 必须是以下之一:`install`、`update`、`quick-update`
|
||||||
|
|
||||||
无效值将:
|
无效值将:
|
||||||
1. 显示错误并退出(对于目录等关键选项)
|
1. 显示错误并退出(对于目录等关键选项)
|
||||||
|
|
|
||||||
|
|
@ -2,7 +2,7 @@
|
||||||
title: "管理项目上下文"
|
title: "管理项目上下文"
|
||||||
description: 创建并维护 project-context.md 以指导 AI 智能体
|
description: 创建并维护 project-context.md 以指导 AI 智能体
|
||||||
sidebar:
|
sidebar:
|
||||||
order: 7
|
order: 8
|
||||||
---
|
---
|
||||||
|
|
||||||
使用 `project-context.md` 文件确保 AI 智能体在所有工作流程中遵循项目的技术偏好和实现规则。
|
使用 `project-context.md` 文件确保 AI 智能体在所有工作流程中遵循项目的技术偏好和实现规则。
|
||||||
|
|
|
||||||
|
|
@ -5,135 +5,103 @@ sidebar:
|
||||||
order: 5
|
order: 5
|
||||||
---
|
---
|
||||||
|
|
||||||
直接使用 **DEV 智能体**进行 bug 修复、重构或小型针对性更改,这些操作不需要完整的 BMad Method 或 Quick Flow。
|
使用 **Quick Dev** 进行 bug 修复、重构或小型针对性更改,这些操作不需要完整的 BMad Method。
|
||||||
|
|
||||||
## 何时使用此方法
|
## 何时使用此方法
|
||||||
|
|
||||||
- 原因明确且已知的 bug 修复
|
- 原因明确且已知的 bug 修复
|
||||||
- 包含在少数文件中的小型重构(重命名、提取、重组)
|
- 包含在少数文件中的小型重构(重命名、提取、重组)
|
||||||
- 次要功能调整或配置更改
|
- 次要功能调整或配置更改
|
||||||
- 探索性工作,以了解不熟悉的代码库
|
- 依赖更新
|
||||||
|
|
||||||
:::note[前置条件]
|
:::note[前置条件]
|
||||||
- 已安装 BMad Method(`npx bmad-method install`)
|
- 已安装 BMad Method(`npx bmad-method install`)
|
||||||
- AI 驱动的 IDE(Claude Code、Cursor 或类似工具)
|
- AI 驱动的 IDE(Claude Code、Cursor 或类似工具)
|
||||||
:::
|
:::
|
||||||
|
|
||||||
## 选择你的方法
|
|
||||||
|
|
||||||
| 情况 | 智能体 | 原因 |
|
|
||||||
| --- | --- | --- |
|
|
||||||
| 修复特定 bug 或进行小型、范围明确的更改 | **DEV agent** | 直接进入实现,无需规划开销 |
|
|
||||||
| 更改涉及多个文件,或希望先有书面计划 | **Quick Flow Solo Dev** | 在单个工作流中澄清意图、规划、实现和审查,使智能体与你的标准保持一致 |
|
|
||||||
|
|
||||||
如果不确定,请从 DEV 智能体开始。如果更改范围扩大,你始终可以升级到 Quick Flow。
|
|
||||||
|
|
||||||
## 步骤
|
## 步骤
|
||||||
|
|
||||||
### 1. 加载 DEV 智能体
|
### 1. 启动新的聊天
|
||||||
|
|
||||||
在 AI IDE 中启动一个**新的聊天**,并使用斜杠命令加载 DEV 智能体:
|
在 AI IDE 中打开一个**新的聊天会话**。重用之前工作流的会话可能导致上下文冲突。
|
||||||
|
|
||||||
|
### 2. 提供你的意图
|
||||||
|
|
||||||
|
Quick Dev 接受自由形式的意图——可以在调用之前、同时或之后提供。示例:
|
||||||
|
|
||||||
```text
|
```text
|
||||||
/bmad-agent-bmm-dev
|
run quick-dev — 修复允许空密码的登录验证 bug。
|
||||||
```
|
```
|
||||||
|
|
||||||
这会将智能体的角色和能力加载到会话中。如果你决定需要 Quick Flow,请在新的聊天中加载 **Quick Flow Solo Dev** 智能体:
|
|
||||||
|
|
||||||
```text
|
```text
|
||||||
/bmad-agent-bmm-quick-flow-solo-dev
|
run quick-dev — fix https://github.com/org/repo/issues/42
|
||||||
```
|
```
|
||||||
|
|
||||||
加载 Solo Dev 智能体后,描述你的更改并告诉它运行 **quick-dev**。工作流将澄清你的意图、创建计划、实现更改、运行代码审查并呈现结果 — 全部在单次运行中完成。
|
```text
|
||||||
|
run quick-dev — 实现 _bmad-output/implementation-artifacts/my-intent.md 中的意图
|
||||||
|
```
|
||||||
|
|
||||||
:::tip[新聊天]
|
```text
|
||||||
加载智能体时始终启动新的聊天会话。重用之前工作流的会话可能导致上下文冲突。
|
我觉得问题在 auth 中间件,它没有检查 token 过期。
|
||||||
:::
|
让我看看... 是的,src/auth/middleware.ts 第 47 行完全跳过了
|
||||||
|
exp 检查。run quick-dev
|
||||||
|
```
|
||||||
|
|
||||||
### 2. 描述更改
|
```text
|
||||||
|
run quick-dev
|
||||||
|
> 你想做什么?
|
||||||
|
重构 UserService 以使用 async/await 而不是回调。
|
||||||
|
```
|
||||||
|
|
||||||
用通俗语言告诉智能体你需要什么。具体说明问题,如果你知道相关代码的位置,也请说明。
|
纯文本、文件路径、GitHub issue URL、bug 跟踪器链接——任何 LLM 能解析为具体意图的内容都可以。
|
||||||
|
|
||||||
:::note[示例提示词]
|
### 3. 回答问题并批准
|
||||||
**Bug 修复** -- "修复允许空密码的登录验证 bug。验证逻辑位于 `src/auth/validate.ts`。"
|
|
||||||
|
|
||||||
**重构** -- "重构 UserService 以使用 async/await 而不是回调。"
|
Quick Dev 可能会提出澄清问题,或在实现之前呈现简短的规范供你批准。回答它的问题,并在你对计划满意时批准。
|
||||||
|
|
||||||
**配置更改** -- "更新 CI 流水线以在运行之间缓存 node_modules。"
|
### 4. 审查和推送
|
||||||
|
|
||||||
**依赖更新** -- "将 express 依赖升级到最新的 v5 版本并修复任何破坏性更改。"
|
Quick Dev 实现更改、审查自己的工作、修复问题,并在本地提交。完成后,它会在编辑器中打开受影响的文件。
|
||||||
:::
|
|
||||||
|
|
||||||
你不需要提供每个细节。智能体会读取相关的源文件,并在需要时提出澄清问题。
|
- 浏览 diff 以确认更改符合你的意图
|
||||||
|
|
||||||
### 3. 让智能体工作
|
|
||||||
|
|
||||||
智能体将:
|
|
||||||
|
|
||||||
- 读取并分析相关的源文件
|
|
||||||
- 提出解决方案并解释其推理
|
|
||||||
- 在受影响的文件中实现更改
|
|
||||||
- 如果存在测试套件,则运行项目的测试套件
|
|
||||||
|
|
||||||
如果你的项目有测试,智能体会在进行更改后自动运行它们,并迭代直到测试通过。对于没有测试套件的项目,请手动验证更改(运行应用、访问端点、检查输出)。
|
|
||||||
|
|
||||||
### 4. 审查和验证
|
|
||||||
|
|
||||||
在提交之前,审查更改内容:
|
|
||||||
|
|
||||||
- 通读 diff 以确认更改符合你的意图
|
|
||||||
- 自己运行应用程序或测试以再次检查
|
|
||||||
- 如果看起来有问题,告诉智能体需要修复什么——它可以在同一会话中迭代
|
- 如果看起来有问题,告诉智能体需要修复什么——它可以在同一会话中迭代
|
||||||
|
|
||||||
满意后,使用描述修复的清晰消息提交更改。
|
满意后,推送提交。Quick Dev 会提供推送和创建 PR 的选项。
|
||||||
|
|
||||||
:::caution[如果出现问题]
|
:::caution[如果出现问题]
|
||||||
如果提交的更改导致意外问题,请使用 `git revert HEAD` 干净地撤销最后一次提交。然后启动与 DEV 智能体的新聊天以尝试不同的方法。
|
如果推送的更改导致意外问题,请使用 `git revert HEAD` 干净地撤销最后一次提交。然后启动新聊天并再次运行 Quick Dev 以尝试不同的方法。
|
||||||
:::
|
:::
|
||||||
|
|
||||||
## 学习你的代码库
|
|
||||||
|
|
||||||
DEV 智能体也适用于探索不熟悉的代码。在新的聊天中加载它并提出问题:
|
|
||||||
|
|
||||||
:::note[示例提示词]
|
|
||||||
"解释此代码库中的身份验证系统是如何工作的。"
|
|
||||||
|
|
||||||
"向我展示 API 层中的错误处理发生在哪里。"
|
|
||||||
|
|
||||||
"`ProcessOrder` 函数的作用是什么,什么调用了它?"
|
|
||||||
:::
|
|
||||||
|
|
||||||
使用智能体了解你的项目,理解组件如何连接,并在进行更改之前探索不熟悉的区域。
|
|
||||||
|
|
||||||
## 你将获得
|
## 你将获得
|
||||||
|
|
||||||
- 已应用修复或重构的修改后的源文件
|
- 已应用修复或重构的修改后的源文件
|
||||||
- 通过的测试(如果你的项目有测试套件)
|
- 通过的测试(如果你的项目有测试套件)
|
||||||
- 描述更改的干净提交
|
- 带有约定式提交消息的准备推送的提交
|
||||||
|
|
||||||
不会生成规划产物——这就是这种方法的意义所在。
|
## 延迟工作
|
||||||
|
|
||||||
|
Quick Dev 保持每次运行聚焦于单一目标。如果你的请求包含多个独立目标,或者审查发现了与你的更改无关的已有问题,Quick Dev 会将它们延迟到一个文件中(实现产物目录中的 `deferred-work.md`),而不是试图一次解决所有问题。
|
||||||
|
|
||||||
|
运行后检查此文件——它是你的待办事项积压。每个延迟项目都可以稍后输入到新的 Quick Dev 运行中。
|
||||||
|
|
||||||
## 何时升级到正式规划
|
## 何时升级到正式规划
|
||||||
|
|
||||||
在以下情况下考虑使用 [Quick Flow](../explanation/quick-flow.md) 或完整的 BMad Method:
|
在以下情况下考虑使用完整的 BMad Method:
|
||||||
|
|
||||||
- 更改影响多个系统或需要在许多文件中进行协调更新
|
- 更改影响多个系统或需要在许多文件中进行协调更新
|
||||||
- 你不确定范围,需要规范来理清思路
|
- 你不确定范围,需要先进行需求发现
|
||||||
- 修复在工作过程中变得越来越复杂
|
|
||||||
- 你需要为团队记录文档或架构决策
|
- 你需要为团队记录文档或架构决策
|
||||||
|
|
||||||
|
参见 [Quick Dev](../explanation/quick-dev.md) 了解 Quick Dev 如何融入 BMad Method。
|
||||||
|
|
||||||
---
|
---
|
||||||
## 术语说明
|
## 术语说明
|
||||||
|
|
||||||
- **agent**:智能体。在人工智能与编程文档中,指具备自主决策或执行能力的单元。
|
- **Quick Dev**:快速开发。BMad Method 中的快速工作流,用于小型更改的完整实现周期。
|
||||||
- **Quick Flow**:快速流程。BMad Method 中的一种统一工作流程,用于快速澄清意图、规划、实现和审查小型更改。
|
|
||||||
- **refactoring**:重构。在不改变代码外部行为的情况下改进其内部结构的过程。
|
- **refactoring**:重构。在不改变代码外部行为的情况下改进其内部结构的过程。
|
||||||
- **breaking changes**:破坏性更改。可能导致现有代码或功能不再正常工作的更改。
|
- **breaking changes**:破坏性更改。可能导致现有代码或功能不再正常工作的更改。
|
||||||
- **test suite**:测试套件。一组用于验证软件功能的测试用例集合。
|
- **test suite**:测试套件。一组用于验证软件功能的测试用例集合。
|
||||||
- **CI pipeline**:CI 流水线。持续集成流水线,用于自动化构建、测试和部署代码。
|
- **CI pipeline**:CI 流水线。持续集成流水线,用于自动化构建、测试和部署代码。
|
||||||
- **async/await**:异步编程语法。JavaScript/TypeScript 中用于处理异步操作的语法糖。
|
|
||||||
- **callbacks**:回调函数。作为参数传递给其他函数并在适当时候被调用的函数。
|
|
||||||
- **endpoint**:端点。API 中可访问的特定 URL 路径。
|
|
||||||
- **diff**:差异。文件或代码更改前后的对比。
|
- **diff**:差异。文件或代码更改前后的对比。
|
||||||
- **commit**:提交。将更改保存到版本控制系统的操作。
|
- **commit**:提交。将更改保存到版本控制系统的操作。
|
||||||
- **git revert HEAD**:Git 命令,用于撤销最后一次提交。
|
- **conventional commit**:约定式提交。遵循标准格式的提交消息。
|
||||||
|
|
|
||||||
|
|
@ -2,7 +2,7 @@
|
||||||
title: "文档分片指南"
|
title: "文档分片指南"
|
||||||
description: 将大型 Markdown 文件拆分为更小的组织化文件,以更好地管理上下文
|
description: 将大型 Markdown 文件拆分为更小的组织化文件,以更好地管理上下文
|
||||||
sidebar:
|
sidebar:
|
||||||
order: 8
|
order: 9
|
||||||
---
|
---
|
||||||
|
|
||||||
如果需要将大型 Markdown 文件拆分为更小、组织良好的文件以更好地管理上下文,请使用 `shard-doc` 工具。
|
如果需要将大型 Markdown 文件拆分为更小、组织良好的文件以更好地管理上下文,请使用 `shard-doc` 工具。
|
||||||
|
|
|
||||||
|
|
@ -23,7 +23,7 @@ sidebar:
|
||||||
| Scrum Master (Bob) | `SP`, `CS`, `ER`, `CC` | 冲刺规划、创建用户故事、史诗回顾、纠正方向 |
|
| Scrum Master (Bob) | `SP`, `CS`, `ER`, `CC` | 冲刺规划、创建用户故事、史诗回顾、纠正方向 |
|
||||||
| Developer (Amelia) | `DS`, `CR` | 开发用户故事、代码评审 |
|
| Developer (Amelia) | `DS`, `CR` | 开发用户故事、代码评审 |
|
||||||
| QA Engineer (Quinn) | `QA` | 自动化(为现有功能生成测试) |
|
| QA Engineer (Quinn) | `QA` | 自动化(为现有功能生成测试) |
|
||||||
| Quick Flow Solo Dev (Barry) | `QS`, `QD`, `CR` | 快速规格、快速开发、代码评审 |
|
| Quick Flow Solo Dev (Barry) | `QD`, `CR` | 快速开发、代码评审 |
|
||||||
| UX Designer (Sally) | `CU` | 创建 UX 设计 |
|
| UX Designer (Sally) | `CU` | 创建 UX 设计 |
|
||||||
| Technical Writer (Paige) | `DP`, `WD`, `US`, `MG`, `VD`, `EC` | 文档化项目、撰写文档、更新标准、Mermaid 生成、验证文档、解释概念 |
|
| Technical Writer (Paige) | `DP`, `WD`, `US`, `MG`, `VD`, `EC` | 文档化项目、撰写文档、更新标准、Mermaid 生成、验证文档、解释概念 |
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -7230,9 +7230,9 @@
|
||||||
"license": "ISC"
|
"license": "ISC"
|
||||||
},
|
},
|
||||||
"node_modules/h3": {
|
"node_modules/h3": {
|
||||||
"version": "1.15.5",
|
"version": "1.15.8",
|
||||||
"resolved": "https://registry.npmjs.org/h3/-/h3-1.15.5.tgz",
|
"resolved": "https://registry.npmjs.org/h3/-/h3-1.15.8.tgz",
|
||||||
"integrity": "sha512-xEyq3rSl+dhGX2Lm0+eFQIAzlDN6Fs0EcC4f7BNUmzaRX/PTzeuM+Tr2lHB8FoXggsQIeXLj8EDVgs5ywxyxmg==",
|
"integrity": "sha512-iOH6Vl8mGd9nNfu9C0IZ+GuOAfJHcyf3VriQxWaSWIB76Fg4BnFuk4cxBxjmQSSxJS664+pgjP6e7VBnUzFfcg==",
|
||||||
"dev": true,
|
"dev": true,
|
||||||
"license": "MIT",
|
"license": "MIT",
|
||||||
"dependencies": {
|
"dependencies": {
|
||||||
|
|
|
||||||
|
|
@ -39,12 +39,13 @@
|
||||||
"lint:fix": "eslint . --ext .js,.cjs,.mjs,.yaml --fix",
|
"lint:fix": "eslint . --ext .js,.cjs,.mjs,.yaml --fix",
|
||||||
"lint:md": "markdownlint-cli2 \"**/*.md\"",
|
"lint:md": "markdownlint-cli2 \"**/*.md\"",
|
||||||
"prepare": "command -v husky >/dev/null 2>&1 && husky || exit 0",
|
"prepare": "command -v husky >/dev/null 2>&1 && husky || exit 0",
|
||||||
"quality": "npm run format:check && npm run lint && npm run lint:md && npm run docs:build && npm run test:install && npm run validate:refs",
|
"quality": "npm run format:check && npm run lint && npm run lint:md && npm run docs:build && npm run test:install && npm run validate:refs && npm run validate:skills",
|
||||||
"rebundle": "node tools/cli/bundlers/bundle-web.js rebundle",
|
"rebundle": "node tools/cli/bundlers/bundle-web.js rebundle",
|
||||||
"test": "npm run test:refs && npm run test:install && npm run lint && npm run lint:md && npm run format:check",
|
"test": "npm run test:refs && npm run test:install && npm run lint && npm run lint:md && npm run format:check",
|
||||||
"test:install": "node test/test-installation-components.js",
|
"test:install": "node test/test-installation-components.js",
|
||||||
"test:refs": "node test/test-file-refs-csv.js",
|
"test:refs": "node test/test-file-refs-csv.js",
|
||||||
"validate:refs": "node tools/validate-file-refs.js --strict"
|
"validate:refs": "node tools/validate-file-refs.js --strict",
|
||||||
|
"validate:skills": "node tools/validate-skills.js --strict"
|
||||||
},
|
},
|
||||||
"lint-staged": {
|
"lint-staged": {
|
||||||
"*.{js,cjs,mjs}": [
|
"*.{js,cjs,mjs}": [
|
||||||
|
|
|
||||||
|
|
@ -1,6 +0,0 @@
|
||||||
---
|
|
||||||
name: bmad-create-product-brief
|
|
||||||
description: 'Create product brief through collaborative discovery. Use when the user says "lets create a product brief" or "help me create a project brief"'
|
|
||||||
---
|
|
||||||
|
|
||||||
Follow the instructions in ./workflow.md.
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
type: skill
|
|
||||||
|
|
@ -1,10 +0,0 @@
|
||||||
---
|
|
||||||
stepsCompleted: []
|
|
||||||
inputDocuments: []
|
|
||||||
date: {{system-date}}
|
|
||||||
author: {{user_name}}
|
|
||||||
---
|
|
||||||
|
|
||||||
# Product Brief: {{project_name}}
|
|
||||||
|
|
||||||
<!-- Content will be appended sequentially through collaborative workflow steps -->
|
|
||||||
|
|
@ -1,170 +0,0 @@
|
||||||
---
|
|
||||||
# File References
|
|
||||||
outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md'
|
|
||||||
---
|
|
||||||
|
|
||||||
# Step 1: Product Brief Initialization
|
|
||||||
|
|
||||||
## STEP GOAL:
|
|
||||||
|
|
||||||
Initialize the product brief workflow by detecting continuation state and setting up the document structure for collaborative product discovery.
|
|
||||||
|
|
||||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
|
||||||
|
|
||||||
### Universal Rules:
|
|
||||||
|
|
||||||
- 🛑 NEVER generate content without user input
|
|
||||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
|
||||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
|
||||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
|
||||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
|
||||||
|
|
||||||
### Role Reinforcement:
|
|
||||||
|
|
||||||
- ✅ You are a product-focused Business Analyst facilitator
|
|
||||||
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
|
||||||
- ✅ We engage in collaborative dialogue, not command-response
|
|
||||||
- ✅ You bring structured thinking and facilitation skills, while the user brings domain expertise and product vision
|
|
||||||
- ✅ Maintain collaborative discovery tone throughout
|
|
||||||
|
|
||||||
### Step-Specific Rules:
|
|
||||||
|
|
||||||
- 🎯 Focus only on initialization and setup - no content generation yet
|
|
||||||
- 🚫 FORBIDDEN to look ahead to future steps or assume knowledge from them
|
|
||||||
- 💬 Approach: Systematic setup with clear reporting to user
|
|
||||||
- 📋 Detect existing workflow state and handle continuation properly
|
|
||||||
|
|
||||||
## EXECUTION PROTOCOLS:
|
|
||||||
|
|
||||||
- 🎯 Show your analysis of current state before taking any action
|
|
||||||
- 💾 Initialize document structure and update frontmatter appropriately
|
|
||||||
- 📖 Set up frontmatter `stepsCompleted: [1]` before loading next step
|
|
||||||
- 🚫 FORBIDDEN to load next step until user selects 'C' (Continue)
|
|
||||||
|
|
||||||
## CONTEXT BOUNDARIES:
|
|
||||||
|
|
||||||
- Available context: Variables from workflow.md are available in memory
|
|
||||||
- Focus: Workflow initialization and document setup only
|
|
||||||
- Limits: Don't assume knowledge from other steps or create content yet
|
|
||||||
- Dependencies: Configuration loaded from workflow.md initialization
|
|
||||||
|
|
||||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
|
||||||
|
|
||||||
### 1. Check for Existing Workflow State
|
|
||||||
|
|
||||||
First, check if the output document already exists:
|
|
||||||
|
|
||||||
**Workflow State Detection:**
|
|
||||||
|
|
||||||
- Look for file `{outputFile}`
|
|
||||||
- If exists, read the complete file including frontmatter
|
|
||||||
- If not exists, this is a fresh workflow
|
|
||||||
|
|
||||||
### 2. Handle Continuation (If Document Exists)
|
|
||||||
|
|
||||||
If the document exists and has frontmatter with `stepsCompleted`:
|
|
||||||
|
|
||||||
**Continuation Protocol:**
|
|
||||||
|
|
||||||
- **STOP immediately** and load `./step-01b-continue.md`
|
|
||||||
- Do not proceed with any initialization tasks
|
|
||||||
- Let step-01b handle all continuation logic
|
|
||||||
- This is an auto-proceed situation - no user choice needed
|
|
||||||
|
|
||||||
### 3. Fresh Workflow Setup (If No Document)
|
|
||||||
|
|
||||||
If no document exists or no `stepsCompleted` in frontmatter:
|
|
||||||
|
|
||||||
#### A. Input Document Discovery
|
|
||||||
|
|
||||||
load context documents using smart discovery. Documents can be in the following locations:
|
|
||||||
- {planning_artifacts}/**
|
|
||||||
- {output_folder}/**
|
|
||||||
- {product_knowledge}/**
|
|
||||||
- {project-root}/docs/**
|
|
||||||
|
|
||||||
Also - when searching - documents can be a single markdown file, or a folder with an index and multiple files. For Example, if searching for `*foo*.md` and not found, also search for a folder called *foo*/index.md (which indicates sharded content)
|
|
||||||
|
|
||||||
Try to discover the following:
|
|
||||||
- Brainstorming Reports (`*brainstorming*.md`)
|
|
||||||
- Research Documents (`*research*.md`)
|
|
||||||
- Project Documentation (generally multiple documents might be found for this in the `{product_knowledge}` or `docs` folder.)
|
|
||||||
- Project Context (`**/project-context.md`)
|
|
||||||
|
|
||||||
<critical>Confirm what you have found with the user, along with asking if the user wants to provide anything else. Only after this confirmation will you proceed to follow the loading rules</critical>
|
|
||||||
|
|
||||||
**Loading Rules:**
|
|
||||||
|
|
||||||
- Load ALL discovered files completely that the user confirmed or provided (no offset/limit)
|
|
||||||
- If there is a project context, whatever is relevant should try to be biased in the remainder of this whole workflow process
|
|
||||||
- For sharded folders, load ALL files to get complete picture, using the index first to potentially know the potential of each document
|
|
||||||
- index.md is a guide to what's relevant whenever available
|
|
||||||
- Track all successfully loaded files in frontmatter `inputDocuments` array
|
|
||||||
|
|
||||||
#### B. Create Initial Document
|
|
||||||
|
|
||||||
**Document Setup:**
|
|
||||||
|
|
||||||
- Copy the template from `../product-brief.template.md` to `{outputFile}`, and update the frontmatter fields
|
|
||||||
|
|
||||||
#### C. Present Initialization Results
|
|
||||||
|
|
||||||
**Setup Report to User:**
|
|
||||||
"Welcome {{user_name}}! I've set up your product brief workspace for {{project_name}}.
|
|
||||||
|
|
||||||
**Document Setup:**
|
|
||||||
|
|
||||||
- Created: `{outputFile}` from template
|
|
||||||
- Initialized frontmatter with workflow state
|
|
||||||
|
|
||||||
**Input Documents Discovered:**
|
|
||||||
|
|
||||||
- Research: {number of research files loaded or "None found"}
|
|
||||||
- Brainstorming: {number of brainstorming files loaded or "None found"}
|
|
||||||
- Project docs: {number of project files loaded or "None found"}
|
|
||||||
- Project Context: {number of project context files loaded or "None found"}
|
|
||||||
|
|
||||||
**Files loaded:** {list of specific file names or "No additional documents found"}
|
|
||||||
|
|
||||||
Do you have any other documents you'd like me to include, or shall we continue to the next step?"
|
|
||||||
|
|
||||||
### 4. Present MENU OPTIONS
|
|
||||||
|
|
||||||
Display: "**Proceeding to product vision discovery...**"
|
|
||||||
|
|
||||||
#### Menu Handling Logic:
|
|
||||||
|
|
||||||
- After setup report is presented, without delay, read fully and follow: ./step-02-vision.md
|
|
||||||
|
|
||||||
#### EXECUTION RULES:
|
|
||||||
|
|
||||||
- This is an initialization step with auto-proceed after setup completion
|
|
||||||
- Proceed directly to next step after document setup and reporting
|
|
||||||
|
|
||||||
## CRITICAL STEP COMPLETION NOTE
|
|
||||||
|
|
||||||
ONLY WHEN [setup completion is achieved and frontmatter properly updated], will you then read fully and follow: `./step-02-vision.md` to begin product vision discovery.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
|
||||||
|
|
||||||
### ✅ SUCCESS:
|
|
||||||
|
|
||||||
- Existing workflow detected and properly handed off to step-01b
|
|
||||||
- Fresh workflow initialized with template and proper frontmatter
|
|
||||||
- Input documents discovered and loaded using sharded-first logic
|
|
||||||
- All discovered files tracked in frontmatter `inputDocuments`
|
|
||||||
- Menu presented and user input handled correctly
|
|
||||||
- Frontmatter updated with `stepsCompleted: [1]` before proceeding
|
|
||||||
|
|
||||||
### ❌ SYSTEM FAILURE:
|
|
||||||
|
|
||||||
- Proceeding with fresh initialization when existing workflow exists
|
|
||||||
- Not updating frontmatter with discovered input documents
|
|
||||||
- Creating document without proper template structure
|
|
||||||
- Not checking sharded folders first before whole files
|
|
||||||
- Not reporting discovered documents to user clearly
|
|
||||||
- Proceeding without user selecting 'C' (Continue)
|
|
||||||
|
|
||||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
|
||||||
|
|
@ -1,158 +0,0 @@
|
||||||
---
|
|
||||||
# File References
|
|
||||||
outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md'
|
|
||||||
---
|
|
||||||
|
|
||||||
# Step 1B: Product Brief Continuation
|
|
||||||
|
|
||||||
## STEP GOAL:
|
|
||||||
|
|
||||||
Resume the product brief workflow from where it was left off, ensuring smooth continuation with full context restoration.
|
|
||||||
|
|
||||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
|
||||||
|
|
||||||
### Universal Rules:
|
|
||||||
|
|
||||||
- 🛑 NEVER generate content without user input
|
|
||||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
|
||||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
|
||||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
|
||||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
|
||||||
|
|
||||||
### Role Reinforcement:
|
|
||||||
|
|
||||||
- ✅ You are a product-focused Business Analyst facilitator
|
|
||||||
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
|
||||||
- ✅ We engage in collaborative dialogue, not command-response
|
|
||||||
- ✅ You bring structured thinking and facilitation skills, while the user brings domain expertise and product vision
|
|
||||||
- ✅ Maintain collaborative continuation tone throughout
|
|
||||||
|
|
||||||
### Step-Specific Rules:
|
|
||||||
|
|
||||||
- 🎯 Focus only on understanding where we left off and continuing appropriately
|
|
||||||
- 🚫 FORBIDDEN to modify content completed in previous steps
|
|
||||||
- 💬 Approach: Systematic state analysis with clear progress reporting
|
|
||||||
- 📋 Resume workflow from exact point where it was interrupted
|
|
||||||
|
|
||||||
## EXECUTION PROTOCOLS:
|
|
||||||
|
|
||||||
- 🎯 Show your analysis of current state before taking any action
|
|
||||||
- 💾 Keep existing frontmatter `stepsCompleted` values
|
|
||||||
- 📖 Only load documents that were already tracked in `inputDocuments`
|
|
||||||
- 🚫 FORBIDDEN to discover new input documents during continuation
|
|
||||||
|
|
||||||
## CONTEXT BOUNDARIES:
|
|
||||||
|
|
||||||
- Available context: Current document and frontmatter are already loaded
|
|
||||||
- Focus: Workflow state analysis and continuation logic only
|
|
||||||
- Limits: Don't assume knowledge beyond what's in the document
|
|
||||||
- Dependencies: Existing workflow state from previous session
|
|
||||||
|
|
||||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
|
||||||
|
|
||||||
### 1. Analyze Current State
|
|
||||||
|
|
||||||
**State Assessment:**
|
|
||||||
Review the frontmatter to understand:
|
|
||||||
|
|
||||||
- `stepsCompleted`: Which steps are already done
|
|
||||||
- `lastStep`: The most recently completed step number
|
|
||||||
- `inputDocuments`: What context was already loaded
|
|
||||||
- All other frontmatter variables
|
|
||||||
|
|
||||||
### 2. Restore Context Documents
|
|
||||||
|
|
||||||
**Context Reloading:**
|
|
||||||
|
|
||||||
- For each document in `inputDocuments`, load the complete file
|
|
||||||
- This ensures you have full context for continuation
|
|
||||||
- Don't discover new documents - only reload what was previously processed
|
|
||||||
- Maintain the same context as when workflow was interrupted
|
|
||||||
|
|
||||||
### 3. Present Current Progress
|
|
||||||
|
|
||||||
**Progress Report to User:**
|
|
||||||
"Welcome back {{user_name}}! I'm resuming our product brief collaboration for {{project_name}}.
|
|
||||||
|
|
||||||
**Current Progress:**
|
|
||||||
|
|
||||||
- Steps completed: {stepsCompleted}
|
|
||||||
- Last worked on: Step {lastStep}
|
|
||||||
- Context documents available: {len(inputDocuments)} files
|
|
||||||
|
|
||||||
**Document Status:**
|
|
||||||
|
|
||||||
- Current product brief is ready with all completed sections
|
|
||||||
- Ready to continue from where we left off
|
|
||||||
|
|
||||||
Does this look right, or do you want to make any adjustments before we proceed?"
|
|
||||||
|
|
||||||
### 4. Determine Continuation Path
|
|
||||||
|
|
||||||
**Next Step Logic:**
|
|
||||||
Based on `lastStep` value, determine which step to load next:
|
|
||||||
|
|
||||||
- If `lastStep = 1` → Load `./step-02-vision.md`
|
|
||||||
- If `lastStep = 2` → Load `./step-03-users.md`
|
|
||||||
- If `lastStep = 3` → Load `./step-04-metrics.md`
|
|
||||||
- Continue this pattern for all steps
|
|
||||||
- If `lastStep = 6` → Workflow already complete
|
|
||||||
|
|
||||||
### 5. Handle Workflow Completion
|
|
||||||
|
|
||||||
**If workflow already complete (`lastStep = 6`):**
|
|
||||||
"Great news! It looks like we've already completed the product brief workflow for {{project_name}}.
|
|
||||||
|
|
||||||
The final document is ready at `{outputFile}` with all sections completed through step 6.
|
|
||||||
|
|
||||||
Would you like me to:
|
|
||||||
|
|
||||||
- Review the completed product brief with you
|
|
||||||
- Suggest next workflow steps (like PRD creation)
|
|
||||||
- Start a new product brief revision
|
|
||||||
|
|
||||||
What would be most helpful?"
|
|
||||||
|
|
||||||
### 6. Present MENU OPTIONS
|
|
||||||
|
|
||||||
**If workflow not complete:**
|
|
||||||
Display: "Ready to continue with Step {nextStepNumber}: {nextStepTitle}?
|
|
||||||
|
|
||||||
**Select an Option:** [C] Continue to Step {nextStepNumber}"
|
|
||||||
|
|
||||||
#### Menu Handling Logic:
|
|
||||||
|
|
||||||
- IF C: Read fully and follow the appropriate next step file based on `lastStep`
|
|
||||||
- IF Any other comments or queries: respond and redisplay menu
|
|
||||||
|
|
||||||
#### EXECUTION RULES:
|
|
||||||
|
|
||||||
- ALWAYS halt and wait for user input after presenting menu
|
|
||||||
- ONLY proceed to next step when user selects 'C'
|
|
||||||
- User can chat or ask questions about current progress
|
|
||||||
|
|
||||||
## CRITICAL STEP COMPLETION NOTE
|
|
||||||
|
|
||||||
ONLY WHEN [C continue option] is selected and [current state confirmed], will you then read fully and follow the appropriate next step file to resume the workflow.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
|
||||||
|
|
||||||
### ✅ SUCCESS:
|
|
||||||
|
|
||||||
- All previous input documents successfully reloaded
|
|
||||||
- Current workflow state accurately analyzed and presented
|
|
||||||
- User confirms understanding of progress before continuation
|
|
||||||
- Correct next step identified and prepared for loading
|
|
||||||
- Proper continuation path determined based on `lastStep`
|
|
||||||
|
|
||||||
### ❌ SYSTEM FAILURE:
|
|
||||||
|
|
||||||
- Discovering new input documents instead of reloading existing ones
|
|
||||||
- Modifying content from already completed steps
|
|
||||||
- Loading wrong next step based on `lastStep` value
|
|
||||||
- Proceeding without user confirmation of current state
|
|
||||||
- Not maintaining context consistency from previous session
|
|
||||||
|
|
||||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
|
||||||
|
|
@ -1,193 +0,0 @@
|
||||||
---
|
|
||||||
# File References
|
|
||||||
outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md'
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# Step 2: Product Vision Discovery
|
|
||||||
|
|
||||||
## STEP GOAL:
|
|
||||||
|
|
||||||
Conduct comprehensive product vision discovery to define the core problem, solution, and unique value proposition through collaborative analysis.
|
|
||||||
|
|
||||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
|
||||||
|
|
||||||
### Universal Rules:
|
|
||||||
|
|
||||||
- 🛑 NEVER generate content without user input
|
|
||||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
|
||||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
|
||||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
|
||||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
|
||||||
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
|
|
||||||
|
|
||||||
### Role Reinforcement:
|
|
||||||
|
|
||||||
- ✅ You are a product-focused Business Analyst facilitator
|
|
||||||
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
|
||||||
- ✅ We engage in collaborative dialogue, not command-response
|
|
||||||
- ✅ You bring structured thinking and facilitation skills, while the user brings domain expertise and product vision
|
|
||||||
- ✅ Maintain collaborative discovery tone throughout
|
|
||||||
|
|
||||||
### Step-Specific Rules:
|
|
||||||
|
|
||||||
- 🎯 Focus only on product vision, problem, and solution discovery
|
|
||||||
- 🚫 FORBIDDEN to generate vision without real user input and collaboration
|
|
||||||
- 💬 Approach: Systematic discovery from problem to solution
|
|
||||||
- 📋 COLLABORATIVE discovery, not assumption-based vision crafting
|
|
||||||
|
|
||||||
## EXECUTION PROTOCOLS:
|
|
||||||
|
|
||||||
- 🎯 Show your analysis before taking any action
|
|
||||||
- 💾 Generate vision content collaboratively with user
|
|
||||||
- 📖 Update frontmatter `stepsCompleted: [1, 2]` before loading next step
|
|
||||||
- 🚫 FORBIDDEN to proceed without user confirmation through menu
|
|
||||||
|
|
||||||
## CONTEXT BOUNDARIES:
|
|
||||||
|
|
||||||
- Available context: Current document and frontmatter from step 1, input documents already loaded in memory
|
|
||||||
- Focus: This will be the first content section appended to the document
|
|
||||||
- Limits: Focus on clear, compelling product vision and problem statement
|
|
||||||
- Dependencies: Document initialization from step-01 must be complete
|
|
||||||
|
|
||||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
|
||||||
|
|
||||||
### 1. Begin Vision Discovery
|
|
||||||
|
|
||||||
**Opening Conversation:**
|
|
||||||
"As your PM peer, I'm excited to help you shape the vision for {{project_name}}. Let's start with the foundation.
|
|
||||||
|
|
||||||
**Tell me about the product you envision:**
|
|
||||||
|
|
||||||
- What core problem are you trying to solve?
|
|
||||||
- Who experiences this problem most acutely?
|
|
||||||
- What would success look like for the people you're helping?
|
|
||||||
- What excites you most about this solution?
|
|
||||||
|
|
||||||
Let's start with the problem space before we get into solutions."
|
|
||||||
|
|
||||||
### 2. Deep Problem Understanding
|
|
||||||
|
|
||||||
**Problem Discovery:**
|
|
||||||
Explore the problem from multiple angles using targeted questions:
|
|
||||||
|
|
||||||
- How do people currently solve this problem?
|
|
||||||
- What's frustrating about current solutions?
|
|
||||||
- What happens if this problem goes unsolved?
|
|
||||||
- Who feels this pain most intensely?
|
|
||||||
|
|
||||||
### 3. Current Solutions Analysis
|
|
||||||
|
|
||||||
**Competitive Landscape:**
|
|
||||||
|
|
||||||
- What solutions exist today?
|
|
||||||
- Where do they fall short?
|
|
||||||
- What gaps are they leaving open?
|
|
||||||
- Why haven't existing solutions solved this completely?
|
|
||||||
|
|
||||||
### 4. Solution Vision
|
|
||||||
|
|
||||||
**Collaborative Solution Crafting:**
|
|
||||||
|
|
||||||
- If we could solve this perfectly, what would that look like?
|
|
||||||
- What's the simplest way we could make a meaningful difference?
|
|
||||||
- What makes your approach different from what's out there?
|
|
||||||
- What would make users say 'this is exactly what I needed'?
|
|
||||||
|
|
||||||
### 5. Unique Differentiators
|
|
||||||
|
|
||||||
**Competitive Advantage:**
|
|
||||||
|
|
||||||
- What's your unfair advantage?
|
|
||||||
- What would be hard for competitors to copy?
|
|
||||||
- What insight or approach is uniquely yours?
|
|
||||||
- Why is now the right time for this solution?
|
|
||||||
|
|
||||||
### 6. Generate Executive Summary Content
|
|
||||||
|
|
||||||
**Content to Append:**
|
|
||||||
Prepare the following structure for document append:
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
## Executive Summary
|
|
||||||
|
|
||||||
[Executive summary content based on conversation]
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Core Vision
|
|
||||||
|
|
||||||
### Problem Statement
|
|
||||||
|
|
||||||
[Problem statement content based on conversation]
|
|
||||||
|
|
||||||
### Problem Impact
|
|
||||||
|
|
||||||
[Problem impact content based on conversation]
|
|
||||||
|
|
||||||
### Why Existing Solutions Fall Short
|
|
||||||
|
|
||||||
[Analysis of existing solution gaps based on conversation]
|
|
||||||
|
|
||||||
### Proposed Solution
|
|
||||||
|
|
||||||
[Proposed solution description based on conversation]
|
|
||||||
|
|
||||||
### Key Differentiators
|
|
||||||
|
|
||||||
[Key differentiators based on conversation]
|
|
||||||
```
|
|
||||||
|
|
||||||
### 7. Present MENU OPTIONS
|
|
||||||
|
|
||||||
**Content Presentation:**
|
|
||||||
"I've drafted the executive summary and core vision based on our conversation. This captures the essence of {{project_name}} and what makes it special.
|
|
||||||
|
|
||||||
**Here's what I'll add to the document:**
|
|
||||||
[Show the complete markdown content from step 6]
|
|
||||||
|
|
||||||
**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
|
|
||||||
|
|
||||||
#### Menu Handling Logic:
|
|
||||||
|
|
||||||
- IF A: Invoke the `bmad-advanced-elicitation` skill with current vision content to dive deeper and refine
|
|
||||||
- IF P: Invoke the `bmad-party-mode` skill to bring different perspectives to positioning and differentiation
|
|
||||||
- IF C: Save content to {outputFile}, update frontmatter with stepsCompleted: [1, 2], then read fully and follow: ./step-03-users.md
|
|
||||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#7-present-menu-options)
|
|
||||||
|
|
||||||
#### EXECUTION RULES:
|
|
||||||
|
|
||||||
- ALWAYS halt and wait for user input after presenting menu
|
|
||||||
- ONLY proceed to next step when user selects 'C'
|
|
||||||
- After other menu items execution, return to this menu with updated content
|
|
||||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
|
||||||
|
|
||||||
## CRITICAL STEP COMPLETION NOTE
|
|
||||||
|
|
||||||
ONLY WHEN [C continue option] is selected and [vision content finalized and saved to document with frontmatter updated], will you then read fully and follow: `./step-03-users.md` to begin target user discovery.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
|
||||||
|
|
||||||
### ✅ SUCCESS:
|
|
||||||
|
|
||||||
- Clear problem statement that resonates with target users
|
|
||||||
- Compelling solution vision that addresses the core problem
|
|
||||||
- Unique differentiators that provide competitive advantage
|
|
||||||
- Executive summary that captures the product essence
|
|
||||||
- A/P/C menu presented and handled correctly with proper task execution
|
|
||||||
- Content properly appended to document when C selected
|
|
||||||
- Frontmatter updated with stepsCompleted: [1, 2]
|
|
||||||
|
|
||||||
### ❌ SYSTEM FAILURE:
|
|
||||||
|
|
||||||
- Accepting vague problem statements without pushing for specificity
|
|
||||||
- Creating solution vision without fully understanding the problem
|
|
||||||
- Missing unique differentiators or competitive insights
|
|
||||||
- Generating vision without real user input and collaboration
|
|
||||||
- Not presenting standard A/P/C menu after content generation
|
|
||||||
- Appending content without user selecting 'C'
|
|
||||||
- Not updating frontmatter properly
|
|
||||||
|
|
||||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
|
||||||
|
|
@ -1,196 +0,0 @@
|
||||||
---
|
|
||||||
# File References
|
|
||||||
outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md'
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# Step 3: Target Users Discovery
|
|
||||||
|
|
||||||
## STEP GOAL:
|
|
||||||
|
|
||||||
Define target users with rich personas and map their key interactions with the product through collaborative user research and journey mapping.
|
|
||||||
|
|
||||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
|
||||||
|
|
||||||
### Universal Rules:
|
|
||||||
|
|
||||||
- 🛑 NEVER generate content without user input
|
|
||||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
|
||||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
|
||||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
|
||||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
|
||||||
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
|
|
||||||
|
|
||||||
### Role Reinforcement:
|
|
||||||
|
|
||||||
- ✅ You are a product-focused Business Analyst facilitator
|
|
||||||
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
|
||||||
- ✅ We engage in collaborative dialogue, not command-response
|
|
||||||
- ✅ You bring structured thinking and facilitation skills, while the user brings domain expertise and product vision
|
|
||||||
- ✅ Maintain collaborative discovery tone throughout
|
|
||||||
|
|
||||||
### Step-Specific Rules:
|
|
||||||
|
|
||||||
- 🎯 Focus only on defining who this product serves and how they interact with it
|
|
||||||
- 🚫 FORBIDDEN to create generic user profiles without specific details
|
|
||||||
- 💬 Approach: Systematic persona development with journey mapping
|
|
||||||
- 📋 COLLABORATIVE persona development, not assumption-based user creation
|
|
||||||
|
|
||||||
## EXECUTION PROTOCOLS:
|
|
||||||
|
|
||||||
- 🎯 Show your analysis before taking any action
|
|
||||||
- 💾 Generate user personas and journeys collaboratively with user
|
|
||||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3]` before loading next step
|
|
||||||
- 🚫 FORBIDDEN to proceed without user confirmation through menu
|
|
||||||
|
|
||||||
## CONTEXT BOUNDARIES:
|
|
||||||
|
|
||||||
- Available context: Current document and frontmatter from previous steps, product vision and problem already defined
|
|
||||||
- Focus: Creating vivid, actionable user personas that align with product vision
|
|
||||||
- Limits: Focus on users who directly experience the problem or benefit from the solution
|
|
||||||
- Dependencies: Product vision and problem statement from step-02 must be complete
|
|
||||||
|
|
||||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
|
||||||
|
|
||||||
### 1. Begin User Discovery
|
|
||||||
|
|
||||||
**Opening Exploration:**
|
|
||||||
"Now that we understand what {{project_name}} does, let's define who it's for.
|
|
||||||
|
|
||||||
**User Discovery:**
|
|
||||||
|
|
||||||
- Who experiences the problem we're solving?
|
|
||||||
- Are there different types of users with different needs?
|
|
||||||
- Who gets the most value from this solution?
|
|
||||||
- Are there primary users and secondary users we should consider?
|
|
||||||
|
|
||||||
Let's start by identifying the main user groups."
|
|
||||||
|
|
||||||
### 2. Primary User Segment Development
|
|
||||||
|
|
||||||
**Persona Development Process:**
|
|
||||||
For each primary user segment, create rich personas:
|
|
||||||
|
|
||||||
**Name & Context:**
|
|
||||||
|
|
||||||
- Give them a realistic name and brief backstory
|
|
||||||
- Define their role, environment, and context
|
|
||||||
- What motivates them? What are their goals?
|
|
||||||
|
|
||||||
**Problem Experience:**
|
|
||||||
|
|
||||||
- How do they currently experience the problem?
|
|
||||||
- What workarounds are they using?
|
|
||||||
- What are the emotional and practical impacts?
|
|
||||||
|
|
||||||
**Success Vision:**
|
|
||||||
|
|
||||||
- What would success look like for them?
|
|
||||||
- What would make them say "this is exactly what I needed"?
|
|
||||||
|
|
||||||
**Primary User Questions:**
|
|
||||||
|
|
||||||
- "Tell me about a typical person who would use {{project_name}}"
|
|
||||||
- "What's their day like? Where does our product fit in?"
|
|
||||||
- "What are they trying to accomplish that's hard right now?"
|
|
||||||
|
|
||||||
### 3. Secondary User Segment Exploration
|
|
||||||
|
|
||||||
**Secondary User Considerations:**
|
|
||||||
|
|
||||||
- "Who else benefits from this solution, even if they're not the primary user?"
|
|
||||||
- "Are there admin, support, or oversight roles we should consider?"
|
|
||||||
- "Who influences the decision to adopt or purchase this product?"
|
|
||||||
- "Are there partner or stakeholder users who matter?"
|
|
||||||
|
|
||||||
### 4. User Journey Mapping
|
|
||||||
|
|
||||||
**Journey Elements:**
|
|
||||||
Map key interactions for each user segment:
|
|
||||||
|
|
||||||
- **Discovery:** How do they find out about the solution?
|
|
||||||
- **Onboarding:** What's their first experience like?
|
|
||||||
- **Core Usage:** How do they use the product day-to-day?
|
|
||||||
- **Success Moment:** When do they realize the value?
|
|
||||||
- **Long-term:** How does it become part of their routine?
|
|
||||||
|
|
||||||
**Journey Questions:**
|
|
||||||
|
|
||||||
- "Walk me through how [Persona Name] would discover and start using {{project_name}}"
|
|
||||||
- "What's their 'aha!' moment?"
|
|
||||||
- "How does this product change how they work or live?"
|
|
||||||
|
|
||||||
### 5. Generate Target Users Content
|
|
||||||
|
|
||||||
**Content to Append:**
|
|
||||||
Prepare the following structure for document append:
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
## Target Users
|
|
||||||
|
|
||||||
### Primary Users
|
|
||||||
|
|
||||||
[Primary user segment content based on conversation]
|
|
||||||
|
|
||||||
### Secondary Users
|
|
||||||
|
|
||||||
[Secondary user segment content based on conversation, or N/A if not discussed]
|
|
||||||
|
|
||||||
### User Journey
|
|
||||||
|
|
||||||
[User journey content based on conversation, or N/A if not discussed]
|
|
||||||
```
|
|
||||||
|
|
||||||
### 6. Present MENU OPTIONS
|
|
||||||
|
|
||||||
**Content Presentation:**
|
|
||||||
"I've mapped out who {{project_name}} serves and how they'll interact with it. This helps us ensure we're building something that real people will love to use.
|
|
||||||
|
|
||||||
**Here's what I'll add to the document:**
|
|
||||||
[Show the complete markdown content from step 5]
|
|
||||||
|
|
||||||
**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
|
|
||||||
|
|
||||||
#### Menu Handling Logic:
|
|
||||||
|
|
||||||
- IF A: Invoke the `bmad-advanced-elicitation` skill with current user content to dive deeper into personas and journeys
|
|
||||||
- IF P: Invoke the `bmad-party-mode` skill to bring different perspectives to validate user understanding
|
|
||||||
- IF C: Save content to {outputFile}, update frontmatter with stepsCompleted: [1, 2, 3], then read fully and follow: ./step-04-metrics.md
|
|
||||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#6-present-menu-options)
|
|
||||||
|
|
||||||
#### EXECUTION RULES:
|
|
||||||
|
|
||||||
- ALWAYS halt and wait for user input after presenting menu
|
|
||||||
- ONLY proceed to next step when user selects 'C'
|
|
||||||
- After other menu items execution, return to this menu with updated content
|
|
||||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
|
||||||
|
|
||||||
## CRITICAL STEP COMPLETION NOTE
|
|
||||||
|
|
||||||
ONLY WHEN [C continue option] is selected and [user personas finalized and saved to document with frontmatter updated], will you then read fully and follow: `./step-04-metrics.md` to begin success metrics definition.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
|
||||||
|
|
||||||
### ✅ SUCCESS:
|
|
||||||
|
|
||||||
- Rich, believable user personas with clear motivations
|
|
||||||
- Clear distinction between primary and secondary users
|
|
||||||
- User journeys that show key interaction points and value creation
|
|
||||||
- User segments that align with product vision and problem statement
|
|
||||||
- A/P/C menu presented and handled correctly with proper task execution
|
|
||||||
- Content properly appended to document when C selected
|
|
||||||
- Frontmatter updated with stepsCompleted: [1, 2, 3]
|
|
||||||
|
|
||||||
### ❌ SYSTEM FAILURE:
|
|
||||||
|
|
||||||
- Creating generic user profiles without specific details
|
|
||||||
- Missing key user segments that are important to success
|
|
||||||
- User journeys that don't show how the product creates value
|
|
||||||
- Not connecting user needs back to the problem statement
|
|
||||||
- Not presenting standard A/P/C menu after content generation
|
|
||||||
- Appending content without user selecting 'C'
|
|
||||||
- Not updating frontmatter properly
|
|
||||||
|
|
||||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
|
||||||
|
|
@ -1,199 +0,0 @@
|
||||||
---
|
|
||||||
# File References
|
|
||||||
outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md'
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# Step 4: Success Metrics Definition
|
|
||||||
|
|
||||||
## STEP GOAL:
|
|
||||||
|
|
||||||
Define comprehensive success metrics that include user success, business objectives, and key performance indicators through collaborative metric definition aligned with product vision and user value.
|
|
||||||
|
|
||||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
|
||||||
|
|
||||||
### Universal Rules:
|
|
||||||
|
|
||||||
- 🛑 NEVER generate content without user input
|
|
||||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
|
||||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
|
||||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
|
||||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
|
||||||
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
|
|
||||||
|
|
||||||
### Role Reinforcement:
|
|
||||||
|
|
||||||
- ✅ You are a product-focused Business Analyst facilitator
|
|
||||||
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
|
||||||
- ✅ We engage in collaborative dialogue, not command-response
|
|
||||||
- ✅ You bring structured thinking and facilitation skills, while the user brings domain expertise and product vision
|
|
||||||
- ✅ Maintain collaborative discovery tone throughout
|
|
||||||
|
|
||||||
### Step-Specific Rules:
|
|
||||||
|
|
||||||
- 🎯 Focus only on defining measurable success criteria and business objectives
|
|
||||||
- 🚫 FORBIDDEN to create vague metrics that can't be measured or tracked
|
|
||||||
- 💬 Approach: Systematic metric definition that connects user value to business success
|
|
||||||
- 📋 COLLABORATIVE metric definition that drives actionable decisions
|
|
||||||
|
|
||||||
## EXECUTION PROTOCOLS:
|
|
||||||
|
|
||||||
- 🎯 Show your analysis before taking any action
|
|
||||||
- 💾 Generate success metrics collaboratively with user
|
|
||||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4]` before loading next step
|
|
||||||
- 🚫 FORBIDDEN to proceed without user confirmation through menu
|
|
||||||
|
|
||||||
## CONTEXT BOUNDARIES:
|
|
||||||
|
|
||||||
- Available context: Current document and frontmatter from previous steps, product vision and target users already defined
|
|
||||||
- Focus: Creating measurable, actionable success criteria that align with product strategy
|
|
||||||
- Limits: Focus on metrics that drive decisions and demonstrate real value creation
|
|
||||||
- Dependencies: Product vision and user personas from previous steps must be complete
|
|
||||||
|
|
||||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
|
||||||
|
|
||||||
### 1. Begin Success Metrics Discovery
|
|
||||||
|
|
||||||
**Opening Exploration:**
|
|
||||||
"Now that we know who {{project_name}} serves and what problem it solves, let's define what success looks like.
|
|
||||||
|
|
||||||
**Success Discovery:**
|
|
||||||
|
|
||||||
- How will we know we're succeeding for our users?
|
|
||||||
- What would make users say 'this was worth it'?
|
|
||||||
- What metrics show we're creating real value?
|
|
||||||
|
|
||||||
Let's start with the user perspective."
|
|
||||||
|
|
||||||
### 2. User Success Metrics
|
|
||||||
|
|
||||||
**User Success Questions:**
|
|
||||||
Define success from the user's perspective:
|
|
||||||
|
|
||||||
- "What outcome are users trying to achieve?"
|
|
||||||
- "How will they know the product is working for them?"
|
|
||||||
- "What's the moment where they realize this is solving their problem?"
|
|
||||||
- "What behaviors indicate users are getting value?"
|
|
||||||
|
|
||||||
**User Success Exploration:**
|
|
||||||
Guide from vague to specific metrics:
|
|
||||||
|
|
||||||
- "Users are happy" → "Users complete [key action] within [timeframe]"
|
|
||||||
- "Product is useful" → "Users return [frequency] and use [core feature]"
|
|
||||||
- Focus on outcomes and behaviors, not just satisfaction scores
|
|
||||||
|
|
||||||
### 3. Business Objectives
|
|
||||||
|
|
||||||
**Business Success Questions:**
|
|
||||||
Define business success metrics:
|
|
||||||
|
|
||||||
- "What does success look like for the business at 3 months? 12 months?"
|
|
||||||
- "Are we measuring revenue, user growth, engagement, something else?"
|
|
||||||
- "What business metrics would make you say 'this is working'?"
|
|
||||||
- "How does this product contribute to broader company goals?"
|
|
||||||
|
|
||||||
**Business Success Categories:**
|
|
||||||
|
|
||||||
- **Growth Metrics:** User acquisition, market penetration
|
|
||||||
- **Engagement Metrics:** Usage patterns, retention, satisfaction
|
|
||||||
- **Financial Metrics:** Revenue, profitability, cost efficiency
|
|
||||||
- **Strategic Metrics:** Market position, competitive advantage
|
|
||||||
|
|
||||||
### 4. Key Performance Indicators
|
|
||||||
|
|
||||||
**KPI Development Process:**
|
|
||||||
Define specific, measurable KPIs:
|
|
||||||
|
|
||||||
- Transform objectives into measurable indicators
|
|
||||||
- Ensure each KPI has a clear measurement method
|
|
||||||
- Define targets and timeframes where appropriate
|
|
||||||
- Include leading indicators that predict success
|
|
||||||
|
|
||||||
**KPI Examples:**
|
|
||||||
|
|
||||||
- User acquisition: "X new users per month"
|
|
||||||
- Engagement: "Y% of users complete core journey weekly"
|
|
||||||
- Business impact: "$Z in cost savings or revenue generation"
|
|
||||||
|
|
||||||
### 5. Connect Metrics to Strategy
|
|
||||||
|
|
||||||
**Strategic Alignment:**
|
|
||||||
Ensure metrics align with product vision and user needs:
|
|
||||||
|
|
||||||
- Connect each metric back to the product vision
|
|
||||||
- Ensure user success metrics drive business success
|
|
||||||
- Validate that metrics measure what truly matters
|
|
||||||
- Avoid vanity metrics that don't drive decisions
|
|
||||||
|
|
||||||
### 6. Generate Success Metrics Content
|
|
||||||
|
|
||||||
**Content to Append:**
|
|
||||||
Prepare the following structure for document append:
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
## Success Metrics
|
|
||||||
|
|
||||||
[Success metrics content based on conversation]
|
|
||||||
|
|
||||||
### Business Objectives
|
|
||||||
|
|
||||||
[Business objectives content based on conversation, or N/A if not discussed]
|
|
||||||
|
|
||||||
### Key Performance Indicators
|
|
||||||
|
|
||||||
[Key performance indicators content based on conversation, or N/A if not discussed]
|
|
||||||
```
|
|
||||||
|
|
||||||
### 7. Present MENU OPTIONS
|
|
||||||
|
|
||||||
**Content Presentation:**
|
|
||||||
"I've defined success metrics that will help us track whether {{project_name}} is creating real value for users and achieving business objectives.
|
|
||||||
|
|
||||||
**Here's what I'll add to the document:**
|
|
||||||
[Show the complete markdown content from step 6]
|
|
||||||
|
|
||||||
**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
|
|
||||||
|
|
||||||
#### Menu Handling Logic:
|
|
||||||
|
|
||||||
- IF A: Invoke the `bmad-advanced-elicitation` skill with current metrics content to dive deeper into success metric insights
|
|
||||||
- IF P: Invoke the `bmad-party-mode` skill to bring different perspectives to validate comprehensive metrics
|
|
||||||
- IF C: Save content to {outputFile}, update frontmatter with stepsCompleted: [1, 2, 3, 4], then read fully and follow: ./step-05-scope.md
|
|
||||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#7-present-menu-options)
|
|
||||||
|
|
||||||
#### EXECUTION RULES:
|
|
||||||
|
|
||||||
- ALWAYS halt and wait for user input after presenting menu
|
|
||||||
- ONLY proceed to next step when user selects 'C'
|
|
||||||
- After other menu items execution, return to this menu with updated content
|
|
||||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
|
||||||
|
|
||||||
## CRITICAL STEP COMPLETION NOTE
|
|
||||||
|
|
||||||
ONLY WHEN [C continue option] is selected and [success metrics finalized and saved to document with frontmatter updated], will you then read fully and follow: `./step-05-scope.md` to begin MVP scope definition.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
|
||||||
|
|
||||||
### ✅ SUCCESS:
|
|
||||||
|
|
||||||
- User success metrics that focus on outcomes and behaviors
|
|
||||||
- Clear business objectives aligned with product strategy
|
|
||||||
- Specific, measurable KPIs with defined targets and timeframes
|
|
||||||
- Metrics that connect user value to business success
|
|
||||||
- A/P/C menu presented and handled correctly with proper task execution
|
|
||||||
- Content properly appended to document when C selected
|
|
||||||
- Frontmatter updated with stepsCompleted: [1, 2, 3, 4]
|
|
||||||
|
|
||||||
### ❌ SYSTEM FAILURE:
|
|
||||||
|
|
||||||
- Vague success metrics that can't be measured or tracked
|
|
||||||
- Business objectives disconnected from user success
|
|
||||||
- Too many metrics or missing critical success indicators
|
|
||||||
- Metrics that don't drive actionable decisions
|
|
||||||
- Not presenting standard A/P/C menu after content generation
|
|
||||||
- Appending content without user selecting 'C'
|
|
||||||
- Not updating frontmatter properly
|
|
||||||
|
|
||||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
|
||||||
|
|
@ -1,213 +0,0 @@
|
||||||
---
|
|
||||||
# File References
|
|
||||||
outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md'
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# Step 5: MVP Scope Definition
|
|
||||||
|
|
||||||
## STEP GOAL:
|
|
||||||
|
|
||||||
Define MVP scope with clear boundaries and outline future vision through collaborative scope negotiation that balances ambition with realism.
|
|
||||||
|
|
||||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
|
||||||
|
|
||||||
### Universal Rules:
|
|
||||||
|
|
||||||
- 🛑 NEVER generate content without user input
|
|
||||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
|
||||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
|
||||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
|
||||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
|
||||||
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
|
|
||||||
|
|
||||||
### Role Reinforcement:
|
|
||||||
|
|
||||||
- ✅ You are a product-focused Business Analyst facilitator
|
|
||||||
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
|
||||||
- ✅ We engage in collaborative dialogue, not command-response
|
|
||||||
- ✅ You bring structured thinking and facilitation skills, while the user brings domain expertise and product vision
|
|
||||||
- ✅ Maintain collaborative discovery tone throughout
|
|
||||||
|
|
||||||
### Step-Specific Rules:
|
|
||||||
|
|
||||||
- 🎯 Focus only on defining minimum viable scope and future vision
|
|
||||||
- 🚫 FORBIDDEN to create MVP scope that's too large or includes non-essential features
|
|
||||||
- 💬 Approach: Systematic scope negotiation with clear boundary setting
|
|
||||||
- 📋 COLLABORATIVE scope definition that prevents scope creep
|
|
||||||
|
|
||||||
## EXECUTION PROTOCOLS:
|
|
||||||
|
|
||||||
- 🎯 Show your analysis before taking any action
|
|
||||||
- 💾 Generate MVP scope collaboratively with user
|
|
||||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5]` before loading next step
|
|
||||||
- 🚫 FORBIDDEN to proceed without user confirmation through menu
|
|
||||||
|
|
||||||
## CONTEXT BOUNDARIES:
|
|
||||||
|
|
||||||
- Available context: Current document and frontmatter from previous steps, product vision, users, and success metrics already defined
|
|
||||||
- Focus: Defining what's essential for MVP vs. future enhancements
|
|
||||||
- Limits: Balance user needs with implementation feasibility
|
|
||||||
- Dependencies: Product vision, user personas, and success metrics from previous steps must be complete
|
|
||||||
|
|
||||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
|
||||||
|
|
||||||
### 1. Begin Scope Definition
|
|
||||||
|
|
||||||
**Opening Exploration:**
|
|
||||||
"Now that we understand what {{project_name}} does, who it serves, and how we'll measure success, let's define what we need to build first.
|
|
||||||
|
|
||||||
**Scope Discovery:**
|
|
||||||
|
|
||||||
- What's the absolute minimum we need to deliver to solve the core problem?
|
|
||||||
- What features would make users say 'this solves my problem'?
|
|
||||||
- How do we balance ambition with getting something valuable to users quickly?
|
|
||||||
|
|
||||||
Let's start with the MVP mindset: what's the smallest version that creates real value?"
|
|
||||||
|
|
||||||
### 2. MVP Core Features Definition
|
|
||||||
|
|
||||||
**MVP Feature Questions:**
|
|
||||||
Define essential features for minimum viable product:
|
|
||||||
|
|
||||||
- "What's the core functionality that must work?"
|
|
||||||
- "Which features directly address the main problem we're solving?"
|
|
||||||
- "What would users consider 'incomplete' if it was missing?"
|
|
||||||
- "What features create the 'aha!' moment we discussed earlier?"
|
|
||||||
|
|
||||||
**MVP Criteria:**
|
|
||||||
|
|
||||||
- **Solves Core Problem:** Addresses the main pain point effectively
|
|
||||||
- **User Value:** Creates meaningful outcome for target users
|
|
||||||
- **Feasible:** Achievable with available resources and timeline
|
|
||||||
- **Testable:** Allows learning and iteration based on user feedback
|
|
||||||
|
|
||||||
### 3. Out of Scope Boundaries
|
|
||||||
|
|
||||||
**Out of Scope Exploration:**
|
|
||||||
Define what explicitly won't be in MVP:
|
|
||||||
|
|
||||||
- "What features would be nice to have but aren't essential?"
|
|
||||||
- "What functionality could wait for version 2.0?"
|
|
||||||
- "What are we intentionally saying 'no' to for now?"
|
|
||||||
- "How do we communicate these boundaries to stakeholders?"
|
|
||||||
|
|
||||||
**Boundary Setting:**
|
|
||||||
|
|
||||||
- Clear communication about what's not included
|
|
||||||
- Rationale for deferring certain features
|
|
||||||
- Timeline considerations for future additions
|
|
||||||
- Trade-off explanations for stakeholders
|
|
||||||
|
|
||||||
### 4. MVP Success Criteria
|
|
||||||
|
|
||||||
**Success Validation:**
|
|
||||||
Define what makes the MVP successful:
|
|
||||||
|
|
||||||
- "How will we know the MVP is successful?"
|
|
||||||
- "What metrics will indicate we should proceed beyond MVP?"
|
|
||||||
- "What user feedback signals validate our approach?"
|
|
||||||
- "What's the decision point for scaling beyond MVP?"
|
|
||||||
|
|
||||||
**Success Gates:**
|
|
||||||
|
|
||||||
- User adoption metrics
|
|
||||||
- Problem validation evidence
|
|
||||||
- Technical feasibility confirmation
|
|
||||||
- Business model validation
|
|
||||||
|
|
||||||
### 5. Future Vision Exploration
|
|
||||||
|
|
||||||
**Vision Questions:**
|
|
||||||
Define the longer-term product vision:
|
|
||||||
|
|
||||||
- "If this is wildly successful, what does it become in 2-3 years?"
|
|
||||||
- "What capabilities would we add with more resources?"
|
|
||||||
- "How does the MVP evolve into the full product vision?"
|
|
||||||
- "What markets or user segments could we expand to?"
|
|
||||||
|
|
||||||
**Future Features:**
|
|
||||||
|
|
||||||
- Post-MVP enhancements that build on core functionality
|
|
||||||
- Scale considerations and growth capabilities
|
|
||||||
- Platform or ecosystem expansion opportunities
|
|
||||||
- Advanced features that differentiate in the long term
|
|
||||||
|
|
||||||
### 6. Generate MVP Scope Content
|
|
||||||
|
|
||||||
**Content to Append:**
|
|
||||||
Prepare the following structure for document append:
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
## MVP Scope
|
|
||||||
|
|
||||||
### Core Features
|
|
||||||
|
|
||||||
[Core features content based on conversation]
|
|
||||||
|
|
||||||
### Out of Scope for MVP
|
|
||||||
|
|
||||||
[Out of scope content based on conversation, or N/A if not discussed]
|
|
||||||
|
|
||||||
### MVP Success Criteria
|
|
||||||
|
|
||||||
[MVP success criteria content based on conversation, or N/A if not discussed]
|
|
||||||
|
|
||||||
### Future Vision
|
|
||||||
|
|
||||||
[Future vision content based on conversation, or N/A if not discussed]
|
|
||||||
```
|
|
||||||
|
|
||||||
### 7. Present MENU OPTIONS
|
|
||||||
|
|
||||||
**Content Presentation:**
|
|
||||||
"I've defined the MVP scope for {{project_name}} that balances delivering real value with realistic boundaries. This gives us a clear path forward while keeping our options open for future growth.
|
|
||||||
|
|
||||||
**Here's what I'll add to the document:**
|
|
||||||
[Show the complete markdown content from step 6]
|
|
||||||
|
|
||||||
**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
|
|
||||||
|
|
||||||
#### Menu Handling Logic:
|
|
||||||
|
|
||||||
- IF A: Invoke the `bmad-advanced-elicitation` skill with current scope content to optimize scope definition
|
|
||||||
- IF P: Invoke the `bmad-party-mode` skill to bring different perspectives to validate MVP scope
|
|
||||||
- IF C: Save content to {outputFile}, update frontmatter with stepsCompleted: [1, 2, 3, 4, 5], then read fully and follow: ./step-06-complete.md
|
|
||||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#7-present-menu-options)
|
|
||||||
|
|
||||||
#### EXECUTION RULES:
|
|
||||||
|
|
||||||
- ALWAYS halt and wait for user input after presenting menu
|
|
||||||
- ONLY proceed to next step when user selects 'C'
|
|
||||||
- After other menu items execution, return to this menu with updated content
|
|
||||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
|
||||||
|
|
||||||
## CRITICAL STEP COMPLETION NOTE
|
|
||||||
|
|
||||||
ONLY WHEN [C continue option] is selected and [MVP scope finalized and saved to document with frontmatter updated], will you then read fully and follow: `./step-06-complete.md` to complete the product brief workflow.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
|
||||||
|
|
||||||
### ✅ SUCCESS:
|
|
||||||
|
|
||||||
- MVP features that solve the core problem effectively
|
|
||||||
- Clear out-of-scope boundaries that prevent scope creep
|
|
||||||
- Success criteria that validate MVP approach and inform go/no-go decisions
|
|
||||||
- Future vision that inspires while maintaining focus on MVP
|
|
||||||
- A/P/C menu presented and handled correctly with proper task execution
|
|
||||||
- Content properly appended to document when C selected
|
|
||||||
- Frontmatter updated with stepsCompleted: [1, 2, 3, 4, 5]
|
|
||||||
|
|
||||||
### ❌ SYSTEM FAILURE:
|
|
||||||
|
|
||||||
- MVP scope too large or includes non-essential features
|
|
||||||
- Missing clear boundaries leading to scope creep
|
|
||||||
- No success criteria to validate MVP approach
|
|
||||||
- Future vision disconnected from MVP foundation
|
|
||||||
- Not presenting standard A/P/C menu after content generation
|
|
||||||
- Appending content without user selecting 'C'
|
|
||||||
- Not updating frontmatter properly
|
|
||||||
|
|
||||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
|
||||||
|
|
@ -1,159 +0,0 @@
|
||||||
---
|
|
||||||
# File References
|
|
||||||
outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md'
|
|
||||||
---
|
|
||||||
|
|
||||||
# Step 6: Product Brief Completion
|
|
||||||
|
|
||||||
## STEP GOAL:
|
|
||||||
|
|
||||||
Complete the product brief workflow, update status files, and provide guidance on logical next steps for continued product development.
|
|
||||||
|
|
||||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
|
||||||
|
|
||||||
### Universal Rules:
|
|
||||||
|
|
||||||
- 🛑 NEVER generate content without user input
|
|
||||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
|
||||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
|
||||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
|
||||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
|
||||||
|
|
||||||
### Role Reinforcement:
|
|
||||||
|
|
||||||
- ✅ You are a product-focused Business Analyst facilitator
|
|
||||||
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
|
||||||
- ✅ We engage in collaborative dialogue, not command-response
|
|
||||||
- ✅ You bring structured thinking and facilitation skills, while the user brings domain expertise and product vision
|
|
||||||
- ✅ Maintain collaborative completion tone throughout
|
|
||||||
|
|
||||||
### Step-Specific Rules:
|
|
||||||
|
|
||||||
- 🎯 Focus only on completion, next steps, and project guidance
|
|
||||||
- 🚫 FORBIDDEN to generate new content for the product brief
|
|
||||||
- 💬 Approach: Systematic completion with quality validation and next step recommendations
|
|
||||||
- 📋 FINALIZE document and update workflow status appropriately
|
|
||||||
|
|
||||||
## EXECUTION PROTOCOLS:
|
|
||||||
|
|
||||||
- 🎯 Show your analysis before taking any action
|
|
||||||
- 💾 Update the main workflow status file with completion information
|
|
||||||
- 📖 Suggest potential next workflow steps for the user
|
|
||||||
- 🚫 DO NOT load additional steps after this one (this is final)
|
|
||||||
|
|
||||||
## CONTEXT BOUNDARIES:
|
|
||||||
|
|
||||||
- Available context: Complete product brief document from all previous steps, workflow frontmatter shows all completed steps
|
|
||||||
- Focus: Completion validation, status updates, and next step guidance
|
|
||||||
- Limits: No new content generation, only completion and wrap-up activities
|
|
||||||
- Dependencies: All previous steps must be completed with content saved to document
|
|
||||||
|
|
||||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
|
||||||
|
|
||||||
### 1. Announce Workflow Completion
|
|
||||||
|
|
||||||
**Completion Announcement:**
|
|
||||||
"🎉 **Product Brief Complete, {{user_name}}!**
|
|
||||||
|
|
||||||
I've successfully collaborated with you to create a comprehensive Product Brief for {{project_name}}.
|
|
||||||
|
|
||||||
**What we've accomplished:**
|
|
||||||
|
|
||||||
- ✅ Executive Summary with clear vision and problem statement
|
|
||||||
- ✅ Core Vision with solution definition and unique differentiators
|
|
||||||
- ✅ Target Users with rich personas and user journeys
|
|
||||||
- ✅ Success Metrics with measurable outcomes and business objectives
|
|
||||||
- ✅ MVP Scope with focused feature set and clear boundaries
|
|
||||||
- ✅ Future Vision that inspires while maintaining current focus
|
|
||||||
|
|
||||||
**The complete Product Brief is now available at:** `{outputFile}`
|
|
||||||
|
|
||||||
This brief serves as the foundation for all subsequent product development activities and strategic decisions."
|
|
||||||
|
|
||||||
### 2. Document Quality Check
|
|
||||||
|
|
||||||
**Completeness Validation:**
|
|
||||||
Perform final validation of the product brief:
|
|
||||||
|
|
||||||
- Does the executive summary clearly communicate the vision and problem?
|
|
||||||
- Are target users well-defined with compelling personas?
|
|
||||||
- Do success metrics connect user value to business objectives?
|
|
||||||
- Is MVP scope focused and realistic?
|
|
||||||
- Does the brief provide clear direction for next steps?
|
|
||||||
|
|
||||||
**Consistency Validation:**
|
|
||||||
|
|
||||||
- Do all sections align with the core problem statement?
|
|
||||||
- Is user value consistently emphasized throughout?
|
|
||||||
- Are success criteria traceable to user needs and business goals?
|
|
||||||
- Does MVP scope align with the problem and solution?
|
|
||||||
|
|
||||||
### 3. Suggest Next Steps
|
|
||||||
|
|
||||||
**Recommended Next Workflow:**
|
|
||||||
Provide guidance on logical next workflows:
|
|
||||||
|
|
||||||
1. `create-prd` - Create detailed Product Requirements Document
|
|
||||||
- Brief provides foundation for detailed requirements
|
|
||||||
- User personas inform journey mapping
|
|
||||||
- Success metrics become specific acceptance criteria
|
|
||||||
- MVP scope becomes detailed feature specifications
|
|
||||||
|
|
||||||
**Other Potential Next Steps:**
|
|
||||||
|
|
||||||
1. `create-ux-design` - UX research and design (can run parallel with PRD)
|
|
||||||
2. `domain-research` - Deep market or domain research (if needed)
|
|
||||||
|
|
||||||
**Strategic Considerations:**
|
|
||||||
|
|
||||||
- The PRD workflow builds directly on this brief for detailed planning
|
|
||||||
- Consider team capacity and immediate priorities
|
|
||||||
- Use brief to validate concept before committing to detailed work
|
|
||||||
- Brief can guide early technical feasibility discussions
|
|
||||||
|
|
||||||
### 4. Congrats to the user
|
|
||||||
|
|
||||||
"**Your Product Brief for {{project_name}} is now complete and ready for the next phase!**"
|
|
||||||
|
|
||||||
Recap that the brief captures everything needed to guide subsequent product development:
|
|
||||||
|
|
||||||
- Clear vision and problem definition
|
|
||||||
- Deep understanding of target users
|
|
||||||
- Measurable success criteria
|
|
||||||
- Focused MVP scope with realistic boundaries
|
|
||||||
- Inspiring long-term vision
|
|
||||||
|
|
||||||
### 5. Suggest next steps
|
|
||||||
|
|
||||||
Product Brief complete. Invoke the `bmad-help` skill.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
|
||||||
|
|
||||||
### ✅ SUCCESS:
|
|
||||||
|
|
||||||
- Product brief contains all essential sections with collaborative content
|
|
||||||
- All collaborative content properly saved to document with proper frontmatter
|
|
||||||
- Workflow status file updated with completion information and timestamp
|
|
||||||
- Clear next step guidance provided to user with specific workflow recommendations
|
|
||||||
- Document quality validation completed with completeness and consistency checks
|
|
||||||
- User acknowledges completion and understands next available options
|
|
||||||
- Workflow properly marked as complete in status tracking
|
|
||||||
|
|
||||||
### ❌ SYSTEM FAILURE:
|
|
||||||
|
|
||||||
- Not updating workflow status file with completion information
|
|
||||||
- Missing clear next step guidance for user
|
|
||||||
- Not confirming document completeness with user
|
|
||||||
- Workflow not properly marked as complete in status tracking
|
|
||||||
- User unclear about what happens next or available options
|
|
||||||
- Document quality issues not identified or addressed
|
|
||||||
|
|
||||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
|
||||||
|
|
||||||
## FINAL WORKFLOW COMPLETION
|
|
||||||
|
|
||||||
This product brief is now complete and serves as the strategic foundation for the entire product lifecycle. All subsequent design, architecture, and development work should trace back to the vision, user needs, and success criteria documented in this brief.
|
|
||||||
|
|
||||||
**Congratulations on completing the Product Brief for {{project_name}}!** 🎉
|
|
||||||
|
|
@ -1,55 +0,0 @@
|
||||||
# Product Brief Workflow
|
|
||||||
|
|
||||||
**Goal:** Create comprehensive product briefs through collaborative step-by-step discovery as creative Business Analyst working with the user as peers.
|
|
||||||
|
|
||||||
**Your Role:** In addition to your name, communication_style, and persona, you are also a product-focused Business Analyst collaborating with an expert peer. This is a partnership, not a client-vendor relationship. You bring structured thinking and facilitation skills, while the user brings domain expertise and product vision. Work together as equals.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## WORKFLOW ARCHITECTURE
|
|
||||||
|
|
||||||
This uses **step-file architecture** for disciplined execution:
|
|
||||||
|
|
||||||
### Core Principles
|
|
||||||
|
|
||||||
- **Micro-file Design**: Each step is a self contained instruction file that is a part of an overall workflow that must be followed exactly
|
|
||||||
- **Just-In-Time Loading**: Only the current step file is in memory - never load future step files until told to do so
|
|
||||||
- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
|
|
||||||
- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
|
|
||||||
- **Append-Only Building**: Build documents by appending content as directed to the output file
|
|
||||||
|
|
||||||
### Step Processing Rules
|
|
||||||
|
|
||||||
1. **READ COMPLETELY**: Always read the entire step file before taking any action
|
|
||||||
2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
|
|
||||||
3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
|
|
||||||
4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
|
|
||||||
5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
|
|
||||||
6. **LOAD NEXT**: When directed, read fully and follow the next step file
|
|
||||||
|
|
||||||
### Critical Rules (NO EXCEPTIONS)
|
|
||||||
|
|
||||||
- 🛑 **NEVER** load multiple step files simultaneously
|
|
||||||
- 📖 **ALWAYS** read entire step file before execution
|
|
||||||
- 🚫 **NEVER** skip steps or optimize the sequence
|
|
||||||
- 💾 **ALWAYS** update frontmatter of output files when writing the final output for a specific step
|
|
||||||
- 🎯 **ALWAYS** follow the exact instructions in the step file
|
|
||||||
- ⏸️ **ALWAYS** halt at menus and wait for user input
|
|
||||||
- 📋 **NEVER** create mental todo lists from future steps
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## INITIALIZATION SEQUENCE
|
|
||||||
|
|
||||||
### 1. Configuration Loading
|
|
||||||
|
|
||||||
Load and read full config from {project-root}/_bmad/bmm/config.yaml and resolve:
|
|
||||||
|
|
||||||
- `project_name`, `output_folder`, `planning_artifacts`, `user_name`, `communication_language`, `document_output_language`, `user_skill_level`
|
|
||||||
|
|
||||||
✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the configured `{communication_language}`.
|
|
||||||
✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`.
|
|
||||||
|
|
||||||
### 2. First Step EXECUTION
|
|
||||||
|
|
||||||
Read fully and follow: `./steps/step-01-init.md` to begin the workflow.
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
type: skill
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
type: skill
|
|
||||||
|
|
@ -1,7 +1,6 @@
|
||||||
---
|
---
|
||||||
name: bmad-product-brief-preview
|
name: bmad-product-brief
|
||||||
description: Create or update product briefs through guided or autonomous discovery. Use when the user requests to 'create a product brief', 'help me create a project brief', or 'update my product brief'.
|
description: Create or update product briefs through guided or autonomous discovery. Use when the user requests to create or update a Product Brief.
|
||||||
argument-hint: "[optional --create, --edit, --optimize, --distillate, --inputs, --headless] [brief idea]"
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Create Product Brief
|
# Create Product Brief
|
||||||
|
|
@ -1,6 +1,6 @@
|
||||||
---
|
---
|
||||||
name: bmad-domain-research
|
name: bmad-domain-research
|
||||||
description: 'Conduct domain and industry research. Use when the user says "lets create a research report on [domain or industry]"'
|
description: 'Conduct domain and industry research. Use when the user says wants to do domain research for a topic or industry'
|
||||||
---
|
---
|
||||||
|
|
||||||
Follow the instructions in ./workflow.md.
|
Follow the instructions in ./workflow.md.
|
||||||
|
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
type: skill
|
|
||||||
|
|
@ -1,6 +1,6 @@
|
||||||
---
|
---
|
||||||
name: bmad-market-research
|
name: bmad-market-research
|
||||||
description: 'Conduct market research on competition and customers. Use when the user says "create a market research report about [business idea]".'
|
description: 'Conduct market research on competition and customers. Use when the user says they need market research'
|
||||||
---
|
---
|
||||||
|
|
||||||
Follow the instructions in ./workflow.md.
|
Follow the instructions in ./workflow.md.
|
||||||
|
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
type: skill
|
|
||||||
|
|
@ -1,6 +1,6 @@
|
||||||
---
|
---
|
||||||
name: bmad-technical-research
|
name: bmad-technical-research
|
||||||
description: 'Conduct technical research on technologies and architecture. Use when the user says "create a technical research report on [topic]".'
|
description: 'Conduct technical research on technologies and architecture. Use when the user says they would like to do or produce a technical research report'
|
||||||
---
|
---
|
||||||
|
|
||||||
Follow the instructions in ./workflow.md.
|
Follow the instructions in ./workflow.md.
|
||||||
|
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
type: skill
|
|
||||||
|
|
@ -1,182 +0,0 @@
|
||||||
# Market Research Step 1: Market Research Initialization
|
|
||||||
|
|
||||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
|
||||||
|
|
||||||
- 🛑 NEVER generate research content in init step
|
|
||||||
- ✅ ALWAYS confirm understanding of user's research goals
|
|
||||||
- 📋 YOU ARE A MARKET RESEARCH FACILITATOR, not content generator
|
|
||||||
- 💬 FOCUS on clarifying scope and approach
|
|
||||||
- 🔍 NO WEB RESEARCH in init - that's for later steps
|
|
||||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete research
|
|
||||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
|
||||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
|
||||||
|
|
||||||
## EXECUTION PROTOCOLS:
|
|
||||||
|
|
||||||
- 🎯 Confirm research understanding before proceeding
|
|
||||||
- ⚠️ Present [C] continue option after scope clarification
|
|
||||||
- 💾 Write initial scope document immediately
|
|
||||||
- 📖 Update frontmatter `stepsCompleted: [1]` before loading next step
|
|
||||||
- 🚫 FORBIDDEN to load next step until C is selected
|
|
||||||
|
|
||||||
## CONTEXT BOUNDARIES:
|
|
||||||
|
|
||||||
- Current document and frontmatter from main workflow discovery are available
|
|
||||||
- Research type = "market" is already set
|
|
||||||
- **Research topic = "{{research_topic}}"** - discovered from initial discussion
|
|
||||||
- **Research goals = "{{research_goals}}"** - captured from initial discussion
|
|
||||||
- Focus on market research scope clarification
|
|
||||||
- Web search capabilities are enabled for later steps
|
|
||||||
|
|
||||||
## YOUR TASK:
|
|
||||||
|
|
||||||
Initialize market research by confirming understanding of {{research_topic}} and establishing clear research scope.
|
|
||||||
|
|
||||||
## MARKET RESEARCH INITIALIZATION:
|
|
||||||
|
|
||||||
### 1. Confirm Research Understanding
|
|
||||||
|
|
||||||
**INITIALIZE - DO NOT RESEARCH YET**
|
|
||||||
|
|
||||||
Start with research confirmation:
|
|
||||||
"I understand you want to conduct **market research** for **{{research_topic}}** with these goals: {{research_goals}}
|
|
||||||
|
|
||||||
**My Understanding of Your Research Needs:**
|
|
||||||
|
|
||||||
- **Research Topic**: {{research_topic}}
|
|
||||||
- **Research Goals**: {{research_goals}}
|
|
||||||
- **Research Type**: Market Research
|
|
||||||
- **Approach**: Comprehensive market analysis with source verification
|
|
||||||
|
|
||||||
**Market Research Areas We'll Cover:**
|
|
||||||
|
|
||||||
- Market size, growth dynamics, and trends
|
|
||||||
- Customer insights and behavior analysis
|
|
||||||
- Competitive landscape and positioning
|
|
||||||
- Strategic recommendations and implementation guidance
|
|
||||||
|
|
||||||
**Does this accurately capture what you're looking for?**"
|
|
||||||
|
|
||||||
### 2. Refine Research Scope
|
|
||||||
|
|
||||||
Gather any clarifications needed:
|
|
||||||
|
|
||||||
#### Scope Clarification Questions:
|
|
||||||
|
|
||||||
- "Are there specific customer segments or aspects of {{research_topic}} we should prioritize?"
|
|
||||||
- "Should we focus on specific geographic regions or global market?"
|
|
||||||
- "Is this for market entry, expansion, product development, or other business purpose?"
|
|
||||||
- "Any competitors or market segments you specifically want us to analyze?"
|
|
||||||
|
|
||||||
### 3. Document Initial Scope
|
|
||||||
|
|
||||||
**WRITE IMMEDIATELY TO DOCUMENT**
|
|
||||||
|
|
||||||
Write initial research scope to document:
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
# Market Research: {{research_topic}}
|
|
||||||
|
|
||||||
## Research Initialization
|
|
||||||
|
|
||||||
### Research Understanding Confirmed
|
|
||||||
|
|
||||||
**Topic**: {{research_topic}}
|
|
||||||
**Goals**: {{research_goals}}
|
|
||||||
**Research Type**: Market Research
|
|
||||||
**Date**: {{date}}
|
|
||||||
|
|
||||||
### Research Scope
|
|
||||||
|
|
||||||
**Market Analysis Focus Areas:**
|
|
||||||
|
|
||||||
- Market size, growth projections, and dynamics
|
|
||||||
- Customer segments, behavior patterns, and insights
|
|
||||||
- Competitive landscape and positioning analysis
|
|
||||||
- Strategic recommendations and implementation guidance
|
|
||||||
|
|
||||||
**Research Methodology:**
|
|
||||||
|
|
||||||
- Current web data with source verification
|
|
||||||
- Multiple independent sources for critical claims
|
|
||||||
- Confidence level assessment for uncertain data
|
|
||||||
- Comprehensive coverage with no critical gaps
|
|
||||||
|
|
||||||
### Next Steps
|
|
||||||
|
|
||||||
**Research Workflow:**
|
|
||||||
|
|
||||||
1. ✅ Initialization and scope setting (current step)
|
|
||||||
2. Customer Insights and Behavior Analysis
|
|
||||||
3. Competitive Landscape Analysis
|
|
||||||
4. Strategic Synthesis and Recommendations
|
|
||||||
|
|
||||||
**Research Status**: Scope confirmed, ready to proceed with detailed market analysis
|
|
||||||
```
|
|
||||||
|
|
||||||
### 4. Present Confirmation and Continue Option
|
|
||||||
|
|
||||||
Show initial scope document and present continue option:
|
|
||||||
"I've documented our understanding and initial scope for **{{research_topic}}** market research.
|
|
||||||
|
|
||||||
**What I've established:**
|
|
||||||
|
|
||||||
- Research topic and goals confirmed
|
|
||||||
- Market analysis focus areas defined
|
|
||||||
- Research methodology verification
|
|
||||||
- Clear workflow progression
|
|
||||||
|
|
||||||
**Document Status:** Initial scope written to research file for your review
|
|
||||||
|
|
||||||
**Ready to begin detailed market research?**
|
|
||||||
[C] Continue - Confirm scope and proceed to customer insights analysis
|
|
||||||
[Modify] Suggest changes to research scope before proceeding
|
|
||||||
|
|
||||||
### 5. Handle User Response
|
|
||||||
|
|
||||||
#### If 'C' (Continue):
|
|
||||||
|
|
||||||
- Update frontmatter: `stepsCompleted: [1]`
|
|
||||||
- Add confirmation note to document: "Scope confirmed by user on {{date}}"
|
|
||||||
- Load: `{project-root}/_bmad/bmm-skills/1-analysis/research/market-steps/step-02-customer-behavior.md`
|
|
||||||
|
|
||||||
#### If 'Modify':
|
|
||||||
|
|
||||||
- Gather user changes to scope
|
|
||||||
- Update document with modifications
|
|
||||||
- Re-present updated scope for confirmation
|
|
||||||
|
|
||||||
## SUCCESS METRICS:
|
|
||||||
|
|
||||||
✅ Research topic and goals accurately understood
|
|
||||||
✅ Market research scope clearly defined
|
|
||||||
✅ Initial scope document written immediately
|
|
||||||
✅ User opportunity to review and modify scope
|
|
||||||
✅ [C] continue option presented and handled correctly
|
|
||||||
✅ Document properly updated with scope confirmation
|
|
||||||
|
|
||||||
## FAILURE MODES:
|
|
||||||
|
|
||||||
❌ Not confirming understanding of research topic and goals
|
|
||||||
❌ Generating research content instead of just scope clarification
|
|
||||||
❌ Not writing initial scope document to file
|
|
||||||
❌ Not providing opportunity for user to modify scope
|
|
||||||
❌ Proceeding to next step without user confirmation
|
|
||||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor research decisions
|
|
||||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
|
||||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
|
||||||
|
|
||||||
## INITIALIZATION PRINCIPLES:
|
|
||||||
|
|
||||||
This step ensures:
|
|
||||||
|
|
||||||
- Clear mutual understanding of research objectives
|
|
||||||
- Well-defined research scope and approach
|
|
||||||
- Immediate documentation for user review
|
|
||||||
- User control over research direction before detailed work begins
|
|
||||||
|
|
||||||
## NEXT STEP:
|
|
||||||
|
|
||||||
After user confirmation and scope finalization, load `{project-root}/_bmad/bmm-skills/1-analysis/research/market-steps/step-02-customer-behavior.md` to begin detailed market research with customer insights analysis.
|
|
||||||
|
|
||||||
Remember: Init steps confirm understanding and scope, not generate research content!
|
|
||||||
|
|
@ -1,237 +0,0 @@
|
||||||
# Market Research Step 2: Customer Behavior and Segments
|
|
||||||
|
|
||||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
|
||||||
|
|
||||||
- 🛑 NEVER generate content without web search verification
|
|
||||||
- ✅ Search the web to verify and supplement your knowledge with current facts
|
|
||||||
- 📋 YOU ARE A CUSTOMER BEHAVIOR ANALYST, not content generator
|
|
||||||
- 💬 FOCUS on customer behavior patterns and demographic analysis
|
|
||||||
- 🔍 WEB SEARCH REQUIRED - verify current facts against live sources
|
|
||||||
- 📝 WRITE CONTENT IMMEDIATELY TO DOCUMENT
|
|
||||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete research
|
|
||||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
|
||||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
|
||||||
|
|
||||||
## EXECUTION PROTOCOLS:
|
|
||||||
|
|
||||||
- 🎯 Show web search analysis before presenting findings
|
|
||||||
- ⚠️ Present [C] continue option after customer behavior content generation
|
|
||||||
- 📝 WRITE CUSTOMER BEHAVIOR ANALYSIS TO DOCUMENT IMMEDIATELY
|
|
||||||
- 💾 ONLY proceed when user chooses C (Continue)
|
|
||||||
- 📖 Update frontmatter `stepsCompleted: [1, 2]` before loading next step
|
|
||||||
- 🚫 FORBIDDEN to load next step until C is selected
|
|
||||||
|
|
||||||
## CONTEXT BOUNDARIES:
|
|
||||||
|
|
||||||
- Current document and frontmatter from step-01 are available
|
|
||||||
- Focus on customer behavior patterns and demographic analysis
|
|
||||||
- Web search capabilities with source verification are enabled
|
|
||||||
- Previous step confirmed research scope and goals
|
|
||||||
- **Research topic = "{{research_topic}}"** - established from initial discussion
|
|
||||||
- **Research goals = "{{research_goals}}"** - established from initial discussion
|
|
||||||
|
|
||||||
## YOUR TASK:
|
|
||||||
|
|
||||||
Conduct customer behavior and segment analysis with emphasis on patterns and demographics.
|
|
||||||
|
|
||||||
## CUSTOMER BEHAVIOR ANALYSIS SEQUENCE:
|
|
||||||
|
|
||||||
### 1. Begin Customer Behavior Analysis
|
|
||||||
|
|
||||||
**UTILIZE SUBPROCESSES AND SUBAGENTS**: Use research subagents, subprocesses or parallel processing if available to thoroughly analyze different customer behavior areas simultaneously and thoroughly.
|
|
||||||
|
|
||||||
Start with customer behavior research approach:
|
|
||||||
"Now I'll conduct **customer behavior analysis** for **{{research_topic}}** to understand customer patterns.
|
|
||||||
|
|
||||||
**Customer Behavior Focus:**
|
|
||||||
|
|
||||||
- Customer behavior patterns and preferences
|
|
||||||
- Demographic profiles and segmentation
|
|
||||||
- Psychographic characteristics and values
|
|
||||||
- Behavior drivers and influences
|
|
||||||
- Customer interaction patterns and engagement
|
|
||||||
|
|
||||||
**Let me search for current customer behavior insights.**"
|
|
||||||
|
|
||||||
### 2. Parallel Customer Behavior Research Execution
|
|
||||||
|
|
||||||
**Execute multiple web searches simultaneously:**
|
|
||||||
|
|
||||||
Search the web: "{{research_topic}} customer behavior patterns"
|
|
||||||
Search the web: "{{research_topic}} customer demographics"
|
|
||||||
Search the web: "{{research_topic}} psychographic profiles"
|
|
||||||
Search the web: "{{research_topic}} customer behavior drivers"
|
|
||||||
|
|
||||||
**Analysis approach:**
|
|
||||||
|
|
||||||
- Look for customer behavior studies and research reports
|
|
||||||
- Search for demographic segmentation and analysis
|
|
||||||
- Research psychographic profiling and value systems
|
|
||||||
- Analyze behavior drivers and influencing factors
|
|
||||||
- Study customer interaction and engagement patterns
|
|
||||||
|
|
||||||
### 3. Analyze and Aggregate Results
|
|
||||||
|
|
||||||
**Collect and analyze findings from all parallel searches:**
|
|
||||||
|
|
||||||
"After executing comprehensive parallel web searches, let me analyze and aggregate customer behavior findings:
|
|
||||||
|
|
||||||
**Research Coverage:**
|
|
||||||
|
|
||||||
- Customer behavior patterns and preferences
|
|
||||||
- Demographic profiles and segmentation
|
|
||||||
- Psychographic characteristics and values
|
|
||||||
- Behavior drivers and influences
|
|
||||||
- Customer interaction patterns and engagement
|
|
||||||
|
|
||||||
**Cross-Behavior Analysis:**
|
|
||||||
[Identify patterns connecting demographics, psychographics, and behaviors]
|
|
||||||
|
|
||||||
**Quality Assessment:**
|
|
||||||
[Overall confidence levels and research gaps identified]"
|
|
||||||
|
|
||||||
### 4. Generate Customer Behavior Content
|
|
||||||
|
|
||||||
**WRITE IMMEDIATELY TO DOCUMENT**
|
|
||||||
|
|
||||||
Prepare customer behavior analysis with web search citations:
|
|
||||||
|
|
||||||
#### Content Structure:
|
|
||||||
|
|
||||||
When saving to document, append these Level 2 and Level 3 sections:
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
## Customer Behavior and Segments
|
|
||||||
|
|
||||||
### Customer Behavior Patterns
|
|
||||||
|
|
||||||
[Customer behavior patterns analysis with source citations]
|
|
||||||
_Behavior Drivers: [Key motivations and patterns from web search]_
|
|
||||||
_Interaction Preferences: [Customer engagement and interaction patterns]_
|
|
||||||
_Decision Habits: [How customers typically make decisions]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Demographic Segmentation
|
|
||||||
|
|
||||||
[Demographic analysis with source citations]
|
|
||||||
_Age Demographics: [Age groups and preferences]_
|
|
||||||
_Income Levels: [Income segments and purchasing behavior]_
|
|
||||||
_Geographic Distribution: [Regional/city differences]_
|
|
||||||
_Education Levels: [Education impact on behavior]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Psychographic Profiles
|
|
||||||
|
|
||||||
[Psychographic analysis with source citations]
|
|
||||||
_Values and Beliefs: [Core values driving customer behavior]_
|
|
||||||
_Lifestyle Preferences: [Lifestyle choices and behaviors]_
|
|
||||||
_Attitudes and Opinions: [Customer attitudes toward products/services]_
|
|
||||||
_Personality Traits: [Personality influences on behavior]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Customer Segment Profiles
|
|
||||||
|
|
||||||
[Detailed customer segment profiles with source citations]
|
|
||||||
_Segment 1: [Detailed profile including demographics, psychographics, behavior]_
|
|
||||||
_Segment 2: [Detailed profile including demographics, psychographics, behavior]_
|
|
||||||
_Segment 3: [Detailed profile including demographics, psychographics, behavior]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Behavior Drivers and Influences
|
|
||||||
|
|
||||||
[Behavior drivers analysis with source citations]
|
|
||||||
_Emotional Drivers: [Emotional factors influencing behavior]_
|
|
||||||
_Rational Drivers: [Logical decision factors]_
|
|
||||||
_Social Influences: [Social and peer influences]_
|
|
||||||
_Economic Influences: [Economic factors affecting behavior]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Customer Interaction Patterns
|
|
||||||
|
|
||||||
[Customer interaction analysis with source citations]
|
|
||||||
_Research and Discovery: [How customers find and research options]_
|
|
||||||
_Purchase Decision Process: [Steps in purchase decision making]_
|
|
||||||
_Post-Purchase Behavior: [After-purchase engagement patterns]_
|
|
||||||
_Loyalty and Retention: [Factors driving customer loyalty]_
|
|
||||||
_Source: [URL]_
|
|
||||||
```
|
|
||||||
|
|
||||||
### 5. Present Analysis and Continue Option
|
|
||||||
|
|
||||||
**Show analysis and present continue option:**
|
|
||||||
|
|
||||||
"I've completed **customer behavior analysis** for {{research_topic}}, focusing on customer patterns.
|
|
||||||
|
|
||||||
**Key Customer Behavior Findings:**
|
|
||||||
|
|
||||||
- Customer behavior patterns clearly identified with drivers
|
|
||||||
- Demographic segmentation thoroughly analyzed
|
|
||||||
- Psychographic profiles mapped and documented
|
|
||||||
- Customer interaction patterns captured
|
|
||||||
- Multiple sources verified for critical insights
|
|
||||||
|
|
||||||
**Ready to proceed to customer pain points?**
|
|
||||||
[C] Continue - Save this to document and proceed to pain points analysis
|
|
||||||
|
|
||||||
### 6. Handle Continue Selection
|
|
||||||
|
|
||||||
#### If 'C' (Continue):
|
|
||||||
|
|
||||||
- **CONTENT ALREADY WRITTEN TO DOCUMENT**
|
|
||||||
- Update frontmatter: `stepsCompleted: [1, 2]`
|
|
||||||
- Load: `{project-root}/_bmad/bmm-skills/1-analysis/research/market-steps/step-03-customer-pain-points.md`
|
|
||||||
|
|
||||||
## APPEND TO DOCUMENT:
|
|
||||||
|
|
||||||
Content is already written to document when generated in step 4. No additional append needed.
|
|
||||||
|
|
||||||
## SUCCESS METRICS:
|
|
||||||
|
|
||||||
✅ Customer behavior patterns identified with current citations
|
|
||||||
✅ Demographic segmentation thoroughly analyzed
|
|
||||||
✅ Psychographic profiles clearly documented
|
|
||||||
✅ Customer interaction patterns captured
|
|
||||||
✅ Multiple sources verified for critical insights
|
|
||||||
✅ Content written immediately to document
|
|
||||||
✅ [C] continue option presented and handled correctly
|
|
||||||
✅ Proper routing to next step (customer pain points)
|
|
||||||
✅ Research goals alignment maintained
|
|
||||||
|
|
||||||
## FAILURE MODES:
|
|
||||||
|
|
||||||
❌ Relying solely on training data without web verification for current facts
|
|
||||||
|
|
||||||
❌ Missing critical customer behavior patterns
|
|
||||||
❌ Incomplete demographic segmentation analysis
|
|
||||||
❌ Missing psychographic profile documentation
|
|
||||||
❌ Not writing content immediately to document
|
|
||||||
❌ Not presenting [C] continue option after content generation
|
|
||||||
❌ Not routing to customer pain points analysis step
|
|
||||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor research decisions
|
|
||||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
|
||||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
|
||||||
|
|
||||||
## CUSTOMER BEHAVIOR RESEARCH PROTOCOLS:
|
|
||||||
|
|
||||||
- Research customer behavior studies and market research
|
|
||||||
- Use demographic data from authoritative sources
|
|
||||||
- Research psychographic profiling and value systems
|
|
||||||
- Analyze customer interaction and engagement patterns
|
|
||||||
- Focus on current behavior data and trends
|
|
||||||
- Present conflicting information when sources disagree
|
|
||||||
- Apply confidence levels appropriately
|
|
||||||
|
|
||||||
## BEHAVIOR ANALYSIS STANDARDS:
|
|
||||||
|
|
||||||
- Always cite URLs for web search results
|
|
||||||
- Use authoritative customer research sources
|
|
||||||
- Note data currency and potential limitations
|
|
||||||
- Present multiple perspectives when sources conflict
|
|
||||||
- Apply confidence levels to uncertain data
|
|
||||||
- Focus on actionable customer insights
|
|
||||||
|
|
||||||
## NEXT STEP:
|
|
||||||
|
|
||||||
After user selects 'C', load `{project-root}/_bmad/bmm-skills/1-analysis/research/market-steps/step-03-customer-pain-points.md` to analyze customer pain points, challenges, and unmet needs for {{research_topic}}.
|
|
||||||
|
|
||||||
Remember: Always write research content to document immediately and emphasize current customer data with rigorous source verification!
|
|
||||||
|
|
@ -1,249 +0,0 @@
|
||||||
# Market Research Step 3: Customer Pain Points and Needs
|
|
||||||
|
|
||||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
|
||||||
|
|
||||||
- 🛑 NEVER generate content without web search verification
|
|
||||||
|
|
||||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
|
||||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
|
||||||
- ✅ Search the web to verify and supplement your knowledge with current facts
|
|
||||||
- 📋 YOU ARE A CUSTOMER NEEDS ANALYST, not content generator
|
|
||||||
- 💬 FOCUS on customer pain points, challenges, and unmet needs
|
|
||||||
- 🔍 WEB SEARCH REQUIRED - verify current facts against live sources
|
|
||||||
- 📝 WRITE CONTENT IMMEDIATELY TO DOCUMENT
|
|
||||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
|
||||||
|
|
||||||
## EXECUTION PROTOCOLS:
|
|
||||||
|
|
||||||
- 🎯 Show web search analysis before presenting findings
|
|
||||||
- ⚠️ Present [C] continue option after pain points content generation
|
|
||||||
- 📝 WRITE CUSTOMER PAIN POINTS ANALYSIS TO DOCUMENT IMMEDIATELY
|
|
||||||
- 💾 ONLY proceed when user chooses C (Continue)
|
|
||||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3]` before loading next step
|
|
||||||
- 🚫 FORBIDDEN to load next step until C is selected
|
|
||||||
|
|
||||||
## CONTEXT BOUNDARIES:
|
|
||||||
|
|
||||||
- Current document and frontmatter from previous steps are available
|
|
||||||
- Customer behavior analysis completed in previous step
|
|
||||||
- Focus on customer pain points, challenges, and unmet needs
|
|
||||||
- Web search capabilities with source verification are enabled
|
|
||||||
- **Research topic = "{{research_topic}}"** - established from initial discussion
|
|
||||||
- **Research goals = "{{research_goals}}"** - established from initial discussion
|
|
||||||
|
|
||||||
## YOUR TASK:
|
|
||||||
|
|
||||||
Conduct customer pain points and needs analysis with emphasis on challenges and frustrations.
|
|
||||||
|
|
||||||
## CUSTOMER PAIN POINTS ANALYSIS SEQUENCE:
|
|
||||||
|
|
||||||
### 1. Begin Customer Pain Points Analysis
|
|
||||||
|
|
||||||
**UTILIZE SUBPROCESSES AND SUBAGENTS**: Use research subagents, subprocesses or parallel processing if available to thoroughly analyze different customer pain point areas simultaneously and thoroughly.
|
|
||||||
|
|
||||||
Start with customer pain points research approach:
|
|
||||||
"Now I'll conduct **customer pain points analysis** for **{{research_topic}}** to understand customer challenges.
|
|
||||||
|
|
||||||
**Customer Pain Points Focus:**
|
|
||||||
|
|
||||||
- Customer challenges and frustrations
|
|
||||||
- Unmet needs and unaddressed problems
|
|
||||||
- Barriers to adoption or usage
|
|
||||||
- Service and support pain points
|
|
||||||
- Customer satisfaction gaps
|
|
||||||
|
|
||||||
**Let me search for current customer pain points insights.**"
|
|
||||||
|
|
||||||
### 2. Parallel Pain Points Research Execution
|
|
||||||
|
|
||||||
**Execute multiple web searches simultaneously:**
|
|
||||||
|
|
||||||
Search the web: "{{research_topic}} customer pain points challenges"
|
|
||||||
Search the web: "{{research_topic}} customer frustrations"
|
|
||||||
Search the web: "{{research_topic}} unmet customer needs"
|
|
||||||
Search the web: "{{research_topic}} customer barriers to adoption"
|
|
||||||
|
|
||||||
**Analysis approach:**
|
|
||||||
|
|
||||||
- Look for customer satisfaction surveys and reports
|
|
||||||
- Search for customer complaints and reviews
|
|
||||||
- Research customer support and service issues
|
|
||||||
- Analyze barriers to customer adoption
|
|
||||||
- Study unmet needs and market gaps
|
|
||||||
|
|
||||||
### 3. Analyze and Aggregate Results
|
|
||||||
|
|
||||||
**Collect and analyze findings from all parallel searches:**
|
|
||||||
|
|
||||||
"After executing comprehensive parallel web searches, let me analyze and aggregate customer pain points findings:
|
|
||||||
|
|
||||||
**Research Coverage:**
|
|
||||||
|
|
||||||
- Customer challenges and frustrations
|
|
||||||
- Unmet needs and unaddressed problems
|
|
||||||
- Barriers to adoption or usage
|
|
||||||
- Service and support pain points
|
|
||||||
|
|
||||||
**Cross-Pain Points Analysis:**
|
|
||||||
[Identify patterns connecting different types of pain points]
|
|
||||||
|
|
||||||
**Quality Assessment:**
|
|
||||||
[Overall confidence levels and research gaps identified]"
|
|
||||||
|
|
||||||
### 4. Generate Customer Pain Points Content
|
|
||||||
|
|
||||||
**WRITE IMMEDIATELY TO DOCUMENT**
|
|
||||||
|
|
||||||
Prepare customer pain points analysis with web search citations:
|
|
||||||
|
|
||||||
#### Content Structure:
|
|
||||||
|
|
||||||
When saving to document, append these Level 2 and Level 3 sections:
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
## Customer Pain Points and Needs
|
|
||||||
|
|
||||||
### Customer Challenges and Frustrations
|
|
||||||
|
|
||||||
[Customer challenges analysis with source citations]
|
|
||||||
_Primary Frustrations: [Major customer frustrations identified]_
|
|
||||||
_Usage Barriers: [Barriers preventing effective usage]_
|
|
||||||
_Service Pain Points: [Customer service and support issues]_
|
|
||||||
_Frequency Analysis: [How often these challenges occur]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Unmet Customer Needs
|
|
||||||
|
|
||||||
[Unmet needs analysis with source citations]
|
|
||||||
_Critical Unmet Needs: [Most important unaddressed needs]_
|
|
||||||
_Solution Gaps: [Opportunities to address unmet needs]_
|
|
||||||
_Market Gaps: [Market opportunities from unmet needs]_
|
|
||||||
_Priority Analysis: [Which needs are most critical]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Barriers to Adoption
|
|
||||||
|
|
||||||
[Adoption barriers analysis with source citations]
|
|
||||||
_Price Barriers: [Cost-related barriers to adoption]_
|
|
||||||
_Technical Barriers: [Complexity or technical barriers]_
|
|
||||||
_Trust Barriers: [Trust and credibility issues]_
|
|
||||||
_Convenience Barriers: [Ease of use or accessibility issues]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Service and Support Pain Points
|
|
||||||
|
|
||||||
[Service pain points analysis with source citations]
|
|
||||||
_Customer Service Issues: [Common customer service problems]_
|
|
||||||
_Support Gaps: [Areas where customer support is lacking]_
|
|
||||||
_Communication Issues: [Communication breakdowns and frustrations]_
|
|
||||||
_Response Time Issues: [Slow response and resolution problems]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Customer Satisfaction Gaps
|
|
||||||
|
|
||||||
[Satisfaction gap analysis with source citations]
|
|
||||||
_Expectation Gaps: [Differences between expectations and reality]_
|
|
||||||
_Quality Gaps: [Areas where quality expectations aren't met]_
|
|
||||||
_Value Perception Gaps: [Perceived value vs actual value]_
|
|
||||||
_Trust and Credibility Gaps: [Trust issues affecting satisfaction]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Emotional Impact Assessment
|
|
||||||
|
|
||||||
[Emotional impact analysis with source citations]
|
|
||||||
_Frustration Levels: [Customer frustration severity assessment]_
|
|
||||||
_Loyalty Risks: [How pain points affect customer loyalty]_
|
|
||||||
_Reputation Impact: [Impact on brand or product reputation]_
|
|
||||||
_Customer Retention Risks: [Risk of customer loss from pain points]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Pain Point Prioritization
|
|
||||||
|
|
||||||
[Pain point prioritization with source citations]
|
|
||||||
_High Priority Pain Points: [Most critical pain points to address]_
|
|
||||||
_Medium Priority Pain Points: [Important but less critical pain points]_
|
|
||||||
_Low Priority Pain Points: [Minor pain points with lower impact]_
|
|
||||||
_Opportunity Mapping: [Pain points with highest solution opportunity]_
|
|
||||||
_Source: [URL]_
|
|
||||||
```
|
|
||||||
|
|
||||||
### 5. Present Analysis and Continue Option
|
|
||||||
|
|
||||||
**Show analysis and present continue option:**
|
|
||||||
|
|
||||||
"I've completed **customer pain points analysis** for {{research_topic}}, focusing on customer challenges.
|
|
||||||
|
|
||||||
**Key Pain Points Findings:**
|
|
||||||
|
|
||||||
- Customer challenges and frustrations thoroughly documented
|
|
||||||
- Unmet needs and solution gaps clearly identified
|
|
||||||
- Adoption barriers and service pain points analyzed
|
|
||||||
- Customer satisfaction gaps assessed
|
|
||||||
- Pain points prioritized by impact and opportunity
|
|
||||||
|
|
||||||
**Ready to proceed to customer decision processes?**
|
|
||||||
[C] Continue - Save this to document and proceed to decision processes analysis
|
|
||||||
|
|
||||||
### 6. Handle Continue Selection
|
|
||||||
|
|
||||||
#### If 'C' (Continue):
|
|
||||||
|
|
||||||
- **CONTENT ALREADY WRITTEN TO DOCUMENT**
|
|
||||||
- Update frontmatter: `stepsCompleted: [1, 2, 3]`
|
|
||||||
- Load: `{project-root}/_bmad/bmm-skills/1-analysis/research/market-steps/step-04-customer-decisions.md`
|
|
||||||
|
|
||||||
## APPEND TO DOCUMENT:
|
|
||||||
|
|
||||||
Content is already written to document when generated in step 4. No additional append needed.
|
|
||||||
|
|
||||||
## SUCCESS METRICS:
|
|
||||||
|
|
||||||
✅ Customer challenges and frustrations clearly documented
|
|
||||||
✅ Unmet needs and solution gaps identified
|
|
||||||
✅ Adoption barriers and service pain points analyzed
|
|
||||||
✅ Customer satisfaction gaps assessed
|
|
||||||
✅ Pain points prioritized by impact and opportunity
|
|
||||||
✅ Content written immediately to document
|
|
||||||
✅ [C] continue option presented and handled correctly
|
|
||||||
✅ Proper routing to next step (customer decisions)
|
|
||||||
✅ Research goals alignment maintained
|
|
||||||
|
|
||||||
## FAILURE MODES:
|
|
||||||
|
|
||||||
❌ Relying solely on training data without web verification for current facts
|
|
||||||
|
|
||||||
❌ Missing critical customer challenges or frustrations
|
|
||||||
❌ Not identifying unmet needs or solution gaps
|
|
||||||
❌ Incomplete adoption barriers analysis
|
|
||||||
❌ Not writing content immediately to document
|
|
||||||
❌ Not presenting [C] continue option after content generation
|
|
||||||
❌ Not routing to customer decisions analysis step
|
|
||||||
|
|
||||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
|
||||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
|
||||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
|
||||||
|
|
||||||
## CUSTOMER PAIN POINTS RESEARCH PROTOCOLS:
|
|
||||||
|
|
||||||
- Research customer satisfaction surveys and reviews
|
|
||||||
- Use customer feedback and complaint data
|
|
||||||
- Analyze customer support and service issues
|
|
||||||
- Study barriers to customer adoption
|
|
||||||
- Focus on current pain point data
|
|
||||||
- Present conflicting information when sources disagree
|
|
||||||
- Apply confidence levels appropriately
|
|
||||||
|
|
||||||
## PAIN POINTS ANALYSIS STANDARDS:
|
|
||||||
|
|
||||||
- Always cite URLs for web search results
|
|
||||||
- Use authoritative customer research sources
|
|
||||||
- Note data currency and potential limitations
|
|
||||||
- Present multiple perspectives when sources conflict
|
|
||||||
- Apply confidence levels to uncertain data
|
|
||||||
- Focus on actionable pain point insights
|
|
||||||
|
|
||||||
## NEXT STEP:
|
|
||||||
|
|
||||||
After user selects 'C', load `{project-root}/_bmad/bmm-skills/1-analysis/research/market-steps/step-04-customer-decisions.md` to analyze customer decision processes, journey mapping, and decision factors for {{research_topic}}.
|
|
||||||
|
|
||||||
Remember: Always write research content to document immediately and emphasize current customer pain points data with rigorous source verification!
|
|
||||||
|
|
@ -1,259 +0,0 @@
|
||||||
# Market Research Step 4: Customer Decisions and Journey
|
|
||||||
|
|
||||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
|
||||||
|
|
||||||
- 🛑 NEVER generate content without web search verification
|
|
||||||
|
|
||||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
|
||||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
|
||||||
- ✅ Search the web to verify and supplement your knowledge with current facts
|
|
||||||
- 📋 YOU ARE A CUSTOMER DECISION ANALYST, not content generator
|
|
||||||
- 💬 FOCUS on customer decision processes and journey mapping
|
|
||||||
- 🔍 WEB SEARCH REQUIRED - verify current facts against live sources
|
|
||||||
- 📝 WRITE CONTENT IMMEDIATELY TO DOCUMENT
|
|
||||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
|
||||||
|
|
||||||
## EXECUTION PROTOCOLS:
|
|
||||||
|
|
||||||
- 🎯 Show web search analysis before presenting findings
|
|
||||||
- ⚠️ Present [C] continue option after decision processes content generation
|
|
||||||
- 📝 WRITE CUSTOMER DECISIONS ANALYSIS TO DOCUMENT IMMEDIATELY
|
|
||||||
- 💾 ONLY proceed when user chooses C (Continue)
|
|
||||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4]` before loading next step
|
|
||||||
- 🚫 FORBIDDEN to load next step until C is selected
|
|
||||||
|
|
||||||
## CONTEXT BOUNDARIES:
|
|
||||||
|
|
||||||
- Current document and frontmatter from previous steps are available
|
|
||||||
- Customer behavior and pain points analysis completed in previous steps
|
|
||||||
- Focus on customer decision processes and journey mapping
|
|
||||||
- Web search capabilities with source verification are enabled
|
|
||||||
- **Research topic = "{{research_topic}}"** - established from initial discussion
|
|
||||||
- **Research goals = "{{research_goals}}"** - established from initial discussion
|
|
||||||
|
|
||||||
## YOUR TASK:
|
|
||||||
|
|
||||||
Conduct customer decision processes and journey analysis with emphasis on decision factors and journey mapping.
|
|
||||||
|
|
||||||
## CUSTOMER DECISIONS ANALYSIS SEQUENCE:
|
|
||||||
|
|
||||||
### 1. Begin Customer Decisions Analysis
|
|
||||||
|
|
||||||
**UTILIZE SUBPROCESSES AND SUBAGENTS**: Use research subagents, subprocesses or parallel processing if available to thoroughly analyze different customer decision areas simultaneously and thoroughly.
|
|
||||||
|
|
||||||
Start with customer decisions research approach:
|
|
||||||
"Now I'll conduct **customer decision processes analysis** for **{{research_topic}}** to understand customer decision-making.
|
|
||||||
|
|
||||||
**Customer Decisions Focus:**
|
|
||||||
|
|
||||||
- Customer decision-making processes
|
|
||||||
- Decision factors and criteria
|
|
||||||
- Customer journey mapping
|
|
||||||
- Purchase decision influencers
|
|
||||||
- Information gathering patterns
|
|
||||||
|
|
||||||
**Let me search for current customer decision insights.**"
|
|
||||||
|
|
||||||
### 2. Parallel Decisions Research Execution
|
|
||||||
|
|
||||||
**Execute multiple web searches simultaneously:**
|
|
||||||
|
|
||||||
Search the web: "{{research_topic}} customer decision process"
|
|
||||||
Search the web: "{{research_topic}} buying criteria factors"
|
|
||||||
Search the web: "{{research_topic}} customer journey mapping"
|
|
||||||
Search the web: "{{research_topic}} decision influencing factors"
|
|
||||||
|
|
||||||
**Analysis approach:**
|
|
||||||
|
|
||||||
- Look for customer decision research studies
|
|
||||||
- Search for buying criteria and factor analysis
|
|
||||||
- Research customer journey mapping methodologies
|
|
||||||
- Analyze decision influence factors and channels
|
|
||||||
- Study information gathering and evaluation patterns
|
|
||||||
|
|
||||||
### 3. Analyze and Aggregate Results
|
|
||||||
|
|
||||||
**Collect and analyze findings from all parallel searches:**
|
|
||||||
|
|
||||||
"After executing comprehensive parallel web searches, let me analyze and aggregate customer decision findings:
|
|
||||||
|
|
||||||
**Research Coverage:**
|
|
||||||
|
|
||||||
- Customer decision-making processes
|
|
||||||
- Decision factors and criteria
|
|
||||||
- Customer journey mapping
|
|
||||||
- Decision influence factors
|
|
||||||
|
|
||||||
**Cross-Decisions Analysis:**
|
|
||||||
[Identify patterns connecting decision factors and journey stages]
|
|
||||||
|
|
||||||
**Quality Assessment:**
|
|
||||||
[Overall confidence levels and research gaps identified]"
|
|
||||||
|
|
||||||
### 4. Generate Customer Decisions Content
|
|
||||||
|
|
||||||
**WRITE IMMEDIATELY TO DOCUMENT**
|
|
||||||
|
|
||||||
Prepare customer decisions analysis with web search citations:
|
|
||||||
|
|
||||||
#### Content Structure:
|
|
||||||
|
|
||||||
When saving to document, append these Level 2 and Level 3 sections:
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
## Customer Decision Processes and Journey
|
|
||||||
|
|
||||||
### Customer Decision-Making Processes
|
|
||||||
|
|
||||||
[Decision processes analysis with source citations]
|
|
||||||
_Decision Stages: [Key stages in customer decision making]_
|
|
||||||
_Decision Timelines: [Timeframes for different decisions]_
|
|
||||||
_Complexity Levels: [Decision complexity assessment]_
|
|
||||||
_Evaluation Methods: [How customers evaluate options]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Decision Factors and Criteria
|
|
||||||
|
|
||||||
[Decision factors analysis with source citations]
|
|
||||||
_Primary Decision Factors: [Most important factors in decisions]_
|
|
||||||
_Secondary Decision Factors: [Supporting factors influencing decisions]_
|
|
||||||
_Weighing Analysis: [How different factors are weighed]_
|
|
||||||
_Evoluton Patterns: [How factors change over time]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Customer Journey Mapping
|
|
||||||
|
|
||||||
[Journey mapping analysis with source citations]
|
|
||||||
_Awareness Stage: [How customers become aware of {{research_topic}}]_
|
|
||||||
_Consideration Stage: [Evaluation and comparison process]_
|
|
||||||
_Decision Stage: [Final decision-making process]_
|
|
||||||
_Purchase Stage: [Purchase execution and completion]_
|
|
||||||
_Post-Purchase Stage: [Post-decision evaluation and behavior]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Touchpoint Analysis
|
|
||||||
|
|
||||||
[Touchpoint analysis with source citations]
|
|
||||||
_Digital Touchpoints: [Online and digital interaction points]_
|
|
||||||
_Offline Touchpoints: [Physical and in-person interaction points]_
|
|
||||||
_Information Sources: [Where customers get information]_
|
|
||||||
_Influence Channels: [What influences customer decisions]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Information Gathering Patterns
|
|
||||||
|
|
||||||
[Information patterns analysis with source citations]
|
|
||||||
_Research Methods: [How customers research options]_
|
|
||||||
_Information Sources Trusted: [Most trusted information sources]_
|
|
||||||
_Research Duration: [Time spent gathering information]_
|
|
||||||
_Evaluation Criteria: [How customers evaluate information]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Decision Influencers
|
|
||||||
|
|
||||||
[Decision influencer analysis with source citations]
|
|
||||||
_Peer Influence: [How friends and family influence decisions]_
|
|
||||||
_Expert Influence: [How expert opinions affect decisions]_
|
|
||||||
_Media Influence: [How media and marketing affect decisions]_
|
|
||||||
_Social Proof Influence: [How reviews and testimonials affect decisions]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Purchase Decision Factors
|
|
||||||
|
|
||||||
[Purchase decision factors analysis with source citations]
|
|
||||||
_Immediate Purchase Drivers: [Factors triggering immediate purchase]_
|
|
||||||
_Delayed Purchase Drivers: [Factors causing purchase delays]_
|
|
||||||
_Brand Loyalty Factors: [Factors driving repeat purchases]_
|
|
||||||
_Price Sensitivity: [How price affects purchase decisions]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Customer Decision Optimizations
|
|
||||||
|
|
||||||
[Decision optimization analysis with source citations]
|
|
||||||
_Friction Reduction: [Ways to make decisions easier]_
|
|
||||||
_Trust Building: [Building customer trust in decisions]_
|
|
||||||
_Conversion Optimization: [Optimizing decision-to-purchase rates]_
|
|
||||||
_Loyalty Building: [Building long-term customer relationships]_
|
|
||||||
_Source: [URL]_
|
|
||||||
```
|
|
||||||
|
|
||||||
### 5. Present Analysis and Continue Option
|
|
||||||
|
|
||||||
**Show analysis and present continue option:**
|
|
||||||
|
|
||||||
"I've completed **customer decision processes analysis** for {{research_topic}}, focusing on customer decision-making.
|
|
||||||
|
|
||||||
**Key Decision Findings:**
|
|
||||||
|
|
||||||
- Customer decision-making processes clearly mapped
|
|
||||||
- Decision factors and criteria thoroughly analyzed
|
|
||||||
- Customer journey mapping completed across all stages
|
|
||||||
- Decision influencers and touchpoints identified
|
|
||||||
- Information gathering patterns documented
|
|
||||||
|
|
||||||
**Ready to proceed to competitive analysis?**
|
|
||||||
[C] Continue - Save this to document and proceed to competitive analysis
|
|
||||||
|
|
||||||
### 6. Handle Continue Selection
|
|
||||||
|
|
||||||
#### If 'C' (Continue):
|
|
||||||
|
|
||||||
- **CONTENT ALREADY WRITTEN TO DOCUMENT**
|
|
||||||
- Update frontmatter: `stepsCompleted: [1, 2, 3, 4]`
|
|
||||||
- Load: `{project-root}/_bmad/bmm-skills/1-analysis/research/market-steps/step-05-competitive-analysis.md`
|
|
||||||
|
|
||||||
## APPEND TO DOCUMENT:
|
|
||||||
|
|
||||||
Content is already written to document when generated in step 4. No additional append needed.
|
|
||||||
|
|
||||||
## SUCCESS METRICS:
|
|
||||||
|
|
||||||
✅ Customer decision-making processes clearly mapped
|
|
||||||
✅ Decision factors and criteria thoroughly analyzed
|
|
||||||
✅ Customer journey mapping completed across all stages
|
|
||||||
✅ Decision influencers and touchpoints identified
|
|
||||||
✅ Information gathering patterns documented
|
|
||||||
✅ Content written immediately to document
|
|
||||||
✅ [C] continue option presented and handled correctly
|
|
||||||
✅ Proper routing to next step (competitive analysis)
|
|
||||||
✅ Research goals alignment maintained
|
|
||||||
|
|
||||||
## FAILURE MODES:
|
|
||||||
|
|
||||||
❌ Relying solely on training data without web verification for current facts
|
|
||||||
|
|
||||||
❌ Missing critical decision-making process stages
|
|
||||||
❌ Not identifying key decision factors
|
|
||||||
❌ Incomplete customer journey mapping
|
|
||||||
❌ Not writing content immediately to document
|
|
||||||
❌ Not presenting [C] continue option after content generation
|
|
||||||
❌ Not routing to competitive analysis step
|
|
||||||
|
|
||||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
|
||||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
|
||||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
|
||||||
|
|
||||||
## CUSTOMER DECISIONS RESEARCH PROTOCOLS:
|
|
||||||
|
|
||||||
- Research customer decision studies and psychology
|
|
||||||
- Use customer journey mapping methodologies
|
|
||||||
- Analyze buying criteria and decision factors
|
|
||||||
- Study decision influence and touchpoint analysis
|
|
||||||
- Focus on current decision data
|
|
||||||
- Present conflicting information when sources disagree
|
|
||||||
- Apply confidence levels appropriately
|
|
||||||
|
|
||||||
## DECISION ANALYSIS STANDARDS:
|
|
||||||
|
|
||||||
- Always cite URLs for web search results
|
|
||||||
- Use authoritative customer decision research sources
|
|
||||||
- Note data currency and potential limitations
|
|
||||||
- Present multiple perspectives when sources conflict
|
|
||||||
- Apply confidence levels to uncertain data
|
|
||||||
- Focus on actionable decision insights
|
|
||||||
|
|
||||||
## NEXT STEP:
|
|
||||||
|
|
||||||
After user selects 'C', load `{project-root}/_bmad/bmm-skills/1-analysis/research/market-steps/step-05-competitive-analysis.md` to analyze competitive landscape, market positioning, and competitive strategies for {{research_topic}}.
|
|
||||||
|
|
||||||
Remember: Always write research content to document immediately and emphasize current customer decision data with rigorous source verification!
|
|
||||||
|
|
@ -1,177 +0,0 @@
|
||||||
# Market Research Step 5: Competitive Analysis
|
|
||||||
|
|
||||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
|
||||||
|
|
||||||
- 🛑 NEVER generate content without web search verification
|
|
||||||
|
|
||||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
|
||||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
|
||||||
- ✅ Search the web to verify and supplement your knowledge with current facts
|
|
||||||
- 📋 YOU ARE A COMPETITIVE ANALYST, not content generator
|
|
||||||
- 💬 FOCUS on competitive landscape and market positioning
|
|
||||||
- 🔍 WEB SEARCH REQUIRED - verify current facts against live sources
|
|
||||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
|
||||||
|
|
||||||
## EXECUTION PROTOCOLS:
|
|
||||||
|
|
||||||
- 🎯 Show web search analysis before presenting findings
|
|
||||||
- ⚠️ Present [C] complete option after competitive analysis content generation
|
|
||||||
- 💾 ONLY save when user chooses C (Complete)
|
|
||||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5]` before completing workflow
|
|
||||||
- 🚫 FORBIDDEN to complete workflow until C is selected
|
|
||||||
|
|
||||||
## CONTEXT BOUNDARIES:
|
|
||||||
|
|
||||||
- Current document and frontmatter from previous steps are available
|
|
||||||
- Focus on competitive landscape and market positioning analysis
|
|
||||||
- Web search capabilities with source verification are enabled
|
|
||||||
- May need to search for specific competitor information
|
|
||||||
|
|
||||||
## YOUR TASK:
|
|
||||||
|
|
||||||
Conduct comprehensive competitive analysis with emphasis on market positioning.
|
|
||||||
|
|
||||||
## COMPETITIVE ANALYSIS SEQUENCE:
|
|
||||||
|
|
||||||
### 1. Begin Competitive Analysis
|
|
||||||
|
|
||||||
Start with competitive research approach:
|
|
||||||
"Now I'll conduct **competitive analysis** to understand the competitive landscape.
|
|
||||||
|
|
||||||
**Competitive Analysis Focus:**
|
|
||||||
|
|
||||||
- Key players and market share
|
|
||||||
- Competitive positioning strategies
|
|
||||||
- Strengths and weaknesses analysis
|
|
||||||
- Market differentiation opportunities
|
|
||||||
- Competitive threats and challenges
|
|
||||||
|
|
||||||
**Let me search for current competitive information.**"
|
|
||||||
|
|
||||||
### 2. Generate Competitive Analysis Content
|
|
||||||
|
|
||||||
Prepare competitive analysis with web search citations:
|
|
||||||
|
|
||||||
#### Content Structure:
|
|
||||||
|
|
||||||
When saving to document, append these Level 2 and Level 3 sections:
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
## Competitive Landscape
|
|
||||||
|
|
||||||
### Key Market Players
|
|
||||||
|
|
||||||
[Key players analysis with market share data]
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Market Share Analysis
|
|
||||||
|
|
||||||
[Market share analysis with source citations]
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Competitive Positioning
|
|
||||||
|
|
||||||
[Positioning analysis with source citations]
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Strengths and Weaknesses
|
|
||||||
|
|
||||||
[SWOT analysis with source citations]
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Market Differentiation
|
|
||||||
|
|
||||||
[Differentiation analysis with source citations]
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Competitive Threats
|
|
||||||
|
|
||||||
[Threats analysis with source citations]
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Opportunities
|
|
||||||
|
|
||||||
[Competitive opportunities analysis with source citations]
|
|
||||||
_Source: [URL]_
|
|
||||||
```
|
|
||||||
|
|
||||||
### 3. Present Analysis and Complete Option
|
|
||||||
|
|
||||||
Show the generated competitive analysis and present complete option:
|
|
||||||
"I've completed the **competitive analysis** for the competitive landscape.
|
|
||||||
|
|
||||||
**Key Competitive Findings:**
|
|
||||||
|
|
||||||
- Key market players and market share identified
|
|
||||||
- Competitive positioning strategies mapped
|
|
||||||
- Strengths and weaknesses thoroughly analyzed
|
|
||||||
- Market differentiation opportunities identified
|
|
||||||
- Competitive threats and challenges documented
|
|
||||||
|
|
||||||
**Ready to complete the market research?**
|
|
||||||
[C] Complete Research - Save final document and conclude
|
|
||||||
|
|
||||||
### 4. Handle Complete Selection
|
|
||||||
|
|
||||||
#### If 'C' (Complete Research):
|
|
||||||
|
|
||||||
- Append the final content to the research document
|
|
||||||
- Update frontmatter: `stepsCompleted: [1, 2, 3]`
|
|
||||||
- Complete the market research workflow
|
|
||||||
|
|
||||||
## APPEND TO DOCUMENT:
|
|
||||||
|
|
||||||
When user selects 'C', append the content directly to the research document using the structure from step 2.
|
|
||||||
|
|
||||||
## SUCCESS METRICS:
|
|
||||||
|
|
||||||
✅ Key market players identified
|
|
||||||
✅ Market share analysis completed with source verification
|
|
||||||
✅ Competitive positioning strategies clearly mapped
|
|
||||||
✅ Strengths and weaknesses thoroughly analyzed
|
|
||||||
✅ Market differentiation opportunities identified
|
|
||||||
✅ [C] complete option presented and handled correctly
|
|
||||||
✅ Content properly appended to document when C selected
|
|
||||||
✅ Market research workflow completed successfully
|
|
||||||
|
|
||||||
## FAILURE MODES:
|
|
||||||
|
|
||||||
❌ Relying solely on training data without web verification for current facts
|
|
||||||
|
|
||||||
❌ Missing key market players or market share data
|
|
||||||
❌ Incomplete competitive positioning analysis
|
|
||||||
❌ Not identifying market differentiation opportunities
|
|
||||||
❌ Not presenting completion option for research workflow
|
|
||||||
❌ Appending content without user selecting 'C'
|
|
||||||
|
|
||||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
|
||||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
|
||||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
|
||||||
|
|
||||||
## COMPETITIVE RESEARCH PROTOCOLS:
|
|
||||||
|
|
||||||
- Search for industry reports and competitive intelligence
|
|
||||||
- Use competitor company websites and annual reports
|
|
||||||
- Research market research firm competitive analyses
|
|
||||||
- Note competitive advantages and disadvantages
|
|
||||||
- Search for recent market developments and disruptions
|
|
||||||
|
|
||||||
## MARKET RESEARCH COMPLETION:
|
|
||||||
|
|
||||||
When 'C' is selected:
|
|
||||||
|
|
||||||
- All market research steps completed
|
|
||||||
- Comprehensive market research document generated
|
|
||||||
- All sections appended with source citations
|
|
||||||
- Market research workflow status updated
|
|
||||||
- Final recommendations provided to user
|
|
||||||
|
|
||||||
## NEXT STEPS:
|
|
||||||
|
|
||||||
Market research workflow complete. User may:
|
|
||||||
|
|
||||||
- Use market research to inform product development strategies
|
|
||||||
- Conduct additional competitive research on specific companies
|
|
||||||
- Combine market research with other research types for comprehensive insights
|
|
||||||
|
|
||||||
Congratulations on completing comprehensive market research! 🎉
|
|
||||||
|
|
@ -1,476 +0,0 @@
|
||||||
# Market Research Step 6: Research Completion
|
|
||||||
|
|
||||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
|
||||||
|
|
||||||
- 🛑 NEVER generate content without web search verification
|
|
||||||
|
|
||||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
|
||||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
|
||||||
- ✅ Search the web to verify and supplement your knowledge with current facts
|
|
||||||
- 📋 YOU ARE A MARKET RESEARCH STRATEGIST, not content generator
|
|
||||||
- 💬 FOCUS on strategic recommendations and actionable insights
|
|
||||||
- 🔍 WEB SEARCH REQUIRED - verify current facts against live sources
|
|
||||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
|
||||||
|
|
||||||
## EXECUTION PROTOCOLS:
|
|
||||||
|
|
||||||
- 🎯 Show web search analysis before presenting findings
|
|
||||||
- ⚠️ Present [C] complete option after completion content generation
|
|
||||||
- 💾 ONLY save when user chooses C (Complete)
|
|
||||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5, 6]` before completing workflow
|
|
||||||
- 🚫 FORBIDDEN to complete workflow until C is selected
|
|
||||||
- 📚 GENERATE COMPLETE DOCUMENT STRUCTURE with intro, TOC, and summary
|
|
||||||
|
|
||||||
## CONTEXT BOUNDARIES:
|
|
||||||
|
|
||||||
- Current document and frontmatter from previous steps are available
|
|
||||||
- **Research topic = "{{research_topic}}"** - comprehensive market analysis
|
|
||||||
- **Research goals = "{{research_goals}}"** - achieved through exhaustive market research
|
|
||||||
- All market research sections have been completed (customer behavior, pain points, decisions, competitive analysis)
|
|
||||||
- Web search capabilities with source verification are enabled
|
|
||||||
- This is the final synthesis step producing the complete market research document
|
|
||||||
|
|
||||||
## YOUR TASK:
|
|
||||||
|
|
||||||
Produce a comprehensive, authoritative market research document on **{{research_topic}}** with compelling narrative introduction, detailed TOC, and executive summary based on exhaustive market research.
|
|
||||||
|
|
||||||
## MARKET RESEARCH COMPLETION SEQUENCE:
|
|
||||||
|
|
||||||
### 1. Begin Strategic Synthesis
|
|
||||||
|
|
||||||
Start with strategic synthesis approach:
|
|
||||||
"Now I'll complete our market research with **strategic synthesis and recommendations** .
|
|
||||||
|
|
||||||
**Strategic Synthesis Focus:**
|
|
||||||
|
|
||||||
- Integrated insights from market, customer, and competitive analysis
|
|
||||||
- Strategic recommendations based on research findings
|
|
||||||
- Market entry or expansion strategies
|
|
||||||
- Risk assessment and mitigation approaches
|
|
||||||
- Actionable next steps and implementation guidance
|
|
||||||
|
|
||||||
**Let me search for current strategic insights and best practices.**"
|
|
||||||
|
|
||||||
### 2. Web Search for Market Entry Strategies
|
|
||||||
|
|
||||||
Search for current market strategies:
|
|
||||||
Search the web: "market entry strategies best practices"
|
|
||||||
|
|
||||||
**Strategy focus:**
|
|
||||||
|
|
||||||
- Market entry timing and approaches
|
|
||||||
- Go-to-market strategies and frameworks
|
|
||||||
- Market positioning and differentiation tactics
|
|
||||||
- Customer acquisition and growth strategies
|
|
||||||
|
|
||||||
### 3. Web Search for Risk Assessment
|
|
||||||
|
|
||||||
Search for current risk approaches:
|
|
||||||
Search the web: "market research risk assessment frameworks"
|
|
||||||
|
|
||||||
**Risk focus:**
|
|
||||||
|
|
||||||
- Market risks and uncertainty management
|
|
||||||
- Competitive threats and mitigation strategies
|
|
||||||
- Regulatory and compliance risks
|
|
||||||
- Economic and market volatility considerations
|
|
||||||
|
|
||||||
### 4. Generate Complete Market Research Document
|
|
||||||
|
|
||||||
Prepare comprehensive market research document with full structure:
|
|
||||||
|
|
||||||
#### Complete Document Structure:
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
# [Compelling Title]: Comprehensive {{research_topic}} Market Research
|
|
||||||
|
|
||||||
## Executive Summary
|
|
||||||
|
|
||||||
[Brief compelling overview of key market findings and strategic implications]
|
|
||||||
|
|
||||||
## Table of Contents
|
|
||||||
|
|
||||||
- Market Research Introduction and Methodology
|
|
||||||
- {{research_topic}} Market Analysis and Dynamics
|
|
||||||
- Customer Insights and Behavior Analysis
|
|
||||||
- Competitive Landscape and Positioning
|
|
||||||
- Strategic Market Recommendations
|
|
||||||
- Market Entry and Growth Strategies
|
|
||||||
- Risk Assessment and Mitigation
|
|
||||||
- Implementation Roadmap and Success Metrics
|
|
||||||
- Future Market Outlook and Opportunities
|
|
||||||
- Market Research Methodology and Source Documentation
|
|
||||||
- Market Research Appendices and Additional Resources
|
|
||||||
|
|
||||||
## 1. Market Research Introduction and Methodology
|
|
||||||
|
|
||||||
### Market Research Significance
|
|
||||||
|
|
||||||
**Compelling market narrative about why {{research_topic}} research is critical now**
|
|
||||||
_Market Importance: [Strategic market significance with up-to-date context]_
|
|
||||||
_Business Impact: [Business implications of market research]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Market Research Methodology
|
|
||||||
|
|
||||||
[Comprehensive description of market research approach including:]
|
|
||||||
|
|
||||||
- **Market Scope**: [Comprehensive market coverage areas]
|
|
||||||
- **Data Sources**: [Authoritative market sources and verification approach]
|
|
||||||
- **Analysis Framework**: [Structured market analysis methodology]
|
|
||||||
- **Time Period**: [current focus and market evolution context]
|
|
||||||
- **Geographic Coverage**: [Regional/global market scope]
|
|
||||||
|
|
||||||
### Market Research Goals and Objectives
|
|
||||||
|
|
||||||
**Original Market Goals:** {{research_goals}}
|
|
||||||
|
|
||||||
**Achieved Market Objectives:**
|
|
||||||
|
|
||||||
- [Market Goal 1 achievement with supporting evidence]
|
|
||||||
- [Market Goal 2 achievement with supporting evidence]
|
|
||||||
- [Additional market insights discovered during research]
|
|
||||||
|
|
||||||
## 2. {{research_topic}} Market Analysis and Dynamics
|
|
||||||
|
|
||||||
### Market Size and Growth Projections
|
|
||||||
|
|
||||||
_[Comprehensive market analysis]_
|
|
||||||
_Market Size: [Current market valuation and size]_
|
|
||||||
_Growth Rate: [CAGR and market growth projections]_
|
|
||||||
_Market Drivers: [Key factors driving market growth]_
|
|
||||||
_Market Segments: [Detailed market segmentation analysis]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Market Trends and Dynamics
|
|
||||||
|
|
||||||
[Current market trends analysis]
|
|
||||||
_Emerging Trends: [Key market trends and their implications]_
|
|
||||||
_Market Dynamics: [Forces shaping market evolution]_
|
|
||||||
_Consumer Behavior Shifts: [Changes in customer behavior and preferences]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Pricing and Business Model Analysis
|
|
||||||
|
|
||||||
[Comprehensive pricing and business model analysis]
|
|
||||||
_Pricing Strategies: [Current pricing approaches and models]_
|
|
||||||
_Business Model Evolution: [Emerging and successful business models]_
|
|
||||||
_Value Proposition Analysis: [Customer value proposition assessment]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
## 3. Customer Insights and Behavior Analysis
|
|
||||||
|
|
||||||
### Customer Behavior Patterns
|
|
||||||
|
|
||||||
[Customer insights analysis with current context]
|
|
||||||
_Behavior Patterns: [Key customer behavior trends and patterns]_
|
|
||||||
_Customer Journey: [Complete customer journey mapping]_
|
|
||||||
_Decision Factors: [Factors influencing customer decisions]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Customer Pain Points and Needs
|
|
||||||
|
|
||||||
[Comprehensive customer pain point analysis]
|
|
||||||
_Pain Points: [Key customer challenges and frustrations]_
|
|
||||||
_Unmet Needs: [Unsolved customer needs and opportunities]_
|
|
||||||
_Customer Expectations: [Current customer expectations and requirements]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Customer Segmentation and Targeting
|
|
||||||
|
|
||||||
[Detailed customer segmentation analysis]
|
|
||||||
_Customer Segments: [Detailed customer segment profiles]_
|
|
||||||
_Target Market Analysis: [Most attractive customer segments]_
|
|
||||||
_Segment-specific Strategies: [Tailored approaches for key segments]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
## 4. Competitive Landscape and Positioning
|
|
||||||
|
|
||||||
### Competitive Analysis
|
|
||||||
|
|
||||||
[Comprehensive competitive analysis]
|
|
||||||
_Market Leaders: [Dominant competitors and their strategies]_
|
|
||||||
_Emerging Competitors: [New entrants and innovative approaches]_
|
|
||||||
_Competitive Advantages: [Key differentiators and competitive advantages]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Market Positioning Strategies
|
|
||||||
|
|
||||||
[Strategic positioning analysis]
|
|
||||||
_Positioning Opportunities: [Opportunities for market differentiation]_
|
|
||||||
_Competitive Gaps: [Unserved market needs and opportunities]_
|
|
||||||
_Positioning Framework: [Recommended positioning approach]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
## 5. Strategic Market Recommendations
|
|
||||||
|
|
||||||
### Market Opportunity Assessment
|
|
||||||
|
|
||||||
[Strategic market opportunities analysis]
|
|
||||||
_High-Value Opportunities: [Most attractive market opportunities]_
|
|
||||||
_Market Entry Timing: [Optimal timing for market entry or expansion]_
|
|
||||||
_Growth Strategies: [Recommended approaches for market growth]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Strategic Recommendations
|
|
||||||
|
|
||||||
[Comprehensive strategic recommendations]
|
|
||||||
_Market Entry Strategy: [Recommended approach for market entry/expansion]_
|
|
||||||
_Competitive Strategy: [Recommended competitive positioning and approach]_
|
|
||||||
_Customer Acquisition Strategy: [Recommended customer acquisition approach]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
## 6. Market Entry and Growth Strategies
|
|
||||||
|
|
||||||
### Go-to-Market Strategy
|
|
||||||
|
|
||||||
[Comprehensive go-to-market approach]
|
|
||||||
_Market Entry Approach: [Recommended market entry strategy and tactics]_
|
|
||||||
_Channel Strategy: [Optimal channels for market reach and customer acquisition]_
|
|
||||||
_Partnership Strategy: [Strategic partnership and collaboration opportunities]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Growth and Scaling Strategy
|
|
||||||
|
|
||||||
[Market growth and scaling analysis]
|
|
||||||
_Growth Phases: [Recommended phased approach to market growth]_
|
|
||||||
_Scaling Considerations: [Key factors for successful market scaling]_
|
|
||||||
_Expansion Opportunities: [Opportunities for geographic or segment expansion]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
## 7. Risk Assessment and Mitigation
|
|
||||||
|
|
||||||
### Market Risk Analysis
|
|
||||||
|
|
||||||
[Comprehensive market risk assessment]
|
|
||||||
_Market Risks: [Key market-related risks and uncertainties]_
|
|
||||||
_Competitive Risks: [Competitive threats and mitigation strategies]_
|
|
||||||
_Regulatory Risks: [Regulatory and compliance considerations]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Mitigation Strategies
|
|
||||||
|
|
||||||
[Risk mitigation and contingency planning]
|
|
||||||
_Risk Mitigation Approaches: [Strategies for managing identified risks]_
|
|
||||||
_Contingency Planning: [Backup plans and alternative approaches]_
|
|
||||||
_Market Sensitivity Analysis: [Impact of market changes on strategy]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
## 8. Implementation Roadmap and Success Metrics
|
|
||||||
|
|
||||||
### Implementation Framework
|
|
||||||
|
|
||||||
[Comprehensive implementation guidance]
|
|
||||||
_Implementation Timeline: [Recommended phased implementation approach]_
|
|
||||||
_Required Resources: [Key resources and capabilities needed]_
|
|
||||||
_Implementation Milestones: [Key milestones and success criteria]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Success Metrics and KPIs
|
|
||||||
|
|
||||||
[Comprehensive success measurement framework]
|
|
||||||
_Key Performance Indicators: [Critical metrics for measuring success]_
|
|
||||||
_Monitoring and Reporting: [Approach for tracking and reporting progress]_
|
|
||||||
_Success Criteria: [Clear criteria for determining success]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
## 9. Future Market Outlook and Opportunities
|
|
||||||
|
|
||||||
### Future Market Trends
|
|
||||||
|
|
||||||
[Forward-looking market analysis]
|
|
||||||
_Near-term Market Evolution: [1-2 year market development expectations]_
|
|
||||||
_Medium-term Market Trends: [3-5 year expected market developments]_
|
|
||||||
_Long-term Market Vision: [5+ year market outlook for {{research_topic}}]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
### Strategic Opportunities
|
|
||||||
|
|
||||||
[Market opportunity analysis and recommendations]
|
|
||||||
_Emerging Opportunities: [New market opportunities and their potential]_
|
|
||||||
_Innovation Opportunities: [Areas for market innovation and differentiation]_
|
|
||||||
_Strategic Market Investments: [Recommended market investments and priorities]_
|
|
||||||
_Source: [URL]_
|
|
||||||
|
|
||||||
## 10. Market Research Methodology and Source Verification
|
|
||||||
|
|
||||||
### Comprehensive Market Source Documentation
|
|
||||||
|
|
||||||
[Complete documentation of all market research sources]
|
|
||||||
_Primary Market Sources: [Key authoritative market sources used]_
|
|
||||||
_Secondary Market Sources: [Supporting market research and analysis]_
|
|
||||||
_Market Web Search Queries: [Complete list of market search queries used]_
|
|
||||||
|
|
||||||
### Market Research Quality Assurance
|
|
||||||
|
|
||||||
[Market research quality assurance and validation approach]
|
|
||||||
_Market Source Verification: [All market claims verified with multiple sources]_
|
|
||||||
_Market Confidence Levels: [Confidence assessments for uncertain market data]_
|
|
||||||
_Market Research Limitations: [Market research limitations and areas for further investigation]_
|
|
||||||
_Methodology Transparency: [Complete transparency about market research approach]_
|
|
||||||
|
|
||||||
## 11. Market Research Appendices and Additional Resources
|
|
||||||
|
|
||||||
### Detailed Market Data Tables
|
|
||||||
|
|
||||||
[Comprehensive market data tables supporting research findings]
|
|
||||||
_Market Size Data: [Detailed market size and growth data tables]_
|
|
||||||
_Customer Analysis Data: [Detailed customer behavior and segmentation data]_
|
|
||||||
_Competitive Analysis Data: [Detailed competitor comparison and positioning data]_
|
|
||||||
|
|
||||||
### Market Resources and References
|
|
||||||
|
|
||||||
[Valuable market resources for continued research and implementation]
|
|
||||||
_Market Research Reports: [Authoritative market research reports and publications]_
|
|
||||||
_Industry Associations: [Key industry organizations and market resources]_
|
|
||||||
_Market Analysis Tools: [Tools and resources for ongoing market analysis]_
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Market Research Conclusion
|
|
||||||
|
|
||||||
### Summary of Key Market Findings
|
|
||||||
|
|
||||||
[Comprehensive summary of the most important market research findings]
|
|
||||||
|
|
||||||
### Strategic Market Impact Assessment
|
|
||||||
|
|
||||||
[Assessment of market implications for {{research_topic}}]
|
|
||||||
|
|
||||||
### Next Steps Market Recommendations
|
|
||||||
|
|
||||||
[Specific next steps for leveraging this market research]
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
**Market Research Completion Date:** {{date}}
|
|
||||||
**Research Period:** current comprehensive market analysis
|
|
||||||
**Document Length:** As needed for comprehensive market coverage
|
|
||||||
**Source Verification:** All market facts cited with current sources
|
|
||||||
**Market Confidence Level:** High - based on multiple authoritative market sources
|
|
||||||
|
|
||||||
_This comprehensive market research document serves as an authoritative market reference on {{research_topic}} and provides strategic market insights for informed decision-making._
|
|
||||||
```
|
|
||||||
|
|
||||||
### 5. Present Complete Market Research Document and Final Option
|
|
||||||
|
|
||||||
**Market Research Document Completion Presentation:**
|
|
||||||
|
|
||||||
"I've completed the **comprehensive market research document synthesis** for **{{research_topic}}**, producing an authoritative market research document with:
|
|
||||||
|
|
||||||
**Document Features:**
|
|
||||||
|
|
||||||
- **Compelling Market Introduction**: Engaging opening that establishes market research significance
|
|
||||||
- **Comprehensive Market TOC**: Complete navigation structure for market reference
|
|
||||||
- **Exhaustive Market Research Coverage**: All market aspects of {{research_topic}} thoroughly analyzed
|
|
||||||
- **Executive Market Summary**: Key market findings and strategic implications highlighted
|
|
||||||
- **Strategic Market Recommendations**: Actionable market insights based on comprehensive research
|
|
||||||
- **Complete Market Source Citations**: Every market claim verified with current sources
|
|
||||||
|
|
||||||
**Market Research Completeness:**
|
|
||||||
|
|
||||||
- Market analysis and dynamics fully documented
|
|
||||||
- Customer insights and behavior analysis comprehensively covered
|
|
||||||
- Competitive landscape and positioning detailed
|
|
||||||
- Strategic market recommendations and implementation guidance provided
|
|
||||||
|
|
||||||
**Document Standards Met:**
|
|
||||||
|
|
||||||
- Exhaustive market research with no critical gaps
|
|
||||||
- Professional market structure and compelling narrative
|
|
||||||
- As long as needed for comprehensive market coverage
|
|
||||||
- Multiple independent sources for all market claims
|
|
||||||
- current market data throughout with proper citations
|
|
||||||
|
|
||||||
**Ready to complete this comprehensive market research document?**
|
|
||||||
[C] Complete Research - Save final comprehensive market research document
|
|
||||||
|
|
||||||
### 6. Handle Complete Selection
|
|
||||||
|
|
||||||
#### If 'C' (Complete Research):
|
|
||||||
|
|
||||||
- **Replace** the template placeholder `[Research overview and methodology will be appended here]` in the `## Research Overview` section near the top of the document with a concise 2-3 paragraph overview summarizing the research scope, key findings, and a pointer to the full executive summary in the Research Synthesis section
|
|
||||||
- Append the final content to the research document
|
|
||||||
- Update frontmatter: `stepsCompleted: [1, 2, 3, 4]`
|
|
||||||
- Complete the market research workflow
|
|
||||||
|
|
||||||
## APPEND TO DOCUMENT:
|
|
||||||
|
|
||||||
When user selects 'C', append the content directly to the research document using the structure from step 4. Also replace the `[Research overview and methodology will be appended here]` placeholder in the Research Overview section at the top of the document.
|
|
||||||
|
|
||||||
## SUCCESS METRICS:
|
|
||||||
|
|
||||||
✅ Compelling market introduction with research significance
|
|
||||||
✅ Comprehensive market table of contents with complete document structure
|
|
||||||
✅ Exhaustive market research coverage across all market aspects
|
|
||||||
✅ Executive market summary with key findings and strategic implications
|
|
||||||
✅ Strategic market recommendations grounded in comprehensive research
|
|
||||||
✅ Complete market source verification with current citations
|
|
||||||
✅ Professional market document structure and compelling narrative
|
|
||||||
✅ [C] complete option presented and handled correctly
|
|
||||||
✅ Market research workflow completed with comprehensive document
|
|
||||||
|
|
||||||
## FAILURE MODES:
|
|
||||||
|
|
||||||
❌ Not producing compelling market introduction
|
|
||||||
❌ Missing comprehensive market table of contents
|
|
||||||
❌ Incomplete market research coverage across market aspects
|
|
||||||
❌ Not providing executive market summary with key findings
|
|
||||||
❌ Missing strategic market recommendations based on research
|
|
||||||
❌ Relying solely on training data without web verification for current facts
|
|
||||||
❌ Producing market document without professional structure
|
|
||||||
❌ Not presenting completion option for final market document
|
|
||||||
|
|
||||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
|
||||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
|
||||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
|
||||||
|
|
||||||
## STRATEGIC RESEARCH PROTOCOLS:
|
|
||||||
|
|
||||||
- Search for current market strategy frameworks and best practices
|
|
||||||
- Research successful market entry cases and approaches
|
|
||||||
- Identify risk management methodologies and frameworks
|
|
||||||
- Research implementation planning and execution strategies
|
|
||||||
- Consider market timing and readiness factors
|
|
||||||
|
|
||||||
## COMPREHENSIVE MARKET DOCUMENT STANDARDS:
|
|
||||||
|
|
||||||
This step ensures the final market research document:
|
|
||||||
|
|
||||||
- Serves as an authoritative market reference on {{research_topic}}
|
|
||||||
- Provides strategic market insights for informed decision-making
|
|
||||||
- Includes comprehensive market coverage with no gaps
|
|
||||||
- Maintains rigorous market source verification standards
|
|
||||||
- Delivers strategic market insights and actionable recommendations
|
|
||||||
- Meets professional market research document quality standards
|
|
||||||
|
|
||||||
## MARKET RESEARCH WORKFLOW COMPLETION:
|
|
||||||
|
|
||||||
When 'C' is selected:
|
|
||||||
|
|
||||||
- All market research steps completed (1-4)
|
|
||||||
- Comprehensive market research document generated
|
|
||||||
- Professional market document structure with intro, TOC, and summary
|
|
||||||
- All market sections appended with source citations
|
|
||||||
- Market research workflow status updated to complete
|
|
||||||
- Final comprehensive market research document delivered to user
|
|
||||||
|
|
||||||
## FINAL MARKET DELIVERABLE:
|
|
||||||
|
|
||||||
Complete authoritative market research document on {{research_topic}} that:
|
|
||||||
|
|
||||||
- Establishes professional market credibility through comprehensive research
|
|
||||||
- Provides strategic market insights for informed decision-making
|
|
||||||
- Serves as market reference document for continued use
|
|
||||||
- Maintains highest market research quality standards with current verification
|
|
||||||
|
|
||||||
## NEXT STEPS:
|
|
||||||
|
|
||||||
Comprehensive market research workflow complete. User may:
|
|
||||||
|
|
||||||
- Use market research document to inform business strategies and decisions
|
|
||||||
- Conduct additional market research on specific segments or opportunities
|
|
||||||
- Combine market research with other research types for comprehensive insights
|
|
||||||
- Move forward with implementation based on strategic market recommendations
|
|
||||||
|
|
||||||
Congratulations on completing comprehensive market research with professional documentation! 🎉
|
|
||||||
|
|
@ -1,29 +0,0 @@
|
||||||
---
|
|
||||||
stepsCompleted: []
|
|
||||||
inputDocuments: []
|
|
||||||
workflowType: 'research'
|
|
||||||
lastStep: 1
|
|
||||||
research_type: '{{research_type}}'
|
|
||||||
research_topic: '{{research_topic}}'
|
|
||||||
research_goals: '{{research_goals}}'
|
|
||||||
user_name: '{{user_name}}'
|
|
||||||
date: '{{date}}'
|
|
||||||
web_research_enabled: true
|
|
||||||
source_verification: true
|
|
||||||
---
|
|
||||||
|
|
||||||
# Research Report: {{research_type}}
|
|
||||||
|
|
||||||
**Date:** {{date}}
|
|
||||||
**Author:** {{user_name}}
|
|
||||||
**Research Type:** {{research_type}}
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Research Overview
|
|
||||||
|
|
||||||
[Research overview and methodology will be appended here]
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
<!-- Content will be appended sequentially through research workflow steps -->
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
type: skill
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
type: skill
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
type: skill
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
type: skill
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
type: skill
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
type: skill
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
type: skill
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
type: skill
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
type: skill
|
|
||||||
|
|
@ -2,6 +2,7 @@
|
||||||
diff_output: '' # set at runtime
|
diff_output: '' # set at runtime
|
||||||
spec_file: '' # set at runtime (path or empty)
|
spec_file: '' # set at runtime (path or empty)
|
||||||
review_mode: '' # set at runtime: "full" or "no-spec"
|
review_mode: '' # set at runtime: "full" or "no-spec"
|
||||||
|
story_key: '' # set at runtime when discovered from sprint status
|
||||||
---
|
---
|
||||||
|
|
||||||
# Step 1: Gather Context
|
# Step 1: Gather Context
|
||||||
|
|
@ -23,8 +24,8 @@ review_mode: '' # set at runtime: "full" or "no-spec"
|
||||||
- When multiple phrases match, prefer the most specific match (e.g., "branch diff" over bare "diff").
|
- When multiple phrases match, prefer the most specific match (e.g., "branch diff" over bare "diff").
|
||||||
- **If a clear match is found:** Announce the detected mode (e.g., "Detected intent: review staged changes only") and proceed directly to constructing `{diff_output}` using the corresponding sub-case from instruction 3. Skip to instruction 4 (spec question).
|
- **If a clear match is found:** Announce the detected mode (e.g., "Detected intent: review staged changes only") and proceed directly to constructing `{diff_output}` using the corresponding sub-case from instruction 3. Skip to instruction 4 (spec question).
|
||||||
- **If no match from invocation text, check sprint tracking.** Look for a sprint status file (`*sprint-status*`) in `{implementation_artifacts}` or `{planning_artifacts}`. If found, scan for any story with status `review`. Handle as follows:
|
- **If no match from invocation text, check sprint tracking.** Look for a sprint status file (`*sprint-status*`) in `{implementation_artifacts}` or `{planning_artifacts}`. If found, scan for any story with status `review`. Handle as follows:
|
||||||
- **Exactly one `review` story:** Suggest it: "I found story {{story-id}} in `review` status. Would you like to review its changes? [Y] Yes / [N] No, let me choose". If confirmed, use the story context to determine the diff source (branch name derived from story slug, or uncommitted changes). If declined, fall through to instruction 2.
|
- **Exactly one `review` story:** Set `{story_key}` to the story's key (e.g., `1-2-user-auth`). Suggest it: "I found story {{story-id}} in `review` status. Would you like to review its changes? [Y] Yes / [N] No, let me choose". If confirmed, use the story context to determine the diff source (branch name derived from story slug, or uncommitted changes). If declined, clear `{story_key}` and fall through to instruction 2.
|
||||||
- **Multiple `review` stories:** Present them as numbered options alongside a manual choice option. Wait for user selection. Then use the selected story's context to determine the diff source as in the single-story case above, and proceed to instruction 3.
|
- **Multiple `review` stories:** Present them as numbered options alongside a manual choice option. Wait for user selection. If the user selects a story, set `{story_key}` to the selected story's key and use the selected story's context to determine the diff source as in the single-story case above, and proceed to instruction 3. If the user selects the manual choice, clear `{story_key}` and fall through to instruction 2.
|
||||||
- **If no match and no sprint tracking:** Fall through to instruction 2.
|
- **If no match and no sprint tracking:** Fall through to instruction 2.
|
||||||
|
|
||||||
2. HALT. Ask the user: **What do you want to review?** Present these options:
|
2. HALT. Ask the user: **What do you want to review?** Present these options:
|
||||||
|
|
|
||||||
|
|
@ -13,27 +13,20 @@ failed_layers: '' # set at runtime: comma-separated list of layers that failed o
|
||||||
|
|
||||||
## INSTRUCTIONS
|
## INSTRUCTIONS
|
||||||
|
|
||||||
1. Launch parallel subagents. Each subagent gets NO conversation history from this session:
|
1. If `{review_mode}` = `"no-spec"`, note to the user: "Acceptance Auditor skipped — no spec file provided."
|
||||||
|
|
||||||
- **Blind Hunter** -- Invoke the `bmad-review-adversarial-general` skill in a subagent. Pass `content` = `{diff_output}` only. No spec, no project access.
|
2. Launch parallel subagents without conversation context. If subagents are not available, generate prompt files in `{implementation_artifacts}` — one per reviewer role below — and HALT. Ask the user to run each in a separate session (ideally a different LLM) and paste back the findings. When findings are pasted, resume from this point and proceed to step 3.
|
||||||
|
|
||||||
- **Edge Case Hunter** -- Invoke the `bmad-review-edge-case-hunter` skill in a subagent. Pass `content` = `{diff_output}`. This subagent has read access to the project.
|
- **Blind Hunter** — receives `{diff_output}` only. No spec, no context docs, no project access. Invoke via the `bmad-review-adversarial-general` skill.
|
||||||
|
|
||||||
- **Acceptance Auditor** (only if `{review_mode}` = `"full"`) -- A subagent that receives `{diff_output}`, the content of the file at `{spec_file}`, and any loaded context docs. Its prompt:
|
- **Edge Case Hunter** — receives `{diff_output}` and read access to the project. Invoke via the `bmad-review-edge-case-hunter` skill.
|
||||||
> You are an Acceptance Auditor. Review this diff against the spec and context docs. Check for: violations of acceptance criteria, deviations from spec intent, missing implementation of specified behavior, contradictions between spec constraints and actual code. Output findings as a markdown list. Each finding: one-line title, which AC/constraint it violates, and evidence from the diff.
|
|
||||||
|
|
||||||
2. **Subagent failure handling**: If any subagent fails, times out, or returns empty results, append the layer name to `{failed_layers}` (comma-separated) and proceed with findings from the remaining layers.
|
- **Acceptance Auditor** (only if `{review_mode}` = `"full"`) — receives `{diff_output}`, the content of the file at `{spec_file}`, and any loaded context docs. Its prompt:
|
||||||
|
> You are an Acceptance Auditor. Review this diff against the spec and context docs. Check for: violations of acceptance criteria, deviations from spec intent, missing implementation of specified behavior, contradictions between spec constraints and actual code. Output findings as a Markdown list. Each finding: one-line title, which AC/constraint it violates, and evidence from the diff.
|
||||||
|
|
||||||
3. If `{review_mode}` = `"no-spec"`, note to the user: "Acceptance Auditor skipped — no spec file provided."
|
3. **Subagent failure handling**: If any subagent fails, times out, or returns empty results, append the layer name to `{failed_layers}` (comma-separated) and proceed with findings from the remaining layers.
|
||||||
|
|
||||||
4. **Fallback** (if subagents are not available): Generate prompt files in `{implementation_artifacts}` -- one per active reviewer:
|
4. Collect all findings from the completed layers.
|
||||||
- `review-blind-hunter.md` (always)
|
|
||||||
- `review-edge-case-hunter.md` (always)
|
|
||||||
- `review-acceptance-auditor.md` (only if `{review_mode}` = `"full"`)
|
|
||||||
|
|
||||||
HALT. Tell the user to run each prompt in a separate session and paste back findings. When findings are pasted, resume from this point and proceed to step 3.
|
|
||||||
|
|
||||||
5. Collect all findings from the completed layers.
|
|
||||||
|
|
||||||
|
|
||||||
## NEXT
|
## NEXT
|
||||||
|
|
|
||||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue