10 tips para sacarle el máximo provecho a OpenCode

1. Inicializa tu proyecto con `/init`

Antes de escribir una sola línea de código, ejecuta /init en la raíz de tu proyecto. OpenCode analizará tu repositorio y generará un archivo de contexto base que el modelo usará en cada sesión. Es el punto de partida que evita que tengas que explicar tu proyecto desde cero en cada conversación.

Este comando creara un archivo AGENTS.md con el contexto del proyecto:

Inicializar proyecto en OpenCode

2. Usa `undo` y `redo` sin miedo

OpenCode rastrea los cambios que hace el modelo en tus archivos. Si algo no te convence, undo revierte la última acción y con redo la restaura. Esto te da libertad para experimentar sin el temor de romper algo permanentemente.

3. Menciona archivos con `@` para ser preciso

Cuando referencias un archivo con @NombreDelArchivo, el modelo sabe exactamente dónde buscar el contexto relevante en lugar de explorar el proyecto entero. Esto reduce el consumo de tokens de forma significativa y hace que las respuestas sean más precisas.

# Ejemplo
Refactoriza la lógica de autenticación en @src/features/auth/hooks/useAuth.ts

Úsalo siempre que puedas. Es uno de los hábitos que más impacto tiene en la calidad de las respuestas.

4. Intercambia modelos según la tarea

No todos los modelos cuestan lo mismo en tokens, y no todas las tareas requieren el modelo más potente. Una regla práctica:

• Modelo rápido/económico: exploración, preguntas simples, refactors menores.
• Modelo potente: arquitectura, lógica compleja, debugging profundo.

Cambiar de modelo en el momento correcto te permite hacer más con el mismo presupuesto de tokens.

5. Domina `plan` y `build`

OpenCode tiene dos modos de operación que trabajan en secuencia:

• plan: el modelo analiza el problema y propone una estrategia antes de tocar el código. Úsalo para tareas complejas o de alto riesgo.
• build: el modelo ejecuta directamente los cambios.

La combinación correcta es usar plan para validar el enfoque y luego build para ejecutar. Saltar directo a build en tareas complejas es probable que genere resultados no muy buenos.

6. Activa el Prompt Improver antes de programar

El Prompt Improver es una funcionalidad que hace preguntas de clarificación antes de ejecutar una tarea. En lugar de asumir lo que quieres, el modelo recopila la información necesaria para actuar con precisión. Te ahorra varios ciclos de corrección.

Puedes usar la skill skills.sh/github/awesome-copilot/boost-prompt para potenciar esta tarea.

Ejemplo de Prompt Improver

7. Crea comandos para tareas repetitivas

Si te encuentras escribiendo el mismo tipo de instrucción una y otra vez, es una señal de que necesitas un comando personalizado. OpenCode permite definirlos para estandarizar tareas frecuentes como:

• Generar tests para un módulo.
• Crear un nuevo feature siguiendo la estructura del proyecto.
• Revisar un archivo en busca de code smells.

Los comandos convierten una instrucción repetitiva en una sola acción.

Para configurarlos, crea una carpeta llamada commands dentro de .opencode y añade un archivo Markdown con el nombre de tu comando (ej. .opencode/commands/NEW-FEATURE.md). Debe seguir esta estructura:

---
description: Descripción del comando
agent: plan o build
---

Contenido de la instrucción

Ejemplo detallado para un servicio:

---
description: A command to create a folder structure for a new feature in a project.
agent: build
---

Create a new service for the entity $1. 
Follow the Hexagonal Architecture pattern:
1. Create the Input Port (Interface) in `domain/ports/in`.
2. Create the Service Implementation in `domain/services`.
3. Use Spring Boot annotations and ensure the code is compatible with Java 17.
4. If $2 is provided, use it as the primary repository interface.

Check the existing folder structure in `src/main/java` before generating.

Para ejecutarlo, escribe / y OpenCode te sugerirá tus comandos personalizados:

8. Aprovecha las skills

Las skills son fragmentos de contexto especializado que el modelo puede cargar bajo demanda. Antes de crear una desde cero, ejecuta find-skills para ver cuáles ya están disponibles. Puede que alguien ya haya construido exactamente lo que necesitas.

Puedes visitar la pagina skills.sh donde existen una gran cantidad de skills listas para usar.

9. Crea tus propias skills

Esta es la funcionalidad que más diferencia hace a largo plazo. Puedes crear skills específicas para tu proyecto en .opencode/skills/ o .agents/skills/ para dar compatibilidad a mas agentes. Cada skill es un archivo Markdown con contexto estructurado que el modelo carga cuando lo necesita.

Estructura básica:

.opencode/skills/
└── structure/
    └── SKILL.md

Una skill bien escrita define el stack, la arquitectura de carpetas y los estándares de código de tu proyecto. Por ejemplo, una skill para un proyecto React con Feature-Sliced Design podría verse así:

---
name: structure
description: Contexto específico del proyecto: stack, arquitectura y convenciones.
---

## Stack
- React (Functional Components, Hooks)
- TypeScript (Strict Mode)
- Tailwind CSS + shadcn/ui
- TanStack Query

## Arquitectura de carpetas

- `src/components/` → Componentes genéricos y reutilizables (agnósticos al dominio).
- `src/features/<feature>/` → Módulos por dominio. Cada uno contiene:
  - `/components`, `/hooks`, `/services`, `/types`, `/store` (opcional).
- `src/services/` → Configuración global de API (Axios, interceptores).
- `src/hooks/` → Hooks reutilizables en toda la app (`useAuth`, `useDebounce`).
- `src/lib/` → Utilidades, helpers y configuraciones de terceros.
- `src/types/` → Interfaces globales compartidas entre features.

## Estándares de código

- **Componentes dumb:** la lógica va en hooks, no en componentes `.tsx`.
- **Data fetching:** los services solo hacen fetch. El estado asíncrono va en hooks con TanStack Query.
- **TypeScript:** prohibido usar `any`. Define interfaces explícitas para props, respuestas de API y payloads.
- **Estilos:** usa `cn()` (clsx + tailwind-merge) para componer clases dinámicas.
- **Nomenclatura:**
  - Componentes: `PascalCase` → `UserProfile.tsx`
  - Hooks/utilidades: `camelCase` → `useUserFetch.ts`
  - Preferir exportaciones nombradas sobre `export default`.

Con una skill como esta, el modelo ya sabe cómo está organizado tu proyecto, cuál es el stack y cuáles son las reglas. No tienes que repetirlo nunca más.

10. Aprovecha las sesiones continuas

OpenCode mantiene el contexto a lo largo de una sesión. Esto significa que puedes construir sobre lo que ya se hizo sin tener que re-explicar el estado del proyecto en cada mensaje. Úsalo a tu favor, en lugar de abrir una sesión nueva por cada tarea, encadena las que tienen relación. El modelo recuerda las decisiones previas y las aplica de forma consistente.

Puedes usar /session para listar las sesiones activas.