Son tres cosas distintas que se confunden porque aparecen juntas en cualquier conversación sobre IA, y porque las tres «amplían» lo que puede hacer el modelo. No compiten: son capas de la misma pila.

Una skill es una carpeta con un fichero de instrucciones que le dice al agente cómo se hace una tarea concreta en tu equipo. No es código: es contexto empaquetado y versionado.

.claude/skills/revisar-pr/
├── SKILL.md          <- las instrucciones
└── checklist.md      <- material de apoyo, se carga solo si hace falta

---
name: revisar-pr
description: Revisa un pull request con el checklist del equipo. Usar cuando
  se pida revisar un PR, unos cambios o un diff.
---
 
# Revisión de pull request
 
1. Leer la descripción del PR y comprobar que hay una issue enlazada.
2. Revisar contra checklist.md, en ese orden.
3. Clasificar cada hallazgo: bloqueante, recomendable o nota.
4. No comentar estilo: de eso ya se encarga el formateador.

Lo que hace que esto escale es cómo se cargan: de todas las skills instaladas, el agente lleva siempre en contexto solo el nombre y la descripción —dos líneas—, y el cuerpo entra únicamente cuando la tarea encaja. Por eso se pueden tener veinte sin llenar la ventana de contexto.

Dónde viven:

• .claude/skills/ o .opencode/skills/ en el proyecto: viajan en el repositorio, se revisan en el PR y valen para todo el equipo. Es el caso normal.
• ~/.claude/skills/ en tu casa: tus manías, en todos los proyectos.

Los comandos /kiro-* del tema 11 son exactamente esto: cc-sdd instala el flujo SDD completo como skills dentro del proyecto.

Cuándo escribir una: cuando algo se repite y sale distinto cada vez, o cuando hay un procedimiento del equipo que hoy solo está en la cabeza de alguien. Lo que no puede hacer una skill es actuar: solo guía cómo se actúa.

Un agente es un modelo metido en un bucle con herramientas: piensa, actúa, observa el resultado y vuelve a decidir. La diferencia con un chat no es el modelo, es que puede ver las consecuencias de lo que hace y corregir.

En este curso los agentes aparecen de dos formas:

• El agente de terminal que usas tú: Claude Code, OpenCode, Codex (tema 3). El bucle lo lleva la herramienta.
• Los subagentes: agentes especializados que el principal lanza para un trozo del trabajo, cada uno con su propia ventana de contexto, sus herramientas y sus instrucciones. Esa ventana propia es la razón de fondo para usarlos, más que el paralelismo: es lo que permite abarcar un problema que no cabría en una sola conversación (tema 5, orquestador).

Montar un agente es decidir cuatro cosas, y ninguna es el prompt:

1. Qué herramientas puede usar, y cuáles no.
2. Cuándo para: el criterio de terminado, comprobable (tema 4).
3. Qué presupuesto tiene: vueltas, tiempo, dinero.
4. Qué pasa cuando falla un paso: reintento, vuelta atrás o persona.

Model Context Protocol es un protocolo abierto para conectar agentes con sistemas externos a través de una interfaz común. La analogía es el USB-C: antes cada herramienta escribía su propio conector para cada servicio; con MCP se escribe un servidor y lo usa cualquier cliente que hable el protocolo.

Un servidor MCP expone tres cosas:

Cuándo hace falta: el agente necesita datos vivos que no están ni en su entrenamiento ni en el repositorio —el estado de un pedido, una consulta a la base de datos de preproducción, el CRM—, o varias herramientas distintas necesitan acceder igual al mismo sistema.

Cuándo no: si lo que hace falta es leer un fichero, buscar en el proyecto o lanzar un comando, el agente ya lo hace con sus herramientas nativas. Montar un servidor MCP para eso es infraestructura que mantener a cambio de nada.

En un sistema montado del todo trabajan las tres capas a la vez: MCP le da acceso a los sistemas, las skills le dicen cómo usarlos bien, y el agente lleva el hilo de lo que hay que hacer.

• MCP vs Skills vs Agents With Scripts: Which One Should You Pick?