Saltar al contenido principal

Cómo uso opencode en mi flujo diario

Trabajo con opencode como si fuera un sistema operativo de agentes. No es solo una capa de automatización; es una forma estructurada de pensar el trabajo técnico. Todo está organizado para que la IA actúe con precisión y sin improvisar: roles claros, conocimiento cargado bajo demanda y comandos que encapsulan procesos completos.

A continuación cuento, de forma directa y práctica, cómo lo uso en mi día a día.

1. Empiezo por el agente correcto​

Mi regla base es simple: no entro a trabajar sin elegir bien el agente de entrada. En Floutic hay cuatro agentes principales y cada uno tiene una responsabilidad distinta.

  • OpenAgent (openagent) es el punto de entrada universal. Si tengo una tarea de producto, un bug o una duda general, empiezo aquí. Analiza el pedido, carga el contexto correcto y decide si delega a especialistas.
  • OpenCoder (opencoder) es mi ingeniero lead. Lo uso cuando necesito implementación directa o una refactorización compleja.
  • OpenRepoManager (repo-manager) lo reservo para el mantenimiento de la infraestructura de IA: skills, contexto, limpieza, validaciones.
  • OpenSystemBuilder (system-builder) solo aparece cuando creo un sistema nuevo desde cero.

Esta separación me evita mezclar responsabilidades y mantiene el flujo limpio.

2. La clave está en el contexto (y en cargarlo tarde)​

No intento cargar todo el conocimiento al inicio. En lugar de eso uso lazy loading: cargo solo lo mínimo necesario para la tarea actual. El sistema de contexto está diseñado para eso.

¿Cómo funciona en la práctica?

  1. Empiezo leyendo un navigation.md para entender la estructura.
  2. Identifico el archivo exacto que necesito (por ejemplo, un estándar o una guía).
  3. Cargo ese archivo y ejecuto.

Esto mantiene las respuestas precisas y evita el ruido innecesario.

3. Las skills son reglas, no sugerencias​

Cuando una tarea requiere precisión (migraciones, Docker, FastAPI, Zod, Tailwind), el sistema obliga a leer primero la skill correspondiente. Eso evita que un agente improvise y mantiene consistencia en todo el repositorio.

Ejemplos típicos:

  • docker-floutic para comandos de infraestructura.
  • fastapi-floutic para endpoints.
  • zod-3-floutic para validación de formularios.
  • git-flow-floutic para commits.

Las skills son como recetas obligatorias antes de cocinar.

4. Mis comandos favoritos​

Además de agentes y skills, opencode ofrece comandos que encapsulan flujos completos. Esto es clave para mantener disciplina operativa.

  • /plan: planificación estructurada antes de implementar.
  • /tdd: flujo Test-Driven Development Red→Green→Refactor.
  • /build-fix: diagnóstico y resolución de errores de build.
  • /review: code review sistemático con checklists.
  • /commit: genera commits con formato Floutic y aplica convenciones de scope y emojis.
  • /test: ejecuta el pipeline completo de tests.
  • /context: gestiona el sistema de contexto (harvest, extract, organize, update, error).
  • /clean: limpia formato, imports y linting.
  • /optimize: revisa performance, seguridad y posibles fallos.

Estos comandos me ahorran pasos y estandarizan el resultado.

5. Delegar bien es parte del diseño​

OpenAgent no intenta hacerlo todo. Cuando detecta que la tarea requiere especialización, delega a subagentes específicos (frontend, backend, devops, tester, technical writer). Esto mantiene la interfaz limpia, pero la ejecución especializada.

Yo solo pido la tarea y confío en la delegación automática.

6. Resultados que busco con este enfoque​

Este flujo no es solo comodidad, es control:

  • Menos errores por falta de contexto.
  • Menos pasos manuales repetitivos.
  • Decisiones consistentes entre equipos.
  • Documentación viva y mantenible.

Al final, opencode se vuelve una extensión natural de mi forma de trabajar: más estructura, menos fricción.

7. Resumen rápido​

Si lo tuviera que resumir en una sola línea sería:

“Usar opencode es usar agentes con roles claros, skills obligatorias y contexto cargado justo a tiempo.”

Si quieres adaptar este flujo a tu equipo, lo primero es definir:

  1. Qué agentes serán tus puntos de entrada.
  2. Qué skills son obligatorias por tipo de tarea.
  3. Qué comandos representan procesos críticos.