3. Teammates — Roles, Especialidades y Límites

Descripción

El team lead coordina. Los teammates ejecutan. Pero "ejecutar" sin definición clara produce los mismos problemas que tenías con subagents genéricos en el módulo 1 — resultados impredecibles, archivos que no debían tocarse, y conflictos entre agentes que trabajan en el mismo espacio. Un teammate bien definido es un subagent especializado que el team lead sabe exactamente cuándo y para qué invocar.

En esta cápsula aprenderás a diseñar teammates con roles y boundaries claros. No se trata solo de crear agent files — se trata de diseñar la estructura del equipo: qué hace cada miembro, qué NO hace, qué directorios posee, qué skills precarga, y cómo su descripción ayuda al team lead a tomar decisiones de asignación. Un equipo con teammates bien definidos funciona con coordinación mínima. Un equipo con teammates vagos requiere micromanagement del team lead — y eso es exactamente lo que queríamos evitar.

Al terminar, tendrás 2-3 teammates configurados con roles complementarios, boundaries explícitos, y descriptions que el team lead puede usar para asignar trabajo automáticamente.

⚠️ FEATURE EXPERIMENTAL

Los teammates funcionan como subagent files estándar (feature estable). Su integración formal con Agent Teams es experimental a marzo 2026. Todo lo que configures aquí funciona también como subagent standalone.

Última verificación: Marzo 2026

Anatomía de un Teammate

Es un subagent file con propósito de equipo

Un teammate es técnicamente idéntico a un subagent: un archivo Markdown con frontmatter YAML y system prompt. La diferencia es de contexto — está diseñado para ser invocado por un team lead, no directamente por el usuario.

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

## Role

You are a frontend specialist on a development team. You receive
task assignments from the team lead. You implement UI components,
pages, and client-side logic.

## Boundaries

You ONLY modify files in:
- src/components/
- src/pages/
- src/styles/
- src/hooks/
- src/utils/client/

You NEVER modify:
- src/api/
- src/models/
- src/services/
- database/
- tests/ (unless specifically asked to fix a frontend test)

## Working Standards
- Follow existing component patterns in the project
- Use TypeScript for all new files
- Every component exports types for its props
- CSS modules for styling, no inline styles
- Report what you created/modified and why

## Output Format

### Task Completion Report
**Task ID:** [assigned ID]
**Status:** DONE | PARTIAL | BLOCKED
**Files modified:** [list]
**Changes:**
1. [file] — [what and why]
**Notes:** [blockers, questions, or dependencies needed]

Campos que importan para el team lead

description — Este campo es clave para Agent Teams. El team lead lee las descriptions de todos los teammates para decidir a quién asignar cada tarea. Una description vaga ("Handles frontend stuff") produce asignaciones vagas. Una description precisa ("Implements UI components, pages, and client-side logic. Works exclusively in frontend directories. Expert in React and CSS.") permite decisiones informadas.

tools — Define las capacidades reales del teammate. Un teammate sin Write no puede crear archivos. Uno sin Bash no puede ejecutar comandos. Las herramientas refuerzan los boundaries del system prompt.

model — Los teammates generalmente pueden usar haiku o sonnet dependiendo de la complejidad de sus tareas. No necesitan opus — eso es responsabilidad del team lead.

Diseñando Roles Complementarios

El principio de cobertura sin overlap

Un buen equipo cubre todo el codebase sin que dos teammates tengan autoridad sobre los mismos archivos:

┌─────────────────────────────────────────────┐
│                  CODEBASE                    │
│                                              │
│  ┌──────────────┐  ┌──────────────────────┐  │
│  │  frontend/   │  │  backend/            │  │
│  │  components/ │  │  api/                │  │
│  │  pages/      │  │  models/             │  │
│  │  styles/     │  │  services/           │  │
│  │              │  │  database/           │  │
│  │  FRONTEND    │  │  BACKEND AGENT       │  │
│  │  AGENT       │  │                      │  │
│  └──────────────┘  └──────────────────────┘  │
│                                              │
│  ┌──────────────────────────────────────────┐│
│  │  tests/    config/    docs/              ││
│  │  SHARED ZONE (team lead decides)         ││
│  └──────────────────────────────────────────┘│
└─────────────────────────────────────────────┘

Regla: Cada archivo del proyecto debe tener como máximo un teammate que puede modificarlo. Si dos teammates pueden editar el mismo archivo, tendrás conflictos. La "shared zone" (tests, config, docs) la gestiona el team lead, asignando según el contexto.

Ejemplo: equipo frontend + backend

frontend-agent:
  POSEE:  src/components/, src/pages/, src/styles/, src/hooks/
  LEE:    src/types/, src/api/contracts/  (para conocer la API)
  NO TOCA: src/api/, src/models/, src/services/, database/

backend-agent:
  POSEE:  src/api/, src/models/, src/services/, database/
  LEE:    src/types/  (para mantener consistencia de tipos)
  NO TOCA: src/components/, src/pages/, src/styles/

tests/ → Asignado por el team lead según contexto:
  - Test de componente → frontend-agent
  - Test de endpoint → backend-agent
  - Test de integración → el que más contexto tenga

Ejemplo: equipo tripartito (API + DB + Test)

api-dev:
  POSEE:  src/routes/, src/schemas/, src/middleware/
  LEE:    src/models/  (para conocer los tipos de datos)
  NO TOCA: src/models/ (solo lee), tests/, migrations/

db-dev:
  POSEE:  src/models/, src/repositories/, alembic/
  LEE:    src/routes/  (para entender cómo se usan los datos)
  NO TOCA: src/routes/ (solo lee), tests/, middleware/

test-runner:
  POSEE:  tests/
  LEE:    src/ completo  (para entender qué testear)
  NO TOCA: src/  (solo lee), alembic/, config/

Boundaries: Más que Directorios

4 tipos de boundaries

1. Boundaries de archivos (directorios):

## Boundaries
You ONLY modify files in:
- src/api/routes/
- src/api/schemas/

You NEVER modify files in:
- src/models/ (read-only for context)
- tests/
- config/

2. Boundaries de operaciones (herramientas):

# Teammate que implementa
tools: Read, Write, Edit, Glob, Grep, Bash

# Teammate que solo testea
tools: Read, Glob, Grep, Bash
disallowedTools: Write, Edit

3. Boundaries de decisiones (system prompt):

## Decision Boundaries

You make decisions about:
- Component structure and props
- CSS styling approach
- Client-side state management

You do NOT make decisions about:
- API endpoint design (ask backend-agent via team lead)
- Data model structure (accept what db-dev defines)
- Authentication flow (accept what the team lead specifies)

4. Boundaries de conocimiento (skills):

skills:
  - react-patterns      # Preloaded domain knowledge
  - css-conventions

Los boundaries de archivos evitan conflictos. Los de operaciones refuerzan restricciones. Los de decisiones evitan scope creep. Los de conocimiento mantienen al teammate enfocado en su dominio.

Boundaries como contrato

Piensa en los boundaries como un contrato entre el teammate y el team lead:

CONTRATO: frontend-agent

PUEDO:
- Crear y modificar componentes React
- Crear archivos CSS module
- Usar hooks existentes o crear nuevos
- Instalar dependencias de UI (con aprobación)

NO PUEDO:
- Crear endpoints de API
- Modificar modelos de datos
- Cambiar configuración de base de datos
- Decidir la estructura de la API

NECESITO DEL EQUIPO:
- Tipos de datos definidos por db-dev
- Contracts de API definidos por api-dev
- Decisiones de UX del team lead

Este contrato hace explícitas las dependencias entre teammates — información que el team lead usa para coordinar.

Skills: Precargar Conocimiento de Dominio

Qué son y cuándo usarlas

Las skills son archivos de conocimiento que se precargan en el contexto del teammate. Un skill file contiene patrones, convenciones, o referencias que el teammate necesita para trabajar consistentemente.

skills:
  - react-component-patterns
  - project-style-guide

Claude busca skills en:

1. .claude/skills/ (proyecto)
2. ~/.claude/skills/ (usuario)
3. Skills de plugins habilitados

Ejemplo: skill de convenciones frontend

Crea .claude/skills/react-component-patterns.md:

# React Component Patterns

## File Structure
Every component in a directory with:
- ComponentName.tsx (implementation)
- ComponentName.module.css (styles)
- index.ts (re-export)

## Props Pattern
Always define props interface:
```typescript
interface ProfileCardProps {
  user: User;
  onEdit?: () => void;
  className?: string;
}

State Pattern

• useState for local state
• useContext for shared state
• No Redux — use React Context + useReducer

Naming

• Components: PascalCase
• Hooks: camelCase starting with "use"
• CSS modules: camelCase for class names

Con esta skill precargada, el frontend-agent sigue estas convenciones sin que el team lead las repita en cada asignación.

### Skills vs system prompt

| Aspecto | System Prompt | Skills |
|---------|--------------|--------|
| Contenido | Rol, proceso, format | Conocimiento de dominio |
| Tamaño | Corto y enfocado | Puede ser extenso |
| Reutilización | Específico del teammate | Compartible entre teammates |
| Cambio | Cambia si cambia el rol | Cambia si cambian las convenciones |

Regla: el system prompt define **qué hace** el teammate. Las skills definen **cómo lo hace** según las convenciones del proyecto.

---

## Memory Scopes por Teammate

### Cuándo configurar memoria

En el módulo 2 aprendiste sobre memory scopes. Para teammates, la memoria es útil cuando:

- El teammate se ejecuta múltiples veces y debe recordar decisiones anteriores
- El equipo tiene convenciones que se descubren durante la ejecución
- Quieres que el teammate acumule conocimiento del proyecto

```yaml
memory: project    # Recuerda entre sesiones para este proyecto
memory: user       # Recuerda globalmente (todos los proyectos)

Ejemplo práctico

---
name: backend-agent
description: Backend specialist for API and data access
memory: project
---

Con memory: project, el backend-agent recuerda:

• Qué endpoints creó en sesiones anteriores
• Qué convenciones de naming descubrió en el proyecto
• Errores que encontró y cómo los resolvió

Sin memoria, cada ejecución es la primera vez — lo cual es aceptable para tareas aisladas pero ineficiente para desarrollo iterativo.

Naming Conventions que Ayudan al Team Lead

Por qué el nombre importa

El team lead usa el name y description de cada teammate para decidir asignaciones. Buenos nombres y descriptions producen buenas asignaciones automáticas.

# ❌ Nombres vagos — el team lead no puede diferenciar
name: agent-1
description: Does development tasks

name: agent-2
description: Also does development tasks

# ✅ Nombres descriptivos — el team lead sabe quién hace qué
name: frontend-agent
description: Implements React components and pages in src/components/ and src/pages/

name: backend-agent
description: Implements FastAPI endpoints and SQLAlchemy models in src/api/ and src/models/

Patrón de naming recomendado

[dominio]-[rol]

Ejemplos:
  frontend-agent     → Dominio: frontend, Rol: implementador general
  backend-agent      → Dominio: backend, Rol: implementador general
  api-dev            → Dominio: API, Rol: developer
  db-dev             → Dominio: database, Rol: developer
  test-runner        → Dominio: testing, Rol: ejecutor
  security-reviewer  → Dominio: seguridad, Rol: reviewer
  docs-writer        → Dominio: documentación, Rol: escritor

La description como spec de asignación

La description no es solo metadata — es la especificación que el team lead usa para decidir. Incluye:

1. Qué hace: "Implements React components"
2. Dónde trabaja: "in src/components/ and src/pages/"
3. En qué es experto: "Expert in React, TypeScript, and CSS modules"
4. Qué NO hace: (en el system prompt, no en la description)

# ❌ Description genérica
description: Frontend development

# ✅ Description como spec
description: Implements React components, pages, and client-side hooks. Works exclusively in src/components/, src/pages/, src/hooks/. Expert in TypeScript, React Server Components, and Tailwind CSS.

Configuración Completa: Frontend Agent

---
name: frontend-agent
description: Implements React components, pages, and client-side logic. Works exclusively in frontend directories (src/components/, src/pages/, src/hooks/, src/styles/). Expert in TypeScript, React, and CSS modules.
tools: Read, Write, Edit, Glob, Grep, Bash
model: sonnet
maxTurns: 25
skills:
  - react-component-patterns
  - project-style-guide
---

## Role

You are a frontend specialist receiving task assignments from a team lead.
You implement UI components, pages, and client-side logic following
project conventions.

## Boundaries

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

### Files you READ (for context, never modify):
- src/types/** (shared type definitions)
- src/api/contracts/** (API response shapes)
- CLAUDE.md (project conventions)

### Files you NEVER touch:
- src/api/** (backend territory)
- src/models/** (database territory)
- src/services/** (backend territory)
- database/** (database territory)
- tests/** (unless fixing a specific frontend test)

## Working Standards

1. Every component in its own directory with .tsx, .module.css, and index.ts
2. Props defined as TypeScript interfaces, exported from the component file
3. No inline styles — use CSS modules
4. Custom hooks for shared logic, prefixed with "use"
5. Error boundaries around async components

## When Receiving a Task

1. Read the task description and dependencies
2. Check if prerequisite outputs exist (API types, contracts)
3. Implement following project conventions
4. Self-review: verify TypeScript compiles, no console.logs left
5. Report completion with files changed and rationale

## Output Format

### Task Report
**Task:** [ID and description]
**Status:** DONE | PARTIAL | BLOCKED
**Files:**
- Created: [list]
- Modified: [list]
**Summary:** [what was done and why]
**Dependencies needed:** [if BLOCKED, what's missing]

Configuración Completa: Backend Agent

---
name: backend-agent
description: Implements API endpoints, business logic, and data access layer. Works exclusively in backend directories (src/api/, src/models/, src/services/). Expert in FastAPI, SQLAlchemy, and Pydantic.
tools: Read, Write, Edit, Glob, Grep, Bash
model: sonnet
maxTurns: 25
skills:
  - fastapi-patterns
  - sqlalchemy-conventions
---

## Role

You are a backend specialist receiving task assignments from a team lead.
You implement API endpoints, business logic, and data access following
project conventions.

## Boundaries

### Files you OWN:
- src/api/routes/**
- src/api/schemas/**
- src/models/**
- src/services/**
- src/utils/server/**

### Files you READ:
- src/types/** (shared type definitions)
- CLAUDE.md (project conventions)
- alembic/ (migration history for context)

### Files you NEVER touch:
- src/components/** (frontend territory)
- src/pages/** (frontend territory)
- src/styles/** (frontend territory)
- tests/** (unless fixing a specific backend test)

## Working Standards

1. Every endpoint has a Pydantic request and response model
2. Business logic in services/, not in route handlers
3. Database access through repository pattern
4. All endpoints have error handling (HTTPException with correct codes)
5. Async functions for all database operations

## API Contract Pattern

When creating a new endpoint, also create the type definition
in src/types/ so the frontend-agent can consume it:

```python
# src/api/schemas/profile.py
class ProfileResponse(BaseModel):
    id: int
    username: str
    email: str
    avatar_url: str | None

This schema becomes the contract between you and frontend-agent.

Output Format

Task Report

Task: [ID and description] Status: DONE | PARTIAL | BLOCKED Files:

• Created: [list]
• Modified: [list] API Endpoints: [if applicable]
• [METHOD /path] — [description] Summary: [what was done and why] Dependencies needed: [if BLOCKED, what's missing]

---

## Teammate vs Teammate: Tabla Comparativa

| Aspecto | frontend-agent | backend-agent |
|---------|---------------|---------------|
| **Directorios propios** | components/, pages/, styles/, hooks/ | api/, models/, services/ |
| **Lee sin modificar** | types/, api/contracts/ | types/, alembic/ |
| **Modelo** | sonnet | sonnet |
| **Skills** | react-patterns, style-guide | fastapi-patterns, sqlalchemy |
| **Tools especiales** | — | Bash (para migrations) |
| **Output clave** | Componentes creados, props | Endpoints creados, schemas |
| **Depende de** | API contracts del backend | Tipos compartidos |
| **Publica para** | — | Types en src/types/ |

La tabla hace visible cómo los teammates se complementan: el backend publica API contracts que el frontend consume. El frontend no necesita saber cómo funciona la API internamente — solo la forma de la respuesta.

---

## Alternativa Manual: Teammates sin Agent Teams

Si Agent Teams no está disponible, los teammates funcionan como subagents estándar invocados por un coordinador:

```markdown
---
name: coordinator
tools: Agent(frontend-agent), Agent(backend-agent), Read, Glob, Grep
model: sonnet
---

## Teammate Management

When delegating to a teammate:
1. Include the task ID and full description
2. Specify which files to work in
3. Provide any outputs from prior tasks as context
4. Request the standard Task Report format

Example delegation:
"Task T3: Implement ProfilePage component in src/components/.
 Use the ProfileResponse type from src/types/profile.ts (created in T1).
 Follow react-component-patterns conventions.
 Report: files created, props defined, and status."

Los agent files de los teammates son idénticos en ambos casos. La diferencia es cómo se coordinan: con Agent Teams el team lead tiene primitivas de coordinación; sin ellos, la lógica está en el system prompt del coordinador.

Troubleshooting

"El team lead asigna tareas al teammate equivocado"

Causa: Las descriptions de los teammates no diferencian claramente sus dominios.

Solución: En la description, incluye:

• Qué directorios posee (no solo "frontend" — lista los paths)
• En qué tecnologías es experto
• Qué tipo de tareas maneja (componentes, endpoints, tests)

"Un teammate modifica archivos de otro teammate"

Causa: Los boundaries no están reforzados por herramientas, solo por system prompt.

Solución: Agrega un hook PreToolUse que valide el path:

#!/bin/bash
# .claude/hooks/validate-frontend-boundaries.sh
if [[ "$AGENT_NAME" == "frontend-agent" ]]; then
  FILE=$(echo "$TOOL_INPUT" | jq -r '.file_path // .path // empty')
  if [[ -n "$FILE" && ! "$FILE" =~ ^src/(components|pages|styles|hooks)/ ]]; then
    echo "BLOCKED: frontend-agent cannot modify $FILE"
    exit 2
  fi
fi

"Los teammates no siguen las convenciones del proyecto"

Causa: No hay skills precargadas o el system prompt no referencia CLAUDE.md.

Solución:

1. Crea skills con las convenciones del proyecto
2. Referencia las skills en el frontmatter del teammate
3. En el system prompt, agrega: "Read CLAUDE.md before starting any task"

"Un teammate reporta BLOCKED pero el team lead no reacciona"

Causa: El team lead no tiene instrucciones sobre qué hacer con el status BLOCKED.

Solución: En el system prompt del team lead, agrega:

When a teammate reports BLOCKED:
1. Read the "Dependencies needed" section
2. Check if another teammate can provide what's needed
3. If yes, assign a task to that teammate first
4. If no, report the blocker to the user

"Los teammates producen outputs en formatos diferentes"

Causa: Cada teammate tiene un output format ligeramente diferente o no lo sigue.

Solución: Estandariza el output format en una skill compartida:

# .claude/skills/task-report-format.md
## Standard Task Report

All teammates MUST use this exact format:

### Task Report
**Task:** [ID] — [description]
**Status:** DONE | PARTIAL | BLOCKED
**Files:** [list of created/modified]
**Summary:** [1-2 sentences]
**Dependencies needed:** [if BLOCKED]

Y referénciala en cada teammate: skills: [task-report-format, ...]

Ejercicios

Ejercicio 1: Teammate mínimo (Fácil)

Crea un teammate docs-writer que genera documentación. Solo puede leer código y escribir archivos en docs/. No puede modificar código fuente ni ejecutar comandos.

---
name: docs-writer
description: Generates documentation from code analysis. Writes to docs/ directory only. Expert in API documentation and README files.
tools: Read, Glob, Grep, Write
disallowedTools: Edit, Bash
model: haiku
maxTurns: 15
---

## Role
Documentation specialist. You read code and produce documentation.
You NEVER modify source code.

## Boundaries
- WRITE to: docs/ directory only
- READ: entire codebase for context
- NEVER modify: src/, tests/, config/

## Output Format
### Task Report
**Task:** [ID]
**Status:** DONE | PARTIAL
**Files created:** [list in docs/]
**Summary:** [what was documented]

Ejercicio 2: Identificar boundaries faltantes (Fácil)

Este teammate tiene problemas de boundaries. Identifica 4 problemas y corrígelos:

---
name: full-stack
description: Does everything
tools: Read, Write, Edit, Bash, Glob, Grep
model: sonnet
---

You are a full-stack developer. Implement whatever is asked.

---
name: fullstack-dev
description: Implements features that span frontend and backend. Works in src/components/, src/api/, and src/services/. Expert in React + FastAPI integration.
tools: Read, Write, Edit, Bash, Glob, Grep
model: sonnet
maxTurns: 30
---

## Role
Full-stack developer. Implements features that require
both frontend and backend changes.

## Boundaries
- MODIFY: src/components/, src/api/, src/services/
- READ: src/models/, src/types/, CLAUDE.md
- NEVER: database/, alembic/, tests/

## Output Format
### Task Report
**Task:** [ID]  **Status:** DONE | PARTIAL | BLOCKED
**Frontend files:** [list]
**Backend files:** [list]
**Summary:** [what and why]

Ejercicio 3: Diseñar un equipo de 3 teammates (Medio)

Diseña 3 teammates para un proyecto Python/Django con frontend React. Define: name, description, boundaries (POSEE, LEE, NO TOCA), y una skill que cada uno necesitaría. Dibuja el diagrama de cobertura del codebase.

CODEBASE COVERAGE:

frontend-agent:     react-app/src/ (components, pages, hooks)
django-dev:         backend/ (views, serializers, urls, services)
db-dev:             backend/models/, migrations/

Shared (team lead):  tests/, docs/, config/

Ejercicio 4: Skill file para tu proyecto (Medio)

Crea un skill file que capture las convenciones de tu proyecto actual. Incluye: estructura de archivos, patrones de código (con ejemplos), naming conventions, y errores comunes a evitar. Luego asócialo a un teammate.

# FastAPI Project Conventions

## Directory Structure
src/
├── routes/       # One file per resource (users.py, products.py)
├── schemas/      # Pydantic models, one file per resource
├── models/       # SQLAlchemy models
├── services/     # Business logic (no HTTP, no DB imports)
├── repositories/ # Database access (no business logic)
└── core/         # Config, deps, security

## Route Pattern
@router.get("/{id}", response_model=schemas.UserResponse)
async def get_user(id: int, service: UserService = Depends()):
    return await service.get_by_id(id)

## Naming
- Routes: plural nouns (users, products)
- Schemas: ResourceAction (UserCreate, UserResponse)
- Services: ResourceService (UserService)
- Repositories: ResourceRepository (UserRepository)

## Common Mistakes to Avoid
- Business logic in route handlers (put in services)
- Direct DB access in routes (use repositories)
- Missing response_model on routes
- Sync functions for DB operations (use async)

skills:
  - fastapi-project-conventions

Ejercicio 5: Hook de validación de boundaries (Difícil)

Escribe un hook PreToolUse que valide que cada teammate solo modifique archivos dentro de sus boundaries. El hook debe:

1. Detectar qué teammate está ejecutando
2. Verificar que el path del archivo está dentro de los boundaries permitidos
3. Bloquear la operación si está fuera de boundaries (exit code 2)

#!/bin/bash

TOOL_NAME="$1"
TOOL_INPUT="$2"
AGENT_NAME="${CLAUDE_AGENT_NAME:-unknown}"

if [[ "$TOOL_NAME" != "Write" && "$TOOL_NAME" != "Edit" ]]; then
  exit 0
fi

FILE=$(echo "$TOOL_INPUT" | jq -r '.file_path // .path // empty')
if [[ -z "$FILE" ]]; then
  exit 0
fi

case "$AGENT_NAME" in
  frontend-agent)
    if [[ ! "$FILE" =~ ^src/(components|pages|styles|hooks|utils/client)/ ]]; then
      echo "BLOCKED: $AGENT_NAME cannot modify $FILE (outside frontend boundaries)"
      exit 2
    fi
    ;;
  backend-agent)
    if [[ ! "$FILE" =~ ^src/(api|models|services|utils/server)/ ]]; then
      echo "BLOCKED: $AGENT_NAME cannot modify $FILE (outside backend boundaries)"
      exit 2
    fi
    ;;
esac

exit 0

{
  "hooks": {
    "PreToolUse": [
      { "command": ".claude/hooks/validate-teammate-boundaries.sh" }
    ]
  }
}

Ejercicio 6: Teammate con memoria y contexto acumulado (Difícil)

Configura un teammate api-dev con memory scope project. Ejecútalo en una tarea, verifica que la memoria se guardó, y luego ejecútalo en una segunda tarea. Compara: ¿la segunda ejecución fue más eficiente? ¿El teammate recordó convenciones de la primera?

---
name: api-dev
description: API endpoint developer with project memory
memory: project
model: sonnet
tools: Read, Write, Edit, Glob, Grep, Bash
maxTurns: 20
---

## Role
API developer. You remember context from prior tasks in this project.

## Memory Usage
- When you discover project conventions, remember them
- When you make decisions about patterns, record the reasoning
- When you encounter errors, remember the resolution

## First Task Behavior
- Read CLAUDE.md and existing code to discover conventions
- Note patterns: naming, structure, error handling style
- Implement the task following discovered conventions

## Subsequent Task Behavior
- Use remembered conventions without re-reading everything
- Verify if conventions have changed (check file dates)
- Build on prior decisions for consistency

Resumen

• Un teammate es un subagent file diseñado para ser invocado por un team lead — técnicamente igual, conceptualmente diferente
• La description es la pieza más importante para Agent Teams — el team lead la usa para decidir asignaciones
• Los boundaries definen qué puede modificar cada teammate — cobertura sin overlap evita conflictos
• Hay 4 tipos de boundaries: archivos (directorios), operaciones (herramientas), decisiones (system prompt), y conocimiento (skills)
• Las skills precargan conocimiento de dominio — convenciones que el teammate sigue automáticamente
• El naming sigue el patrón [dominio]-[rol] — descriptivo para humanos y para el team lead
• Cada teammate produce un Task Report estandarizado que el team lead puede procesar
• Sin Agent Teams, los teammates funcionan como subagents estándar invocados por un coordinador — los agent files son idénticos

Recursos Adicionales

1. Create Custom Subagents (Anthropic Docs) — Documentación oficial de agent files con frontmatter YAML
2. Claude Code Hooks Reference — Hooks PreToolUse para enforcement de boundaries
3. Claude Code Best Practices — Buenas prácticas de delegación y especialización
4. Prompt Engineering: Be Clear and Direct — Técnicas de claridad aplicables a descriptions y boundaries
5. Claude Code Settings — Configuración de skills y hooks
6. Claude Code CLI Reference — Flag --agent y gestión de agent files
7. Principle of Least Privilege (OWASP) — Fundamento de seguridad detrás de boundaries restrictivos
8. Claude Code Overview — Contexto general para entender cómo encajan los teammates

Siguiente cápsula: En la cápsula 04 aprenderás a crear y gestionar el task board — la lista de tareas con dependencias, prioridades, y estados que el team lead usa para coordinar al equipo. Verás cómo declarar dependencias entre tareas, cómo el team lead resuelve el orden de ejecución, y qué pasa cuando una dependencia no se cumple.