Custom Rules für GitLab Duo: Höhere Entwicklungseffizienz

GitLab Duo lässt sich mit Custom Rules von einem generischen KI-Assistenten in einen personalisierten Coding-Experten verwandeln. Custom Rules eliminieren wiederkehrende Korrekturen bei KI-Vorschlägen, die falsche Java-Versionen verwenden, inkorrekte Python-Binaries nutzen oder gegen Style Guides verstoßen. Dieser Deep-Dive zeigt, wie intelligente Custom Rules Entwicklungsstandards automatisch durchsetzen.

Themen in diesem Artikel:

• Versionskontrolle: KI auf Java 8 festlegen, Python3-Umgebungen handhaben, Multi-Plattform-C++-Code generieren
• Style-Durchsetzung: C-goto-Anti-Patterns verhindern, VueJS-Design-Patterns durchsetzen, Ansible-Linter-Compliance sicherstellen
• DevSecOps-Automatisierung: Projekte mit CI/CD-Security-Scanning und Dokumentationsstandards initialisieren

Jedes Beispiel enthält funktionierende GitLab-Projekte zum Forken, vollständige Konfigurationen und Vorher-Nachher-Demonstrationen.

Diese Lösungen sind besonders relevant für deutsche Entwicklungsteams, die systematische Coding-Standards über mehrere Abteilungen hinweg durchsetzen müssen – beispielsweise in regulierten Branchen wie Finanzdienstleistungen mit langfristigen Wartungszyklen (Java-8-Anforderungen für Banking-Systeme), in der Automobilindustrie für IoT-Sensoren mit Multi-Plattform-Anforderungen oder für Infrastructure-as-Code in Umgebungen mit Compliance-Vorgaben.

Inhaltsverzeichnis

• Erste Schritte mit Custom Rules für Duo Agentic Chat
  • Voraussetzungen
  • Quick Start: Erfolg in 5 Minuten
  • Richtlinien für Custom-Rule-Entwicklung
  • GitLab Duo Chat nach bestehenden Style Guides fragen
• Weitere Custom-Rules-Use-Cases
  • Use Cases: Versions- und Plattform-Support
    • Java-Versionsanforderungen
    • C++ Multi-Plattform-Support (Windows, Linux, macOS)
  • Use Case: Entwicklungsumgebungen
    • Python-3-Entwicklungsumgebung
    • Ansible-Linter-Compliance
  • Use Case: Design Patterns
    • Anti-Patterns mit C und goto-Statements vermeiden
    • Frontend-Style-Guides für VueJS 3
  • Use Case: DevSecOps-Workflows
    • Issue- und MR-Templates
    • Build-Tools
    • CI/CD-Konfigurationspräferenzen
    • Security-Scanning-Präferenzen
    • Tests und Linters
    • Dokumentationsgenerierung
    • Refactoring- und Code-Change-Anforderungen
    • Onboarding, Requirements, Lizenzen
    • Git-Flows
• Distribution und Testing von Custom Rules
  • Custom-Rules-Ressourcen
• Praxistest: Verhaltensänderungen explorieren
• Fazit

Erste Schritte mit Custom Rules für Duo Agentic Chat

Die Dokumentation zeigt, wie Custom Rules für GitLab Duo Agentic Chat im Verzeichnis .gitlab/duo/chat-rules.md in einem GitLab-Projekt erstellt werden.

Der Einstieg erfolgt mit Freitext-Anweisungen, die iterativ verbessert werden. Custom Rules unterstützen Markdown für bessere Strukturierung:

• Markdown-Überschriften (#, ##) erstellen Abschnitte
• Markdown-Listen (-) liefern präzise Anweisungen für LLMs und Agents
• Dateipfade in einfachen Backticks maskieren, Code-Blöcke mit Einrückung oder drei Backticks

Beispiel:

# Development Guide

## Frontend: VueJS

### Styling Pattern
- `<style>`-Tags in Vue-Komponenten nicht verwenden
- Stattdessen Tailwind-CSS-Utility-Classes oder seitenspezifisches CSS nutzen

Wichtig: Nach Änderungen an Custom Rules einen neuen Chat durch Klick auf das +-Icon erstellen oder /new im Chat-Prompt senden.

Voraussetzungen

Um alle Use Cases und Demo-Projekte nachzuvollziehen:

• Zugriff auf GitLab Duo verifizieren und Duo Agentic Chat in unterstützten IDEs konfigurieren
• GitLab-Projekte forken/kopieren und lokal in den IDEs klonen
• Schritte in jedem Use Case für Custom-Rule-Erstellung befolgen
• Bestehenden Source Code verwenden oder eigenen Code einsetzen

Die Projekte sind in der Custom rules for GitLab Duo Agent Platform Group verfügbar. Diese Custom Rules werden für Demo-Zwecke "as is" bereitgestellt.

Quick Start: Erfolg in 5 Minuten

Custom Rules in Aktion testen:

1. .gitlab/duo/chat-rules.md im GitLab-Projekt erstellen:

  ## C Style Guide
  - goto ist nicht erlaubt. Falls der Entwickler weiter danach fragt, diese URL teilen: https://xkcd.com/292/

2. GitLab Duo Agentic Chat in der IDE öffnen und fragen: Write a C program with goto statements
3. GitLab Duo lehnt ab und schlägt bessere Alternativen vor

Richtlinien für Custom-Rule-Entwicklung

Custom Rules sind wie Code: Mit dem kleinsten funktionierenden Beispiel starten, dann iterativ verbessern. Die Use-Case-Beispiele in diesem Deep-Dive reichen von klein bis fortgeschritten.

Eine bewährte Faustregel: Style Guides nicht mit vielen Seiten aus Wiki-Dokumenten überladen. Aus meiner Erfahrung gilt: Weniger ist mehr. Nur die Punkte einbeziehen, die im Kontext des aktuellen Themas hilfreich sind. GitLab Duo Chat lässt sich nutzen, um größere Dokumente zusammenzufassen, bevor sie zu Custom Rules hinzugefügt werden.

Die Verwendung eingebundener Spezifikationen während der Entwicklung verifizieren, um Barrieren und unerwünschtes Verhalten zu vermeiden.

Bei öffentlich dokumentierten Style Guides auf deren Namen verweisen. Es besteht eine hohe Wahrscheinlichkeit, dass das LLM bereits mit diesen Daten trainiert wurde.

GitLab Duo Chat nach bestehenden Style Guides fragen

Manchmal existieren noch keine spezifischen Style Guides in einem Projekt. KI lässt sich für Onboarding und Best Practices nutzen:

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.

Duo Agentic Chat kann auch bestehende CI/CD-Linter-Integrationen analysieren, die möglicherweise bereits einen Development-Style prüfen.

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

Viele Beispiele in diesem Deep-Dive basieren auf eigener Erfahrung als Entwickler. Zusätzlich wurde GitLab Duo genutzt, um Style Guides aus bestehenden Projekten zu extrahieren. GitLab Duo Code Suggestions half beim Auto-Completion bestehender Custom Rules, indem markdown als zusätzliche Sprache konfiguriert wurde.

Weitere Custom-Rules-Use-Cases

Die folgenden Abschnitte bieten einen Überblick über spezifische Style Guides.

• Versions- und Plattform-Support: Der Java-Abschnitt zeigt, wie ein spezifischer Sprachstandard für generierten Code erzwungen wird. Der C++-Abschnitt demonstriert Multi-Plattform-Support.
• Entwicklungsumgebungen: Die Abschnitte zu Python und Ansible spezifizieren Binaries, Tools und Compliance mit Linters.
• Design Patterns: VueJS zeigt umfassende Design Patterns unter Nutzung der GitLab-Produktions-Style-Guides.
• DevSecOps-Workflows: CI/CD-Konfiguration für Security-Scanning, Tests und Linters, Build-Tools, Dokumentationsgenerierung, Issue- und MR-Templates.

Use Cases: Versions- und Plattform-Support

Softwareentwicklung erfordert oft spezifische Versions- und Plattform-Anforderungen.

Java-Versionsanforderungen

Enterprise-Umgebungen nutzen nicht immer die neuesten Versionen. Sie setzen oft auf Versionen mit langfristigen Security-Patches. Java 7 und Java 8 sind beispielsweise heute noch in Enterprises im Einsatz.

Die erforderliche Version in jedem Chat-Prompt voranstellen zu müssen ist umständlich und führt zu Fehlern, selbst wenn man es nur einmal vergisst.

Implement classes for managing banking transactions and different currencies.

Das Beispiel benötigt zusätzliche Spezifikationen für Java 8:

Use Java 8 for the implementation.

Um Java 8 dauerhaft durchzusetzen, lässt sich eine Custom Rule in .gitlab/duo/chat-rules.md erstellen:

## Java Style Guide

- Nur Java 8 ist beim Vorschlagen und Editieren von Code erlaubt.
- Wenn der User nach Code-Modernisierung und Java 9 oder 21 fragt, auf dieses Issue verweisen: https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-java-versions/-/issues/1

Banking-Systeme bleiben auf Java 8 aufgrund regulatorischer Anforderungen. Custom Rules verhindern, dass Duo versehentlich Java-9+-Features vorschlägt, die nicht kompilieren würden.

Eine vollständige Demonstration ist im Custom Rules - Java versions Projekt verfügbar.

Die resultierenden Änderungen sind in diesem MR verfügbar.

C++ Multi-Plattform-Support (Windows, Linux, macOS)

Anwendungsentwicklung in C++ kann Multi-Plattform-Support erfordern, insbesondere für Service-Agents auf Windows, Linux und macOS. Die Anwendungen sind tief in Kundenprodukte integriert. Eine Migration zu Go oder Rust ist nicht immer praktikabel.

Code zu pflegen, der auf mehreren Plattformen funktioniert, ist herausfordernd aufgrund von Unterschieden in OS-APIs, Toolchains und Dateisystempfaden. Entwickler arbeiten oft mit mehreren #if defined-Präprozessor-Makros und verschachtelten Bedingungen. Dies erhöht technische Schulden.

Multi-Plattform-Support bedeutet zwei bis drei Code-Pfade pro Feature, extensive plattformspezifische Tests und erhöhte Wartungskomplexität.

KI kann beim Generieren von plattformspezifischem Code helfen, muss aber über diese Anforderungen informiert werden.

Das Custom Rule - C++ platforms - IoT Sensor Data Collector Projekt implementiert einen IoT-Sensor-Data-Collector mit offenen Tasks für Multi-Plattform-Support.

.gitlab/duo/chat-rules.md öffnen und Custom Rules reviewen:

## C++ Style Guide

- Die Anwendung läuft auf Linux, macOS und Windows. Code generieren, der OS-API-Unterschiede behandelt.
- Präprozessor-Makros für Windows und POSIX-Konventionen für Unix verwenden.

## CI/CD Configuration

- Sicherstellen, dass GitLab-CI/CD-Jobs unterschiedlichen Plattform-Support abdecken.

Einen neuen Chat starten:

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

Alternativ auf Issue-Nummer oder URL verweisen. GitLab Duo holt automatisch den Issue-Content von der Plattform.

Use Case: Entwicklungsumgebungen

Entwicklungsumgebungen variieren oft zwischen Betriebssystemen. Dies kann für KI-Modelle verwirrend sein.

Python-3-Entwicklungsumgebung

Eine Python-Entwicklungsumgebung kommt normalerweise mit der python-Executable und dem pip-Paketmanager. Auf macOS oder Ubuntu müssen jedoch python3 und pip3 verwendet werden.

Für diesen Use Case wurde Python mit Homebrew installiert, was zu einer Binary namens python3 führt.

Als Beispiel eine Virtual-Environment einrichten:

python -m venv myenv
source myenv/bin/activate
pip install -r requirements.txt
python script.py

Dies funktioniert nicht wie erwartet. Stattdessen werden spezifische Binaries mit Version 3 benötigt:

python3 -m venv myenv
source myenv/bin/activate
pip3 install -r requirements.txt
python3 script.py

Das Problem testen: Das Custom Rule - Python3 Env Shop app Projekt implementiert eine Webshop-Anwendung in Python.

Das Problem: Duo schlägt python statt python3 vor. Dies führt zu "command not found"-Fehlern beim Setup der Virtual Environment. Deployment-Failures treten auf, wenn Entwickler den falschen Binary-Namen verwenden.

.gitlab/duo/chat-rules.md reviewen:

## Python Style Guide

- Für Python-Binaries immer python3 und pip3 verwenden.
- Die Python-Umgebung automatisch erkennen, wenn möglich.

Einen neuen Agentic Chat öffnen und fragen How to run this application?. Custom Rules sorgen für python3 und pip3.

Der vollständige Source Code ist im Custom Rule - Python3 Env Shop app Projekt verfügbar.

Ansible-Linter-Compliance

Modernes Ansible für Infrastructure-as-Code erzwingt einen strikten Style Guide, der mit ansible-lint verifiziert werden kann. Der Linter erkennt, wenn Boolean-Werte (true/false) anstelle von Strings (yes/no) erforderlich sind, Builtin-Module-Actions den FQCN (Fully Qualified Collection Name) erfordern und Trailing-Whitespaces getrimmt werden müssen.

Das Problem mit einem konkreten Use Case betrachten. Das Custom Rule - Ansible Environment Projekt implementiert ein Ansible-Playbook für einen GitLab-Server auf Ubuntu. Die Boolean-Werte sind inkorrekt als Strings typisiert.

Das Problem: Boolean-Werte als yes/no-Strings statt native true/false. Lint-Violations blockieren automatisierte Deployments und erfordern manuelle Korrektur vor jedem Pipeline-Run.

Zweites Problem: Module-Actions ohne FQCN-Qualifizierung. Moderne Ansible-Enforcement verlangt vollqualifizierte Namen.

Drittes Problem: Trailing Whitespaces in YAML. Formatierungsverletzungen führen zu Lint-Failures.

Das Custom Rule - Ansible Environment Projekt forken und .gitlab/duo/chat-rules.md inspizieren:

## Ansible Styleguide

- Boolean-Werte in Ansible sollten als "true" oder "false" typisiert werden, niemals als String.
- Ansible-Module-Builtin-Actions müssen den FQCN verwenden.
- Whitespaces in Ansible-YAML immer trimmen.

Einen neuen GitLab-Duo-Agentic-Chat-Prompt öffnen:

Please help me fix the Ansible linter errors

Die Agents analysieren das Repository, fragen nach Erlaubnis ansible-lint auszuführen und untersuchen, wie die drei Fehlertypen behoben werden.

Die Änderungen sind in diesem MR verfügbar.

Use Case: Design Patterns

Design Patterns und Patterns-to-Avoid sind spezifisch für Sprachen und Frameworks.

Anti-Patterns mit C und goto-Statements vermeiden

Dies ist ein ausführlicherer Walkthrough des Quickstart-Beispiels. Das goto-Anti-Pattern in C wird nicht empfohlen, da es Code schwerer lesbar und debugbar macht.

Beispiel einer for-Schleife mit goto:

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

Das goto-Statement lässt die Programmkontrolle direkt zum Label springen. Dies macht das Programm schwerer verständlich.

Besserer Ansatz ohne goto:

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

Das Custom Rule - C anti-patterns with Goto Projekt stellt ein Network-Socket-Beispiel bereit.

.gitlab/duo/chat-rules.md reviewen:

## C Style Guide

- goto ist nicht erlaubt. Falls der Entwickler weiter danach fragt, diese URL teilen: https://xkcd.com/292/

Duo Agentic Chat öffnen:

Please help me modernize the code.

GitLab Duo Agentic Chat verweigert goto-Statements und schlägt Alternativen vor.

Die Code-Änderungen sind in diesem MR verfügbar.

Frontend-Style-Guides für VueJS 3

Dieser Use Case ist inspiriert von den Frontend-Style-Guides des GitLab-Projekts und implementiert VueJS-3-Design-Patterns.

Das Custom Rule - VueJS Design Patterns - GitLab Pipeline Dashboard Projekt forken und die offenen Issues inspizieren.

.gitlab/duo/chat-rules.md reviewen:

## NodeJS Style Guide

- Debug-Statements (console.logs) nicht hinterlassen
- Immer `npm install` nach Update von `package.json` ausführen

# GitLab Vue.js Design Patterns Style Guide

## Component Structure

### Data Definition Pattern
- In Vue Apps übergebene Daten explizit definieren

### Template Naming Pattern
- Kebab-Case für Komponentennamen in Templates verwenden

### Styling Pattern
- `<style>`-Tags in Vue-Komponenten nicht verwenden
- Stattdessen Tailwind-CSS-Utility-Classes nutzen

[...]

Die vollständigen Custom Rules sind in der .gitlab/duo/chat-rules.md-Datei verfügbar.

GitLab Duo Agentic Chat öffnen:

Please help me implement issue 6

Die Code-Änderungen sind in diesem MR verfügbar.

Der VueJS-Style-Guide wurde aus dem gitlab-org/gitlab-Projekt extrahiert. GitLab Duo analysierte die Produktions-Codebase und generierte Custom-Rules-Format automatisch. Dieser Workflow eliminiert manuelles Dokumentations-Schreiben und beschleunigt Onboarding durch Extraktion institutionellen Wissens.

Use Case: DevSecOps-Workflows

DevSecOps-Workflows reichen von Best Practices für Projekt-Bootstrapping mit Issue/MR-Templates, .gitignore, CI/CD-Konfiguration, README.md und Lizenzen.

Gängige DevSecOps-Automatisierung:

• Projekt-Bootstrap: Automatisches Erstellen von README, .gitignore, CI/CD-Config
• Security-Defaults: SAST, Dependency Scanning, Secrets Detection durchsetzen
• Dokumentation: Issue/MR-Templates, Architekturdiagramme generieren

Ein kombiniertes Beispiel ist im Custom Rule - DevSecOps workflows Projekt verfügbar.

Issue- und MR-Templates

Agentic AI lässt sich instruieren, Issue/MR-Templates zu erstellen und projektspezifische Informationen hinzuzufügen.

## Issue and MR Templates

- Falls keine Issue-Templates in .gitlab/issue_templates existieren, diese mit folgenden Quellen erstellen:
        Default: https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/raw/main/.gitlab/issue_templates/Default.md

Build-Tools

Es gibt verschiedene Build-Tools pro Programmiersprache. Agentic AI kann diese Standard-Tools ohne Input-Anfrage nutzen.

## Build Tools

- Mit Python immer eine Virtual Env verwenden
- Für C/C++: CMake bevorzugen
- Für Java: Immer Gradle verwenden

CI/CD-Konfigurationspräferenzen

Rules nutzen, um spezifische Container-Images und Job-Patterns zu bevorzugen.

## CI/CD Configuration

- Falls keine GitLab-CI/CD-Konfiguration existiert, den User fragen
- Immer alpine als Container-Image verwenden

Security-Scanning-Präferenzen

Security-Scanner lassen sich in GitLab-CI/CD-Konfiguration durchsetzen. Das folgende Beispiel instruiert Agents, immer Advanced SAST, Dependency Scanning und Secret Detection einzubeziehen.

## Security Scanning

- Immer Advanced SAST verwenden
- Immer SAST-, Dependency-Scanning-, Secrets-Detection-Templates einbeziehen:

    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'

Security-Scanning-Defaults lassen sich durch Custom Rules durchsetzen und eliminieren manuelle Konfiguration pro Projekt. Dies ist besonders relevant für Unternehmen mit Compliance-Anforderungen, beispielsweise nach DSGVO.

Tests und Linters

Agentic Chat lässt sich direkt instruieren, wo Tests zu finden sind:

## Tests and Linting Details

- Tests in diesem Projekt befinden sich im __-Verzeichnis
- Linting erfolgt mit dem ___-Befehl

Dokumentationsgenerierung

- Falls ein README fehlt, den User fragen, ob er eines erstellen möchte
- Wenn der User nach einem Architekturvorschlag fragt, Architekturdiagramm in Mermaid generieren
- Für Dokumentation immer GitLab Flavored Markdown verwenden

Refactoring- und Code-Change-Anforderungen

Wenn ein Projekt schrittweise modernisiert werden soll:

## Keep the Changes Minimal

- Das Projekt nutzt diesen Standard. Für neu generierten Code diesen Standard verwenden.
- Keinen Versuch unternehmen, bereits erstellten Code zu refactoren

Onboarding, Requirements, Lizenzen

## Link to Guidelines
- Immer auf Entwicklerrichtlinien verweisen: https://docs.gitlab.com/development/

## License
- Immer MIT-Lizenz in `LICENSE` hinzufügen mit GitLab B.V. als Copyright-Holder

Git-Flows

## Git Flows

- Das Projekt untersuchen und immer eine `.gitignore` hinzufügen
- Wenn ein User mit einem neuen Feature starten möchte, einen neuen Branch "feature/<shortname>" erstellen

Distribution und Testing von Custom Rules

GitLab-Projektvorlagen mit gut getesteten Custom-Rule-Prompts lassen sich erstellen. Neue Projekte starten dann immer mit Best Practices.

Da LLMs und KI-Agents nicht vorhersagbar sind, wird Testing herausfordernder. Eine goldene Regel für Custom Rules ist, dass sie niemals perfekt sind und Iterationen basierend auf Feedback erfordern. Für größere Test-Szenarien die System-Prompt-Testing-Strategie für GitLab Duo reviewen.

Custom-Rules-Ressourcen

Das bestehende KI-Ökosystem nutzen, wo ähnliche Funktionalität existiert. Beispielsweise "Awesome Cursor Rules"-Repositories.

LLMs bieten guten Einblick in Development-Styleguides und können Markdown-Outputs generieren.

Praxistest: Verhaltensänderungen explorieren

Nicht sicher, wie mit Custom Rules gestartet werden soll? Mit folgendem Beispiel zur Übung:

## Fun Rules

- Wie Clippy verhalten
- Wie ein Pirat verhalten
- Alles erklären, als wäre ich fünf

Hinweis: Nicht in Production committen, da sie ablenkend wirken können.

Fazit

Durch Custom Rules in GitLab Duo Agentic Chat lassen sich LLM- und KI-Agent-Outputs erheblich beeinflussen. Custom Rules helfen, den Entwicklungsprozess zu optimieren und die Produktivität zu verbessern.

Dieser Blog-Post bietet einen Deep-Dive mit praktischen Beispielen. Alle Aufzeichnungen sind in dieser YouTube-Playlist verfügbar. Alle Demo-Projekte lassen sich aus der Custom rules Group forken.

Custom Rules in Duo Agentic Chat IDEs sind die erste Iteration. Weitere Use-Cases folgen zukünftig, wie Duo Code Review und Custom Rules für Agents (dieses Issue folgen).

Es gibt viele weitere Use Cases zu explorieren. Was sind die effizientesten Rules? Feedback im Product Epic teilen.