Comandos de OpenCode: comandos personalizados, argumentos y uso seguro

OpenCode incluye /init, /undo, /redo, /share y /help. No son alias de Shell ni entradas para package.json. Escríbelos en la interfaz de OpenCode y lee el resultado antes de continuar.

/help es la primera comprobación cuando no conoces la lista de la versión instalada. /undo y /redo no sustituyen a Git. Con /share, revisa qué datos de sesión se harán visibles antes de usarlo con código privado. La lista integrada puede cambiar con cada versión.

1. Crea .opencode/commands/review.md en la raíz del proyecto.
2. Añade una descripción breve y una tarea con un límite claro.
3. Prueba el comando en una rama pequeña y revisa el prompt y el 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.

El nombre del archivo se convierte en el nombre del comando: se invoca como /review. Usa ~/.config/opencode/commands/ para flujos personales globales y .opencode/commands/ para rutas, pruebas o reglas del equipo. Un prompt que dice “revisa los cambios y propone un plan” es más fácil de comprobar que “arregla todo”.

También puedes definir comandos en el objeto command de JSON o JSONC. Es útil cuando el comando debe seleccionar un agent o un modelo concreto. Las rutas y la precedencia pertenecen a la guía de configuración 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 configuración no es un almacén de secretos. Las claves y tokens deben permanecer en el flujo de credenciales del proveedor. Un comando que usa archivos o Shell se revisa como 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\" }" entrega tres valores. La plantilla debe indicar el uso de cada uno y mostrar la ruta antes de escribir. Para una sola frase libre, $ARGUMENTS es más sencillo.

Usa @src/components/Button.tsx para una referencia de archivo y !`npm test` o !`git log --oneline -10` para incluir salida de Shell. Como el comando se ejecuta desde la raíz del proyecto, evita operaciones destructivas o datos secretos en las plantillas reutilizables.

Los argumentos son entradas, no permisos. Empieza con una prueba de solo lectura, aprueba después un cambio pequeño y automatiza únicamente en un repositorio de confianza.

Un comando personalizado con el mismo nombre puede reemplazar un comando integrado. Evita help, undo y share salvo que sea una decisión intencional. Un nombre como review-tests comunica mejor el resultado esperado.

Revisa los archivos de comandos como código: diff del prompt, respuesta, archivos referenciados y Shell propuesto. Comprueba agents y modelos con la guía de Agents; para Skills y MCP, usa las guías de Skills y MCP.

1. Alcance: describe entrada y salida en una frase.
2. Ubicación: elige carpeta de proyecto o global y documenta la decisión.
3. Entradas: prueba valores normales, ausentes, entre comillas y rutas.
4. Contexto: revisa referencias y salida antes de editar.
5. Permisos: empieza con ask o lectura y aprueba cambios pequeños.
6. Reversión: guarda el comando en Git y anota cómo desactivarlo.

Así se separan las fallas: un comando ausente apunta a la ruta, un resultado extraño al prompt o los argumentos, una edición rechazada a los permisos y un modelo que falla al proveedor.