Veröffentlicht am: 12. August 2025
14 Minuten Lesezeit
Custom Rules für GitLab Duo: Höhere Entwicklungseffizienz
KI-Assistenten verstehen die eigene Code-Basis mit Custom Rules und generieren produktionsreifen Code mit minimalen Review-Zyklen.
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
- Weitere Custom-Rules-Use-Cases
- Distribution und Testing von Custom Rules
- 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: ```markdown # 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:
.gitlab/duo/chat-rules.mdim GitLab-Projekt erstellen: ```markdown
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
<figure class="video_container">
<iframe width="560" height="315" src="https://www.youtube.com/embed/C0eMKjRMI5w" frameborder="0" allowfullscreen="true">
</iframe>
</figure>
### 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: ```markdown 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. ```markdown 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](https://docs.gitlab.com/user/project/repository/code_suggestions/supported_extensions/#add-support-for-more-languages) konfiguriert wurde.
## Weitere Custom-Rules-Use-Cases
Die folgenden Abschnitte bieten einen Überblick über spezifische Style Guides.
- **Versions- und Plattform-Support**: Der [Java-Abschnitt](#java-versionsanforderungen) zeigt, wie ein spezifischer Sprachstandard für generierten Code erzwungen wird. Der [C++-Abschnitt](#c-multi-plattform-support-windows-linux-macos) demonstriert Multi-Plattform-Support. - **Entwicklungsumgebungen**: Die Abschnitte zu [Python](#python-3-entwicklungsumgebung) und [Ansible](#ansible-linter-compliance) spezifizieren Binaries, Tools und Compliance mit Linters. - **Design Patterns**: [VueJS](#frontend-style-guides-für-vuejs-3) zeigt umfassende Design Patterns unter Nutzung der GitLab-Produktions-Style-Guides. - **DevSecOps-Workflows**: [CI/CD-Konfiguration](#cicd-konfigurationspräferenzen) für Security-Scanning, [Tests und Linters](#tests-und-linters), [Build-Tools](#build-tools), [Dokumentationsgenerierung](#dokumentationsgenerierung), [Issue- und MR-Templates](#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. ```markdown Implement classes for managing banking transactions and different currencies. ```
Das Beispiel benötigt zusätzliche Spezifikationen für Java 8: ```markdown Use Java 8 for the implementation. ```
Um Java 8 dauerhaft durchzusetzen, lässt sich eine Custom Rule in `.gitlab/duo/chat-rules.md` erstellen: ```markdown ## 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](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-java-versions) verfügbar.
<figure class="video_container">
<iframe width="560" height="315" src="https://www.youtube.com/embed/iZLvpgHdABY" frameborder="0" allowfullscreen="true">
</iframe>
</figure>
Die resultierenden Änderungen sind in [diesem MR](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-java-versions/-/merge_requests/2) 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](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-cpp-platform-iot-sensor-data-collector) implementiert einen IoT-Sensor-Data-Collector mit offenen Tasks für Multi-Plattform-Support.
`.gitlab/duo/chat-rules.md` öffnen und Custom Rules reviewen: ```markdown ## 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: ```markdown 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.
<figure class="video_container">
<iframe width="560" height="315" src="https://www.youtube.com/embed/C5NxOjB0R1Q" frameborder="0" allowfullscreen="true">
</iframe>
</figure>
### 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: ```shell 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: ```shell 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](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-python-3-env-shop-app) 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: ```markdown ## 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`.
<figure class="video_container">
<iframe width="560" height="315" src="https://www.youtube.com/embed/UQ2_OCvUmF0" frameborder="0" allowfullscreen="true">
</iframe>
</figure>
Der vollständige Source Code ist im [Custom Rule - Python3 Env Shop app Projekt](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-python-3-env-shop-app) 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](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-ansible-environment) 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](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-ansible-environment) forken und `.gitlab/duo/chat-rules.md` inspizieren: ```markdown ## 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: ```markdown 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.
<figure class="video_container">
<iframe width="560" height="315" src="https://www.youtube.com/embed/P465U8IfScE" frameborder="0" allowfullscreen="true">
</iframe>
</figure>
Die Änderungen sind in [diesem MR](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-ansible-environment/-/merge_requests/1) 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](#quick-start-erfolg-in-5-minuten). Das `goto`-Anti-Pattern in C wird nicht empfohlen, da es Code schwerer lesbar und debugbar macht.
Beispiel einer for-Schleife mit goto: ```C // 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: C // 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: ```markdown ## C Style Guide
- goto ist nicht erlaubt. Falls der Entwickler weiter danach fragt, diese URL teilen: https://xkcd.com/292/
Duo Agentic Chat öffnen:markdown Please help me modernize the code. ``` GitLab Duo Agentic Chat verweigertgoto-Statements und schlägt Alternativen vor.