Manche Prompts tippt man jeden Tag. Prüfe den Build. Lies den Diff und gib mir ein Review. Leg eine neue Seite an. Mit OpenCode Commands wird aus so einem Prompt ein eigener Slash Befehl. Ihr schreibt ihn einmal, legt ihn ins Repository und das ganze Team nutzt ihn. Hier steht, wie das funktioniert, und dazu vier Commands, die wir selbst nutzen.
NCA KI Workshop für Developer: Euer Team baut eigene Commands, Regeln und Quality Gates für OpenCode und lernt Agentic Coding für die Produktion. Zum KI Workshop für Developer
Was ein Command in OpenCode ist
Ein Command ist ein gespeicherter Prompt mit einem Namen. Ihr ruft ihn im TUI mit einem Schrägstrich auf, zum Beispiel /check. OpenCode bringt schon einige Befehle mit, etwa /init, /undo, /redo und /help. Eigene Commands kommen dazu. Heißt ein eigener Command wie ein eingebauter, überschreibt er ihn.
Der Vorteil ist mehr als Bequemlichkeit. Ein Command sorgt dafür, dass eine Aufgabe jedes Mal gleich abläuft. Das ist der Unterschied zwischen einem Team, das zufällig gute Prompts schreibt, und einem Team mit festen Abläufen.
Wo OpenCode Commands liegen
Es gibt zwei Wege. Der einfache Weg sind Markdown Dateien. Der Dateiname wird zum Namen des Commands:
- Im Projekt:
.opencode/commands/. Diese Commands committet ihr und teilt sie mit dem Team. - Global:
~/.config/opencode/commands/. Diese Commands gelten nur für euch, in jedem Projekt.
Der zweite Weg ist das Feld command in der opencode.json. Das passt für kurze Prompts. Für alles mit mehreren Zeilen sind Markdown Dateien übersichtlicher.
So ist eine Command Datei aufgebaut
Oben steht ein Frontmatter mit Einstellungen, darunter der Prompt. Diese Felder sind wichtig:
- description: Kurze Beschreibung, die im TUI beim Tippen erscheint.
- agent: Welcher Agent den Command ausführt, zum Beispiel build oder plan. Ohne Angabe nutzt OpenCode den aktuellen Agent.
- model: Ein anderes Modell nur für diesen Command.
- subtask: Mit
trueläuft der Command als Subagent und füllt nicht euren Hauptkontext.
Argumente übergeben mit ARGUMENTS
Mit $ARGUMENTS fügt OpenCode alles ein, was ihr nach dem Command tippt. Für einzelne Werte gibt es $1, $2 und so weiter. Aus /seite kontakt wird so ein Prompt, der genau die Seite kontakt anlegt.
Shell Ausgaben direkt in den Prompt holen
Das ist der stärkste Trick. Schreibt einen Befehl in Backticks mit einem Ausrufezeichen davor. OpenCode führt ihn im Projektordner aus und setzt die Ausgabe in den Prompt ein. Der Agent sieht dann echte Fehlermeldungen, echte Diffs und echte Logs. Er muss nicht raten. Mit @ und einem Dateinamen bindet ihr außerdem den Inhalt einer Datei ein.
Vier OpenCode Commands zum Kopieren
1. Build und Checks prüfen, gespeichert als .opencode/commands/check.md:
---
description: Build und Checks prüfen und Fehler beheben
agent: build
---
Ergebnis vom Build:
!`npm run build`
Ergebnis der Tests:
!`npm test`
Behebe alle Fehler. Ändere keine Tests, um sie grün zu machen.
2. Review der eigenen Änderungen, gespeichert als review.md. Der Command läuft im Plan Agent als Subtask und ändert nichts:
---
description: Review der aktuellen Änderungen
agent: plan
subtask: true
---
Aktuelle Änderungen:
!`git diff`
Prüfe die Änderungen auf Fehler, Sicherheitslücken und fehlende Tests.
Gib eine kurze Liste mit Datei, Problem und Vorschlag aus.
3. Neue Seite nach Projektmuster anlegen, gespeichert als seite.md:
---
description: Neue Seite nach dem Muster der Startseite anlegen
---
Lege eine neue Seite mit dem Namen $ARGUMENTS an.
Nutze Aufbau und Komponenten wie in @src/pages/index.astro.
Texte kommen nach src/content, nicht ins Layout.
Prüfe am Ende mit npm run build.
4. Commit Nachricht vorschlagen, gespeichert als commit-text.md. Der Command schreibt nur den Text, committen tut ihr selbst:
---
description: Commit Nachricht aus den gestagten Änderungen vorschlagen
subtask: true
---
Gestagte Änderungen:
!`git diff --staged`
Schlage eine kurze Commit Nachricht vor. Erste Zeile höchstens 60 Zeichen.
Führe keinen Commit aus.
Achtet darauf, dass die Befehle in den Backticks zu euren OpenCode Permissions passen. Steht git diff auf ask, fragt OpenCode bei jedem Aufruf nach. Lesende Befehle wie git diff und npm test stehen bei uns deshalb auf allow.
Commands im Team teilen und pflegen
Legt Team Commands immer ins Repository unter .opencode/commands/. Dann gelten sie für jeden, der das Projekt auscheckt. Ändert ihr einen Command, läuft die Änderung durch den normalen Pull Request. So reviewt das Team auch die Prompts, nicht nur den Code. Persönliche Helfer bleiben im globalen Ordner.
| Baustein | Schreibweise | Wofür |
|---|---|---|
| Alle Argumente | $ARGUMENTS | Freier Text nach dem Command |
| Einzelne Argumente | $1, $2, $3 | Mehrere Werte in fester Reihenfolge |
| Shell Ausgabe | Ausrufezeichen und Befehl in Backticks | Echte Ausgaben von Build, Tests oder Git |
| Datei einbinden | @pfad/zur/datei | Inhalt einer Datei als Kontext |
| Eigener Kontext | subtask: true | Läuft als Subagent ohne den Hauptkontext zu füllen |
Alle Optionen erklärt die OpenCode Doku zu Commands. Die eingebauten Befehle stehen in der OpenCode Doku zum TUI. Wie ihr Agents für Commands festlegt, zeigt die OpenCode Doku zu Agents.
Wie wir Teams bei festen Abläufen mit OpenCode helfen
OpenCode ist bei uns der Coding Agent im Alltag. Commands sind ein kleiner, aber wirkungsvoller Teil eines guten Setups. Dazu gehören Regeln, Rechte und Quality Gates. Wie das mit Astro und GitHub Pages zusammenspielt, zeigen unsere Vibe Coding Tipps und Tricks. Warum Leitplanken mit jedem Modell wichtiger werden, steht in KI Guardrails und bessere Modelle.
Welche Modelle sich für welche Aufgabe eignen, vergleichen wir bei den Vibe Coding Modellen. Pipelines für KI Code beschreiben die Vibe Coding CI/CD Pipelines. Wie Roland mit OpenCode live vor Publikum baut, zeigt der Bericht vom UPSCALER Event in Essen. Begleitung im Projekt gibt es in der Vibe Coding Beratung. Das Vorgespräch ist kostenlos, abgerechnet wird transparent nach Minuten.
Häufige Fragen zu OpenCode Commands
Wie erstelle ich 2026 einen eigenen Command in OpenCode?
Legt eine Markdown Datei unter .opencode/commands im Projekt an. Der Dateiname wird zum Namen des Commands. Oben steht ein Frontmatter mit description und optional agent, model oder subtask. Darunter folgt der Prompt. Danach ruft ihr ihn im TUI mit einem Schrägstrich und dem Namen auf.
Wie übergebe ich 2026 Argumente an einen OpenCode Command?
Mit $ARGUMENTS setzt OpenCode alles ein, was ihr nach dem Command tippt. Für mehrere einzelne Werte nutzt ihr $1, $2 und $3. So wird aus einem Aufruf mit Seitennamen ein Prompt, der genau diese Seite anlegt. Werte mit Leerzeichen setzt ihr in Anführungszeichen.
Kann ein OpenCode Command 2026 Shell Befehle ausführen?
Ja. Ein Befehl in Backticks mit einem Ausrufezeichen davor läuft im Projektordner. Seine Ausgabe landet direkt im Prompt. So sieht der Agent echte Fehlermeldungen aus Build oder Tests. Achtet darauf, dass die Befehle zu euren Permissions passen, sonst fragt OpenCode bei jedem Aufruf nach.
Was bringt subtask bei OpenCode Commands 2026?
Mit subtask true läuft der Command als Subagent. Er bekommt einen eigenen Kontext und füllt nicht eure laufende Session. Das passt gut für Reviews oder Zusammenfassungen, deren Ergebnis ihr braucht, deren Zwischenschritte aber nur den Kontext aufblähen würden.
Wo liegen globale OpenCode Commands?
Globale Commands liegen unter ~/.config/opencode/commands. Sie gelten in jedem Projekt, aber nur für euch. Commands für das Team gehören ins Repository unter .opencode/commands. Dann laufen Änderungen an Prompts durch denselben Review wie der Code.
Kann ich eingebaute Befehle wie init überschreiben?
Ja. Heißt ein eigener Command genauso wie ein eingebauter, gewinnt der eigene. Das solltet ihr nur bewusst tun. Wer im Team /init tippt, erwartet das bekannte Verhalten. Gebt eigenen Commands deshalb lieber eindeutige Namen.
Feste Abläufe für euer KI Setup
Wir bauen mit eurem Team Commands, Regeln und Quality Gates für OpenCode, oder eure Developer lernen es im KI Workshop selbst. Das Vorgespräch ist kostenlos, abgerechnet wird transparent nach Minuten.
