opencodefrontendbackenddevopsworkflows

Workflows Especializados: OpenCode para Frontend, Backend y DevOps

By Binary Core

Los prompts efectivos varían según el dominio. Lo que funciona para un componente React no funciona para un script de Python o una configuración de Docker. Este artículo presenta workflows especializados para frontend, backend y DevOps, con patrones de prompts probados.

Este tutorial asume que dominas el flujo Plan/Build y la configuración avanzada. Aquí nos enfocamos en workflows por dominio.

Workflows para Frontend (React/Next.js)

Creación de componentes

[Plan Mode]

Crea un componente Button siguiendo el diseño system del proyecto:

Requisitos:
- Variantes: primary, secondary, ghost
- Tamaños: sm, md, lg
- Estados: default, hover, active, disabled, loading
- Accesibilidad: focus visible, aria-label, keyboard navigation
- TypeScript: props tipadas correctamente

Referencia:
- Usa el mismo patrón que @src/components/Card.tsx
- Estilos en @src/styles/components.css
- Iconos de lucide-react

El componente debe ser server-compatible (Next.js 15).

Optimización de renderizado

[Plan Mode]

Optimiza @src/components/ProductList.tsx para renderizar
10,000 items sin lag:

Analiza:
1. ¿Hay re-renders innecesarios?
2. ¿Se puede usar React.memo?
3. ¿Se puede virtualizar la lista?
4. ¿Hay cálculos en render que pueden memoizarse?
5. ¿Se puede usar lazy loading?

Sugiere implementación con react-window o react-virtual.

State management

[Plan Mode]

Este componente @src/components/Cart.tsx tiene estado complejo.

Evalúa si debería:
1. Mantener useState local
2. Usar Context API
3. Migrar a Zustand
4. Usar Redux Toolkit

Considera:
- Cuántos componentes consumen el estado
- Qué tan complejas son las actualizaciones
- Si hay persistencia needed
- Si hay middleware necesario

Recomienda la mejor opción e implementa.

Server Components vs Client Components

[Plan Mode]

Revisa @src/app/dashboard/page.tsx y determina:

1. Qué partes pueden ser Server Components
2. Qué partes necesitan "use client"
3. Qué puede moverse a edge functions
4. Qué puede hacerse streaming

Optimiza para:
- Minimizar JavaScript enviado al cliente
- Maximizar server-side rendering
- Reducir time to interactive

Sigue convenciones de Next.js 15 App Router.

Workflows para Backend (Node.js/TypeScript)

Creación de APIs REST

[Plan Mode]

Crea endpoint REST para CRUD de productos:

Especificación:
- GET /api/products - listado con paginación
- GET /api/products/:id - detalle
- POST /api/products - crear
- PUT /api/products/:id - actualizar
- DELETE /api/products/:id - eliminar

Requisitos:
- Validación con Zod
- Manejo de errores consistente
- Status codes correctos (200, 201, 400, 404, 500)
- TypeScript estricto
- Tests de integración

Sigue el patrón de @src/api/users.ts.

Middleware y autenticación

[Plan Mode]

Crea middleware de autenticación JWT para Express:

Funcionalidad:
- Verificar token en header Authorization
- Extraer user del token
- Adjuntar user a req object
- Manejar tokens expirados
- Manejar tokens inválidos

Seguridad:
- No exponer errores detallados
- Rate limiting en auth endpoints
- Protección contra timing attacks

Integra con @src/middleware/ existente.

Database queries

[Plan Mode]

Optimiza esta query en @src/repositories/OrderRepository.ts:

```typescript
async function getUserOrders(userId: string) {
  return await db.order.findMany({
    where: { userId },
    include: { items: true, user: true }
  });
}

Problemas:

  • N+1 queries
  • Datos innecesarios en include
  • Sin paginación
  • Sin índices

Optimiza para:

  • Usar select específico
  • Añadir paginación
  • Usar índices apropiados
  • Considerar cursor-based pagination

### Background jobs

[Plan Mode]

Implementa procesamiento de emails en background:

Requisitos:

  • Cola con Bull o RabbitMQ
  • Reintentos con backoff
  • Dead letter queue
  • Monitoreo de jobs fallidos
  • Workers escalables

Escenarios:

  • Welcome email al registrar
  • Recuperación de contraseña
  • Notificación de orden
  • Email marketing

Sigue patrones de @src/jobs/ existente.


## Workflows para Backend (Python/FastAPI)

### Endpoints FastAPI

[Plan Mode]

Crea endpoint FastAPI para análisis de datos:

python
@app.post("/api/analyze")
async def analyze_data(data: AnalysisRequest):
    # Implementación

Requisitos:

  • Pydantic models para request/response
  • Validación automática
  • Documentación OpenAPI
  • Async/await para I/O
  • Error handling con HTTPException

Sigue el patrón de @app/api/analysis.py.


### Data processing

[Plan Mode]

Optimiza este script de procesamiento de datos:

python
def process_large_file(filepath):
    with open(filepath) as f:
        for line in f:
            data = json.loads(line)
            processed = transform(data)
            save(processed)

Problemas:

  • Síncrono, lento para archivos grandes
  • Sin paralelización
  • Sin batching
  • Sin manejo de errores

Optimiza con:

  • asyncio/aiofiles
  • Multiprocessing
  • Batching
  • Progress bars

## Workflows para DevOps

### Dockerfiles

[Plan Mode]

Optimiza este Dockerfile para Node.js:

dockerfile
FROM node:18
WORKDIR /app
COPY . .
RUN npm install
RUN npm run build
CMD ["npm", "start"]

Problemas:

  • Imagen grande (copia node_modules)
  • Sin multi-stage build
  • Sin cache de dependencias
  • Sin non-root user

Optimiza para:

  • Multi-stage build
  • Cache de dependencias
  • Imagen final pequeña
  • Security best practices

### Docker Compose

[Plan Mode]

Crea docker-compose.yml para desarrollo local:

Servicios:

  • app (Next.js)
  • api (Node.js/Express)
  • db (PostgreSQL)
  • redis (caching)
  • mailhog (email testing)

Requisitos:

  • Volúmenes para hot reload
  • Networks para comunicación
  • Environment variables
  • Health checks
  • Dependencias entre servicios

### CI/CD pipelines

[Plan Mode]

Genera workflow de GitHub Actions para despliegue:

Stages:

  1. Lint y typecheck
  2. Tests unitarios
  3. Tests E2E con Playwright
  4. Build de producción
  5. Despliegue a Vercel

Requisitos:

  • Cache de dependencias
  • Paralelización de jobs
  • Matriz de Node.js versions
  • Secrets management
  • Rollback automático

### Terraform/Infrastructure as Code

[Plan Mode]

Genera módulo de Terraform para infraestructura AWS:

Recursos:

  • VPC con subnets públicas y privadas
  • RDS PostgreSQL
  • ECS cluster para containers
  • ALB para load balancing
  • S3 para assets estáticos

Best practices:

  • Remote state
  • Outputs para otros módulos
  • Variables sensibles en variables
  • Tags para cost tracking
  • IAM roles least privilege

## Workflows para Scripts y Utilidades

### Scripts de migración

[Plan Mode]

Crea script de migración de datos:

Escenario:

  • Migrar usuarios de legacy DB a PostgreSQL
  • Transformar datos (normalizar emails, fechas)
  • Validar antes de insertar
  • Log de progreso
  • Rollback capability

Requisitos:

  • TypeScript con type safety
  • Transacciones de BD
  • Batch processing
  • Error handling robusto
  • Reporte final

Script: @scripts/migrate-users.ts


### Scripts de mantenimiento

[Plan Mode]

Crea script de mantenimiento de base de datos:

Tareas:

  • Limpiar registros antiguos (>90 días)
  • Reindexar tablas
  • Actualizar estadísticas
  • Verificar integridad
  • Generar reporte

Requisitos:

  • Configurable via flags
  • Dry-run mode
  • Logging detallado
  • Safe defaults
  • Confirmación para operaciones destructivas

## Workflows por Framework

### Next.js específico

[Plan Mode]

Implementa ISR (Incremental Static Regeneration) para página de productos:

Requisitos:

  • Revalidate cada 5 minutos
  • Fallback a loading state
  • Error boundaries
  • Cache headers apropiados
  • Tags para revalidación on-demand

Archivo: @src/app/products/page.tsx


### Express específico

[Plan Mode]

Añade rate limiting a Express app:

Requisitos:

  • express-rate-limit
  • Límites diferentes por endpoint
  • Redis store para distribuido
  • Whitelist de IPs confiables
  • Headers de rate limit en response

Integra con @src/app.ts existente.


### Prisma específico

[Plan Mode]

Optimiza schema de Prisma:

Analiza @prisma/schema.prisma:

  1. ¿Hay índices faltantes?
  2. ¿Hay relaciones sin onDelete?
  3. ¿Hay campos redundantes?
  4. ¿Hay tipos ineficientes?

Sugiere optimizaciones para:

  • Performance de queries
  • Tamaño de BD
  • Integridad de datos
  • Migraciones limpias

## Patrones de Prompts por Dominio

### Frontend pattern

[Frontend Context] Stack: React, Next.js 15, TypeScript, Tailwind, shadcn/ui Component: [nombre] Props: [lista] Estado: [local/context/global]

[Requirements]

  • [requisito 1]
  • [requisito 2]

[References]

  • Similar a: @ruta/componente
  • Estilos: @ruta/styles
  • Iconos: librería específica

[Constraints]

  • Server-compatible: yes/no
  • Accessibility: WCAG AA
  • Performance: memoization needed

### Backend pattern

[Backend Context] Stack: Node.js, Express, TypeScript, Prisma, PostgreSQL Endpoint: [método] [ruta] Purpose: [descripción]

[Requirements]

  • Validación: Zod/Joi
  • Auth: JWT/session
  • Rate limiting: yes/no
  • Caching: Redis/none

[Database]

  • Model: Prisma schema
  • Query: select/include/where
  • Indexes: needed

[Error Handling]

  • 400: validation
  • 401: auth
  • 404: not found
  • 500: server error

### DevOps pattern

[DevOps Context] Tool: [Docker/Terraform/K8s] Environment: [dev/staging/prod] Purpose: [descripción]

[Requirements]

  • Security: non-root, secrets
  • Performance: caching, compression
  • Scalability: horizontal/vertical
  • Monitoring: logs, metrics
  • Cost: optimization

[Constraints]

  • Cloud provider: AWS/GCP/Azure
  • Budget limits
  • Compliance requirements

## Errores Comunes por Dominio

| Dominio | Error Común | Solución |
|--------|-------------|----------|
| Frontend | Re-renders innecesarios | Usa React.memo, useMemo, useCallback |
| Frontend | "use client" excesivo | Mueve lógica a Server Components |
| Backend | N+1 queries | Usa include/select, eager loading |
| Backend | Sync blocking I/O | Usa async/await, worker threads |
| DevOps | Imágenes Docker grandes | Multi-stage builds, alpine |
| DevOps | Secrets en código | Environment variables, secret managers |

## Conclusión

Los workflows especializados requieren:
1. **Contexto de dominio**: Stack específico en AGENTS.md
2. **Patrones de prompts**: Reutilizables por tipo de tarea
3. **Referencias existentes**: Código similar en el proyecto
4. **Conocimiento de best practices**: Framework-specific
5. **Iteración**: Ajustar prompts según resultados

En Binary Core, mantenemos una librería de prompts por dominio en `.opencode/prompts/`. Cada nuevo proyecto hereda estos patrones y el equipo es productivo desde el día uno, sin reinventar prompts para cada tarea.

¿Listo para integrar con tu flujo de versiones? Aprende [workflows de Git con OpenCode](/blog/2026/06/opencode-git-workflows).

---

**Serie completa:**
1. [Instalación y primeros pasos](/blog/2026/06/opencode-instalacion-primeros-pasos)
2. [Flujo de trabajo Plan/Build](/blog/2026/06/opencode-flujo-plan-build)
3. [Configuración avanzada](/blog/2026/06/opencode-configuracion-avanzada)
4. [Debugging](/blog/2026/06/opencode-debugging)
5. [Refactors](/blog/2026/06/opencode-refactors)
6. [Generación de tests](/blog/2026/06/opencode-generacion-tests)
7. [Code review](/blog/2026/06/opencode-code-review)
8. Workflows especializados (este artículo)

Binary Core

Equipo Binary Core

← Back to blog