GitLab Duo Agentic Chat : renforcez votre code avec les règles personnalisées

Transformez GitLab Duo d'un assistant IA générique en un expert en codage personnalisé pour votre équipe grâce aux règles personnalisées. Ne perdez plus de temps à corriger constamment les suggestions de l'IA qui utilisent les mauvaises versions de Java et des binaires Python incorrects ou qui vont à l'encontre de vos guides de style. Ce guide approfondi vous apprendra à créer des règles personnalisées intelligentes qui appliquent automatiquement vos normes de développement.

Nous aborderons les points suivants :

• Contrôle des versions : obligez l'IA à utiliser Java 8, gérez les environnements Python3 et générez du code C++ multi-plateforme
• Application du style : prévenez les anti-patterns C goto, appliquez les design patterns VueJS et assurez la conformité aux linters Ansible
• Automatisation DevSecOps : configurez des projets avec scans de sécurité CI/CD appropriés et normes de documentation

Chaque exemple inclut des projets GitLab fonctionnels à dupliquer, des configurations complètes et des démonstrations avant/après. Découvrez comment les systèmes bancaires maintiennent leur conformité à Java 8, comment les collecteurs IoT fonctionnent sur plusieurs plateformes et comment les composants VueJS suivent les normes de production de GitLab.

Premiers pas avec les règles personnalisées pour GitLab Duo Agentic Chat

Suivez la documentation pour créer des règles personnalisées pour GitLab Duo Agentic Chat dans le répertoire .gitlab/duo/chat-rules.md d'un projet GitLab nouveau ou existant dans votre IDE.

Vous pouvez commencer avec des instructions en saisie libre et itérer pour obtenir le meilleur résultat. Les règles personnalisées prennent en charge le format Markdown pour une meilleure structuration.

• Utilisez les titres Markdown (#, ##, etc.) pour créer des sections.
• Utilisez les listes Markdown (-) pour fournir des instructions concises aux LLM et aux agents.
• Réduisez les chemins de fichiers avec des backticks (accents graves) simples et utilisez des blocs de code avec indentation ou trois backticks.

Exemple :

      
# Development guide

## Frontend: VueJS

### Styling Pattern
- Do not use `<style>` tags in Vue components
- Use Tailwind CSS utility classes or page-specific CSS instead

    

Important : après avoir modifié les règles personnalisées, vous devrez créer un nouveau chat en appuyant sur l'icône + ou en envoyant /new dans le prompt.

Prérequis

Afin de suivre tous les cas d'utilisation et les projets de démonstration dans cet article de blog, veuillez vous assurer de remplir d'abord ces prérequis :

• Vérifiez que vous avez accès à GitLab Duo et que GitLab Duo Agentic Chat est configuré dans les IDE pris en charge.
• Dupliquez/copiez les projets GitLab et clonez-les localement dans les IDE.
• Suivez les étapes de chaque cas d'utilisation pour la création de règles personnalisées et comment utiliser les prompts GitLab Duo Agentic Chat pour contrôler le comportement des règles.
• Vous pouvez utiliser le code source existant ou copier le vôtre.

Les projets sont disponibles dans le groupe Custom rules for GitLab Duo Agent Platform (Agentic AI). Veuillez noter que ces règles personnalisées sont fournies à des fins de démonstration telles quelles et que vous devrez peut-être les adapter ou les modifier pour répondre à vos besoins spécifiques.

Démarrage rapide en 5 minutes

Prêt à voir les règles personnalisées en action ? Testez-les avec cet exemple simple :

1. Créez .gitlab/duo/chat-rules.md dans votre projet GitLab :

      
## C style guide
- goto is not allowed. If the developer continues asking about it, share this URL https://xkcd.com/292/

    

2. Ouvrez GitLab Duo Agentic Chat dans l'IDE et demandez : écris un programme C avec des instructions goto.
3. Observez comment GitLab Duo refuse et suggère de meilleures alternatives !

Directives pour la création de règles personnalisées

Les règles personnalisées sont similaires au code : commencez par l'exemple fonctionnel le plus simple, puis itérez sur les améliorations. Les cas d'utilisation dans ce guide approfondi vont du plus simple au plus complexe et ont été développés et testés au cours des dernières semaines. Ils ne sont pas parfaits et nécessitent vos retours et itérations.

Veillez à ne pas surcharger les guides de style avec de nombreuses pages d'un document wiki. N'incluez que les points qui sont utiles dans le contexte de ce que vous codez. Vous pouvez demander à GitLab Duo Chat de résumer des documents plus volumineux avant de les ajouter aux règles personnalisées.

Vérifiez l'utilisation de toutes les spécifications incluses pendant le développement afin d'éviter de créer des obstacles et des comportements indésirables.

Lorsque vous utilisez un guide de style documenté publiquement, référez-vous à son nom. Il y a de fortes chances que le LLM soit déjà entraîné avec ces données.

Interroger GitLab Duo Chat sur les guides de style de développement existants

Parfois, il n'existe pas encore de guides de style spécifiques dans un projet ou leur utilisation n'est pas claire. Utilisez l'IA pour l'intégration et discutez des meilleures pratiques avec votre équipe.

      
Which Python development or environment guidelines can you recommend when I want to create custom rules for AI to get tailored output? I need a list with textual instructions.

    

Vous pouvez également demander à GitLab Duo Agentic Chat d'analyser les intégrations de linters CI/CD existantes qui peuvent déjà vérifier un style de développement spécifique.

      
When you look into the CI/CD linter checks and configuration in the project, which development style guide can you summarize for me?

    

De nombreux exemples de cet article de blog sont basés sur ma propre expérience et mes points de friction en tant que développeur. J'ai également demandé à GitLab Duo d'extraire des guides de style de projets existants et j'ai utilisé les fonctionnalités de suggestions de code de GitLab Duo pour aider à l'auto-complétion des règles personnalisées existantes. Vous pouvez obtenir le même résultat en configurant markdown comme langage supplémentaire pour les fonctionnalités de suggestions de code de GitLab Duo dans les IDE.

Autres cas d'utilisation avec des règles personnalisées

Les sections suivantes fournissent un aperçu de guides de style spécifiques. Vous pouvez mapper des langages de programmation et des environnements similaires à vos cas d'utilisation en production.

• Prise en charge de versions et de plateformes : référez-vous à la section Java ci-dessous pour apprendre à forcer un standard de langage spécifique pour le code généré et créé. Vous pouvez appliquer un processus similaire pour les versions C++23 et antérieures, PHP 8, Ruby 3, etc. La section C++ ci-dessous montre comment indiquer des instructions à l'IA agentique avec la prise en charge multi-plateforme.
• Environnements de développement : référez-vous aux sections ci-dessous sur Python et Ansible. Indiquez l'environnement de développement, les binaires, les outils et plus encore. Vous pouvez également indiquer aux agents des informations de routage sur les emplacements des tests/scripts et la façon d'appliquer la conformité avec les linters.
• Design patterns : vous pouvez indiquer des design patterns complets avec VueJS comme exemple, en tirant parti des guides de style de développement de production de GitLab comme base.
• Workflows DevSecOps : configurez des pratiques DevSecOps complètes avec la configuration CI/CD pour des attributs CI/CD spécifiques et des valeurs par défaut pour le scan de sécurité, les tests et linters, et les outils de build. Les cas d'utilisation fréquemment demandés pour la mise en place de projets incluent la génération de documentation avec README.md et diagrammes d'architecture, les modèles de tickets et de merge requests, l'intégration, les exigences et les licences, et les flux Git avec .gitignore. Des techniques avancées avec règles personnalisées sont fournies pour les exigences de refactorisation et de modification du code.

Cas d'utilisation : prise en charge de versions et de plateformes

Le développement logiciel nécessite souvent des versions spécifiques de langages de programmation et de frameworks, ainsi qu'une prise en charge mono ou multi-plateforme. Les exemples suivants illustrent ces scénarios.

Exigences de version Java

Les environnements d'entreprise n'utilisent pas toujours la dernière version logicielle disponible. Ils s'appuient souvent sur des versions maintenues avec des correctifs de sécurité pendant une période plus longue. Par exemple, Java 7 et Java 8 sont encore utilisés dans certaines entreprises aujourd'hui.

Préciser systématiquement la version requise dans les prompts de chat peut être fastidieux et conduire à des erreurs humaines, même en cas d'un seul oubli.

      
Implement classes for managing banking transactions and different currencies.

    

L'exemple nécessitera des indications supplémentaires pour Java 8 :

      
Use Java 8 for the implementation.

    

Pour appliquer Java 8 de manière permanente, vous pouvez créer une règle personnalisée dans .gitlab/duo/chat-rules.md et ajouter éventuellement une URL d'epic de référence si un utilisateur vous pose des questions sur la modernisation du code :

      
## Java style guide


- Only Java 8 is allowed when suggesting and editing code.
- When the user asks about code modernization and Java 9 or 21, or newer, point them to this issue to contribute: https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-java-versions/-/issues/1

    

Une démonstration complète est disponible dans le projet Custom Rules – Java versions.

Les modifications résultantes sont disponibles dans cette merge request.

Prise en charge multi-plateforme C++ (Windows, Linux, macOS)

Le développement d'applications en C++ peut nécessiter une prise en charge multi-plateforme, notamment lors de l'exécution d'agents de service sur des systèmes utilisant Windows, Linux et macOS. Les applications sont profondément intégrées aux produits clients et une migration vers un langage plus moderne comme Go ou Rust n'est pas toujours possible ni pratique.

Maintenir du code qui fonctionne sur plusieurs plateformes peut être difficile en raison des différences dans les API de système d'exploitation, les chaînes d'outils, les versions de bibliothèques et les chemins de système de fichiers. Les équipes de développement sont souvent confrontés à plusieurs macros de préprocesseur #if defined et à des conditions imbriquées. Ils doivent alors ajouter du code et des tests personnalisés pour chaque plateforme prise en charge. Résultat : cette situation alourdit la dette technique et entraîne des défis de maintenance.

L'IA peut aider lors de la génération de code correct et spécifique à une plateforme, mais elle doit connaître ces exigences. Soit l'IA agentique comprendra le code source existant via un graphe de connaissances, soit les équipes devront fournir des instructions via des règles personnalisées et des prompts.

Essayons ce cas d'utilisation en pratique. Le projet Custom Rule – C++ platforms – IoT Sensor Data Collector implémente un collecteur de données de capteurs IoT et a des tâches ouvertes pour moderniser le code source et ajouter la prise en charge multi-plateforme pour Linux, Windows et macOS. Vous pouvez dupliquer le projet et le cloner localement.

Ouvrez le fichier .gitlab/duo/chat-rules.md et examinez ou ajoutez les règles personnalisées suivantes :

      
## C++ style guide

- The application runs on Linux, macOS and Windows. Generate code that handles the OS API differences.
- Use pre-processor macros for Windows and POSIX conventions for Unix (Linux, macOS).

## CI/CD Configuration

- Ensure that GitLab CI/CD jobs cover the different platform support. Use CI/CD job templates with extends where applicable.

    

Démarrez un nouveau chat et demandez de restructurer le code pour la prise en charge multi-plateforme.

      
Please help me restructure the code and ensure multi-platform support.

    

Vous pouvez également indiquer le numéro de ticket ou l'URL (ticket 3). GitLab Duo récupérera automatiquement le contenu du ticket depuis la plateforme GitLab et le mettra dans le contexte de l'IA.

      
Please help me implement issue 3

Please help me implement https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-cpp-platform-iot-sensor-data-collector/-/issues/3

    

Cas d'utilisation : environnements de développement

Les environnements de développement varient souvent entre les systèmes d'exploitation et les équipes, ce qui peut perturber les modèles d'IA qui génèrent du code ou suggèrent des modifications. Les cas d'utilisation suivants illustrent ces problèmes d'environnement et leurs solutions avec des règles personnalisées.

Environnement de développement Python 3

Un environnement de développement Python est généralement fourni avec le fichier exécutable python et le gestionnaire de paquets pip. Cependant, sur des systèmes comme MacOS ou Ubuntu, vous devez utiliser python3 et pip3 pour accéder aux versions plus récentes de Python 3. Cette approche peut entraîner une confusion lors de l'exécution de scripts Python, de la création d'environnements virtuels et de l'installation de dépendances de paquets.

Pour ce cas d'utilisation de règles personnalisées, j'ai installé Python en utilisant Homebrew, ce qui entraîne un fichier exécutable binaire appelé python3 et un gestionnaire de paquets pip3.

Configurez un environnement virtuel Python à titre d'exemple, installez les dépendances avec pip et exécutez l'application :

      
python -m venv myenv
source myenv/bin/activate

pip install -r requirements.txt

python script.py

    

Cela ne fonctionne pas comme prévu, car nous devons utiliser des binaires spécifiques avec la version 3 :

      
python3 -m venv myenv
source myenv/bin/activate

pip3 install -r requirements.txt

python3 script.py

    

Nous pouvons tester ce problème avec l'Agentic Chat pour les blocs de code suggérés et la demande d'approbation pour les commandes à exécuter. Le projet Custom Rule – Python3 Env Shop app implémente une application de boutique web en Python et fournit les chemins de fichiers exécutables Python par défaut dans son fichier README.md qui est généralement ajouté au contexte d'Agentic Chat.

Afin de résoudre le problème, examinez .gitlab/duo/chat-rules.md, qui contient les règles personnalisées suivantes pour appliquer les noms de fichiers exécutables Python.

      
## Python style guide

- For Python binaries, always use python3 and pip3 when suggesting or running shell commands.
- Detect the Python environment automatically when possible.

    

Vous pouvez également instruire les agents avec des routes prédéfinies pour rassembler des informations supplémentaires via l'appel d'outils et/ou le MCP, s'ils ne le font pas déjà automatiquement.

Ouvrez un nouvel Agentic Chat et demandez Comment exécuter cette application ? pour voir les règles personnalisées en action avec python3 et pip3 comme souhaité.

Le code source complet est disponible dans le projet Custom Rule – Python3 Env Shop app.

Conformité au linter Ansible

Le linter Ansible moderne pour les tâches d'Infrastructure-as-Code applique un guide de style strict, qui peut être vérifié avec ansible-lint : il détecte lorsque des valeurs booléennes (true/false) sont requises au lieu de chaînes (yes/no), les actions de modules intégrés qui requièrent le FQCN (Fully Qualified Collection Name) comme noms de paramètres, et les caractères invisibles de fin à supprimer. Les intégrations CLI et IDE, telles que l'extension VS Code Ansible par Red Hat aident les équipes à visualiser ces erreurs. Les LLM et les agents de chat ne génèrent pas toujours du code Ansible correct, ce qui force les équipes à le corriger manuellement.

Examinons le problème avec un cas d'utilisation concret. L'exemple suivant implémente un guide Ansible basique dans le projet Custom Rule – Ansible Environment pour configurer un serveur GitLab sur Ubuntu. Les valeurs booléennes sont incorrectement typées comme chaînes (yes/no), et les actions de modules intégrés ainsi que la suppression des espaces entraînent des problèmes supplémentaires.

Voyons comment nous pouvons créer des règles personnalisées pour aider les agents GitLab Duo à corriger les erreurs de linter Ansible et les empêcher de se reproduire à l'avenir.

Dupliquez et clonez le projet Custom Rule – Ansible Environment et ouvrez .gitlab/duo/chat-rules.md dans l'IDE pour inspecter les règles personnalisées :

      
## Ansible styleguide

- Boolean values in Ansible should be typed as "true" or "false" and never as string.
- Ansible module builtin actions must use the FQCN (Fully Qualified Collection Name).
- Always trim whitespaces in Ansible YAML.

    

Ouvrez un nouveau prompt GitLab Duo Agentic Chat et demandez à l'agent GitLab Duo le même guide de directives et de procédures opérationnelles Ansible :

      
Please help me fix the Ansible linter errors

    

Les agents analyseront le dépôt, demanderont d'exécuter des commandes ansible-lint, et examineront comment corriger les problèmes en suivant les règles personnalisées définies.

Vous pouvez inspecter les règles personnalisées et les modifications de code Ansible dans cette merge request dans le projet Custom Rule – Ansible Environment.

Exercice asynchrone : démarrez un nouveau projet où les règles personnalisées sont configurées par défaut et vérifiez que le guide de style correct est appliqué immédiatement.

Cas d'utilisation : design patterns

Cette section explore les design patterns et modèles à éviter, qui sont spécifiques aux langages et frameworks.

Éviter les anti-patterns avec C et les instructions goto

Voici une présentation plus approfondie de l'exemple de démarrage rapide, qui montre comment vous pouvez donner des instructions à l'IA agentique pour éviter l'anti-pattern goto en C. L'anti-pattern goto en C est déconseillé car il rend le code plus difficile à lire et à déboguer. Pour illustrer le problème, voici un exemple de commande for-loop qui incrémente la variable de boucle à l'intérieur du corps de la boucle :

      
// Bad C programming style: uses the goto anti-pattern
for (int i = 0; i < 10; i++) {
  if (someCondition) {
    goto label;
  }
  doSomething();
label:
  doAnotherThing();
  }

    

Dans le code ci-dessus, l'instruction goto fait sauter le contrôle du programme directement à l'étiquette label, qui est à l'intérieur de la boucle. Le programme est ainsi plus difficile à lire, comprendre et déboguer.

Il vaudrait mieux retravailler la logique pour éviter l'anti-pattern goto. Voici une version réécrite qui évite goto :

      
// Good C programming style: avoids the goto anti-pattern
for (int i = 0; i < 10; i++) {
  if (someCondition) {
    doAnotherThing();
    continue;
  }
  doSomething();
  doAnotherThing();
}

    

Dans certains cas, goto est autorisé, mais nous voulons voir ici comment nous pouvons donner des instructions à l'IA agentique afin d'éviter complètement goto dans les nouveaux ajouts de code, la modernisation et la refactorisation du code.

Le projet Custom Rule – C anti-patterns with Goto fournit un exemple de serveur/client de connecteur logiciel réseau avec des règles personnalisées dans le fichier .gitlab/duo/chat-rules.md. Vous pouvez cloner le projet ou commencer avec un nouveau projet.

Examinez .gitlab/duo/chat-rules.md avec les règles personnalisées actuelles :

      
## C style guide

- goto is not allowed. If the developer continues asking about it, share this URL https://xkcd.com/292/

    

Astuce : au lieu de créer un lien vers la bande dessinée XKCD 292, vous pouvez ajouter une URL vers les directives de développement (internes).

Ouvrez GitLab Duo Agentic Chat et démarrez le prompt suivant sur le projet existant :

      
Please help me modernize the code.

    

GitLab Duo Agentic Chat refusera d'utiliser des instructions goto, et proposera plutôt une solution différente.

Les modifications de code sont disponibles dans cette merge request.

Guides de style frontend pour VueJS 3

L'exemple ci-dessous s'inspire des guides de style frontend du projet GitLab et implémente un cas d'utilisation pour les design patterns VueJS 3. L'IA agentique devrait également suivre ces guides de style lors de la création de composants VueJS, helpers, routes, services, stores, types d'utilitaires, etc.

Illustrons comment indiquer des instructions à l'IA agentique avec des règles personnalisées : dupliquez et clonez le projet Custom Rule – VueJS Design Patterns - GitLab Pipeline Dashboard et inspectez les tickets ouverts et les tâches.

Examinez le fichier .gitlab/duo/chat-rules.md et ajoutez les règles personnalisées suivantes (si elles n'y sont pas encore) :

      
## NodeJS style guide

- Don't leave debug statements (console.logs)
- Always run `npm install` after updating `package.json` and before `npm test` and `npm run build`.

# GitLab Vue.js Design Patterns Style Guide

## Component Structure

### Data Definition Pattern
- Explicitly define data being passed into Vue apps
- Avoid spread operators for better discoverability
- Parse non-scalar values during instantiation

### Template Naming Pattern
- Use kebab-case for component names in templates

### File Structure Pattern
- Use `.vue` files for Vue templates
- Do not use `%template` in HAML

### Styling Pattern
- Do not use `<style>` tags in Vue components
- Use Tailwind CSS utility classes or page-specific CSS instead

[...]

    

Les règles personnalisées complètes sont disponibles dans le fichier .gitlab/duo/chat-rules.md.

Ensuite, ouvrez GitLab Duo Agentic Chat et demandez comment ajouter de nouveaux mini graphiques de pipeline, ou d'autres tâches que vous rencontrez. Astuce : vous pouvez référencer uniquement le ticket ou coller l'URL complète du ticket, et l'Agentic Chat recherchera les deux et extraira le titre et la description pour le contexte actuel.

      
Please help me implement issue 6

    

Les modifications de code qui en résultent sont disponibles dans cette merge request.

Remarque : le guide de style VueJS a été extrait du projet gitlab-org/gitlab grâce à GitLab Duo Agentic Chat avec le prompt suivant :

      
What is the development style guide for VueJS?

Can you print the styleguide as Markdown formatted list with headings.

Create a file in the repo, and only print the style guide rules there, no codeblocks.

    

Cas d'utilisation : workflows DevSecOps

Les workflows DevSecOps comprennent les meilleures pratiques pour la configuration initiale d'un projet avec des modèles de tickets/merge requests, .gitignore, la configuration GitLab CI/CD, la documentation README.md, les licences et bien plus encore. La section suivante explore une large gamme de cas d'utilisation. Vous pouvez vous en inspirer pour vos propres règles personnalisées.

Automatisation DevSecOps courante avec règles personnalisées :

• Configuration initiale de projet : création automatique de README, .gitignore, configuration CI/CD
• Valeurs par défaut de sécurité : application de test statique de sécurité des applications (SAST), scan des dépendances, détection des secrets
• Documentation : génération de templates de tickets/merge requests, diagrammes d'architecture

Un exemple de cas d'utilisation combiné est disponible dans le projet Custom Rule – DevSecOps workflows – Git README build tools issue MR templates. Vous pouvez explorer les règles personnalisées, et les dupliquer/cloner localement pour interroger l'Agentic Chat avec un nouveau prompt, tel que : Aide-moi à effectuer la configuration initiale de ce projet.

Les sections suivantes (aussi disponibles dans la vidéo ci-dessus) fournissent des prompts détaillés.

Templates de tickets et merge requests

Vous pouvez demander à l'IA agentique de créer des templates de tickets/merge requests s'ils sont manquants, et proposer d'ajouter des informations spécifiques au projet ou des étiquettes. Les agents interrogeront automatiquement l'API de GitLab en arrière-plan et intégreront la structure actuelle du projet dans un template.

      
## Issue and MR templates

- If no issue templates for `Default` and `Feature Proposal` exist in .gitlab/issue_templates, create them using the following raw template sources:

        Default: https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/raw/main/.gitlab/issue_templates/Default.md
        Feature Proposal: https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/raw/main/.gitlab/issue_templates/Feature%20Proposal.md

- If no default MR template `Default` exists in `.gitlab/merge_request_templates`, create them using the following raw template sources:

        Default: https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/raw/main/.gitlab/merge_request_templates/Default.md

- Update the project URLs, and available labels in the fetched templates accordingly, or remove anything unknown and let the user know about TODOs.
- Create a test issue/MR, when bootstrapping a new project.

    

Outils de build

Il existe une variété d'outils de build, de gestionnaires de paquets, de compilateurs, de constructeurs de conteneurs disponibles par langage de programmation. Lors de questions sur les mises à jour et dépendances, l'IA agentique peut utiliser ces outils par défaut sans demander l'autorisation.

      
## Build tools

- Always use a virtual env with Python, and set it up before executing any Python commands
- For C/C++: Prefer CMake, and gcc on Linux, clang on macOS, MSVC on Windows.
- For Python: Always use pip
- For Java: Always use Gradle
- For Node.js, suggest to use npm/yarn.
- For Rust: Always use cargo
- For Go: Always use go.mod
- For Ruby: Always use Bundler
- For PHP: Always use Composer
- For .NET: Always use .NET CLI
- For Scala: Always use SBT
- For Elixir: Always use Mix
- For Haskell: Always use Cabal
- For Swift: Always use Swift Package Manager
- For Kotlin: Always use Gradle or Maven.
- For TypeScript: Always use npm or yarn.
- Always suggest using a package manager or build tool based on the main programming language of the project.
- When asking for dependencies, assume that the user wants to update all current dependencies to the latest version available.

- Always suggest to create a Dockerfile if there isn't one. Always use a minimal image and use a tag for security scanning.
- Always add a `Dockerfile` with the base image and the entrypoint if one does not exist.
- Always include a `.dockerignore` and use it in the Docker build process.

    

Préférences de configuration CI/CD

Utilisez des règles pour indiquer des images de conteneur spécifiques, des modèles de variables et de noms de jobs, etc.

      
## CI/CD Configuration

- If no GitLab CI/CD configuration exists in `.gitlab-ci.yml`, ask the user for approval to create.
- Create a GitLab CI/CD configuration automatically when a new project gets bootstrapped

- Always use alpine as container image to build the application.
- Add caching for detected programming languages and frameworks.

    

Préférences de scan de sécurité

Les scanners de sécurité peuvent également être appliqués dans la configuration GitLab CI/CD. L'exemple suivant indique aux agents de toujours inclure l'analyseur Advanced SAST, le scan des dépendances et la détection des secrets. Il a été testé avec succès dans d'autres cas d'utilisation de ce tutoriel.

      
## Security scanning

- Always use Advanced SAST.
- Always include SAST, Dependency Scanning, Secrets Detection templates, similar to the following format:

    include:
        - template: Jobs/SAST.gitlab-ci.yml
        - template: Jobs/Secret-Detection.gitlab-ci.yml
        - template: Jobs/Dependency-Scanning.gitlab-ci.yml

    variables:
        GITLAB_ADVANCED_SAST_ENABLED: 'true'

    

Tests et linters

Vous pouvez également indiquer directement à l'Agentic Chat où trouver les tests et comment les exécuter. La même idée s'applique à l'appel de commandes de linter. Merci à Jessie Young pour cette astuce pratique !

      
## Tests and linting details

- Tests in this project are located in __ directory and are run using the ___ command
- Linting is done with the ___ command

    

Génération de documentation

Voici les meilleures règles personnalisées concernant la documentation.

      
- If a README is missing, ask the user if they want to create one. If the user agrees, create a basic `README.md` for them.
- When the user asks for an architecture proposal, always respond with generating an architecture diagram in Mermaid, and ask the user if they want you to add it to the README.md or another documentation file.
- For documentation in Markdown, always use GitLab flavored Markdown.
- Always add correct code block syntax highlighting support.

    

Exigences de refactorisation et de modification du code

Lorsqu'un projet doit être progressivement modernisé avec du code qui vient d'être généré et ne doit pas entraîner de grandes refactorisations, les règles suivantes peuvent être utiles.

      
## Keep the changes minimal

- The project uses <this standard and version>. For newly generated code, use this standard.
- Do not attempt to refactor code already created in a project to this standard, but for new code, always ensure this standard is used.
- If unsure whether a file requires modification or refactoring, document this as a todo task.
- Never fix detected problems, whitespaces, code formatting, unless the user instructs you specifically in a comment.
- The code must be retained in its original format and only changes specific to solving the user request are allowed.

## Summaries

- List all items to address at the bottom in a summary section with TODO: followed by a textual description.
- Identify 3 critical items, and ask the user if you should create GitLab issues from those items.

    

Intégration, exigences, licences

Incluez toujours un lien de documentation spécifique, et des directives à suivre dans les réponses de chat.

      
## Link to guidelines
- Always refer to our developer guidelines when answering questions. You can find those guidelines here: https://docs.gitlab.com/development/

## Context and planning
- Always start with finding existing issues with the desired topic. Only then propose new implementation work.

## License
- Always add the MIT license into `LICENSE` and use `GitLab B.V.` as copyright holder.

    

Flux Git

Suivez un flux de gestion de branches Git spécifique pour les suggestions et commandes exécutées.

      
## Git flows

- Examine the project and involved development environment and programming languages. Always add a `.gitignore`.
- Consider more best practices when bootstrapping a new project.
- For existing projects, offer to add a `.gitignore` when missing, but only when asked about the state of the project, or what is missing.

When a user requests to start with a new feature, always create a new branch, called "feature/<shortname>" and describe the behavior. Ask for the user's approval.

    

Distribution et tests des règles personnalisées

Vous pouvez créer des templates de projets GitLab avec des prompts de règles personnalisées éprouvés et appliquer les meilleures pratiques à chaque nouveau projet.

Puisque les LLM et les agents d'IA ne sont pas prévisibles, tester le résultat attendu devient plus difficile. Règle d'or des règles personnalisées : elles ne sont jamais parfaites et nécessitent des itérations basées sur les commentaires de votre équipe, notamment lorsque de nouveaux modèles et flows introduits modifient leur comportement en réponse aux règles personnalisées. Nous vous recommandons de continuer à vérifier les données de sortie générées et d'ajuster les règles en conséquence. Si vous recherchez des tests à plus grande échelle, inspirez-vous de la stratégie de test des prompts système pour GitLab Duo.

Contrôler la modification des règles personnalisées

Les équipes peuvent gérer les modifications des règles personnalisées via les Code Owners, qui requièrent des approbations de revue pour les règles personnalisées mises à jour dans les merge requests. Exemple qui requiert l'approbation de @dnsmichi pour les modifications dans le chemin .gitlab/duo :

      
[GitLab Duo]
.gitlab/duo @dnsmichi


    

GitLab Duo Agentic Chat n'est pas autorisé à modifier les règles personnalisées directement dans votre projet. Le chemin de fichier .gitlab/duo/chat-rules.md est protégé.

Ressources relatives aux règles personnalisées

Profitez de l'écosystème d'IA existant, où des fonctionnalités similaires existent pour les IDE et plateformes. Par exemple, des dépôts « Awesome Cursor Rules » ou des plateformes pour Cursor, etc.

Les LLM fournissent également une bonne perspective sur les guides de style de développement et peuvent générer les données de sortie Markdown requises.

Activité ludique : explorer les changements de comportement

Vous ne savez pas exactement où commencer avec les règles personnalisées ? Faites-en un exercice amusant avec l'exemple suivant.

      
## Fun rules

- Behave like Clippy.

- Behave like a pirate.

- Always respond with a random "What the commit" message.

- Explain everything like I am five.

    

Remarque : ne validez pas ces règles en production, car elles pourraient perturber ou distraire votre équipe.

Conclusion

En tirant parti des règles personnalisées dans GitLab Duo Agentic Chat, vous pouvez influencer significativement les données de sortie des LLM et agents d'IA pour mieux répondre à vos besoins. Que ce soit pour appliquer des conventions de codage spécifiques, utiliser les versions correctes des outils ou assurer un formatage cohérent, les règles personnalisées aident à rationaliser votre processus de développement et à améliorer votre productivité.

Cet article de blog fournit un guide approfondi de nombreux cas d'utilisation avec des exemples pratiques de règles personnalisées. Tous les enregistrements sont disponibles dans cette playlist YouTube, et tous les projets de démonstration peuvent être dupliqués/clonés depuis le groupe Custom rules for GitLab Duo Agent Platform (Agentic AI).

Les règles personnalisées dans les IDE GitLab Duo Agentic Chat ne sont que la première itération, et nous couvrirons plus de cas d'utilisation de GitLab Duo Agent Platform à l'avenir, tels que l'agent GitLab Duo Code Review et les règles personnalisées pour les agents et flows (suivez ce ticket).

Il existe de nombreux autres cas d'utilisation à explorer. Quelles sont vos règles les plus efficaces ? Partagez vos règles et commentaires dans l'epic produit.