7.8 KiB
| title | description | sidebar | ||
|---|---|---|---|---|
| Contexte du Projet | Comment project-context.md guide les agents IA avec les règles et préférences de votre projet |
|
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 solutioningbmad-create-story— informe la création de stories avec les patterns du projetbmad-dev-story— guide les décisions d'implémentationbmad-code-review— valide par rapport aux standards du projetbmad-quick-dev— applique les patterns lors de l'implémentation des spécifications techniquesbmad-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 :
## 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 :
## 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 :
# 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 :
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 :
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.
:::