# Systèmes de règles et orientation du comportement (/fr/docs/verdent-for-vscode/agents-rules/rule-systems)

> Contrôler le comportement de Verdent grâce aux systèmes de règles



Les fichiers de règles sont des documents Markdown qui définissent comment Verdent se comporte et répond pendant les sessions de codage. Ils orientent le comportement de l'agent IA, le formatage des sorties, la prise de décision et le respect des standards du projet.

**Objectif :** Les règles vous permettent de personnaliser le comportement de Verdent sans modifier le code ou les paramètres. Elles établissent des conventions de codage, des modèles préférés, un style de communication et des préférences d'exécution des tâches qui persistent entre les sessions.

**Fonctionnement des règles :** Verdent se réfère en continu aux fichiers de règles pendant les conversations, en appliquant les directives à la génération de code, à l'analyse, à la documentation et à la prise de décision. Les règles influencent chaque réponse de l'agent pour garantir la cohérence avec les préférences de l'utilisateur.

**Trois catégories :**

* **Préférences globales** (VERDENT.md) - Style de codage personnel, préférences de langue
* **Standards spécifiques au projet** (AGENTS.md) - Conventions d'équipe, modèles architecturaux
* **Personnalisation des plans** (Plan.md) - Format et contenu de sortie du Plan Mode

**Priorité des règles :** En cas de conflit, Verdent applique la priorité suivante : **AGENTS.md** (la plus élevée) → **VERDENT.md** (moyenne) → **valeurs par défaut** (la plus basse)

***

## Règles utilisateur (VERDENT.md) [#règles-utilisateur-verdentmd]

VERDENT.md définit des préférences globales qui s'appliquent à tous les projets et sessions. Il établit le style de codage personnel, les outils préférés, les préférences de communication et les comportements par défaut.

### Emplacement et portée [#emplacement-et-portée]

**Emplacement du fichier :** `~/.verdent/VERDENT.md`

**Portée :** Globale à tous les projets

**Accès :**

* Paramètres → Règles → Règles utilisateur
* Édition directe du fichier à `~/.verdent/VERDENT.md`

**Prise d'effet des modifications :** Les règles s'appliquent immédiatement dans les nouvelles conversations et influencent les réponses de la conversation en cours.

***

### Cas d'usage [#cas-dusage]

<Tabs>
  <Tab title="Préférences de codage">
    **Préférences de codage**

    * Style d'indentation (2 espaces, 4 espaces, tabulations)
    * Conventions de nommage (camelCase, snake\_case, PascalCase)
    * Fonctionnalités de langage préférées (ES6+, mode strict TypeScript, indications de type)

    Définissez votre style de codage personnel et vos conventions appliquées à tous les projets.
  </Tab>

  <Tab title="Langue de sortie">
    **Langue de sortie**

    * Langue de réponse par défaut (par exemple, "Répondre toujours en espagnol")
    * Gestion des termes techniques ("Utiliser des termes anglais lorsqu'aucun équivalent français n'existe")

    Contrôlez la langue que Verdent utilise dans ses réponses et explications.
  </Tab>

  <Tab title="Commentaires de code">
    **Commentaires de code**

    * Niveau de détail préféré ("Commentaires détaillés" contre "Commentaires minimaux uniquement")
    * Langue des commentaires ("Rédiger les commentaires en français")

    Précisez la quantité et la langue dans laquelle le code doit être commenté.
  </Tab>

  <Tab title="Documentation">
    **Style de documentation**

    * Comment le code doit être documenté (JSDoc, TSDoc, docstrings)
    * Inclure des exemples d'usage dans la documentation

    Définissez les standards de documentation de API et du format de documentation du code.
  </Tab>

  <Tab title="Communication">
    **Communication**

    * Ton et niveau de détail des réponses ("Explications brèves" contre "Explications détaillées")
    * Style d'explication ("Montrer le code d'abord, expliquer ensuite")

    Personnalisez la façon dont Verdent communique et vous présente l'information.
  </Tab>
</Tabs>

***

### Format et syntaxe [#format-et-syntaxe]

VERDENT.md utilise un format Markdown simple avec des puces ou des listes numérotées.

**Structure :**

```markdown
# User Rules

## Code Style Preferences
- Always use TypeScript strict mode
- Prefer functional components in React
- Include JSDoc comments for exported functions

## Documentation
- Add JSDoc comments for all exported functions
- Include usage examples in component documentation

## Communication
- Provide explanations before showing code
- Highlight breaking changes explicitly
```

**Style de rédaction :**

* Utilisez un langage clair et directif ("Toujours utiliser...", "Préférer...", "Ne jamais...")
* Organisez en sections logiques avec des titres
* Puces pour chaque règle individuelle
* Soyez précis sur le comportement souhaité

***

### Exemples par type de développeur [#exemples-par-type-de-développeur]

<Tabs>
  <Tab title="TypeScript">
    ```markdown
    # User Rules

    ## TypeScript Preferences
    - Use strict mode in tsconfig.json
    - Prefer interfaces over type aliases for object shapes
    - Include return types on all functions
    - Use const assertions where appropriate

    ## Code Organization
    - One component per file
    - Named exports instead of default exports
    - Organize imports: external, internal, types

    ## Documentation
    - TSDoc comments for public APIs
    - Include @param and @returns tags
    ```

    **Application :** Lorsque vous demandez à Verdent de créer un nouveau composant React, il va automatiquement :

    * Utiliser TypeScript en mode strict
    * Créer un export nommé (pas un export par défaut)
    * Ajouter des commentaires TSDoc avec des balises @param/@returns
    * Organiser les imports par catégorie
  </Tab>

  <Tab title="Python Data Science">
    ```markdown
    # User Rules

    ## Python Style
    - Follow PEP 8 conventions
    - Use type hints for function signatures
    - Prefer list comprehensions over map/filter

    ## Data Analysis
    - Use pandas for data manipulation
    - Include DataFrame.head() after transformations
    - Document assumptions about data

    ## Output Format
    - Show shape and info() after operations
    - Include visualization examples
    ```

    **Application :** Lorsque vous demandez à Verdent d'écrire du code d'analyse de données, il va :

    * Utiliser pandas pour les opérations sur les données
    * Inclure des indications de type sur toutes les fonctions
    * Afficher DataFrame.head() et shape après les transformations
    * Ajouter des commentaires en ligne documentant les hypothèses sur les données
  </Tab>

  <Tab title="Full-Stack JS">
    ```markdown
    # User Rules

    ## JavaScript Preferences
    - Use ES6+ features (arrow functions, destructuring)
    - Async/await over promises
    - Template literals for string interpolation

    ## Testing
    - Jest for unit tests
    - Include test cases for edge conditions
    - Aim for 80%+ code coverage

    ## Code Review
    - Flag potential performance issues
    - Suggest security improvements
    ```

    **Application :** Verdent va :

    * Écrire du JavaScript moderne avec la syntaxe ES6+
    * Utiliser async/await plutôt que des chaînes de promesses
    * Générer des tests Jest visant 80 % de couverture
    * Identifier de manière proactive les problèmes de performance et de sécurité
  </Tab>

  <Tab title="Multilingue">
    ```markdown
    # User Rules

    ## Communication
    - Always respond in French
    - Use technical English terms when no French equivalent exists
    - Provide French variable/function names when appropriate

    ## Code Comments
    - Write comments in French
    - Documentation in both French and English
    ```

    **Application :** Toutes les réponses de Verdent seront en français, avec les termes techniques en anglais lorsque cela est pertinent. Les commentaires de code et la documentation suivront vos préférences de langue.
  </Tab>

  <Tab title="Minimaliste">
    ```markdown
    # User Rules

    ## Code Style
    - Minimal comments - code should be self-documenting
    - Short, focused functions (< 20 lines)
    - Avoid unnecessary abstractions

    ## Output Preferences
    - Brief explanations
    - Show code first, explain after
    - No verbose documentation unless requested
    ```

    **Application :** Verdent va :

    * Générer du code concis et auto-documenté
    * Garder les fonctions à moins de 20 lignes
    * Fournir de brèves explications après avoir montré le code
    * Éviter les commentaires verbeux à moins que vous ne le demandiez explicitement
  </Tab>
</Tabs>

***

### Comment créer et modifier [#comment-créer-et-modifier]

<Tabs>
  <Tab title="Menu Paramètres">
    **Recommandé pour la plupart des utilisateurs**

    1. Sélectionnez le bouton **Paramètres** dans la barre supérieure de Verdent
    2. Sélectionnez **Règles** dans le menu déroulant
    3. Choisissez **Règles utilisateur**
    4. Le fichier s'ouvre dans l'éditeur VS Code
    5. Modifiez au format Markdown
    6. Enregistrez le fichier (`Cmd+S` / `Ctrl+S`)

    Cette méthode localise automatiquement le fichier et l'ouvre dans votre éditeur par défaut.
  </Tab>

  <Tab title="Édition directe du fichier">
    **Recommandé pour les utilisateurs avancés**

    1. Accédez à `~/.verdent/VERDENT.md`
    2. Ouvrez-le dans un éditeur de texte quelconque
    3. Modifiez le contenu Markdown
    4. Enregistrez les modifications

    Cette méthode est plus rapide si vous préférez travailler directement avec les fichiers de configuration.
  </Tab>
</Tabs>

***

## Règles de projet (AGENTS.md) [#règles-de-projet-agentsmd]

AGENTS.md définit des règles spécifiques au projet qui contrôlent le comportement de l'agent pour le projet en cours. Il établit les standards de codage de l'équipe, les modèles architecturaux, les exigences de test et les flux de travail de développement propres au projet.

### Emplacement et portée [#emplacement-et-portée-1]

**Emplacement du fichier :** Répertoire racine du projet

**Portée :** Le projet en cours uniquement

**Contrôle de version :** Peut être commité dans git pour un partage à l'échelle de l'équipe

**Accès :**

* Paramètres → Règles → Règles de projet
* Édition directe à `<project-root>/AGENTS.md`

***

### Cas d'usage [#cas-dusage-1]

<Tabs>
  <Tab title="Conventions d'équipe">
    **Conventions d'équipe**

    Standards de codage partagés suivis par tous les membres de l'équipe :

    * Indentation cohérente dans toute l'équipe
    * Conventions de nommage pour les composants/fonctions
    * Modèles d'organisation des fichiers

    Appliquez un style de codage cohérent dans toute l'équipe de développement.
  </Tab>

  <Tab title="Architecture">
    **Modèles architecturaux**

    Modèles de conception propres au projet :

    * MVC, microservices, structure de monorepo
    * Approche de gestion d'état (Redux, Context, Zustand)
    * Modèles de conception API (REST, GraphQL)

    Définissez les décisions architecturales et les modèles du projet.
  </Tab>

  <Tab title="Tests">
    **Exigences de test**

    Couverture de test attendue et frameworks :

    * Seuils de couverture minimaux (80 %, 90 %)
    * Frameworks de test (Jest, pytest, Vitest)
    * Conventions de nommage des fichiers de test

    Établissez des standards de test et des critères de qualité pour le projet.
  </Tab>

  <Tab title="Flux de travail">
    **Flux de travail de développement**

    Commandes de build, procédures de déploiement, directives de PR :

    * Comment exécuter les tests (`pnpm test`, `npm run test`)
    * Commandes de build pour des paquets spécifiques
    * Exigences de format de titre de PR

    Documentez les flux de travail et procédures de développement de l'équipe.
  </Tab>

  <Tab title="Technologie">
    **Contraintes technologiques**

    Bibliothèques et versions de framework approuvées :

    * Dépendances autorisées
    * Exigences de version du framework
    * Support de plateforme (iOS 14+, Android API 26+)

    Contrôlez les choix de pile technologique et maintenez la cohérence.
  </Tab>
</Tabs>

**Collaboration en équipe :** AGENTS.md est stocké à la racine du projet et peut être commité dans le contrôle de version, garantissant que tous les membres de l'équipe travaillent avec un comportement d'agent cohérent.

<Tip>
  Partagez AGENTS.md avec votre équipe via le contrôle de version pour garantir un comportement d'IA cohérent chez tous les membres de l'équipe.
</Tip>

***

### Format et syntaxe [#format-et-syntaxe-1]

AGENTS.md utilise un format Markdown avec des sections structurées et des puces, semblable à VERDENT.md mais axé sur les exigences propres au projet.

**Structure :**

```markdown
# AGENTS.md

## Dev environment tips
- Command for navigating workspace
- Installation commands
- Environment setup instructions

## Testing instructions
- Test execution commands
- Coverage requirements
- CI/CD integration details

## PR instructions
- Title format requirements
- Pre-commit checklist
- Review guidelines
```

**Style de rédaction :**

* Langage impératif et directif
* Organisé par domaine de flux de travail (développement, tests, déploiement)
* Commandes et procédures spécifiques
* Standards à l'échelle de l'équipe, pas des préférences personnelles

***

### Exemples par type de projet [#exemples-par-type-de-projet]

<Tabs>
  <Tab title="Monorepo">
    ```markdown
    # AGENTS.md

    ## Dev environment tips
    - Use `pnpm dlx turbo run where <project_name>` to jump to a package
    - Run `pnpm install --filter <project_name>` to add package to workspace
    - Check the name field in package.json to confirm the right name

    ## Testing instructions
    - Run `pnpm turbo run test --filter <project_name>` for all checks
    - From package root: `pnpm test`
    - Focus on one test: `pnpm vitest run -t "<test name>"`
    - Fix all errors before merge

    ## PR instructions
    - Title format: [<project_name>] <Title>
    - Always run `pnpm lint` and `pnpm test` before committing
    ```

    **Application :** Lors du travail sur ce monorepo, Verdent va :

    * Utiliser les commandes turbo pour la navigation et les tests
    * Formater les titres de PR avec le préfixe du nom du projet
    * Exécuter les commandes lint et test avant de suggérer des commits
  </Tab>

  <Tab title="React/TypeScript">
    ```markdown
    # AGENTS.md

    ## Code Standards
    - Use functional components with hooks
    - TypeScript strict mode required
    - Named exports only (no default exports)
    - PropTypes or TypeScript interfaces for all components

    ## File Organization
    - One component per file
    - Components in `src/components/`
    - Hooks in `src/hooks/`
    - Utils in `src/utils/`

    ## Testing
    - Jest + React Testing Library
    - Test all user interactions
    - 80%+ coverage required
    ```

    **Application :** Tous les composants React que Verdent crée vont :

    * Utiliser des composants fonctionnels avec des hooks
    * Inclure des interfaces TypeScript
    * Être placés dans le bon répertoire
    * Inclure des tests Jest visant 80 % de couverture
  </Tab>

  <Tab title="API backend">
    ```markdown
    # AGENTS.md

    ## API Standards
    - All endpoints include input validation
    - Use async/await for asynchronous operations
    - Consistent error format: { error: string, code: number }
    - Rate limiting on public endpoints

    ## Security
    - Never log sensitive data (passwords, tokens, PII)
    - Parameterized queries only (prevent SQL injection)
    - Validate and sanitize all inputs

    ## Testing
    - Unit tests for all business logic
    - Integration tests for API endpoints
    - Test success and error cases
    ```

    **Application :** Lors de la création de points de terminaison API, Verdent va :

    * Ajouter automatiquement la validation des entrées
    * Utiliser des requêtes paramétrées pour les opérations de base de données
    * Générer des tests pour les cas de succès et d'échec
    * Éviter de journaliser des données sensibles
  </Tab>

  <Tab title="Application mobile">
    ```markdown
    # AGENTS.md

    ## Platform Support
    - iOS 14+ and Android API 26+
    - React Native 0.72+
    - Test on both platforms before PR

    ## State Management
    - Use Redux Toolkit
    - Async operations with Redux Thunk
    - Normalize state shape

    ## Performance
    - Images: WebP format, max 500KB
    - Bundle size: monitor with bundle analyzer
    - FlatList for long lists (>20 items)
    ```

    **Application :** Le code de l'application mobile va :

    * Prendre en charge les versions de plateforme minimales
    * Utiliser Redux Toolkit pour l'état
    * Optimiser les images au format WebP
    * Utiliser FlatList pour la performance sur les longues listes
  </Tab>

  <Tab title="Python Django">
    ```markdown
    # AGENTS.md

    ## Django Conventions
    - Follow Django best practices and PEP 8
    - Class-based views preferred
    - Django ORM for database operations
    - Migrations: never edit generated files

    ## Testing
    - pytest-django for all tests
    - Factory Boy for test fixtures
    - Coverage must be 90%+

    ## Deployment
    - Docker compose for local development
    - Environment variables in .env (never committed)
    - Run migrations before deployment
    ```

    **Application :** Le code Django va :

    * Utiliser des vues basées sur des classes
    * Utiliser l'ORM Django plutôt que du SQL brut
    * Générer des tests pytest avec des fixtures Factory Boy
    * Viser une couverture de test de 90 % ou plus
  </Tab>
</Tabs>

***

### Différences avec VERDENT.md [#différences-avec-verdentmd]

**Portée :**

* **VERDENT.md :** Préférences personnelles pour tous les projets
* **AGENTS.md :** Standards d'équipe pour un projet spécifique uniquement

**Priorité :**

* **AGENTS.md :** Priorité plus élevée - remplace les règles utilisateur pour la cohérence du projet
* **VERDENT.md :** Priorité plus basse - s'applique en l'absence de conflit avec une règle de projet

**Axe du contenu :**

* **VERDENT.md :** Style de codage individuel, préférences de communication, outils personnels
* **AGENTS.md :** Conventions d'équipe, architecture du projet, flux de travail partagés, pile technologique

**Contrôle de version :**

* **VERDENT.md :** Non partagé - reste sur la machine de l'individu
* **AGENTS.md :** Commité dans git - partagé avec toute l'équipe

**Stockage :**

* **VERDENT.md :** `~/.verdent/VERDENT.md` (global)
* **AGENTS.md :** Répertoire racine du projet (spécifique au projet)

**Exemple de résolution de conflit :**

```
VERDENT.md: "I prefer 2-space indentation"
AGENTS.md: "This project uses 4-space indentation"
→ Result: 4-space indentation (team standard wins)
```

**Quand utiliser lequel :**

* **VERDENT.md :** Préférences personnelles que vous souhaitez appliquer à tous les projets
* **AGENTS.md :** Standards que toute l'équipe doit suivre pour ce projet

***

## Règles de plan (Plan.md) [#règles-de-plan-planmd]

Plan.md personnalise le contenu et le format des plans générés en Plan Mode. Il contrôle le niveau de détail des plans, les sections incluses, les préférences de formatage et les informations affichées.

### Emplacement et portée [#emplacement-et-portée-2]

**Emplacement du fichier :** \~/.verdent/plan\_settings.json

**Portée :** Globale à tous les projets

**Application :** Uniquement appliqué pendant le Plan Mode lors de la génération de plans

**Accès :**

* Paramètres → Règles → Règles de plan
* Édition directe du fichier à \~/.verdent/plan\_settings.json

***

### Cas d'usage [#cas-dusage-2]

<Tabs>
  <Tab title="Structure du plan">
    **Structure du plan**

    Définissez les sections à inclure :

    * Résumé, prérequis, étapes, vérification
    * Évaluation des risques, procédures de retour en arrière
    * Estimations de temps, chemin critique

    Contrôlez les sections et informations qui apparaissent dans chaque plan.
  </Tab>

  <Tab title="Niveau de détail">
    **Niveau de détail**

    Contrôlez la granularité :

    * Vue d'ensemble de haut niveau (phases de 1 à 2 heures chacune)
    * Étapes de mise en œuvre détaillées (tâches de 15 à 30 minutes)
    * Spécificités au niveau des fonctions (signatures, chemins de fichiers)

    Ajustez le degré de granularité et de précision des plans de mise en œuvre.
  </Tab>

  <Tab title="Format">
    **Préférences de format**

    Choisissez le style de présentation :

    * Listes numérotées contre puces
    * Extraits de code contre descriptions
    * Diagrammes (décrits verbalement)

    Personnalisez le formatage et l'affichage des informations du plan.
  </Tab>

  <Tab title="Information">
    **Inclusion d'informations**

    Précisez des éléments supplémentaires :

    * Estimations de temps en ligne
    * Niveaux de risque (faible/moyen/élevé)
    * Attribution des rôles pour la collaboration en équipe
    * Exigences de test mises en avant

    Ajoutez du contexte et des métadonnées pour rendre les plans plus actionnables.
  </Tab>
</Tabs>

***

### Format et syntaxe [#format-et-syntaxe-2]

Plan.md utilise un format Markdown avec des sections décrivant la structure et le contenu de plan souhaités.

**Structure :**

```markdown

---
name: Plan Rules
version: 1.0.0
last_updated: 2025-11-26
---

## Plan Structure
- Start with brief summary (2-3 sentences)
- Include estimated time for each major step
- List prerequisites before implementation steps
- Identify potential risks

## Level of Detail
- Break tasks into subtasks of 15-30 minutes
- Include specific file paths for modifications
- List functions/components to create/modify

## Format
- Use numbered lists for sequential steps
- Use bullet points for options
- Include code snippets for complex changes
```

***

### Exemples par style de planification [#exemples-par-style-de-planification]

<Tabs>
  <Tab title="Technique détaillé">
    ```markdown
    ---
    name: Detailed Technical
    version: 1.0.0
    last_updated: 2025-11-26
    ---

    ## Plan Structure
    - Executive summary (2-3 sentences)
    - Prerequisites and dependencies
    - Numbered implementation steps
    - Testing and verification strategy
    - Rollback procedures

    ## Level of Detail
    - Break into 20-30 minute tasks
    - Specific file paths for all modifications
    - Function signatures for new code
    - Database schema changes with migration steps

    ## Format
    - Numbered lists for sequence
    - Code blocks for complex logic
    - Diagrams for architecture changes (describe verbally)
    ```

    **Application :** Les plans incluront :

    * Un résumé exécutif en haut
    * Des découpages de tâches de 20 à 30 minutes
    * Des chemins de fichiers spécifiques comme `src/components/Auth/Login.tsx`
    * Des signatures de fonction comme `async function authenticateUser(credentials: UserCredentials): Promise<AuthResult>`
    * Des procédures de test et de retour en arrière
  </Tab>

  <Tab title="Stratégique de haut niveau">
    ```markdown
    ---
    name: High-Level Strategic
    version: 1.0.0
    last_updated: 2025-11-26
    ---

    ## Plan Structure
    - Brief overview (1 paragraph)
    - Major phases only (3-5 high-level steps)
    - Key decisions and trade-offs
    - Success criteria

    ## Level of Detail
    - High-level phases (1-2 hours each)
    - Avoid implementation specifics
    - Focus on approach and strategy

    ## Format
    - Bullet points for flexibility
    - Minimal code examples
    - Emphasize "why" over "how"
    ```

    **Application :** Les plans seront de haut niveau, en se concentrant sur :

    * Une approche stratégique en 3 à 5 phases majeures
    * Des explications sur le "pourquoi" plutôt que sur les détails de mise en œuvre
    * Des points de décision et compromis
    * Des critères de succès sans mise en œuvre spécifique
  </Tab>

  <Tab title="Attentif au temps">
    ```markdown
    ---
    name: Time-Conscious
    version: 1.0.0
    last_updated: 2025-11-26
    ---

    ## Plan Structure
    - Time estimates for each step
    - Total project duration estimate
    - Parallel tasks identified
    - Critical path highlighted

    ## Level of Detail
    - Tasks sized to 30-minute increments
    - Dependencies clearly marked
    - Blocking operations identified

    ## Format
    - Include time estimates inline
    - Mark parallel tasks
    - Highlight critical path with bold
    ```

    **Application :** Les plans incluront :

    * Chaque étape avec une estimation de temps : "Créer le middleware d'authentification (45 minutes)"
    * Durée totale : "Estimation totale : 6 heures"
    * Tâches parallèles indiquées : "Peut être réalisé en parallèle avec l'étape 3"
    * Chemin critique en gras pour montrer les opérations bloquantes
  </Tab>

  <Tab title="Axé sur les risques">
    ```markdown
    ---
    name: Risk-Focused
    version: 1.0.0
    last_updated: 2025-11-26
    ---

    ## Plan Structure
    - Risk assessment for each phase
    - Mitigation strategies included
    - Rollback procedures defined
    - Testing requirements emphasized

    ## Level of Detail
    - Identify potential failure points
    - Document error handling approach
    - Include recovery procedures

    ## Format
    - Risk levels: low, medium, high
    - Separate "Risks" section for each phase
    - Mitigation steps in sub-bullets
    ```

    **Application :** Chaque phase inclura :

    * Évaluation des risques : "Risque : élevé (migration de base de données en production)"
    * Atténuation : "Exécuter d'abord la migration en préproduction, vérifier avec des requêtes de test"
    * Retour en arrière : "Annuler la migration avec le script de retour en arrière en cas de problème"
  </Tab>

  <Tab title="Collaboration en équipe">
    ```markdown
    ---
    name: Team Collaboration
    version: 1.0.0
    last_updated: 2025-11-26
    ---

    ## Plan Structure
    - Role assignments for each task
    - Coordination points identified
    - Review checkpoints included
    - Communication requirements

    ## Level of Detail
    - Specify who handles each component
    - List integration points between team members
    - Include pair programming opportunities

    ## Format
    - Use mentions for role assignments
    - Mark collaboration points
    - Include "Review required" markers
    ```

    **Application :** Les plans préciseront :

    * "API backend (équipe backend) : créer les points de terminaison d'authentification"
    * "Point d'intégration : l'équipe frontend attend la spécification API de l'équipe backend"
    * "Revue requise : revue de l'équipe sécurité avant la fusion"
  </Tab>
</Tabs>

***

### Quand les règles de plan sont-elles appliquées ? [#quand-les-règles-de-plan-sont-elles-appliquées-]

**Application des règles de plan :**

* **Moment :** Uniquement appliquées pendant le Plan Mode lors de la génération de plans
* **Portée :** Contrôle le format et le contenu du plan, pas la génération de code
* **Indépendance :** N'entre pas en conflit avec VERDENT.md ou AGENTS.md

**Application des autres types de règles :**

* **VERDENT.md :** Appliqué en continu dans tous les modes (Agent, Plan, Chat)
* **AGENTS.md :** Appliqué en continu dans tous les modes pour un comportement spécifique au projet

**Exemple d'interaction :**

```
Plan Mode activated:
1. VERDENT.md: "Use TypeScript" → Applied to code in plan
2. AGENTS.md: "Follow project conventions" → Applied to approach
3. plan_rules.md: "Include time estimates" → Applied to plan format
→ Result: Plan shows TypeScript code following project conventions with time estimates
```

**Comportement spécifique au mode :**

* **Agent Mode :** VERDENT.md + AGENTS.md appliqués (pas de plan\_rules.md)
* **Plan Mode :** VERDENT.md + AGENTS.md + Plan.md tous appliqués
* **Chat Mode :** VERDENT.md + AGENTS.md appliqués (pas de Plan.md)

***

## Priorité des règles et résolution de conflits [#priorité-des-règles-et-résolution-de-conflits]

En cas de conflit entre règles, Verdent applique une priorité pour garantir un comportement cohérent.

### Ordre de priorité [#ordre-de-priorité]

**1. Règles de projet (AGENTS.md) - Priorité la plus élevée**Les règles spécifiques au projet remplacent les préférences globales. Les standards d'équipe ont priorité sur les préférences individuelles pour assurer la cohérence.

**2. Règles utilisateur (VERDENT.md) - Priorité moyenne**Les préférences globales s'appliquent lorsqu'aucune règle spécifique au projet n'est en conflit.

**3. Comportement par défaut - Priorité la plus basse**Les valeurs par défaut intégrées de Verdent s'appliquent lorsqu'aucune règle n'est spécifiée.

**Exemple de résolution de conflit :**

```
VERDENT.md: "Use 2-space indentation"
AGENTS.md: "Use 4-space indentation for this project"
→ Result: Verdent uses 4-space indentation (project rules win)
```

**Règles de plan :** Plan.md s'applique de manière indépendante pendant le Plan Mode et n'entre pas en conflit avec les règles utilisateur/projet. Il contrôle le format du plan, tandis que VERDENT.md et AGENTS.md contrôlent le style de code au sein du plan.

<Note>
  Les règles de plan n'affectent que le format de sortie du Plan Mode. Elles ne changent pas la façon dont Verdent analyse ou met en œuvre les solutions.
</Note>

<Tip>
  Retenez la priorité : AGENTS.md (la plus élevée) → VERDENT.md (moyenne) → valeurs par défaut (la plus basse). Les règles de projet gagnent toujours les conflits.
</Tip>

<Info>
  Les algorithmes détaillés de résolution de conflits, les mécanismes permettant de voir quelle règle est appliquée en cas de conflit, et les mécanismes de contournement pour la suspension temporaire des règles sont actuellement en développement.
</Info>

***

### Résolution des problèmes de conflits de règles [#résolution-des-problèmes-de-conflits-de-règles]

Lorsque vous observez un comportement inattendu qui contredit une règle, suivez cette stratégie de débogage :

#### Étape 1 : Identifier le conflit [#étape-1--identifier-le-conflit]

1. Observez le comportement inattendu qui contredit une règle
2. Vérifiez quelles règles pourraient s'appliquer à la situation
3. Recherchez les contradictions entre les fichiers de règles

#### Étape 2 : Vérifier la priorité des règles [#étape-2--vérifier-la-priorité-des-règles]

```
AGENTS.md (highest) → VERDENT.md (medium) → defaults (lowest)
```

Les règles de projet remplacent les préférences personnelles.

#### Étape 3 : Tester isolément [#étape-3--tester-isolément]

**Désactiver VERDENT.md :** Renommez ou videz temporairement le fichier, testez si le conflit se résout

**Tester sans AGENTS.md :** Travaillez dans le projet sans AGENTS.md pour isoler le comportement des règles utilisateur

**Nouvelle conversation :** Démarrez une session fraîche pour éliminer l'influence du contexte de conversation

***

### Scénarios de conflit courants [#scénarios-de-conflit-courants]

#### Scénario 1 : Conflit de formatage [#scénario-1--conflit-de-formatage]

```
VERDENT.md: "Use 2-space indentation"
AGENTS.md: "Use 4-space indentation"
→ Resolution: AGENTS.md wins (project standard)
→ Fix: Accept project standard or discuss with team
```

#### Scénario 2 : Règles contradictoires dans le même fichier [#scénario-2--règles-contradictoires-dans-le-même-fichier]

```
AGENTS.md:
- "Prefer functional components"
- "Use class components for complex state"
→ Resolution: Verdent interprets based on context
→ Fix: Clarify when each rule applies
```

Exemple de correction :

```markdown
- Prefer functional components for simple UI
- Use functional components with hooks for complex state
- Only use class components for legacy code maintenance
```

#### Scénario 3 : Règle trop vague [#scénario-3--règle-trop-vague]

```
"Write good tests"
→ Problem: What is "good"?
→ Fix: "Generate unit tests with 80%+ coverage, include edge cases"
```

***

### Stratégie de débogage [#stratégie-de-débogage]

**1. Test explicite :** Demandez à Verdent "Quelle règle suis-tu pour \[comportement spécifique] ?"

Exemple :

```
You: "Which rule are you following for indentation?"
Verdent: "I'm using 4-space indentation from AGENTS.md (line 12),
which overrides your VERDENT.md preference for 2-space indentation."
```

**2. Raffinement progressif :** Ajoutez de la précision aux règles ambiguës

<Tip>
  Lors du débogage de conflits de règles, désactivez temporairement les règles une par une pour isoler celle qui cause le comportement inattendu.
</Tip>

Avant :

```markdown
- Use appropriate error handling
```

Après :

```markdown
- Wrap async operations in try/catch blocks
- Return error objects with message and code fields
- Log errors with context (function name, input parameters)
```

**3. Marqueurs de priorité :** Utilisez "CRITIQUE :" ou "REQUIS :" pour les règles non négociables

```markdown
## Security Rules
- **CRITICAL:** Never log passwords, API keys, or tokens
- **REQUIRED:** All user inputs must be validated and sanitized
- Preferred: Use parameterized queries for database operations
```

***

### Bonnes pratiques pour la rédaction des règles [#bonnes-pratiques-pour-la-rédaction-des-règles]

**Être précis et directif :**

* Utilisez un langage clair et impératif ("Toujours utiliser...", "Ne jamais...", "Préférer...")
* Évitez les formulations ambiguës ("Essayer de..." → "Toujours...")
* Indiquez exactement ce que vous voulez, pas ce que vous ne voulez pas

**Bon exemple :**

```markdown
- Use async/await for asynchronous operations
- Include JSDoc comments for all exported functions
```

**À éviter :**

```markdown
- Try to use modern JavaScript features
- Add comments when necessary
```

**Organiser logiquement :**

* Regroupez les règles connexes sous des titres de section
* Séparez les préoccupations (style, tests, documentation, sécurité)
* Utilisez une structure cohérente entre les fichiers de règles

**Garder les règles maintenables :**

* Rédigez des règles concises (un concept par puce)
* Révisez et mettez à jour les règles au fil de l'évolution du projet
* Supprimez rapidement les règles obsolètes

**Prioriser les règles importantes :**

* Placez les règles critiques en premier dans chaque section
* Utilisez l'accentuation pour les standards non négociables ("**NE JAMAIS** commiter d'identifiants")
* Concentrez-vous sur les règles qui préviennent les bugs ou les problèmes de sécurité

**Tester l'efficacité des règles :**

* Vérifiez que Verdent suit les règles en pratique
* Démarrez une nouvelle conversation pour tester l'application des règles
* Affinez les règles en fonction du comportement réel de l'agent

**Équilibrer précision et flexibilité :**

* Trop précis → Comportement rigide qui ne s'adapte pas
* Trop vague → Comportement incohérent
* Visez des consignes claires laissant de la place à des décisions adaptées au contexte

**Considérations d'équipe (AGENTS.md) :**

* Impliquez l'équipe dans la création des règles
* Documentez la justification des règles non évidentes
* Concentrez les règles d'équipe sur les standards partagés, pas les préférences personnelles

***

## Voir aussi [#voir-aussi]

<CardGroup cols="2">
  <Card title="Gestion des sous-agents" icon="robot" href="/docs/verdent-for-vscode/agents-rules/subagent-management">
    Créez et gérez des sous-agents spécialisés pour des tâches spécifiques au projet
  </Card>

  <Card title="Bonnes pratiques : prompts" icon="message-lines" href="/docs/verdent-for-vscode/best-practices/prompts">
    Rédiger des prompts efficaces pour tirer le meilleur parti de VerdentP
  </Card>
</CardGroup>