Benutzerdefinierte Modi: Code-Review, Deployment, Linting

Lektion aktualisiert am 2. November 2026. Die Beispiel-Agent-Dateien verwenden nun von Vibe dokumentierte Schlüssel: instructions (nicht system_prompt), active_model (nicht model), [tools.<tool>]-Blöcke für Genehmigungen (der Schlüssel auto_approve existiert nicht in einer Agent-Datei) und echte Tool-Namen (edit, nicht edit_file; kein list_dir-Tool). Erinnerung aus Lektion 3: safety ist ein visueller Indikator, keine Berechtigung. Quelle: Konfigurationsreferenz.

Modi erstellen, die auf Ihren Workflow zugeschnitten sind

Die Lektion über einheitliche Modi hat das Konzept eingeführt; jetzt ist es Zeit, es in die Praxis umzusetzen. Wir erstellen drei benutzerdefinierte Modi, die wiederkehrende Bedürfnisse jedes Entwicklers abdecken: Code-Review, Deployment und Linting. Jeder ist eine .toml-Datei, die in ~/.vibe/agents/ platziert wird, mit maßgeschneiderten Anweisungen. Was diese drei Modi unterscheidet, ist weniger ihre Anweisungen als vielmehr das Paar enabled_tools / [tools.<tool>]: dies entscheidet, was Vibe berühren darf und welches Risiko Sie damit eingehen; safety ist lediglich das visuelle Label.

Ein Revisor, der nichts kaputt machen kann

Der Code-Review-Modus verwandelt Vibe in einen anspruchsvollen Revisor, der die Qualität, Sicherheit und Wartbarkeit Ihres Codes analysiert. Da er nur liest, wird er als safe markiert, und seine Lese-Tools sind auf permission = "always" eingestellt: er arbeitet ohne Unterbrechung und ohne Risiko, da keine Dateien geändert werden. Die Tool-Liste hält dieses Versprechen: kein write_file, kein edit, kein bash.

# ~/.vibe/agents/review.toml
display_name = "Code Review"
description = "Umfassender Code-Review: Sicherheit, Performance, Wartbarkeit."

safety = "safe"
active_model = "mistral-medium-3.5"  # in Vibe integriertes Modell

instructions = """
Sie sind ein Senior-Entwickler im Code-Review-Modus.

Verfahren:
1. Geänderte Dateien lesen (git diff oder spezifizierte Dateien)
2. Jede Änderung an vier Achsen analysieren:
   - Sicherheit (Injection, XSS, CSRF, exponierte Geheimnisse)
   - Performance (N+1, verschachtelte Schleifen, Speicher)
   - Wartbarkeit (Namensgebung, Komplexität, Duplizierung)
   - Korrektheit (Logik, Randfälle, Typen)

Ausgabeformat:
## 🔴 Kritiken (bevor Merge)
## 🟡 Warnungen (bald beheben)
## 🟢 Vorschläge (optionale Verbesserungen)

Für jeden Punkt: Datei, Zeile, Problem, vorgeschlagene Lösung.
"""

enabled_tools = [
  "read_file",
  "grep",
]

[tools.read_file]
permission = "always"

[tools.grep]
permission = "always"

Das im Prompt durchgesetzte Ausgabeformat ist nicht kosmetisch: Es ermöglicht Ihnen auf einen Blick zu sortieren, was einen Pull Request blockiert und was warten kann. Sie starten den Modus und geben ihm entweder eine freie Anweisung oder einen spezifischen Bereich.

vibe --agent review
# > Analysieren Sie geänderte Dateien in der aktuellen Branch
# > /review src/api/

Ein Deployment, das nicht improvisiert

Der Deploy-Modus ist das genaue Gegenteil. Er berührt die Produktion, wird daher als destructive markiert, und seine Schreib- und bash-Tools bleiben bei permission = "ask": jede Aktion erfordert Ihre Validierung. Der gesamte Wert des Modus liegt in der festen Sequenz seines Prompts und insbesondere in seinen Abbruchbedingungen. Ein improvisiertes Deployment am Freitagabend beginnt immer mit einem übersprungenen Schritt; hier stoppt ein roter Test alles.

# ~/.vibe/agents/deploy.toml
display_name = "Deploy"
description = "Kontrolliertes Deployment mit Tests, Build und Verifikation."

safety = "destructive"
active_model = "codestral"  # Alias in config.toml deklariert (Lektion 2)

instructions = """
Sie befinden sich im Deploy-Modus. Folgen Sie dieser Sequenz OHNE AUSNAHME:

1. VERIFIZIEREN — saubere git-Status, keine uncommitteten Dateien
2. TESTEN — vollständige Test-Suite ausführen
3. BUILDEN — Produktions-Build
4. VALIDIEREN — Build prüfen (Größe, Fehler, Warnungen)
5. BESTÄTIGEN — Benutzer fragen, bevor fortgefahren wird
6. DEPLOYEN — Deployment-Befehl ausführen
7. VERIFIZIEREN — bestätigen, dass der Dienst korrekt antwortet

Wenn ein Schritt fehlschlägt: STOPPEN. Das Problem erklären und eine Lösung vorschlagen.
Niemals deployen, wenn Tests fehlschlagen.
Niemals deployen, wenn der Build kritische Warnungen enthält.
"""

enabled_tools = [
  "read_file",
  "write_file",
  "bash",
  "grep",
  "ask_user_question"
]

[tools.write_file]
permission = "ask"

[tools.bash]
permission = "ask"

Das Vorhandensein von ask_user_question in den Tools ist essenziell: Ohne es wäre Schritt 5 Wunschdenken, da der Agent keine technische Möglichkeit hätte, Sie zu befragen.

vibe --agent deploy
# > Folgt der Sequenz Test → Build → Deploy → Verifikation

Automatisierte, aber disziplinierte Bereinigung

Dazwischen liegt der Lint-Modus, der Formatierung, Konventionen und Import-Sortierung automatisiert. Er ändert Dateien, ist daher neutral, aber seine Korrekturen sind mechanisch und über Git reversibel: Die uneingeschränkte Genehmigung seiner Tools (permission = "always") spart Ihnen das Klicken fünfzig Mal. Wenn seine Liste bash enthält, tun Sie dies nur in einer isolierten Umgebung oder beschränken Sie bash auf eine allowlist von Lint-Befehlen. Die drei Regeln am Ende des Prompts verhindern, dass er aus dem Ruder läuft – ein frei laufender Agent würde schnell Biome in einem Projekt installieren, das perfekt mit ESLint auskommt.

# ~/.vibe/agents/lint.toml
display_name = "Lint & Fix"
description = "Automatische Bereinigung: Lint, Format, Imports, Konventionen."

safety = "neutral"
active_model = "codestral"  # Alias in config.toml deklariert (Lektion 2)

instructions = """
Sie befinden sich im Code-Bereinigungsmodus.

Aufgaben:
1. Projekt-Tools erkennen (ESLint, Biome, Prettier, oxlint)
2. Lint mit Auto-Fix ausführen
3. Formatierung ausführen
4. Imports sortieren und bereinigen
5. Erkennbaren toten Code entfernen
6. Fehler melden, die nicht automatisch behoben werden können

Regeln:
- Verwenden Sie bereits im Projekt konfigurierte Tools
- Ändern Sie keine Tool-Konfiguration
- Fügen Sie keine neuen Tools hinzu, ohne zu fragen
"""

enabled_tools = [
  "read_file",
  "edit",
  "bash",
  "grep",
]

[tools.read_file]
permission = "always"

[tools.edit]
permission = "always"

[tools.bash]
permission = "always"  # nur für isolierte Umgebungen reservieren

[tools.grep]
permission = "always"

Zwei weitere Modi und eine Organisationsregel

Das gleiche Prinzip gilt für andere Bedürfnisse. Ein Dokumentationsmodus bleibt neutral, behält aber write_file und edit bei "ask", da das Generieren von Dateien in einem Repository vor dem Schreiben geprüft werden sollte.

# ~/.vibe/agents/docs.toml
display_name = "Documentation"
description = "Generiert und aktualisiert technische Dokumentation."
safety = "neutral"
active_model = "mistral-medium-3.5"  # in Vibe integriertes Modell

instructions = """
Generieren Sie technische Dokumentation. Für jede Datei:
- JSDoc/TSDoc für öffentliche Funktionen
- README mit Nutzungbeispielen
- Dokumentierte Umgebungsvariablen
- API-Schemata, falls zutreffend
"""

enabled_tools = ["read_file", "write_file", "edit", "grep",]

[tools.write_file]
permission = "ask"

[tools.edit]
permission = "ask"

Ein Migrationsmodus hingegen schließt sich dem Deploy in die Kategorie destructive an: Eine misslungene Schema-Migration kann nicht mit einem git revert rückgängig gemacht werden, daher die Anforderung an ein systematisches Rollback-Skript.

# ~/.vibe/agents/migrate.toml
display_name = "Migration"
description = "Verwaltet Datenbank- und Abhängigkeits-Migrationen."
safety = "destructive"
active_model = "mistral-medium-3.5"  # in Vibe integriertes Modell

instructions = """
Sie übernehmen Migrationen. Absolute Regeln:
- Generieren Sie immer ein Rollback-Skript
- Testen Sie die Migration auf einer Kopie vor der Produktion
- Dokumentieren Sie jede Schema-Änderung
"""

enabled_tools = ["read_file", "write_file", "bash", "grep", "ask_user_question"]

[tools.write_file]
permission = "ask"

[tools.bash]
permission = "ask"

Schließlich organisieren Sie Ihr Agenten-Verzeichnis so, dass die Kritikalität in der Baumstruktur selbst lesbar ist. Wenn Sie Modi über die Tastatur mitten in einer Sitzung wechseln, müssen Sie ohne Nachdenken wissen, ob der gerade aktivierte Modus auf Ihre Festplatte schreiben kann.

~/.vibe/agents/
├── review.toml          # safe — nur Lesezugriff
├── lint.toml            # neutral — kontrollierte Änderungen
├── docs.toml            # neutral — Dateigenerierung
├── deploy.toml          # destructive — mit Bestätigung
└── migrate.toml         # destructive — mit Bestätigung

Kernaussagen

• Jeder Modus ist eine .toml-Datei in ~/.vibe/agents/, die für einen spezifischen Workflow konzipiert ist
• Der Review-Modus verfügt nur über Lese-Tools, die uneingeschränkt genehmigt sind: Er kann nur lesen
• Der Deploy-Modus hält bash und Schreiben bei "ask": Er fragt nach Bestätigung
• Der Lint-Modus genehmigt seine Bearbeitungs-Tools uneingeschränkt: Er korrigiert automatisch
• Passen Sie active_model basierend auf der Aufgabenkomplexität an
• instructions sind entscheidend: Seien Sie präzise bezüglich der Sequenz und Regeln