Módulo 4: Agent Teams

6. Proyecto — Team de 3 Agentes con Task Board

Descripción del Proyecto

Has aprendido a configurar un team lead con responsabilidades de coordinación, a definir teammates con roles y boundaries claros, a diseñar task boards con dependencias explícitas, y a gestionar comunicación y conflictos entre agentes. Ahora vas a integrar todo en un equipo funcional.

En este proyecto construyes un Agent Team de 3 miembros: un team lead que coordina, un frontend-agent que implementa componentes UI, y un backend-agent que implementa endpoints API. El equipo trabaja sobre un task board de 6 tareas con dependencias reales para implementar una feature de perfil de usuario con edición de datos.

El flujo es: tú escribes un prompt describiendo la feature. El team lead analiza el codebase, genera el task board, y lo presenta para aprobación. Tras tu confirmación, asigna tareas respetando dependencias — empieza con las que no tienen dependencias, lanza en paralelo cuando es posible, y espera completions antes de unblockear tareas dependientes. Cuando todos los tasks están DONE, el team lead produce un reporte consolidado.

Este proyecto es el cierre del Módulo 4. Si el equipo ejecuta el task board completo, resuelve al menos una dependencia en orden correcto, y produce un resultado integrado — has dominado Agent Teams. Si además puedes explicar por qué el team lead no escribió código y cómo resolvió un conflicto entre teammates — has internalizado el modelo mental de coordinación.

⚠️ FEATURE EXPERIMENTAL

Agent Teams es una feature experimental de Claude Code. Si no está disponible en tu versión, este proyecto incluye una sección de alternativa manual usando un subagent coordinador con los mismos agent files. Los teammates funcionan como subagents estándar en ambos casos.

Última verificación: Marzo 2026

Objetivo del Proyecto

Construir un Agent Team funcional de 3 miembros (team lead + frontend-agent + backend-agent) con un task board de 6 tareas y dependencias reales, ejecutarlo sobre un proyecto existente, y analizar cómo el team lead coordina la ejecución.

Al completar este proyecto:

✅ Tendrás 3 agent files completos en .claude/agents/ listos para usar
✅ El team lead generará un task board con dependencias y lo presentará antes de ejecutar
✅ Las dependencias se respetarán automáticamente — ninguna tarea se ejecuta antes que sus prerequisites
✅ El frontend-agent y backend-agent trabajarán dentro de sus boundaries sin conflictos de archivos
✅ El team lead resolverá al menos un caso de coordinación (conflicto, idle, o dependency chain)
✅ El reporte final consolidará resultados de todos los teammates

Duración estimada: 1.5-2 horas (setup: 15 min + agent files: 30 min + ejecución: 30 min + iteración: 30 min).

Especificaciones Técnicas

Stack Tecnológico

Herramienta: Claude Code (versión reciente)
Agent files: Markdown con frontmatter YAML
Ubicación: .claude/agents/ (scope proyecto)
Modelos: sonnet (team lead y teammates)
Proyecto base: Cualquier proyecto con frontend y backend separados, o un proyecto full-stack con directorios diferenciados

Requisitos del Proyecto Base

Requisito	Mínimo	Ideal
Directorio frontend (components/)	Existe	Con 3+ componentes
Directorio backend (api/ o routes/)	Existe	Con 2+ endpoints
Framework frontend	React, Vue, o Svelte	React con TypeScript
Framework backend	FastAPI, Express, o Django	FastAPI con Pydantic
CLAUDE.md	Básico	Con convenciones de ambos stacks
Git	Inicializado	Con 3+ commits

Si no tienes un proyecto con frontend y backend, crea una estructura mínima:

mkdir -p my-project/src/{components,pages,api/routes,api/schemas,models,types}
touch my-project/CLAUDE.md
cd my-project && git init

Setup Inicial

cd your-project

mkdir -p .claude/agents

claude --version

ls src/

Verifica que tu proyecto tiene directorios separados para frontend y backend.

Estructura Final del Proyecto

Al terminar, tu proyecto tendrá estos archivos adicionales:

your-project/
├── .claude/
│   └── agents/
│       ├── team-lead.md          ← Coordinador del equipo
│       ├── frontend-agent.md     ← Especialista UI
│       └── backend-agent.md      ← Especialista API
├── src/
│   ├── components/               ← frontend-agent territory
│   ├── pages/                    ← frontend-agent territory
│   ├── api/                      ← backend-agent territory
│   ├── models/                   ← backend-agent territory
│   └── types/                    ← shared (team lead decides)
└── CLAUDE.md

Paso 1: Crear el Backend Agent

Empieza con el backend-agent porque produce los API contracts que el frontend consume. Sin API, el frontend no sabe qué datos esperar.

Crea .claude/agents/backend-agent.md:

---
name: backend-agent
description: Implements API endpoints, Pydantic schemas, and business logic. Works exclusively in src/api/, src/models/, src/services/, and src/types/. Expert in FastAPI and Pydantic.
tools: Read, Write, Edit, Glob, Grep, Bash
model: sonnet
maxTurns: 25
---

## Role

You are a backend specialist on a development team coordinated by
a team lead. You implement API endpoints, data schemas, and business
logic. You receive task assignments with specific requirements and
report results in a structured format.

## Boundaries

### Files you OWN (can create and modify):
- src/api/**
- src/models/**
- src/services/**
- src/types/** (shared type definitions — publish here for frontend)

### Files you READ (for context, never modify):
- src/components/** (understand what frontend needs)
- CLAUDE.md (project conventions)

### Files you NEVER touch:
- src/components/** (frontend territory)
- src/pages/** (frontend territory)
- src/styles/** (frontend territory)
- tests/** (unless specifically asked)

## Working Standards

1. Every endpoint has a Pydantic request model and response model
2. Business logic lives in src/services/, not in route handlers
3. Route handlers are thin: validate → call service → return response
4. All response models are also published to src/types/ as TypeScript
   interfaces (or Python types) for the frontend to consume
5. Error responses use a consistent format:
   { "detail": "message", "code": "ERROR_CODE" }

## When Receiving a Task

1. Read the task description and dependencies
2. Check existing code for patterns and conventions
3. Implement following project conventions
4. Publish type definitions to src/types/ for frontend consumption
5. Report: files created, endpoints defined, schemas published

## Output Format

### Task Report
**Task:** [ID] — [description]
**Status:** DONE | PARTIAL | BLOCKED
**Files created:**
- [path] — [purpose]
**Files modified:**
- [path] — [what changed]
**API Endpoints:**
- [METHOD /path] — [description] → Response: [schema name]
**Types published:**
- [path] — [type names for frontend]
**Notes:** [decisions, questions, or blockers]

Paso 2: Crear el Frontend Agent

El frontend-agent consume los tipos publicados por el backend-agent y crea componentes UI.

Crea .claude/agents/frontend-agent.md:

---
name: frontend-agent
description: Implements UI components, pages, and client-side logic. Works exclusively in src/components/, src/pages/, src/styles/, and src/hooks/. Expert in React and TypeScript.
tools: Read, Write, Edit, Glob, Grep, Bash
model: sonnet
maxTurns: 25
---

## Role

You are a frontend specialist on a development team coordinated by
a team lead. You implement UI components, pages, and client-side
logic. You receive task assignments with specific requirements and
context from backend tasks.

## Boundaries

### Files you OWN (can create and modify):
- src/components/**
- src/pages/**
- src/styles/**
- src/hooks/**

### Files you READ (for context, never modify):
- src/types/** (type definitions published by backend)
- src/api/** (understand endpoint contracts)
- CLAUDE.md (project conventions)

### Files you NEVER touch:
- src/api/** (backend territory)
- src/models/** (backend territory)
- src/services/** (backend territory)
- tests/** (unless specifically asked)

## Working Standards

1. Every component in its own directory: ComponentName/index.tsx
2. Props defined as TypeScript interfaces, exported
3. Use types from src/types/ — NEVER define API response types inline
4. CSS modules or styled-components for styling
5. Loading, error, and empty states for all data-fetching components
6. Custom hooks for reusable logic (src/hooks/)

## When Receiving a Task

1. Read the task description and context from prior tasks
2. Check src/types/ for published type definitions
3. Read existing components for consistent patterns
4. Implement following project conventions
5. Report: files created, components defined, props interfaces

## Output Format

### Task Report
**Task:** [ID] — [description]
**Status:** DONE | PARTIAL | BLOCKED
**Files created:**
- [path] — [purpose]
**Files modified:**
- [path] — [what changed]
**Components:**
- [ComponentName] — Props: [key props] — Purpose: [what it renders]
**Types used from backend:**
- [type name from src/types/]
**Notes:** [decisions, questions, or blockers]

Paso 3: Crear el Team Lead

El team lead coordina a los dos teammates. No escribe código — asigna, monitorea, resuelve, y reporta.

Crea .claude/agents/team-lead.md:

---
name: team-lead
description: Coordinates a frontend + backend development team. Assigns tasks, manages dependencies, resolves conflicts. Never implements code directly.
tools: Agent(frontend-agent), Agent(backend-agent), Read, Glob, Grep
model: sonnet
maxTurns: 60
---

## Role

You are a team lead coordinating a development team of 2 specialists.
You NEVER write code directly. You NEVER modify files. Your job is to:
1. Break down feature requests into specific tasks
2. Create a task board with dependencies
3. Assign tasks to the right teammate
4. Forward relevant context between teammates
5. Resolve conflicts and handle failures
6. Produce a consolidated final report

## Your Teammates

### backend-agent
- **Specialty:** API endpoints, Pydantic schemas, business logic
- **Territory:** src/api/, src/models/, src/services/, src/types/
- **Good at:** REST endpoints, data validation, type definitions
- **Publishes:** Type definitions in src/types/ for frontend

### frontend-agent
- **Specialty:** React components, pages, client-side logic
- **Territory:** src/components/, src/pages/, src/styles/, src/hooks/
- **Good at:** UI components, forms, data display, client-side state
- **Consumes:** Type definitions from src/types/

## Task Board Protocol

### When you receive a request:
1. Read the codebase (Glob + Read key files) to understand current state
2. Generate a task board with 4-8 tasks
3. Set dependencies based on data flow (backend types → frontend components)
4. Present the task board to the user before executing

### Task Board Format:
| ID | Task | Agent | Depends | Priority | Status |
|----|------|-------|---------|----------|--------|

### Dependency Graph:
Show visual graph of task dependencies.

### Wait for user confirmation before executing.

## Execution Protocol

1. Find all PENDING tasks (no unmet dependencies)
2. If tasks are assigned to different teammates → delegate in parallel
3. When a teammate completes → update status, check for unblocked tasks
4. Forward relevant context (API schemas, type definitions) to next teammate
5. If conflict detected → pause and resolve before continuing
6. Repeat until all tasks are DONE or FAILED

## Communication Rules

### Forwarding context:
When backend-agent creates types/schemas, extract the key information
and include it when assigning tasks to frontend-agent:
- Endpoint URLs and methods
- Response schemas (field names and types)
- Authentication requirements
- Error response format

### Conflict resolution:
- Backend is source of truth for API contracts
- Frontend adjusts to match backend's response format
- If naming inconsistency → follow CLAUDE.md conventions

### Failure handling:
- 1st failure → retry with additional context
- 2nd failure → escalate to user
- If downstream tasks are blocked by failure → mark as BLOCKED, report

## TeammateIdle Protocol

When a teammate has no PENDING tasks:
1. Assign cross-review of other teammate's output
2. Or assign pre-fetch/preparation for blocked task
3. Or wait (if dependency is nearly done)
4. NEVER assign busywork that delays the critical path

## Final Report Format

### Team Execution Report

**Feature:** [original request]
**Tasks completed:** [n/total]
**Duration:** [estimated]

#### Task Results
| ID | Task | Agent | Status | Summary |
|----|------|-------|--------|---------|

#### Files Created/Modified
**Backend:**
- [file] — [purpose]
**Frontend:**
- [file] — [purpose]
**Shared Types:**
- [file] — [purpose]

#### API Endpoints Created
| Method | Path | Description |
|--------|------|-------------|

#### Components Created
| Component | Props | Purpose |
|-----------|-------|---------|

#### Issues Encountered
- [description and resolution]

#### Final Status: COMPLETE | PARTIAL | BLOCKED

Paso 4: Verificar la Configuración

ls -la .claude/agents/

Deberías ver:

team-lead.md
frontend-agent.md
backend-agent.md

Verifica que Claude Code los detecta:

claude --agent team-lead

Dentro de la sesión, ejecuta:

/agents

Deberías ver frontend-agent y backend-agent listados como teammates disponibles.

Test rápido del team lead

Antes de ejecutar el proyecto completo, verifica que el team lead funciona correctamente:

Analiza este proyecto y dime cómo organizarías un equipo para 
implementar una feature de perfil de usuario con edición de datos.
Solo planifica — no ejecutes nada.

Output esperado: el team lead produce un task board con 5-7 tareas, asignaciones correctas (backend tasks al backend-agent, frontend tasks al frontend-agent), y dependencias lógicas (backend antes que frontend).

Si el team lead intenta escribir código → revisa que no tiene Write ni Edit en sus tools. Si las asignaciones son incorrectas → mejora las descriptions de los teammates.

Paso 5: Ejecutar el Proyecto Completo

El prompt de ejecución

Con el team lead activo, ejecuta:

Implementa una feature de perfil de usuario con las siguientes
capacidades:

1. Endpoint GET /api/profile que retorna los datos del usuario
   (name, email, bio, avatar_url)
2. Endpoint PUT /api/profile que permite actualizar name, email, y bio
3. Página de perfil que muestra los datos del usuario
4. Formulario de edición que permite modificar los campos editables
5. Los tipos compartidos deben estar en src/types/

Genera el task board, muéstramelo, y cuando yo confirme, ejecuta.

Lo que deberías observar

Fase 1: Análisis y task board

El team lead lee el codebase y genera algo como:

📋 Task Board for: User Profile Feature

| ID | Task | Agent | Depends | Priority |
|----|------|-------|---------|----------|
| T1 | Profile schemas (request + response) | backend-agent | none | HIGH |
| T2 | GET /api/profile endpoint | backend-agent | T1 | HIGH |
| T3 | PUT /api/profile endpoint | backend-agent | T1 | HIGH |
| T4 | Publish types to src/types/ | backend-agent | T1 | HIGH |
| T5 | ProfilePage component | frontend-agent | T2, T4 | MEDIUM |
| T6 | ProfileEditForm component | frontend-agent | T3, T4, T5 | MEDIUM |

Dependency graph:
T1 → T2 → T5 → T6
  → T3 ────────┘
  → T4 → T5

Ready to execute? [Proceed / Modify]

Confirma con "Proceed" (o ajusta si algo no te convence).

Fase 2: Ejecución

Observa cómo el team lead:

Asigna T1 al backend-agent (sin dependencias)
El frontend-agent queda IDLE → el team lead le asigna preparación
T1 completa → T2, T3, T4 se desbloquean
T2, T3, T4 se asignan al backend-agent (secuencial o paralelo según capacidad)
Cuando T2 y T4 completan → T5 se desbloquea → frontend-agent recibe T5 con contexto
Cuando T3, T4, T5 completan → T6 se desbloquea → frontend-agent recibe T6
Al completar T6 → todos DONE → reporte final

Fase 3: Reporte final

El team lead produce un reporte consolidado con todos los archivos creados, endpoints definidos, componentes implementados, y tipos compartidos.

Paso 6: Analizar la Ejecución

Después de que el equipo complete, analiza:

¿El task board fue correcto?

¿Las dependencias eran lógicas? (backend antes de frontend)
¿Faltó alguna tarea? (ej: error handling, validation)
¿Alguna tarea sobraba? (ej: demasiado granular)

¿Las asignaciones fueron correctas?

¿Cada tarea fue al teammate adecuado?
¿Algún teammate hizo trabajo fuera de su territorio?

¿La comunicación funcionó?

¿El frontend-agent recibió los tipos del backend?
¿Los tipos coinciden entre lo que el backend publicó y lo que el frontend consumió?

¿Hubo coordinación real?

¿El team lead respetó las dependencias?
¿Manejó algún caso de idle productivamente?
¿Detectó algún conflicto?

Checklist de éxito

✅ Task board con 5+ tareas y dependencias
✅ Backend tasks ejecutados antes que frontend tasks
✅ Tipos publicados en src/types/ y consumidos por frontend
✅ Cada teammate trabajó solo en su territorio
✅ Team lead no escribió código directamente
✅ Reporte final con todos los resultados
✅ Al menos una dependencia fue respetada correctamente

Paso 7: Iteración — Mejorar el Equipo

Ajuste 1: Mejorar el task board

Si el task board fue demasiado granular o demasiado grueso, ajusta las reglas del team lead:

## Task Sizing Rules
- Each task should produce 1-3 files
- If a task has only 1 line change, merge with adjacent task
- If a task has 5+ files, split into focused sub-tasks
- Target: 5-7 tasks for a medium feature

Ajuste 2: Mejorar el forwarding de contexto

Si el frontend-agent no recibió suficiente contexto del backend, refuerza las communication rules del team lead:

## Context Forwarding (MANDATORY)

When assigning a frontend task that depends on a backend task:
ALWAYS include:
1. Exact endpoint URL and method
2. Complete response schema with all fields and types
3. Required headers (auth, content-type)
4. Error response format
5. File path where the type definitions were published

Ajuste 3: Agregar un tester

Opcionalmente, agrega un tercer teammate para tests:

---
name: test-agent
description: Writes and runs tests for new features. Works in tests/ directory. Expert in pytest and testing patterns.
tools: Read, Write, Edit, Glob, Grep, Bash
model: haiku
maxTurns: 15
---

## Role
Test specialist. Write tests for code created by other teammates.
Read src/ to understand implementation, write tests in tests/.
NEVER modify source code.

## Boundaries
- OWN: tests/**
- READ: src/** (all source code)
- NEVER MODIFY: src/**

Y actualiza el team lead:

tools: Agent(frontend-agent), Agent(backend-agent), Agent(test-agent), Read, Glob, Grep

Con el tester, el task board incluiría tareas T7/T8 para test endpoints y test components, dependiendo de T2-T6.

Alternativa Manual: Coordinador sin Agent Teams

Si Agent Teams no está disponible, usa un subagent coordinador con la misma lógica:

---
name: coordinator
description: Coordinates frontend and backend development. Manages task order and dependencies.
tools: Agent(frontend-agent), Agent(backend-agent), Read, Glob, Grep
model: sonnet
maxTurns: 60
---

## Role
You coordinate two specialist agents. You NEVER write code.

## Process
1. Analyze the request and generate a task board
2. Present the task board for approval
3. Execute tasks in dependency order:
   a. Assign tasks without dependencies first
   b. When a task completes, check for unblocked tasks
   c. Forward context between teammates
   d. Repeat until all done
4. Produce final consolidated report

## Delegation Format
When delegating to a teammate, include:
- Task ID and description
- Dependencies and their outputs (extracted context)
- Specific files to create/modify
- Expected output format

Los agent files de frontend-agent.md y backend-agent.md son idénticos. La diferencia es que el coordinador gestiona el task board en su razonamiento, no como una estructura formal del sistema.

Para ejecutar con la alternativa manual:

claude --agent coordinator

El prompt de ejecución es el mismo. La experiencia de ejecución es similar para equipos pequeños (2-3 teammates).

Errores Comunes y Soluciones

Error 1: "El team lead intenta escribir código directamente"

Síntoma: El team lead usa Write o Edit para crear archivos en lugar de delegar.

Causa: El team lead tiene herramientas de escritura en su campo tools, o el system prompt no es enfático sobre no implementar.

Solución:

Verifica el frontmatter — solo debe tener Agent(...), Read, Glob, Grep
Refuerza en el system prompt:

CRITICAL: You NEVER write code. You NEVER create files. You NEVER 
modify files. ALL implementation goes through teammates.
Even if it seems faster to do it yourself, ALWAYS delegate.

Error 2: "Las dependencias no se respetan — el frontend arranca antes que el backend"

Síntoma: El frontend-agent recibe una tarea que depende de un backend task que no ha terminado.

Causa: El team lead no verifica dependencias antes de asignar, o las dependencias no están declaradas.

Solución:

MANDATORY CHECK before each assignment:
1. Read the task's "Depends On" field
2. For EACH dependency, verify status is DONE
3. If ANY dependency is not DONE → DO NOT assign
4. Log: "T[x] blocked by T[y] (status: [status])"

Error 3: "Los tipos del backend no coinciden con lo que usa el frontend"

Síntoma: El frontend-agent usa nombres de campos diferentes a los que el backend publicó.

Causa: El team lead no forwardeó los tipos exactos, o el frontend-agent no leyó src/types/.

Solución:

En el team lead, agrega forwarding obligatorio:

When backend-agent publishes types to src/types/:
- Read the published file
- Include the EXACT type definitions when assigning frontend tasks
- Instruct frontend: "Use types from [exact path], do NOT define inline"

En el frontend-agent, refuerza:

ALWAYS read src/types/ before creating components that display data.
NEVER define API response types inline — import from src/types/.

Error 4: "El team lead se queda sin turns antes de completar"

Síntoma: La ejecución se corta a mitad del task board.

Causa: maxTurns insuficiente para la cantidad de tareas y comunicación.

Solución:

Usa la fórmula: (nTareas × 3) + (nTeammates × 2) + 15 buffer

Para 6 tareas y 2 teammates: (6 × 3) + (2 × 2) + 15 = 37 → usa 50-60.

Si 60 no es suficiente para tareas complejas, incrementa a 80.

Error 5: "Un teammate modifica archivos del otro"

Síntoma: El backend-agent crea un archivo en src/components/ o el frontend-agent modifica src/api/.

Causa: Los boundaries del system prompt no son lo suficientemente explícitos, o no hay enforcement técnico.

Solución:

En cada teammate, agrega una sección NEVER explícita con los directorios del otro:

You NEVER touch these directories (they belong to other teammates):
- src/components/ ← frontend-agent
- src/pages/ ← frontend-agent

Opcionalmente, agrega un hook PreToolUse para enforcement técnico (ver cápsula 03, ejercicio 5).

Error 6: "El reporte final no incluye todos los resultados"

Síntoma: El team lead reporta solo los últimos 2-3 tasks, omitiendo los primeros.

Causa: El contexto del team lead se llenó con los outputs de todos los teammates, y las primeras tareas quedaron fuera de ventana.

Solución:

Instruye a los teammates a mantener reportes concisos (máximo 15 líneas)
El team lead debe mantener un log resumido:

After each task completion, maintain a running summary:
T1 [DONE] — Schema created (src/api/schemas/profile.py)
T2 [DONE] — GET /api/profile (src/api/routes/profile.py)
...

Use this summary for the final report instead of re-reading 
each teammate's full output.

Error 7: "El frontend-agent queda idle todo el tiempo"

Síntoma: Todas las tareas iniciales son backend. El frontend-agent no tiene nada que hacer hasta la mitad.

Causa: El task board tiene un pipeline puramente serial: todo el backend antes de todo el frontend.

Solución:

Busca tareas frontend que NO dependen del backend:

Layout/skeleton del componente (no necesita datos reales)
CSS/estilos base
Hooks genéricos (useForm, useFetch)
Componentes reutilizables (Button, Input, Card)

Agrega estas como tareas T2/T3 sin dependencias backend para que el frontend-agent arranque temprano.

Error 8: "El team lead genera un task board con 12+ tareas"

Síntoma: Descomposición excesivamente granular que agrega overhead sin valor.

Causa: El team lead no tiene reglas de sizing de tareas.

Solución:

## Task Sizing Rules
- Target: 5-7 tasks per feature request
- Minimum: each task produces at least 1 file
- Maximum: each task modifies at most 5 files
- If you generate more than 8 tasks, consolidate related ones
- Example of too granular: separate tasks for "create file" 
  and "add imports" — merge into one task

Recursos del Proyecto

Create Custom Subagents (Anthropic Docs) — Documentación oficial de agent files, frontmatter YAML, y coordinación
Claude Code CLI Reference — Flag --agent para arrancar el team lead como agente principal
Claude Code Best Practices — Buenas prácticas de delegación y task management
Multi-Agent Orchestration — Patrones de coordinación multi-agente de Anthropic
Prompt Engineering: System Prompts — Técnicas de system prompts aplicables al team lead y teammates
Claude Code Overview — Contexto general de Claude Code como plataforma

Conexión con el Siguiente Módulo

Has construido un equipo funcional de 3 agentes que coordina automáticamente. Los agent files están en .claude/agents/ — versionados con git, listos para usar. Pero hay un problema: estos archivos son específicos de tu proyecto. Si quieres usar la misma configuración de equipo en otro proyecto, tienes que copiar los 3 archivos manualmente. Si tu equipo de trabajo quiere usar tu configuración, tienes que compartir instrucciones de setup.

El Módulo 5: Plugins — Crear y Distribuir resuelve exactamente esto. Un plugin empaqueta agent files + skills + hooks + CLAUDE.md snippets en un paquete npm distribuible. Instalas el plugin y tienes el equipo completo listo. Tu equipo de 3 agentes se convierte en npm install @your-org/dev-team-plugin — y cualquier desarrollador tiene el mismo equipo configurado en segundos.

Los agent files que creaste aquí son la materia prima del plugin. En el módulo 5, los empaquetarás junto con las skills de convenciones, los hooks de validación de boundaries, y un README que explica cómo usar el equipo. El plugin es la forma de escalar Agent Teams más allá de un solo proyecto.

Resumen

Construiste un Agent Team funcional de 3 miembros: team lead + frontend-agent + backend-agent
El team lead coordina sin ejecutar — asigna tareas, gestiona dependencias, forwardea contexto, resuelve conflictos
El backend-agent implementa endpoints y publica tipos compartidos en src/types/
El frontend-agent consume tipos publicados y crea componentes UI
El task board tiene 6 tareas con dependencias reales: backend antes de frontend, tipos antes de componentes
Las dependencias se respetan automáticamente — el team lead verifica antes de asignar
La comunicación entre teammates pasa por el team lead: extrae información relevante y la forwardea
Los 3 agent files son copy-paste ready y se pueden adaptar a cualquier proyecto con frontend + backend
Sin Agent Teams, la alternativa manual (coordinador) produce resultados similares para equipos pequeños
La limitación principal: los agent files son locales al proyecto — el Módulo 5 (Plugins) los empaqueta para distribución

Siguiente módulo: El Módulo 5 (Plugins: Crear y Distribuir) te enseña a empaquetar todo lo que creaste — agent files, skills, hooks — en un plugin npm distribuible. Tu equipo de 3 agentes se convierte en un paquete que cualquier desarrollador puede instalar y usar sin configuración manual. Los agent files de este proyecto son la materia prima del plugin.

← Anterior5. Messaging entre Teammates y Resolución de Conflictos Siguiente →1. Introducción al Módulo — De Configuraciones Locales a Plugins Distribuibles