Subagentes y skills en Claude Code para .NET: cuándo usar cada uno (con un conjunto de partida para una solución C#)

Claude Code llega con CLAUDE.md y MCP como la capa base de operación. Pero por encima de esas dos existe una tercera capa: la capa de agentes, formada por skills (slash commands que tú defines) y subagentes (instancias de agente separadas que lanzas para trabajo aislado o en paralelo). En una solución C# de cualquier tamaño real, saber cuándo usar cada uno es la diferencia entre un agente que mantiene el foco y uno que gira en círculos.

¿Cuál es la diferencia entre un skill, un subagente y un slash command en Claude Code?

Un slash command es un atajo de instrucciones: un archivo Markdown que colocas en .claude/commands/ y que se puede invocar como /tu-comando. Al ejecutarlo, Claude Code lee el archivo y actúa sobre él en la sesión actual. El comando es solo texto - una plantilla de prompt que el agente actual ejecuta.

Un skill es el patrón de encapsular un flujo de trabajo reutilizable en un slash command. La palabra “skill” es informal aquí; Claude Code no tiene una primitiva formal “skill” distinta de los comandos. En la práctica, un skill es un slash command que codifica un procedimiento completo y repetible: “añadir una migración de EF Core con un test de rollback” o “escribir un test de contrato para este endpoint”. Se ejecuta en tu sesión, ves cada paso y puedes corregirlo si se desvía.

Un subagente es una instancia de agente genuinamente separada. La capacidad Agent de Claude Code lanza un contexto nuevo con su propio presupuesto de tokens. El subagente hace su trabajo, devuelve un resultado, y su razonamiento interno no queda en tu contexto principal. Esto importa por dos razones: aislamiento de contexto (no puede contaminar tu hilo de trabajo con miles de líneas de resultados de búsqueda) y paralelismo (puedes ejecutar varios subagentes simultáneamente).

Resumen de la heurística: slash command / skill para procedimientos en el hilo actual, supervisados y manejables; subagente para tareas aisladas, exploratorias o paralelizables donde quieres el resultado sin el coste de leer todo el proceso.

¿Cuándo debe una tarea .NET usar un subagente en lugar de un skill?

El marco correcto es: ¿quién debe pagar el coste de contexto, y se beneficia el trabajo del aislamiento?

Usa un skill cuando:

• El procedimiento es repetible y quieres supervisar cada paso.
• Encaja de forma natural en el contexto de la sesión actual: añadir una migración, generar un test de contrato para el archivo que estás editando, ejecutar dotnet format y dotnet test como comprobación post-cambio.
• La salida va directamente al código en el que estás trabajando.

Usa un subagente cuando:

• La tarea es intensiva en exploración: encontrar todos los llamadores de una API obsoleta en una solución de veinte proyectos, auditar todas las versiones de paquetes contra una lista de CVEs conocidos, mapear qué proyectos no tienen cobertura de tests.
• Puede ejecutarse en paralelo con otro trabajo. Mientras un subagente audita src/Billing/, otro puede analizar src/Auth/.
• El trabajo intermedio - miles de líneas de resultados grep, listas de paquetes NuGet - no debería llegar a tu contexto principal. Deja que el subagente lo destile en un resumen de uno o dos párrafos.
• Quieres una segunda opinión independiente - un subagente de revisión de código que empieza sin conocimiento de los supuestos de tu sesión suele detectar cosas que tú mismo descartarías.

Regla práctica: si el trabajo es más largo que una tarea que describirías en dos frases, y sus pasos intermedios no son decisiones que necesitas tomar tú mismo, pertenece a un subagente.

¿Qué subagentes y skills merece la pena configurar para una solución C#?

Este es un conjunto de partida que cubre la mayoría de las tareas recurrentes de un desarrollador .NET senior.

Skills (slash commands en .claude/commands/)

/add-ef-migration - pide el nombre de la migración, genera el comando dotnet ef migrations add con los flags de proyecto correctos, lo ejecuta y confirma que la migración compila. Se ejecuta en el hilo porque normalmente querrás revisar la migración generada antes de hacer cualquier otra cosa.

/write-contract-test - dado el endpoint o método público del archivo actual, escribe un test de contrato (caracterización) que fija el comportamiento existente. Se ejecuta en el hilo para que puedas revisar y ajustar el nombre del test y las aserciones antes de que queden escritas.

/roslyn-review - un procedimiento de revisión de código que usa el MCP de Roslyn para obtener referencias reales de símbolos antes de comentar una superficie de API. En el hilo porque quieres interactuar con sus hallazgos.

/post-change-gate - ejecuta dotnet build, dotnet test y dotnet format --verify-no-changes en secuencia e informa del resultado. Un wrapper fino que convierte la comprobación “¿es este cambio seguro?” en un solo comando.

Subagentes (lanzados para aislamiento y trabajo en paralelo)

Auditoría de dependencias - lanzado contra la solución completa, escanea cada *.csproj en busca de versiones de paquetes, compara con una lista objetivo o una línea base conocida y devuelve una tabla estructurada. La salida es un resumen, no una pared de XML.

Búsqueda de código muerto en toda la solución - usa el MCP de Roslyn para recorrer la solución e informar de las APIs públicas sin llamadores. Un subagente es lo correcto aquí porque la búsqueda es exhaustiva y no necesitas ver cada paso; necesitas la lista.

Informe de cobertura de tests de contrato entre proyectos - comprueba qué servicios públicos carecen de un test de contrato. Devuelve una lista priorizada. Se ejecuta una vez y produce una lista de acciones que importas de vuelta a la sesión principal.

Revisor de código independiente - lanzado después de terminar una funcionalidad, solo con el diff y el conjunto de tests como contexto. Sin memoria de sesión de cómo llegaste hasta ahí. Devuelve hallazgos en formato estructurado.

Este conjunto se construye sobre la base de CLAUDE.md y MCP descrita en el repo dotnet-claude-starter. El repo incluye comandos de ejemplo en .claude/commands/ que puedes copiar y adaptar; los skills son deliberadamente finos - llaman al CLI de dotnet y al MCP de Roslyn en lugar de embeber lógica en el prompt.

FAQ

¿Cuál es la diferencia entre un skill y un subagente en Claude Code? Un skill es un procedimiento reutilizable en el hilo actual que se invoca con un slash command. Un subagente es una instancia de agente separada con su propia ventana de contexto, usada para trabajo que se beneficia del aislamiento o puede ejecutarse en paralelo.

¿Cuándo debo usar un subagente para una tarea .NET? Cuando la tarea sea exploratoria, pueda ejecutarse en paralelo, o contaminaría el contexto de tu sesión principal - auditorías de dependencias de toda la solución, búsquedas de código muerto entre proyectos, o una revisión de código independiente.

¿Puedo ejecutar varios subagentes en paralelo sobre una solución C# grande? Sí. Claude Code puede lanzar múltiples subagentes simultáneamente y reunir sus resúmenes en el contexto principal. Es el patrón correcto para análisis de toda la solución que de otra forma harían explotar la ventana de contexto.

¿Cuántos slash commands puedo registrar en Claude Code? No hay un límite fijo. Los comandos se definen como archivos Markdown en .claude/commands/, uno por comando. Mantén el conjunto pequeño - un comando que hace una sola cosa es más fiable que uno de propósito general.

¿El repositorio dotnet-claude-starter incluye ejemplos de skills? Sí. El repo en github.com/Khavel/dotnet-claude-starter incluye comandos de ejemplo en .claude/commands/ para tareas .NET habituales. El README explica cómo extenderlos.

---

La capa de operación para un SaaS .NET en producción

Los skills y subagentes aquí son la tercera capa; CLAUDE.md es la primera y MCP es la segunda. Sharpyard es el starter kit .NET 10 + Angular para SaaS en producción con las tres capas cableadas desde el principio. Únete a la lista de espera para el precio fundador.

Relacionados: Claude Code para desarrolladores .NET - MCP para .NET - Claude Code en una solución C# grande