Commandes OpenCode : commandes personnalisées, arguments et usage sûr

OpenCode fournit /init, /undo, /redo, /share et /help. Ce ne sont ni des alias Shell ni des entrées à placer dans package.json. Saisissez-les dans l’interface OpenCode et lisez le résultat avant de poursuivre.

/help est le premier contrôle lorsque la liste de la version installée est incertaine. /undo et /redo ne remplacent pas les commits Git. Avec /share, vérifiez les données de session rendues visibles avant de l’utiliser avec du code privé. La liste intégrée peut changer selon les versions.

1. Créez .opencode/commands/review.md à la racine du projet.
2. Ajoutez une description courte et une tâche à limite claire.
3. Testez dans une petite branche et vérifiez le prompt et le 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.

Le nom du fichier devient celui de la commande : elle s’appelle /review. Le dossier ~/.config/opencode/commands/ convient aux workflows personnels et globaux; .opencode/commands/ convient aux chemins, tests et règles d’équipe. « Examiner les changements et proposer un plan » est plus contrôlable que « tout réparer ».

Les commandes peuvent aussi être définies dans l’objet command d’une configuration JSON ou JSONC. C’est utile pour choisir un agent ou un modèle précis. Les chemins, le schéma et la priorité restent couverts par le guide opencode.jsonc.

{
  "$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"
    }
  }
}

La configuration n’est pas un coffre-fort. Les clés et tokens doivent rester dans le chemin d’identifiants prévu par le fournisseur. Une commande qui utilise des fichiers ou le Shell se relit comme un script.

---
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\" }" fournit trois valeurs. Le modèle doit expliquer leur usage et afficher le chemin avant l’écriture. Pour une seule phrase libre, $ARGUMENTS est plus simple.

Utilisez @src/components/Button.tsx pour référencer un fichier, et !`npm test` ou !`git log --oneline -10` pour injecter une sortie Shell dans le prompt. Comme la commande part de la racine du projet, évitez les opérations destructrices ou les secrets dans les modèles réutilisables.

Les arguments sont des entrées, pas des permissions. Commencez par une vérification en lecture seule, approuvez ensuite une petite modification, puis automatisez seulement dans un dépôt de confiance.

Une commande personnalisée portant le même nom peut remplacer une commande intégrée. Évitez help, undo et share sauf si ce remplacement est volontaire. Un nom comme review-tests indique mieux le résultat attendu.

Relisez les fichiers de commandes comme du code : diff du prompt, réponse, fichiers référencés et Shell proposé. Vérifiez les agents et modèles avec le guide Agents; pour Skills et MCP, utilisez les guides Skills et MCP.

1. Périmètre : décrire entrée et sortie en une phrase.
2. Emplacement : choisir projet ou global et documenter.
3. Entrées : tester valeurs normales, absentes, citées et chemins.
4. Contexte : vérifier fichiers et sortie avant une modification.
5. Droits : commencer en lecture ou ask et approuver un petit changement.
6. Retour arrière : conserver le fichier dans Git et noter comment désactiver la commande.

Ce parcours permet d’isoler les pannes : une commande absente indique souvent un chemin, un mauvais résultat le prompt ou les arguments, une édition refusée les permissions et une erreur de modèle le fournisseur.