Comandi OpenCode: comandi personalizzati, argomenti e uso sicuro

OpenCode include /init, /undo, /redo, /share e /help. Non sono alias Shell e non vanno inseriti in package.json. Inseriscili nell’interfaccia OpenCode e leggi il risultato prima di procedere.

/help è il controllo iniziale quando la lista della versione installata non è chiara. /undo e /redo non sostituiscono Git. Con /share, controlla quali dati diventano visibili prima di usarlo con codice privato. La lista integrata può cambiare tra le versioni.

1. Crea .opencode/commands/review.md nella radice del progetto.
2. Aggiungi una descrizione breve e un compito con un confine chiaro.
3. Prova il comando in un branch piccolo e controlla prompt e 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.

Il nome del file diventa il nome del comando: qui si usa /review. ~/.config/opencode/commands/ è adatto a flussi personali globali; .opencode/commands/ a percorsi, test e regole del team. “Rivedi le modifiche e proponi un piano” è più verificabile di “sistema tutto”.

I comandi possono essere definiti nell’oggetto command della configurazione JSON o JSONC. È utile per scegliere un agent o un modello. Percorsi, schema e priorità appartengono alla guida 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 configurazione non è un archivio di segreti. Chiavi e token devono restare nel percorso credenziali del provider. Un comando che usa file o Shell va revisionato come uno 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\" }" fornisce tre valori. Il modello deve spiegare come usarli e mostrare il percorso prima della scrittura. Per una sola frase libera, $ARGUMENTS è più semplice.

Usa @src/components/Button.tsx per un riferimento al file e !`npm test` o !`git log --oneline -10` per inserire output Shell nel prompt. Poiché il comando parte dalla radice del progetto, evita operazioni distruttive o dati segreti nei modelli riutilizzabili.

Gli argomenti sono input, non permessi. Inizia con una prova in sola lettura, approva un cambiamento piccolo e automatizza solo in un repository affidabile.

Un comando personalizzato con lo stesso nome può sostituire un comando integrato. Evita help, undo e share se non è una scelta intenzionale. Un nome come review-tests comunica meglio il risultato.

Rivedi i file dei comandi come codice: diff del prompt, risposta, file citati e Shell proposto. Controlla agent e modelli con la guida Agents; per Skills e MCP usa le guide Skills e MCP.

1. Ambito: descrivi input e output in una frase.
2. Posizione: scegli percorso di progetto o globale e documentalo.
3. Input: prova valori normali, mancanti, quotati e percorsi.
4. Contesto: verifica file e output prima di modificare.
5. Permessi: inizia con ask o lettura e approva piccoli cambiamenti.
6. Rollback: conserva il comando in Git e annota come disattivarlo.

Così i problemi restano separati: comando assente significa spesso percorso, risultato errato prompt o argomenti, modifica negata permessi e modello non riuscito provider.