Comandos do OpenCode: comandos personalizados, argumentos e uso seguro

O OpenCode inclui /init, /undo, /redo, /share e /help. Eles não são aliases de Shell nem entradas para package.json. Digite-os na interface do OpenCode e leia o resultado antes de continuar.

/help é a primeira verificação quando a lista da versão instalada não está clara. /undo e /redo não substituem commits do Git. Com /share, confira quais dados da sessão ficarão visíveis antes de usá-lo com código privado. A lista integrada pode mudar entre versões.

1. Crie .opencode/commands/review.md na raiz do projeto.
2. Adicione uma descrição curta e uma tarefa com limite claro.
3. Teste em uma branch pequena e revise o prompt e o 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.

O nome do arquivo vira o nome do comando: neste caso, /review. Use ~/.config/opencode/commands/ para fluxos pessoais globais e .opencode/commands/ para caminhos, testes e regras da equipe. “Revise as alterações e proponha um plano” é mais verificável que “conserte tudo”.

Também é possível definir comandos no objeto command da configuração JSON ou JSONC. Isso ajuda quando o fluxo precisa escolher um agent ou modelo específico. Caminhos, Schema e precedência pertencem ao guia 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"
    }
  }
}

A configuração não é um cofre de segredos. Chaves e tokens devem ficar no fluxo de credenciais do provider. Um comando que usa arquivos ou Shell deve ser revisado como um 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\" }" fornece três valores. O modelo deve explicar o uso de cada um e mostrar o caminho antes de escrever. Para uma frase livre, $ARGUMENTS é mais simples.

Use @src/components/Button.tsx para referenciar um arquivo e !`npm test` ou !`git log --oneline -10` para inserir saída do Shell no prompt. Como o comando roda a partir da raiz, evite operações destrutivas ou segredos nos modelos reutilizáveis.

Argumentos são entradas, não permissões. Comece com uma verificação somente leitura, aprove uma alteração pequena e automatize apenas em um repositório confiável.

Um comando personalizado com o mesmo nome pode substituir um comando integrado. Evite help, undo e share salvo se essa troca for intencional. Um nome como review-tests comunica melhor o resultado.

Revise os arquivos de comando como código: diff do prompt, resposta, arquivos citados e Shell proposto. Verifique agents e modelos no guia de Agents; para Skills e MCP, use os guias de Skills e MCP.

1. Escopo: descreva entrada e saída em uma frase.
2. Local: escolha projeto ou global e documente.
3. Entradas: teste valores normais, ausentes, entre aspas e caminhos.
4. Contexto: revise arquivos e saída antes de editar.
5. Permissões: comece com ask ou leitura e aprove mudanças pequenas.
6. Reversão: mantenha no Git e anote como desativar o comando.

Assim fica mais fácil separar falhas: comando ausente aponta para caminho, resultado ruim para prompt ou argumentos, alteração recusada para permissões e falha de modelo para o provider.