Curso de OpenCode

Instalar OpenCode mediante script oficial, npm, bun, pnpm, yarn, Homebrew, Arch Linux o método aprobado por IT.

Comparar métodos de instalación según actualización, permisos corporativos, entornos gestionados y reproducibilidad.

Configurar rutas, shell, terminal, variables de entorno y compatibilidad de sistema operativo.

Validar instalación con `opencode`, `opencode --version`, sesiones iniciales y comprobación de logs.

Gestionar `opencode upgrade` para actualizar a la última versión o a una versión específica.

Controlar autoupdate, notificaciones de actualización y política de versiones en equipos corporativos.

Instalar OpenCode en estaciones de desarrollo, máquinas virtuales, devcontainers, runners o entornos remotos.

Preparar entornos Windows con Git Bash cuando sea necesario y revisar diferencias de keybinds, paths y shell.

Diagnosticar fallos iniciales por permisos, PATH, Node/Bun, certificados, proxy o terminal incompatible.

Documentar un procedimiento interno de instalación y actualización para todo el equipo.

Utilizar la interfaz TUI como punto principal de interacción con el agente en proyectos reales.

Navegar sesiones, mensajes, respuestas, herramientas, aprobaciones, agentes, subagentes y contexto de archivo.

Hacer preguntas sobre el repositorio sin modificar archivos, separando exploración de ejecución.

Añadir features mediante instrucciones específicas, referencias a archivos, criterios de aceptación y comandos de validación.

Solicitar cambios sobre código existente con contexto suficiente para evitar ediciones amplias o ambiguas.

Usar `/undo` y `/redo` para revertir o rehacer cambios realizados durante la sesión.

Entender cuándo conviene continuar una sesión, crear una nueva, forkear o compactar contexto.

Trabajar con prompts iterativos sin convertir la conversación en un historial ruidoso e inmanejable.

Incorporar comprobaciones manuales después de cambios generados por el agente.

Crear una rutina diaria de uso: explorar, planificar, editar, probar, revisar, documentar y commitear.

Usar OpenCode desde desktop beta cuando el equipo prefiere una experiencia separada del terminal puro.

Integrar OpenCode en VS Code, Cursor, Windsurf, VSCodium u otros IDEs compatibles con terminal integrada.

Utilizar quick launch para abrir OpenCode en terminal dividida y mantener continuidad con el editor.

Aprovechar context awareness compartiendo selección, pestaña actual o archivo abierto desde el IDE.

Configurar `EDITOR` para flujos como `/editor` o exportación hacia el editor aprobado por el equipo.

Entender ACP como protocolo para usar OpenCode en editores compatibles mediante `opencode acp`.

Comparar TUI, IDE extension, desktop app, web y ACP según flujo del equipo.

Diseñar recomendaciones por perfil: desarrollador, tech lead, QA, SRE, arquitecto o soporte.

Diagnosticar problemas de integración IDE por shell command, permisos de instalación, terminal integrada o extensiones bloqueadas.

Documentar estándares de uso para evitar que cada desarrollador configure una experiencia incompatible.

Comprender que OpenCode puede ejecutarse como servidor local o headless y ser consumido por distintos clientes.

Utilizar `opencode serve` para exponer API HTTP programática sin abrir la TUI.

Utilizar `opencode web` para iniciar interfaz web sobre servidor local o remoto controlado.

Proteger servidor y web mediante `OPENCODE_SERVER_PASSWORD`, usuario básico, hostname y puerto controlado.

Configurar `--port`, `--hostname`, `--cors`, `--mdns` y `--mdns-domain` según entorno.

Utilizar `opencode attach` para conectar una TUI a un backend ya iniciado.

Reducir tiempos de arranque de MCP o servicios externos manteniendo un servidor headless activo.

Entender la relación entre servidor, TUI, OpenAPI 3.1, SDK y clientes programáticos.

Revisar riesgos de exponer servidor OpenCode en red sin autenticación, CORS controlado o aislamiento.

Diseñar usos enterprise: servidor de equipo, sandbox interno, laboratorio, integración con herramientas y acceso remoto seguro.

Ejecutar `opencode run` para tareas no interactivas, scripts, consultas rápidas y automatizaciones reproducibles.

Pasar modelo, agente, archivos, sesión, título, formato JSON y attachment remoto desde línea de comandos.

Gestionar sesiones con `opencode session list`, continuación, fork, borrado y exportación.

Exportar e importar sesiones para auditoría, revisión, reproducción o colaboración técnica.

Usar `opencode stats` para analizar tokens, coste, modelos, herramientas y consumo por proyecto.

Gestionar modelos con `opencode models`, filtros por proveedor, refresh y salida verbose.

Gestionar credenciales con `opencode auth login`, list y logout.

Usar `opencode db` para inspeccionar base local y rutas de datos cuando se necesita troubleshooting avanzado.

Usar `opencode debug`, `--log-level`, `--print-logs` y logs locales para investigar fallos.

Crear scripts internos que integren CLI con pipelines, hooks, revisiones, documentación o validaciones.

Conectar proveedores mediante `/connect` o `opencode auth login`, entendiendo almacenamiento local de credenciales.

Seleccionar modelos desde `/models` y configurar defaults por proyecto, agente o comando.

Trabajar con más de 75 proveedores soportados por AI SDK y Models.dev, incluyendo opciones cloud y modelos locales.

Utilizar OpenCode Zen como gateway opcional con modelos probados y recomendados por el equipo de OpenCode.

Evaluar OpenCode Go como plan de bajo coste para modelos open coding servidos por OpenCode.

Integrar GitHub Copilot o ChatGPT Plus/Pro cuando la política corporativa lo permite y el flujo está soportado.

Comparar modelos para planificación, edición, debugging, refactor, tests, documentación, frontend, backend y razonamiento profundo.

Diseñar una política de modelos permitidos por entorno, coste, sensibilidad de código y tipo de tarea.

Configurar variantes de modelo, variantes built-in, variantes custom y rotación de variantes cuando se quiere comparar rendimiento.

Medir coste, latencia y calidad por modelo antes de estandarizarlo en equipos.

Crear `opencode.json` u `opencode.jsonc` con esquema, providers, modelos, permisos, agentes, commands, MCP, formatters y LSP.

Diferenciar configuración global en `~/.config/opencode`, configuración de proyecto en `.opencode` y configuración inline o por variables.

Utilizar `OPENCODE_CONFIG`, `OPENCODE_CONFIG_DIR`, `OPENCODE_CONFIG_CONTENT` y `OPENCODE_TUI_CONFIG` cuando se necesitan entornos especiales.

Aplicar configuración gestionada en macOS, Linux o Windows para organizaciones que no quieren que el usuario sobrescriba políticas críticas.

Configurar autoupdate, compaction, watcher ignore patterns, instructions, plugins, formatters, LSP y MCP desde config.

Diseñar precedencia entre global, proyecto, custom directory y managed settings para evitar sorpresas.

Crear plantillas de configuración por tipo de proyecto: frontend, backend, monorepo, microservicio, infraestructura o librería.

Mantener configuración versionada en Git cuando afecta al comportamiento del equipo.

Separar ajustes personales de ajustes compartidos para no imponer preferencias individuales al proyecto.

Documentar cada opción crítica con motivo, owner y alcance de aplicación.

Crear `AGENTS.md` con `/init` para capturar build, lint, test, arquitectura, convenciones y gotchas del proyecto.

Revisar el contenido generado por `/init` antes de commitearlo para evitar instrucciones incorrectas o demasiado largas.

Crear reglas manuales con estructura clara: comandos, estándares, testing, arquitectura, seguridad, despliegue y límites.

Diferenciar reglas de proyecto en el root del repositorio y reglas globales personales en `~/.config/opencode/AGENTS.md`.

Aprovechar compatibilidad con `CLAUDE.md` para equipos que migran desde Claude Code sin rehacer todo desde cero.

Referenciar instrucciones externas mediante `instructions` en `opencode.json` cuando existen guías en `CONTRIBUTING.md` o docs internas.

Evitar `AGENTS.md` enormes que consumen contexto y esconden lo importante entre ruido.

Documentar comandos críticos en orden: instalar dependencias, lint, typecheck, test, build y validación focalizada.

Añadir restricciones de seguridad: no tocar secretos, no editar migraciones sin permiso, no ejecutar deploys, no modificar locks sin revisión.

Crear un proceso de revisión de reglas igual que cualquier cambio relevante del repositorio.

Configurar references para que OpenCode pueda usar documentación, librerías, ejemplos o repositorios externos al proyecto.

Añadir references locales mediante rutas relativas, absolutas o `~/` según estructura del equipo.

Añadir references de Git mediante `owner/repo`, URL, branch o ref específico.

Escribir descripciones breves que indiquen cuándo debe usar cada referencia y para qué tipo de tarea.

Ocultar referencias del autocomplete cuando deben estar disponibles pero no saturar la experiencia.

Controlar permisos sobre directorios externos mediante `external_directory`, lectura y edición diferenciadas.

Usar references para design systems, SDKs internos, documentación de producto, ejemplos corporativos y librerías compartidas.

Evitar que el agente edite repositorios externos o documentación compartida sin permiso explícito.

Sincronizar y revisar references cuando cambian branches, versiones o convenciones internas.

Documentar una estrategia corporativa de references por monorepo, plataforma y producto.

Utilizar Build como agente principal para trabajo de desarrollo con herramientas completas habilitadas.

Utilizar Plan para analizar, diseñar estrategia y revisar opciones sin modificar archivos.

Invocar subagentes General, Explore y Scout cuando una tarea requiere investigación especializada o exploración de código.

Cambiar entre agentes primarios durante la sesión con Tab o keybind configurado.

Invocar subagentes manualmente mediante `@` cuando se necesita delegar análisis o búsqueda específica.

Entender cómo los agentes primarios pueden lanzar subagentes automáticamente según descripción y necesidad.

Diferenciar tareas de ejecución, planificación, exploración, revisión y búsqueda para escoger el agente adecuado.

Evitar usar Build para todo cuando basta con análisis sin permisos de edición.

Crear patrones de uso: Plan antes de refactor grande, Explore antes de tocar código desconocido, Build para cambios controlados.

Documentar recomendaciones internas para que el equipo use agentes integrados con criterio.

Crear agentes con `opencode agent create` definiendo descripción, modo, modelo y permisos.

Elegir entre modo `primary`, `subagent` o `all` según interacción directa o delegación especializada.

Diseñar agentes por rol: reviewer, tester, security-auditor, docs-writer, migration-planner, frontend-refactorer o api-designer.

Configurar permisos por agente para limitar edición, shell, web, LSP, skills, MCP o acceso externo.

Crear agentes Markdown con frontmatter, descripción, modelo, modo y política de permisos.

Diseñar descripciones que permitan al agente primario escoger bien cuándo invocar un subagente.

Evitar subagentes demasiado genéricos que compiten entre sí o duplican funciones del agente principal.

Probar agentes personalizados con tareas reales y medir si aportan calidad frente a prompts manuales.

Versionar agentes de proyecto en `.opencode/agent` para compartirlos con el equipo.

Crear un catálogo interno de agentes aprobados con propósito, permisos, owner y ejemplos de uso.

Comprender las herramientas built-in como capacidades que el modelo puede usar para actuar sobre el proyecto.

Usar `read` para inspeccionar archivos completos o rangos concretos sin cargar contexto innecesario.

Usar `grep` y `glob` para localizar código, patrones, rutas y referencias respetando `.gitignore`.

Usar `edit`, `write` y `apply_patch` para modificar archivos, crear nuevos y aplicar diffs de forma controlada.

Usar `bash` para ejecutar tests, lint, build, git status, scripts y comandos de diagnóstico.

Usar `todowrite` para mantener planes de trabajo en tareas complejas y revisar progreso.

Usar `webfetch` y `websearch` para documentación externa cuando el modelo o proveedor lo permite.

Usar `question` para que el agente solicite aclaraciones durante ejecución cuando tiene permiso.

Usar `skill` para cargar instrucciones reutilizables bajo demanda.

Diseñar permisos y reglas para que cada tool se use con el menor privilegio razonable.

Configurar permisos como `allow`, `ask` o `deny` para lectura, edición, shell, búsqueda, web, LSP, skills y subagentes.

Aplicar reglas granulares por patrón, ruta, comando, regex, glob, skill, subagente o herramienta MCP.

Entender que `edit` controla modificaciones de archivo, incluyendo write y apply_patch.

Bloquear lectura de `.env` y archivos sensibles, manteniendo `.env.example` accesible cuando es útil.

Gestionar `external_directory` para controlar acceso a rutas fuera del worktree actual.

Configurar `doom_loop` para detectar repetición de la misma herramienta y evitar bucles improductivos.

Usar aprobación `once`, `always` o `reject` con criterio durante sesiones interactivas.

Denegar comandos peligrosos como deploy, rm masivo, git push, migraciones o modificaciones de producción salvo autorización.

Crear perfiles de permisos: exploración, desarrollo controlado, CI, PR automation, seguridad y documentación.

Revisar permisos periódicamente para equilibrar productividad y riesgo operativo.

Diferenciar permisos de tools y policies de recursos, especialmente uso de proveedores LLM.

Configurar `experimental.policies` para permitir o denegar proveedores específicos.

Bloquear proveedores no aprobados por seguridad, privacidad, coste o normativa corporativa.

Crear reglas amplias de denegación y excepciones explícitas para proveedores permitidos.

Controlar uso de proveedores internos, gateways corporativos, regiones aprobadas o modelos específicos.

Entender que una policy puede ocultar proveedores aunque existan credenciales válidas.

Diseñar políticas globales que un repositorio no pueda relajar localmente.

Sustituir listas antiguas de `disabled_providers` o `enabled_providers` por policies cuando proceda.

Documentar el motivo de cada proveedor permitido o bloqueado.

Integrar policies con configuración enterprise y revisión de seguridad.

Configurar servidores MCP locales mediante comando, entorno y estado enabled/disabled.

Configurar servidores MCP remotos mediante URL, autenticación y overrides locales.

Usar `opencode mcp add`, list, auth, logout y debug para gestionar servidores desde CLI.

Entender que cada MCP añade tools y contexto, por lo que muchos servidores pueden consumir ventana de contexto rápidamente.

Diseñar MCP para GitHub, Jira, bases de datos, documentación, APIs internas, observabilidad o sistemas corporativos.

Aplicar permisos por wildcard para herramientas de un MCP completo o herramientas concretas.

Controlar OAuth de MCP servers y credenciales asociadas a sistemas externos.

Desactivar temporalmente servidores sin eliminarlos cuando no se necesitan en una tarea.

Diagnosticar problemas de conexión, autenticación, tool discovery, latencia o exceso de tokens.

Crear un catálogo MCP aprobado con owner, propósito, riesgos, permisos y ejemplos de uso.

Crear custom tools para encapsular acciones internas que no conviene dejar como comandos bash abiertos.

Diseñar herramientas con argumentos claros, validación, salida estructurada y errores comprensibles.

Escribir custom tools en TypeScript, JavaScript, Python u otros lenguajes soportados por el entorno del equipo.

Pasar contexto de proyecto o sesión a la herramienta cuando hace falta comportamiento contextualizado.

Crear herramientas para consultar APIs internas, validar arquitectura, revisar convenciones o ejecutar checks corporativos.

Evitar herramientas con permisos excesivos que permitan al agente modificar sistemas externos sin control.

Registrar entradas, salidas, errores y duración de herramientas críticas.

Versionar custom tools en `.opencode` o en paquetes internos reutilizables.

Probar custom tools de forma aislada antes de exponerlas al modelo.

Documentar contrato, owner, dependencias, riesgos y ejemplos de cada herramienta.

Entender los plugins como extensiones que pueden engancharse a eventos, modificar comportamiento o añadir integraciones.

Instalar plugins desde CLI con `opencode plugin` o `opencode plug`, usando configuración global o de proyecto.

Cargar plugins desde `.opencode/plugins`, `~/.config/opencode/plugins` o paquetes npm aprobados.

Evaluar plugins comunitarios antes de usarlos en proyectos corporativos por seguridad, mantenimiento y permisos.

Revisar casos del ecosistema: sandboxes, Helicone, type injection, OAuth alternativo, devcontainers, pruning, secret redaction o Wakatime.

Crear plugins internos para notificaciones, telemetría, auditoría, políticas de comandos o integración con plataformas internas.

Ejecutar OpenCode con `--pure` para descartar plugins durante troubleshooting o análisis de comportamiento.

Controlar versiones de plugins, cambios de API y compatibilidad con OpenCode.

Documentar qué plugins están permitidos por equipo, repositorio o entorno.

Crear una política de extensibilidad que permita innovación sin abrir riesgos innecesarios.

Crear skills como carpetas con `SKILL.md` para definir instrucciones reutilizables bajo demanda.

Ubicar skills en `.opencode/skills`, `~/.config/opencode/skills`, `.claude/skills` o `.agents/skills`.

Entender descubrimiento local desde el directorio actual hasta el git worktree.

Diseñar skills para tareas repetibles: refactor seguro, testing, migración, documentación, seguridad, performance o API review.

Mantener el contenido de skills específico, accionable y cargable solo cuando se necesita.

Evitar skills gigantes que sustituyen indebidamente a documentación o prompts de agente.

Combinar skills con agentes especializados para crear workflows internos potentes.

Versionar skills de proyecto y mantener skills globales para preferencias personales.

Probar si el agente carga la skill adecuada y aplica instrucciones sin invadir tareas no relacionadas.

Crear una biblioteca corporativa de skills aprobadas por stack, arquitectura y calidad.

Crear comandos personalizados en `.opencode/commands` o `~/.config/opencode/commands`.

Definir comandos Markdown con frontmatter: descripción, agente, subtask, modelo y template.

Definir comandos en JSON dentro de `opencode.jsonc` cuando se prefiere configuración centralizada.

Utilizar `$ARGUMENTS`, `$1`, `$2` y parámetros posicionales para comandos reutilizables.

Referenciar archivos con `@ruta/archivo` para incluir contexto relevante automáticamente.

Incorporar salida de shell cuando un comando debe usar resultados de tests, git diff o scripts internos.

Crear comandos para test, review, docs, changelog, refactor, migration, security scan, PR summary o release notes.

Evitar comandos ambiguos que ejecutan tareas amplias sin criterios de aceptación ni verificación.

Asociar comandos a agentes concretos para separar plan, build, review o security.

Crear un catálogo de comandos corporativos documentado y versionado en cada tipo de proyecto.

Activar LSP de forma explícita cuando el proyecto se beneficia de diagnósticos semánticos adicionales.

Comprender que LSP está deshabilitado por defecto y puede requerir variable experimental para tool LSP.

Utilizar servidores integrados para lenguajes como TypeScript, Python, Go, Java, Rust, C/C++, PHP, Svelte, Vue, Terraform o YAML.

Configurar LSPs custom o desactivar servidores concretos cuando generan ruido, consumo o conflictos.

Entender operaciones como go to definition, references, hover, symbols, implementation y call hierarchy.

Comparar uso de LSP frente a comandos CLI de lint, typecheck o tests documentados en `AGENTS.md`.

Evitar LSP cuando los servidores se desincronizan, consumen demasiada memoria o ralentizan el flujo del agente.

Documentar requisitos de LSP por stack: SDKs, dependencias, language servers y comandos de instalación.

Usar diagnósticos LSP para mejorar correcciones de código sin sustituir pruebas reales.

Crear recomendaciones internas de cuándo activar LSP por repositorio.

Activar formatters built-in o custom para que los cambios del agente respeten estilo del proyecto.

Configurar Prettier, formatters propios o comandos por extensión desde `opencode.json`.

Desactivar formatters en proyectos donde el formateo se controla exclusivamente por CI o herramientas internas.

Configurar themes built-in, system theme o temas custom para adaptar la TUI al terminal del equipo.

Crear temas JSON con colores, variantes dark/light, referencias y valores heredados del terminal.

Personalizar keybinds en `tui.json`, incluyendo leader key, navegación, acciones y atajos por sistema operativo.

Ajustar keybinds para Windows cuando no existen comportamientos POSIX como suspend.

Documentar combinaciones de teclas esenciales para sesiones, cambio de agentes, navegación y copy/paste.

Establecer una configuración TUI recomendada sin imponer preferencias visuales innecesarias.

Resolver problemas de truecolor, terminal, fuentes, clipboard y compatibilidad de atajos.

Instalar el agente GitHub con `opencode github install` o configuración manual de workflow.

Invocar OpenCode en issues o pull requests mediante comentarios `/opencode` o `/oc`.

Usar el agente para triage de issues, explicación de problemas, implementación de fixes y apertura de PRs.

Ejecutar OpenCode dentro de GitHub Actions runners para mantener ejecución en infraestructura del repositorio.

Configurar eventos soportados como issue comments, PR review comments, issues y schedules según flujo.

Preparar prompts custom para issue triage, PR review, bug fix, documentación o mantenimiento.

Gestionar tokens, secrets, permisos de workflow, ramas, autores y restricciones de seguridad.

Evitar que el agente ejecute cambios amplios en repositorios críticos sin checks, reviewers y permisos controlados.

Probar GitHub agent en repositorios de laboratorio antes de activar en proyectos productivos.

Documentar política de uso en issues y PRs para que el equipo sepa cuándo invocar OpenCode y qué esperar.

Configurar OpenCode en GitLab CI/CD para ejecutar tareas dentro de runners controlados.

Invocar el agente mediante comentarios `@opencode` en issues o merge requests cuando el flujo lo soporta.

Preparar variables CI de tipo File para autenticación OpenCode, marcadas como masked y hidden.

Configurar `.gitlab-ci.yml` o componentes CI para instalar y ejecutar OpenCode con modelo y configuración aprobada.

Crear service accounts y tokens limitados para operaciones sobre repositorio y merge requests.

Usar OpenCode para triage, implementación de fixes, creación de ramas y merge requests.

Revisar diferencias entre GitHub Actions y GitLab CI en permisos, secretos, eventos y contexto disponible.

Evitar ejecución en runners no confiables o compartidos cuando el repositorio contiene código sensible.

Crear templates de pipeline reutilizables por grupo, producto o tipo de repositorio.

Documentar el flujo GitLab con owners, límites, revisiones, logs y rollback.

Usar `/share` para crear enlaces públicos de sesiones cuando se necesita colaborar o pedir ayuda.

Entender que las sesiones compartidas son accesibles para cualquiera con el enlace.

Configurar sharing manual, auto-share o disabled según política de privacidad del equipo.

Deshabilitar sharing en repositorios sensibles o mediante configuración gestionada enterprise.

Usar `opencode export` para extraer sesiones JSON y `--sanitize` para redactar datos sensibles.

Importar sesiones locales o share URLs para análisis, reproducción o transferencia de contexto.

Crear normas de colaboración: qué se puede compartir, con quién, durante cuánto tiempo y con qué sanitización.

Evitar compartir prompts, código, secretos, rutas internas o información de clientes en enlaces públicos.

Usar sesiones compartidas para depuración técnica cuando el contenido no es sensible.

Documentar un flujo de soporte interno basado en export sanitizado, no en capturas desordenadas.

Utilizar el SDK JS/TS `@opencode-ai/sdk` para construir integraciones sobre el servidor OpenCode.

Consumir el servidor HTTP iniciado con `opencode serve` desde herramientas internas o aplicaciones.

Revisar OpenAPI 3.1 publicada por el servidor para generar clientes o inspeccionar endpoints.

Trabajar con APIs de global health, proyectos, sesiones, mensajes, commands, files, tools, LSP, MCP, agents y events.

Usar SSE para observar eventos globales o de sesión cuando una integración necesita seguimiento en tiempo real.

Crear paneles internos, orquestadores, bots, interfaces web o tooling CI sobre OpenCode Server.

Proteger servidor con basic auth, CORS, hostname restringido y red interna.

Separar integraciones experimentales de herramientas productivas que ejecutan cambios reales.

Registrar acciones programáticas para auditoría y soporte.

Documentar contratos de integración para que OpenCode no sea una caja negra dentro de la plataforma interna.

Configurar OpenCode detrás de proxies corporativos con `HTTPS_PROXY`, `HTTP_PROXY` y `NO_PROXY`.

Evitar routing loops asegurando que localhost y 127.0.0.1 quedan fuera del proxy.

Configurar autenticación proxy sin hardcodear contraseñas en scripts o perfiles compartidos.

Usar `NODE_EXTRA_CA_CERTS` para CAs corporativas, inspección TLS o certificados internos.

Diseñar integración con LLM Gateways corporativos cuando proxy NTLM, Kerberos o políticas internas dificultan acceso directo.

Diagnosticar errores de conexión con proveedores, MCP remotos, webfetch, share o autenticación OAuth.

Documentar configuración de red por sistema operativo, terminal, shell y entorno gestionado.

Preparar perfiles para trabajo en VPN, oficina, remoto, devcontainer y runners CI.

Evitar que soluciones personales de proxy queden dentro de repositorios o scripts compartidos.

Crear una guía de troubleshooting de red para adopción enterprise.

Comprender que OpenCode no almacena código ni contexto por defecto, salvo funciones explícitas como share.

Diseñar OpenCode Enterprise para organizaciones que necesitan que código y datos no salgan de su infraestructura.

Usar configuración centralizada para integrar SSO, AI gateway interno y restricciones de proveedores.

Deshabilitar share pages cuando la organización no permite sincronizar conversaciones fuera de su infraestructura.

Evaluar self-hosting de componentes de share cuando se necesita colaboración sin salida de datos.

Crear una configuración gestionada que usuarios no puedan modificar en macOS, Linux o Windows.

Integrar OpenCode con gateways LLM aprobados, logging interno, control de costes y proveedores filtrados.

Definir un piloto interno con equipos, repositorios, métricas, riesgos, soporte y criterios de expansión.

Establecer una política de datos: qué repositorios, archivos, prompts y proveedores están permitidos.

Convertir OpenCode en una capacidad enterprise con ownership técnico, seguridad y soporte.

Bloquear lectura de `.env`, secretos, certificados, tokens, dumps, credenciales y archivos de configuración sensibles.

Configurar permisos `ask` o `deny` para bash, edit, webfetch, websearch, MCP y external directories en repositorios críticos.

Revisar herramientas MCP y plugins como parte de la supply chain, no como extensiones inocuas.

Aplicar controles para comandos destructivos, instalaciones de paquetes, cambios de lockfiles, migraciones y despliegues.

Evitar que el agente copie código propietario a share links, prompts externos o proveedores no aprobados.

Añadir reglas en `AGENTS.md` sobre secretos, datos de clientes, producción, compliance y seguridad.

Usar agentes de security review con permisos de solo lectura para auditoría de código.

Crear checks de precommit o CI que detecten secretos generados o modificados por el agente.

Documentar incidentes de uso indebido y ajustar configuración, permisos o formación.

Establecer una política de revisión humana obligatoria antes de mergear cambios generados por agente.

Analizar un issue con Plan antes de pedir cambios de Build en repositorios complejos.

Pedir al agente que localice puntos de impacto antes de modificar código.

Implementar features con criterios de aceptación, tests, documentación y pasos de verificación.

Refactorizar por fases para evitar cambios masivos imposibles de revisar.

Usar subagentes para exploración de código y revisión posterior de la solución.

Aplicar patches pequeños y revisables en lugar de reescrituras amplias sin justificación.

Ejecutar test focalizado antes de test completo cuando el repositorio es grande.

Generar migraciones, cambios de API o contratos con revisión explícita de compatibilidad.

Documentar decisiones de arquitectura en ADRs, README o comentarios cuando el cambio lo justifica.

Crear una metodología de trabajo agentic: plan, cambio pequeño, verificación, revisión, commit y seguimiento.

Pedir generación de tests a partir de comportamiento esperado, bugs reproducidos y casos límite.

Crear comandos personalizados para unit tests, integration tests, e2e, coverage y mutation testing.

Usar OpenCode para interpretar fallos de CI, logs de tests, snapshots rotos y regresiones.

Evitar que el agente modifique tests para hacerlos pasar sin arreglar el comportamiento real.

Diseñar instrucciones de QA que obliguen a probar happy path, edge cases, errores y permisos.

Usar LSP, linters, typecheck y pruebas CLI como feedback dentro del bucle del agente.

Crear skills de testing por stack: React, Node, Python, Java, .NET, Go, Rust o PHP.

Generar fixtures y mocks manteniendo legibilidad y evitando datos sensibles.

Revisar cobertura después de cambios y priorizar tests que protegen lógica crítica.

Integrar OpenCode con pipelines donde los checks deciden si un cambio puede revisarse.

Usar OpenCode para explicar arquitectura, flujos, módulos, APIs y decisiones históricas de un repositorio.

Generar documentación a partir de código, tests, OpenAPI, schemas, README y convenciones reales.

Crear comandos para actualizar changelogs, ADRs, guías de setup, docs de API y notas de release.

Usar `/init` para mejorar `AGENTS.md` y convertir conocimiento tácito en instrucciones compartidas.

Preparar onboarding técnico con mapa de repo, comandos, módulos críticos y errores habituales.

Evitar documentación inventada exigiendo referencias a archivos, pruebas o código real.

Usar references para conectar documentación de producto, design system y librerías internas.

Revisar documentación generada con owners técnicos antes de publicarla.

Mantener docs vivas mediante comandos periódicos o PR workflows.

Medir utilidad de documentación por reducción de preguntas repetidas y rapidez de incorporación.

Auditar reglas existentes de Claude Code, Cursor, Copilot o agentes internos antes de migrar.

Reutilizar `CLAUDE.md` como fallback cuando no existe `AGENTS.md`.

Migrar skills desde `.claude/skills` o `.agents/skills` aprovechando rutas compatibles.

Convertir prompts recurrentes en custom commands de OpenCode.

Convertir modos o perfiles de otras herramientas en agentes primarios y subagentes de OpenCode.

Revisar diferencias de permisos, tools, MCP, LSP, contexto, share y ejecución shell antes de trasladar workflows.

Comparar resultados entre herramientas en tareas reales: bug fix, refactor, test generation y documentación.

Crear una fase de convivencia para no bloquear a equipos que dependen de flujos anteriores.

Documentar equivalencias y cambios de hábitos para desarrolladores.

Definir cuándo OpenCode pasa a ser estándar y qué excepciones siguen usando otras herramientas.

Diseñar reglas específicas para proyectos frontend con React, Vue, Svelte, Angular, CSS, tests y design systems.

Diseñar reglas para backend con APIs, servicios, capas, bases de datos, migraciones, contratos y observabilidad.

Preparar OpenCode para monorepos con workspaces, paquetes compartidos, límites de dependencia y comandos focalizados.

Usar OpenCode en proyectos data con notebooks, pipelines, SQL, dbt, pruebas de calidad y documentación.

Aplicar OpenCode a infraestructura como Terraform, Kubernetes, Helm, Docker, CI/CD y scripts operativos.

Configurar LSP, formatters y commands por stack para reducir errores y mejorar calidad.

Crear agents especializados por dominio técnico: frontend-reviewer, api-contract-checker, infra-safety, data-quality o migration-planner.

Controlar herramientas peligrosas en infra: apply, destroy, kubectl, helm upgrade, deploy y cambios de secretos.

Preparar references a design systems, APIs internas, docs de plataforma y estándares de arquitectura.

Documentar plantillas por stack para acelerar adopción sin empezar de cero en cada repositorio.

Usar sesiones múltiples para separar tareas independientes y evitar mezclar contextos incompatibles.

Forkear sesiones cuando se quieren probar estrategias alternativas sin perder historial.

Continuar sesiones cuando se necesita retomar trabajo con contexto relevante.

Configurar compaction automática para sesiones largas y evitar desbordes de contexto.

Activar pruning de outputs antiguos cuando conviene reducir tokens sin perder mensajes clave.

Reservar buffer de contexto para compactación y operaciones posteriores.

Diseñar prompts de recap antes de sesiones largas o cambios de fase.

Usar todos, subagentes y commands para mantener estructura durante tareas complejas.

Evitar sesiones enormes donde el agente arrastra decisiones obsoletas.

Crear una disciplina de “cerrar sesión” con resumen, cambios, tests, dudas y próximos pasos.

Localizar logs en `~/.local/share/opencode/log` o ruta equivalente en Windows.

Ajustar `--log-level DEBUG` y `--print-logs` para investigar fallos complejos.

Revisar almacenamiento local de sesiones, datos de aplicación, credenciales y snapshots.

Diagnosticar problemas de proveedores, autenticación, modelos, MCP, proxy, certificados, plugins o LSP.

Usar `opencode debug` para herramientas internas de diagnóstico.

Usar `opencode db path` y consultas controladas cuando se necesita inspeccionar estado local.

Ejecutar `--pure` para descartar plugins durante troubleshooting.

Exportar sesiones sanitizadas para soporte sin revelar datos sensibles.

Usar `opencode uninstall` con `--keep-config`, `--keep-data` o `--dry-run` según necesidad.

Crear runbooks internos de soporte para resolver incidencias frecuentes de OpenCode.

Medir uso con `opencode stats` por días, herramientas, modelos y proyectos.

Relacionar consumo de tokens y coste con tareas completadas, PRs, bugs, documentación y tiempo ahorrado.

Comparar modelos por calidad, coste, latencia y tasa de intervención humana.

Medir impacto en lead time, tiempo de revisión, cobertura, defectos, documentación y onboarding.

Detectar mal uso cuando el coste sube sin mejora de calidad o cuando las sesiones generan demasiado retrabajo.

Crear dashboards internos a partir de exports, stats o integraciones SDK.

Evaluar adopción por equipo, tipo de repo, stack, agente y comando utilizado.

Usar métricas para ajustar permisos, modelos, commands, rules y formación.

Evitar métricas superficiales como “número de prompts” sin relación con outcomes técnicos.

Presentar a dirección una evaluación equilibrada de productividad, coste, calidad y riesgo.

Crear un owner de plataforma OpenCode responsable de configuración, seguridad, soporte y evolución.

Definir estándares globales: proveedores permitidos, share disabled/manual, permisos base, plugins aprobados y reglas mínimas.

Crear plantillas de `.opencode` por tipo de repositorio y stack tecnológico.

Establecer revisión de cambios en agents, commands, skills, MCP y custom tools como código crítico.

Formar a equipos en prompts efectivos, revisión de cambios, seguridad, testing y uso de Plan antes de Build.

Crear pilotos por equipos con repositorios controlados, objetivos medibles y feedback semanal.

Definir niveles de madurez: uso individual, reglas de proyecto, agentes especializados, CI integration y plataforma enterprise.

Crear un proceso de alta de nuevos repositorios con checklist de seguridad, comandos y reglas.

Mantener documentación interna con ejemplos, errores frecuentes, buenas prácticas y FAQs.

Escalar OpenCode sin perder control, privacidad ni calidad de ingeniería.

Seleccionar un repositorio realista de laboratorio con frontend, backend, tests, documentación, CI y deuda técnica controlada.

Instalar OpenCode por método aprobado, validar versión, terminal, proveedor, modelo, credenciales y configuración inicial.

Crear estructura `.opencode` con config de proyecto, rules, agents, commands, skills, references y permisos adaptados.

Generar o mejorar `AGENTS.md` con `/init`, revisando comandos de build, lint, test, arquitectura y gotchas.

Configurar modelos, variantes, OpenCode Zen o proveedor corporativo con política de uso y coste.

Crear agentes personalizados para planning, code review, testing, security y documentación, con permisos diferenciados.

Crear commands para test, review, docs, refactor, PR summary, release notes y troubleshooting.

Configurar MCP local o remoto de laboratorio y aplicar permisos granulares a sus herramientas.

Configurar LSP y formatters cuando el stack lo justifique, documentando beneficios y límites.

Implementar una feature pequeña con Plan y Build, aplicando cambios, tests y documentación.

Refactorizar un módulo con estrategia incremental, subagente de exploración y verificación focalizada.

Generar tests de regresión y revisar que el agente no modifica tests para ocultar errores.

Configurar GitHub o GitLab workflow para invocar OpenCode desde issues, PRs o merge requests.

Usar CLI `run`, sesiones, export/import, stats y servidor headless para automatizar una tarea técnica.

Revisar seguridad: `.env`, permisos, bash, share, MCP, plugins, proveedores, policies y external directories.

Preparar documentación enterprise con instalación, configuración, agentes, workflows, runbooks, métricas y modelo de gobierno.

Presentar la solución final defendiendo arquitectura, productividad, seguridad, extensibilidad, coste, calidad y adopción por equipos.