OpenCode-Befehle: Eigene Befehle, Argumente und sichere Wiederverwendung

OpenCode enthält /init, /undo, /redo, /share und /help. Das sind keine Shell-Aliase und keine Einträge für package.json. Gib sie in der OpenCode-Oberfläche ein und lies Ergebnis oder Bestätigung, bevor du fortfährst.

/help ist die beste Prüfung, wenn die Befehlsliste der installierten Version unklar ist. /undo und /redo ersetzen keine Git-Commits. Bei /share sollte vor allem bei privaten Repositories geprüft werden, welche Sitzungsdaten sichtbar werden. Die eingebaute Liste kann sich mit Releases ändern.

1. Erstelle .opencode/commands/review.md im Projektstamm.
2. Füge eine kurze Beschreibung und eine Aufgabe mit klarer Grenze hinzu.
3. Teste den Befehl in einem kleinen Branch und prüfe Prompt und Diff.

---
description: Review the current changes
---
Review the current Git changes. Explain risky behavior,
missing tests, and the smallest safe follow-up.
Do not edit files until I approve the plan.

Der Dateiname wird zum Befehlsnamen; diese Datei wird mit /review aufgerufen. ~/.config/opencode/commands/ eignet sich für persönliche, projektunabhängige Abläufe. .opencode/commands/ passt für lokale Pfade, Testregeln und Teamkonventionen. Ein klarer Prompt wie „Änderungen prüfen und Plan erstellen“ ist sicherer zu beurteilen als „alles reparieren“.

Eigene Befehle können auch im command-Objekt der JSON- oder JSONC-Konfiguration stehen. Verwende dies, wenn ein bestimmter Agent oder ein Modell gewählt werden soll. Fragen zu Pfaden, Schema und Priorität gehören weiterhin in den opencode.jsonc-Leitfaden.

{
  "$schema": "https://opencode.ai/config.json",
  "command": {
    "test-review": {
      "template": "Review the latest test output and list the first three fixes.",
      "description": "Review test output",
      "agent": "plan"
    }
  }
}

Konfiguration ist kein Geheimnisspeicher. API-Schlüssel und Tokens gehören in den vorgesehenen Credential-Weg. Ein Befehl mit Datei- oder Shell-Kontext verdient dieselbe Prüfung wie ein Skript.

---
description: Create a file with supplied values
---
Create a file named $1 in directory $2.
Use this content: $3
Show the proposed path before writing.

/create-file config.json src "{ \"key\": \"value\" }" liefert drei Werte. Die Vorlage muss erklären, wie sie verwendet werden und welcher Pfad vor dem Schreiben gezeigt wird. Für einen einzigen freien Text ist $ARGUMENTS einfacher.

Mit @src/components/Button.tsx lässt sich eine Datei referenzieren. Mit !`npm test` oder !`git log --oneline -10` kann Shell-Ausgabe in den Prompt gelangen. Da der Befehl im Projektstamm läuft, sollten destruktive oder geheimhaltende Befehle nicht in eine globale Vorlage gelangen.

Argumente sind Eingaben, keine Berechtigungen. Beginne mit einer lesenden Prüfung, genehmige danach eine kleine Änderung und automatisiere erst in einem vertrauenswürdigen Repository.

Ein eigener Befehl mit demselben Namen kann einen integrierten Befehl überschreiben. Vermeide daher help, undo und share, sofern der Austausch nicht ausdrücklich geplant ist. Ein Name wie review-tests ist für andere Entwickler verständlicher.

Prüfe Befehlsdateien wie Code: Prompt-Diff, erzeugte Antwort, referenzierte Dateien und vorgeschlagene Shell-Befehle. Agenten und Modelle sollten mit der Agents-Anleitung abgeglichen werden; bei Skills oder MCP helfen die Skills-Anleitung und die MCP-Anleitung.

1. Umfang: Eingabe und Ausgabe in einem Satz festlegen.
2. Ort: Projekt- oder globales Verzeichnis wählen und dokumentieren.
3. Eingaben: normale, fehlende, quotierte und pfadartige Werte testen.
4. Kontext: Datei- und Shell-Kontext vor einer Änderung prüfen.
5. Rechte: mit ask oder Lesen beginnen und nur kleine Änderungen erlauben.
6. Rollback: im Git festhalten, wie der Befehl deaktiviert oder umbenannt wird.

So lassen sich Fehler zuordnen: fehlender Befehl bedeutet meist Pfadproblem, falsche Antwort Prompt- oder Argumentproblem, verweigerte Änderung Berechtigungsproblem und ein Modellfehler Providerproblem.