Inicio/Agents
AGENTS

Agentes especializados

8 AGENTES · 3 CAPAS

Cada agente tiene un rol específico en el workflow. Saben qué leer, qué generar y cuáles son sus límites.

Product Discovery Agent

Business

Facilitar la sesión de discovery para extraer el contexto de negocio, usuarios y criterios de éxito de un requerimiento.

Requiere

  • Descripción informal del problema
  • Acceso al PO o stakeholder
  • Contexto del producto actual

Lee

  • contexto del producto
  • historias previas relacionadas
  • feedback de usuarios

Genera

  • contexto_negocio.md
  • primera versión de historia_usuario.md

Límites

  • No toma decisiones de arquitectura
  • No define la solución técnica
  • Solo trabaja con lenguaje de negocio
El contexto es comprensible sin explicación adicionalLos criterios de éxito son mediblesHay al menos un actor principal definido

OpenSpec Agent

Spec

Transformar los documentos del Business Layer en el OpenSpec completo: proposal.md, design.md y tasks.md.

Requiere

  • contexto_negocio.md
  • historia_usuario.md
  • criterios_aceptacion.md

Lee

  • Business Layer docs
  • histórico de decisiones técnicas
  • patrones de arquitectura del proyecto

Genera

  • proposal.md
  • design.md
  • tasks.md
  • specs/feature-spec.md

Límites

  • No implementa código
  • No aprueba el design sin revisión humana
  • No crea tareas sin un design aprobado
proposal.md cubre motivación + alternativas + decisióndesign.md tiene arquitectura + modelo + contratostasks.md tiene tareas atómicas con criterios de done

Architecture Agent

Spec

Diseñar la arquitectura técnica del cambio: componentes, relaciones, modelo de datos y contratos API.

Requiere

  • proposal.md
  • contexto de la arquitectura actual del proyecto

Lee

  • proposal.md
  • arquitectura base del sistema
  • ADRs previos
  • patrones usados en el proyecto

Genera

  • arquitectura.md
  • modelo_datos.md
  • contrato_api.md
  • sección architecture en design.md

Límites

  • No implementa código
  • No decide por el equipo en casos con trade-offs significativos
  • No define reglas de negocio
La arquitectura es consistente con el sistema existenteTodos los endpoints tienen request/response definidosEl modelo de datos tiene tipos y relaciones claras

Backend Agent

Execution

Implementar las tareas del backend: APIs, lógica de negocio, acceso a datos y migraciones.

Requiere

  • tasks.md
  • design.md
  • contrato_api.md
  • modelo_datos.md

Lee

  • tasks.md (tarea específica)
  • design.md
  • código existente relacionado
  • patrones del proyecto

Genera

  • código de endpoints
  • migraciones de base de datos
  • tests unitarios
  • tests de integración

Límites

  • Solo implementa la tarea asignada
  • No cambia el modelo de datos sin aprobación
  • No modifica contratos API existentes sin revisión
Los endpoints respetan el contrato definidoHay tests para los happy paths y casos de errorEl código pasa el linter del proyecto

Frontend Agent

Execution

Implementar las tareas de frontend: componentes, vistas, integración con APIs y estados.

Requiere

  • tasks.md
  • design.md
  • contrato_api.md
  • diseño o mockup si existe

Lee

  • tasks.md (tarea específica)
  • componentes existentes
  • design system del proyecto
  • contrato_api.md

Genera

  • componentes React/Vue/etc
  • páginas/rutas
  • tests de componente
  • actualizaciones de estado

Límites

  • No modifica APIs backend
  • No cambia el contrato con el servidor
  • No crea componentes sin base en el design system
Los componentes son responsivosHay tests de renderizado para los estados principalesEl código pasa el linter del proyecto

QA Agent

Quality

Generar y ejecutar el plan de pruebas: unitarias, integración, E2E y regresión.

Requiere

  • criterios_aceptacion.md
  • tasks.md completadas
  • contrato_api.md

Lee

  • criterios_aceptacion.md
  • specs/feature-spec.md
  • código implementado
  • historial de bugs del módulo

Genera

  • plan_pruebas.md
  • casos de prueba
  • reporte_pruebas.md
  • bugs encontrados

Límites

  • No aprueba el feature si hay criterios de aceptación sin cubrir
  • No genera tests para código sin especificación
Todos los criterios de aceptación tienen al menos un caso de pruebaLos edge cases están cubiertosEl reporte incluye evidencia de ejecución

Code Review Agent

Quality

Revisar el código del PR contra las especificaciones, estándares y buenas prácticas del proyecto.

Requiere

  • PR diff
  • design.md o tasks.md
  • estándares del proyecto

Lee

  • PR diff completo
  • design.md
  • contrato_api.md
  • reglas de arquitectura del proyecto

Genera

  • checklist_pr.md completado
  • comentarios de revisión
  • lista de blocking issues

Límites

  • No aprueba PRs con blocking issues abiertos
  • No revisa sin especificación de referencia
  • No toma decisiones de producto
Cada comentario referencia la especificación o estándar violadoLos blocking issues están claramente marcadosEl checklist_pr.md está completamente diligenciado

Release Agent

Delivery

Coordinar el proceso de release: release notes, changelog, tag de versión y validación post-deploy.

Requiere

  • PR aprobado
  • checklist_pr.md completo
  • tasks.md completadas

Lee

  • proposal.md
  • tasks.md
  • CHANGELOG existente
  • checklist_pr.md

Genera

  • release_notes.md
  • entrada en CHANGELOG
  • tag de versión
  • checklist de validación post-deploy

Límites

  • No hace deploy sin todos los quality gates aprobados
  • No genera release notes sin proposal.md de referencia
Las release notes son comprensibles por stakeholders no técnicosEl CHANGELOG sigue el formato del proyectoLa validación post-deploy cubre los flujos críticos