En Skills y agentes vimos lo que dan las herramientas: la skill, que se carga en tu conversación, y el agente, que trabaja en un contexto vacío y devuelve un resultado. Aquí vamos a ver qué hacemos nosotros con eso: en este curso todo se escribe como skill, y hay tres tipos: las que saben, las que hacen y los subagentes que lanzan las que hacen. Cómo se organiza cada una por dentro (carpetas, secciones del SKILL.md) está en Estructura de un skill.

Más información:

• Specification - Agent Skills: el estándar de las skills: una carpeta con su SKILL.md y los ficheros que use.
• Claude Code: skills: cómo se lanzan con / y qué hace context: fork.
• Claude Code: subagents: qué es un subagente y cómo se le pasa el prompt.

Dos ficheros con instrucciones, que se distinguen solo en dónde se carga su contenido (Skill o agente):

• Skill: su fichero se añade a tu conversación. Lo que lee y hace se queda en tu contexto.
• Agente: su fichero va a un contexto nuevo y vacío, junto con el prompt que le pasa el principal. A tu conversación solo vuelve su respuesta.

Y la frontera es más fina de lo que parece: una skill lanzada en una conversación recién abierta que cierras al terminar es un agente (el caso especial del tema 8). Claude Code lo hace explícito: una skill con context: fork en el frontmatter se ejecuta como agente, en un contexto aparte, sin cambiar nada más del fichero.

En este curso todo se escribe como skill. Lo que cambia es para qué sirve cada una, quién la lanza y dónde se carga:

.claude/skills/
├── k-servicios/
│   └── SKILL.md
└── do-crear-servicio/
    ├── SKILL.md
    └── subagents/
        └── verificador.md

Describe cómo se hace algo en el proyecto: cómo son los servicios, cómo se escriben los tests, cómo se nombran los commits. No hace nada sola: la cargan las skills de procedimiento («carga k-servicios») o el modelo cuando ve en su description que la necesita.

Es el ejemplo 1 del tema 8, el repository JPA: conocimiento que tiene que quedarse en la conversación para que valga en el siguiente mensaje. Por eso es una skill y nunca un agente.

Ejecuta un proceso por fases: crear un servicio, revisar un PR, generar los tests. La lanzas tú con /do-crear-servicio R-12 y al terminar te dice qué ha hecho.

Es el ejemplo 2 del tema 8, generar los tests: el trabajo de un agente. Pero lo escribimos como skill, no como agente, por dos razones:

• Un agente no tiene carpeta propia. Es un único fichero en .claude/agents/, así que sus plantillas, scripts, ejemplos y subagentes no pueden ir junto a él. Una skill es una carpeta y lleva dentro todo lo que usa.
• Lanzarla es más corto. En Claude Code un agente se lanza con agent- delante del nombre; una skill, directamente:

@agent-crear-servicio R-12
/do-crear-servicio R-12

Lo que aporta el agente, empezar con el contexto vacío, se consigue lanzando la skill en una conversación limpia, con /clear antes. Y si quieres que se ejecute como agente de verdad, mientras tú sigues en tu conversación, en Claude Code basta con context: fork en el frontmatter:

---
name: do-crear-servicio
description: Crea un servicio de Pedidos con su test a partir de un requisito de
  specs/. Usar cuando se pida crear, añadir o generar un servicio o una clase *Service.
context: fork
---

Un subagente es un trabajo cerrado dentro de una fase de una skill de procedimiento: comprobar que el test cubre el requisito, revisar el fichero generado, juzgar si cumple el checklist. Lo lanza la skill, no tú, y su respuesta la lee la skill para decidir si sigue o corrige.

Su prompt es un fichero .md en la carpeta subagents/ de la skill. Para la herramienta ese fichero no existe: no está en .claude/agents/ ni tiene frontmatter. Es la skill la que dice cuándo se lanza, qué fichero lee y qué le pasa, y Claude Code arranca un subagente genérico con ese prompt:

✅ Lanza un subagente con model: haiku que lea `subagents/verificador.md` y pásale `requisito` y `ruta_test`.
❌ Lanza un subagente que lea `subagents/verificador.md`. (no dice qué le pasa ni con qué modelo)

Es el agente del tema 8 (El fichero del agente), con las mismas tres secciones, Entradas, Proceso y Salida, y las mismas razones:

• Empieza vacío, así que todo lo que necesita le llega en Entradas. «Revisa lo que hemos hecho» no funciona.
• Lo que lee muere con él: la clase, el test, la salida de mvn test. A la skill solo le vuelve la respuesta.
• La respuesta es cerrada, PASS o FAIL en la primera línea, para que la skill la compare tal cual.

¿Por qué un subagente y no otra skill do-? Porque el resultado lo necesita la skill que sigue trabajando, no tú, y porque lo que lee no tiene que llenar tu contexto. Y es un trabajo demasiado pequeño para tener su propia carpeta: va con el procedimiento que lo usa.

El nombre de la skill (su carpeta y su name) empieza por un prefijo que dice de qué tipo es:

• k-, de knowledge, conocimiento en inglés: las que saben cosas: k-servicios, k-tests. Detrás del prefijo, el tema.
• do-, «hacer» en inglés: las que hacen cosas: do-crear-servicio, do-revisar-pr. Detrás del prefijo, un verbo.

Todo en kebab-case. Los subagentes no llevan prefijo: el fichero se llama por su rol, verificador.md, revisor.md, porque ya están dentro de la do- que los lanza.

Ventajas del prefijo:

• No chocan con los comandos de Claude Code, que también se lanzan con /. Una skill llamada init o context se confunde con /init o /context; /do-revisar-pr no coincide con ningún comando.
• Escribiendo /do- sale todo lo que se puede lanzar: el autocompletado enseña solo las skills que hacen cosas, sin las de conocimiento, que no se lanzan a mano.

Tres preguntas, en este orden:

1. ¿Son reglas o es una tarea? Si son reglas (cómo se hace algo), k-. Si es una tarea, sigue.
2. ¿La lanzas tú? Si la pides tú y quieres ver cómo avanza, do-. Si la lanza otra skill en medio de su proceso, sigue.
3. ¿El resultado es una comprobación cerrada que la skill compara? Entonces subagente. Si la skill necesita que lo que se ha leído siga en el contexto, no es un subagente: es una fase más de la do-.

Con el ejemplo del curso:

• Cómo son los servicios → k-servicios.
• Crear un servicio a partir de un requisito → do-crear-servicio.
• Comprobar que el test del servicio cubre el requisito, dentro de do-crear-servicio → subagents/verificador.md.

Di si cada cosa es una skill de conocimiento, una de procedimiento o un subagente, y por qué:

do-revisar-pr tiene estas fases: leer el PR, comprobar las convenciones de los servicios, comprobar que cada requisito tiene test, comprobar la cobertura y escribir el informe. Di qué skills k- carga, qué fases se hacen con un subagente y qué le pasa a cada uno en Entradas.