Erweiterte Produktivität: Kombination von Agenten, Fähigkeiten und Modi

Lektion aktualisiert am 2. November 2026. Die Beispielagentendateien verwenden nun die von Vibe dokumentierten 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 Agentendatei) und die korrekten Tool-Namen (edit, nicht edit_file; kein list_dir-Tool). Erinnerung aus Lektion 3: safety ist ein visueller Indikator, keine Berechtigung. Quelle: Konfigurationsreferenz.

Das vollständige Ökosystem

Sie haben nun die drei Säulen von Mistral Vibe gemeistert: Agenten entscheiden, wer ausführt, Fähigkeiten beschreiben, was getan wird, und Modi setzen den Kontext. In Isolation bietet jeder nur einen bescheidenen Gewinn. Erst ihre Kombination verändert die Art der Arbeit – und diese Lektion zeigt Ihnen, wie Sie sie zu einem kohärenten professionellen Entwicklungsumfeld organisieren.

Alles beginnt mit der Organisation. Was Sie von Projekt zu Projekt begleitet, befindet sich in ~/.vibe/; was nur für ein bestimmtes Repository Sinn ergibt, bleibt im Repository. Diese Trennung verhindert, dass Sie eine Datenbank-Sammlungs-Fähigkeit in jedes Projekt ziehen, und wichtiger noch: Sie stellt sicher, dass ein Kollege Ihr Repository klonen kann, ohne die benötigten Tools zu verpassen.

~/.vibe/
├── agents/
│   ├── review.toml          # Code-Review-Modus (sicher)
│   ├── dev.toml             # Entwicklungsmodus (neutral)
│   ├── deploy.toml          # Bereitstellungsmodus (zerstörerisch)
│   └── ci-runner.toml       # CI-Subagent (yolo, nur Container)
├── skills/
│   ├── code-review/SKILL.md
│   ├── test-gen/SKILL.md
│   ├── smart-commit/SKILL.md
│   ├── lint-fix/SKILL.md
│   └── db-migrate/SKILL.md
└── config.toml

mon-projet/.vibe/
├── skills/
│   ├── deploy-staging/SKILL.md    # Projekt-spezifisch
│   └── seed-database/SKILL.md    # Projekt-spezifisch
└── config.toml                    # Lokale Konfiguration

Ein typischer Tag

Der Morgen beginnt im schreibgeschützten Modus. Sie beginnen mit dem benutzerdefinierten plan-Agenten aus Lektion 2 (Vibe stellt keinen vor), fragen, was sich seit Montag geändert hat, und erhalten eine Erklärung eines Moduls, das Sie seit sechs Monaten nicht berührt haben – keines davon ändert eine Datei. Sobald Sie die Landschaft untersucht haben, schalten Sie mit Shift+Tab in den Review-Modus um, um eine Pull-Request zu bearbeiten.

# Starten Sie mit dem benutzerdefinierten plan-Agenten aus Lektion 2 (schreibgeschützt)
vibe --agent plan

# Aktuelle Änderungen erkunden
> Welche Dateien wurden seit Montag geändert?
> Analysieren Sie die Architektur des src/api/-Moduls

# In den Review-Modus wechseln
# Shift+Tab → review
> Prüfen Sie die Änderungen in PR #42

Als Nächstes folgt die Implementierung, die einen Modus erfordert, der schreiben kann. Sie beschreiben, was Sie wollen, und delegieren alles Mechanische an Slash-Befehle: Tests für die Datei, die Sie gerade geschrieben haben, Bereinigung des berührten Verzeichnisses.

# In den dev-Modus wechseln
# Shift+Tab → dev

> Implementieren Sie den POST /api/users-Endpunkt mit Zod-Validierung

# Slash-Befehle verwenden
/test-gen src/api/users.ts
/lint-fix src/api/

Bevor Sie commiten, wiederholt sich dieselbe Sequenz jedes Mal – genau deshalb haben wir sie zu Befehlen gemacht.

# Slash-Befehle in Sequenz
/lint-fix src/
/code-review src/api/users.ts

# Smart Commit
/smart-commit

Schließlich erfolgt die Bereitstellung in einem destructive-Modus, bei dem jeder Schritt Ihre Validierung erfordert. Hier wirkt der Moduswechsel so sehr als Sicherheitsbarriere wie als Werkzeugumschaltung.

# In den deploy-Modus wechseln (zerstörerisch, Bestätigung erforderlich)
# Shift+Tab → deploy

> Bereitstellen in Staging
# Vibe folgt der Sequenz: test → build → deploy → verify

Agenten und Fähigkeiten zum Sprechen bringen

Ein Agent kann Ihre Fähigkeiten kennen und Sie zum richtigen Zeitpunkt daran erinnern. Erwähnen Sie sie einfach in seinem Systemprompt: Der Agent führt sie nicht für Sie aus, aber er schlägt den relevanten Befehl sofort nach der Codeerstellung vor, genau in dem Moment, in dem Sie vergessen könnten.

# ~/.vibe/agents/fullstack-dev.toml
display_name = "Fullstack Dev"
safety = "neutral"

instructions = """
Sie sind ein Fullstack-Entwickler.
Verfügbare Fähigkeiten, die Sie dem Benutzer vorschlagen können:
- /test-gen für Unit-Tests
- /lint-fix für Bereinigung
- /smart-commit für Commits
- /code-review für Code-Reviews

Nach jeder Implementierung relevante Fähigkeiten vorschlagen.
"""

Subagenten hingegen bearbeiten einen isolierten Teil der Pipeline, während Sie weiterarbeiten. Eine schreibgeschützte Sicherheitsprüfung ist der Lehrbuchfall: Sie benötigt nur read_file und grep, kann also nichts kaputt machen, und läuft parallel, ohne Sie zu unterbrechen.

# Subagent für Sicherheitsanalyse (läuft parallel)
display_name = "Security Check"
agent_type = "subagent"
safety = "safe"
instructions = """Analysieren Sie Dateien auf OWASP Top 10-Schwachstellen."""
enabled_tools = ["read_file", "grep"]

[tools.read_file]
permission = "always"

[tools.grep]
permission = "always"

Drei wiederkehrende Arbeitsabläufe

Der erste, „Erkunden → Planen → Ausführen”, eignet sich für neue Funktionen: Sie erkunden den Codebase mit Ihrem plan-Agenten, um den Kontext zu verstehen, bitten Vibe um einen Implementierungsplan und führen diesen Plan mit dem dev- oder accept-edits-Agenten aus. Der zweite, „Schreiben → Reviewen → Reparieren”, gilt für Code, den Sie gerade geschrieben haben: Implementieren Sie mit dem dev-Agenten, reviewen Sie mit /code-review und reparieren Sie identifizierte Probleme, indem Sie zurück in den dev-Modus wechseln. Der dritte, „Testen → Commiten → Bereitstellen”, schließt den Kreis: /test-gen gefolgt von der Testausführung, /smart-commit für eine konventionelle Nachricht und der deploy-Agent für die Produktionsfreigabe mit Verifikation.

Zwei Ebenen der Konfiguration

Die globale config.toml erklärt, was Sie überall begleitet, einschließlich eines Verzeichnisses mit teamgeteilten Fähigkeiten – so hört eine Commit-Konvention oder eine Review-Checkliste auf, eine persönliche Angelegenheit zu sein.

# ~/.vibe/config.toml

# Global aktivierte Fähigkeiten
enabled_skills = ["code-review", "test-gen", "lint-fix", "smart-commit"]

# Pfade zu teamgeteilten Fähigkeiten
skill_paths = ["/home/equipe/vibe-skills"]

Die lokale Datei ergänzt diese Menge mit projekt-spezifischen Fähigkeiten und entfernt vor allem diejenigen, die dort nicht hingehören. Diese Liste disabled_skills ist genauso wichtig wie die Aktivierung: Autocomplete-Klutter mit irrelevante Befehlen wird schließlich ignoriert.

# mon-projet/.vibe/config.toml

# Zusätzliche Fähigkeiten für dieses Projekt
enabled_skills = ["deploy-staging", "seed-database", "db-migrate"]

# Irrelevante Fähigkeiten deaktivieren
disabled_skills = ["experimental-*"]

Schließlich prüfen Sie, ob dies eine echte Wirkung erzeugt. Zeitmessung Ihres Kontextwechsels: Der Wechsel von einer Aufgabe zur anderen sollte weniger als fünf Sekunden mit Shift+Tab dauern; andernfalls sind Ihre Modi schlecht definiert. Als Nächstes zählen Sie, wie oft pro Tag Ihre Slash-Befehle tatsächlich verwendet werden – ein Befehl, der in zwei Wochen nicht aufgerufen wird, sollte gelöscht oder umbenannt werden. Schauen Sie schließlich, wie viele Probleme der Review-Modus vor dem Commit erfasst: Dies ist die aussagekräftigste Metrik, da sie Bugs zählt, die die Produktion nie erreicht haben.

Kernaussagen

• Organisieren Sie Ihre Agenten nach Sicherheitsniveau, Ihre Fähigkeiten nach Funktionalität
• Folgen Sie dem Muster „Erkunden → Planen → Ausführen” für neue Funktionen
• Verwenden Sie Slash-Befehle für wiederkehrende Aufgaben
• Kombinieren Sie globale Agenten mit lokalen projekt-spezifischen Fähigkeiten
• Shift+Tab ist Ihr produktivster Shortcut
• Messen und passen Sie Ihre Konfiguration regelmäßig an