claude-devfleet

Visión general de la skill claude-devfleet

Qué hace claude-devfleet

claude-devfleet es una skill de coordinación para ejecutar trabajo de programación con varios agentes mediante Claude DevFleet, no un prompt de programación de propósito general. Su función es convertir una solicitud de ingeniería amplia en un conjunto planificado de misiones, enviar esas misiones a git worktrees aislados y devolver informes estructurados de progreso y finalización.

Quién debería instalarla

Esta skill claude-devfleet encaja mejor con usuarios que ya tienen una instalación local o de equipo de DevFleet y quieren ejecución en paralelo con secuenciación consciente de dependencias. Es una muy buena opción para desarrollar funcionalidades, hacer refactors, completar pruebas pendientes o preparar planes de implementación que se dividen de forma natural en tareas independientes o por etapas. Encaja peor si solo necesitas una edición, cambiar un archivo o una respuesta rápida.

Por qué los usuarios la eligen frente a un prompt simple

Su principal diferencia es la orquestación: planificación, aprobación, envío, seguimiento e informes son pasos explícitos. En lugar de pedirle a un solo agente que “lo haga todo”, claude-devfleet para Agent Orchestration te ayuda a dividir el trabajo en misiones con dependencias y luego ejecutarlas en worktrees separados para que los cambios concurrentes no choquen de inmediato.

El principal obstáculo para adoptarla

El mayor freno es la realidad de la configuración: esta skill requiere una instancia activa de Claude DevFleet conectada mediante MCP. Si DevFleet no está instalado, no es accesible o no está expuesto en el endpoint MCP esperado, la skill no puede hacer nada útil. Conviene entenderla como un flujo de ejecución sobre una infraestructura ya existente, no como un instalador autónomo.

Cómo usar la skill claude-devfleet

Contexto de instalación y conexión previa necesaria

Antes de probar el uso de claude-devfleet, asegúrate de que Claude Code pueda conectarse a DevFleet a través de MCP. La propia skill da por hecho que existe una instancia en ejecución y muestra este patrón de conexión:

claude mcp add devfleet --transport http http://localhost:18801/mcp

Si tu servidor DevFleet está en otro host o puerto, ajusta esa URL. Decisión práctica de instalación: si tu entorno no permite servicios MCP locales, es mejor posponer esta skill hasta resolver ese punto.

Cómo se invoca claude-devfleet en la práctica

El flujo principal es:

1. plan_project(prompt) para convertir una petición amplia en un proyecto y un DAG de misiones.
2. Revisar el plan con el usuario antes de ejecutar.
3. dispatch_mission(mission_id, model?, max_turns?) para iniciar el trabajo.
4. Dejar que las misiones vinculadas por dependencias se envíen automáticamente cuando esté configurado.
5. Usar get_report(mission_id) para resumir files_changed, el trabajo completado, los errores y los siguientes pasos.

También puedes construir el plan manualmente con create_project(...) y create_mission(...) cuando ya tienes claro cómo dividir las tareas. La creación manual conviene cuando el grafo de dependencias importa más que la fase de exploración inicial.

Convierte un objetivo impreciso en un prompt sólido

Entrada débil: “Build a REST API.”

Entrada más sólida para la skill claude-devfleet:

• ruta del repositorio o codebase objetivo
• endpoints deseados y método de autenticación
• capa de persistencia
• expectativas de testing
• objetivos excluidos
• restricciones de secuenciación

Ejemplo:
“Plan a project for ./app: add a REST API for projects and tasks, JWT auth, PostgreSQL via existing DB layer, preserve current routes, add integration tests, and keep schema changes isolated from endpoint work. Prefer missions that can run in parallel where safe.”

Por qué funciona: plan_project puede generar un mejor grafo de misiones cuando conoce límites, interfaces y restricciones de secuenciación. Sin eso, es habitual obtener un plan vago o misiones que se solapan demasiado.

Flujo recomendado y qué leer primero

Empieza por SKILL.md, porque en ese archivo este repositorio define el contrato operativo real. Fíjate especialmente en:

• la dependencia obligatoria de MCP
• el flujo plan → approve → dispatch → report
• las herramientas disponibles y sus parámetros
• la gestión de dependencias mediante depends_on y auto_dispatch

Un flujo práctico:

1. Pide solo el plan.
2. Comprueba si las misiones son realmente separables.
3. Aprueba o ajusta el grafo.
4. Lanza una primera misión pequeña para validar el entorno y las suposiciones sobre el repositorio.
5. Escala el envío en paralelo solo después de recibir un primer informe satisfactorio.

Preguntas frecuentes sobre la skill claude-devfleet

¿claude-devfleet es una buena opción para principiantes?

Solo si la persona principiante ya tiene DevFleet en funcionamiento. El modelo de orquestación es conceptualmente claro, pero la barrera real está en la infraestructura y en saber descomponer tareas. Quien empieza y no está familiarizado con MCP o con worktrees probablemente se bloqueará antes de ver valor.

¿Cuándo debería usar esto en lugar de un prompt normal de programación?

Usa claude-devfleet cuando la tarea sea lo bastante grande como para beneficiarse de planificación por misiones, ejecución aislada e informes estructurados. No lo uses para ediciones de un solo archivo, depuración rápida o preguntas exploratorias. En esos casos, un prompt normal es más rápido y tiene menos carga operativa.

¿Cuáles son los límites de la skill?

Esta guía de claude-devfleet cubre el comportamiento de orquestación, no el aprovisionamiento completo del entorno. La skill asume que DevFleet ya existe y que llamadas de herramientas como plan_project, create_mission, dispatch_mission, cancel_mission y get_report están disponibles mediante MCP. Si esas herramientas no están presentes, la skill es, en la práctica, inutilizable.

¿Encaja en flujos de trabajo de equipo?

Sí, especialmente cuando los equipos quieren un grafo de misiones visible y un paralelismo más seguro mediante git worktrees aislados. Resulta menos convincente en repositorios pequeños o en equipos que no quieren auto-merge ni automatización guiada por dependencias dentro de su flujo de desarrollo.

Cómo mejorar la skill claude-devfleet

Da mejores entradas de planificación para claude-devfleet

La forma más rápida de mejorar la salida de claude-devfleet es especificar desde el principio las restricciones de arquitectura y pistas sobre cómo dividir el trabajo. Menciona:

• repositorio/ruta objetivo
• criterios de aceptación
• archivos compartidos que probablemente generen conflictos
• tareas que deben ocurrir primero
• tareas que pueden ejecutarse en paralelo

Esto reduce los grafos de misiones deficientes y evita que dos agentes toquen los mismos puntos conflictivos.

Vigila los modos de fallo más comunes

Los principales fallos son previsibles:

• no hay conexión MCP con DevFleet
• las misiones son demasiado amplias
• las tareas dependientes se lanzan demasiado pronto
• hay ediciones solapadas entre worktrees paralelos
• max_turns es insuficiente para misiones complejas

Si una misión sigue atascándose, reduce el alcance antes de cambiar de modelo o añadir más agentes.

Itera después del primer informe

No des por definitivo el primer plan. Después de get_report(...), ajusta el proyecto:

• divide el trabajo incompleto en seguimientos más acotados
• añade dependencias que se hayan pasado por alto
• cancela misiones que duplicaban esfuerzo
• reescribe los prompts para incluir archivos exactos, interfaces o objetivos de prueba

Aquí es donde claude-devfleet para Agent Orchestration aporta más valor que un único prompt largo: el flujo está pensado para iterar, no para acertar a la primera.

Mejora los resultados con prompts de misión más precisos

Un buen prompt de misión nombra el área del código, el resultado esperado y la definición de terminado. Por ejemplo:
“Implement JWT auth middleware in server/auth, wire it into existing protected routes, add unit tests for token validation and expired tokens, do not change database schema.”

Ese nivel de precisión mejora la calidad del traspaso, reduce el riesgo de merge y hace que el informe final sea más accionable.