Instalé dev-orchestra en Claude Code y llevé el desarrollo con una sola frase

Introducción

En la entrega anterior presenté lo que puede hacer dev-orchestra. Esta vez lo instalo de verdad en un entorno con solo Claude Code y lo uso.

• Calcula unos 5 minutos para leerlo y unos 10 para probarlo
• Se asume que Codex no está instalado (el uso con Codex es el tema de la próxima entrega)

dev-orchestra está publicado en GitHub (licencia MIT). Si te parece útil, una estrella me alegraría mucho.

→ github.com/istb16/dev-orchestra

Qué necesitas

Qué	Notas
Claude Code	Con la sesión ya iniciada
Python 3.11 o superior	Funciona solo con la biblioteca estándar
git	Se usa para obtener el diff que se revisará

No hace falta ninguna clave de API. Usa directamente tu inicio de sesión de Claude Code.

Pasos

1. Instálalo

Son dos líneas en la terminal.

claude plugin marketplace add istb16/dev-orchestra
claude plugin install dev-orchestra@dev-orchestra

Desde dentro de Claude Code, escribir lo siguiente hace lo mismo.

/plugin marketplace add istb16/dev-orchestra
/plugin install dev-orchestra@dev-orchestra

Estará disponible en las sesiones que abras después de instalarlo.

2. Elige un preset la primera vez

La primera vez que haces una petición que usa dev-orchestra, se da cuenta de que aún no hay configuración, te muestra la configuración actual y te pide elegir un preset.

Un preset es una elección de «dónde gastar dinero (tokens)», y hay tres.

Preset	En pocas palabras
quality	Usa más modelos potentes. Prioriza la calidad
standard	Elige este si dudas. Equilibrio entre calidad y coste
fast	Sobre todo modelos ligeros. Prioriza la velocidad y el coste

Más adelante en esta serie explicaré en detalle qué contienen los presets, así que aquí sigo con standard.

En la configuración inicial también te pregunta en qué idioma debe responder. Si eliges japonés, se añade a tu configuración de usuario de Claude Code un hook para «responder en japonés».

3. Comprueba que se monta solo con Claude

Esta es la parte que más quiero que mires. En una máquina sin Codex, al elegir standard obtuve esta configuración (un extracto de config show en dev-orchestra 1.0.0).

Preset: standard (implicit; fitted to claude)
  note: codex not found on PATH: reviewer seat 2 (general) went to claude as claude-general-2 (sonnet)

  Architect
    claude / fable / latest
  Implementer
    claude / opus / latest
  Reviews
    1. claude / opus / latest / general / claude-general
    2. claude / sonnet / latest / general / claude-general-2
    3. claude / sonnet / latest / security / claude-security (opus when high-risk)
    4. claude / sonnet / latest / test / claude-test

El puesto de revisor que normalmente iría a Codex se sustituyó automáticamente por Claude (sonnet). Así no acabas con una configuración que da por supuesto un CLI que no tienes, con revisiones que fallan siempre.

• El diseño usa fable y la implementación usa opus: el modelo se reparte por rol
• Hay 4 revisores. Todos son Claude, pero se ejecutan como procesos aparte que no tienen la conversación de la implementación
• Los 4 revisores también tienen roles distintos: general, security y test

4. Comprueba que todo está listo

Por si acaso, le pedí al agente «Ejecuta el doctor de dev-orchestra» para que revisara el entorno. La parte de Claude Code salió así (extracto).

Claude Code (claude)
  Installed: yes
  Model selection: supported
  Models (cli-help): fable, opus, sonnet
  Read-only runs: enforced by --permission-mode plan --disallowed-tools Edit,Write,NotebookEdit --tools Read,Grep,Glob --strict-mcp-config --restricted

Read-only runs: enforced significa que los roles de diseño y de revisión se ejecutan obligatoriamente en solo lectura mediante flags de Claude Code. No se les pide «por favor, no modifiques nada»: simplemente nunca se les entregan herramientas capaces de modificar.

Si termina con No problems found., ya está todo listo.

5. Haz una petición en una frase

A partir de aquí, solo tienes que hablarle como siempre.

Implementa este issue con el flujo de trabajo configurado

Escribe pruebas para esta función y pásala por la revisión multimodelo

Para que el implementador pueda ejecutar pruebas, primero añade tu comando de pruebas a permissions.allow en .claude/settings.json (p. ej. Bash(npm test:*)). Sin eso, los comandos de shell no se ejecutan automáticamente.

Solo se ejecutan los pasos necesarios según el tamaño de la petición. Para una petición más grande, ocurre así.

1. Diseño: escribe un plan y pregunta «¿Seguimos con este plan?»
2. Aprobación: cuando lees el plan y respondes que sí, pasa a la implementación (no avanza por su cuenta)
3. Implementación → pruebas
4. Revisión: 4 revisores revisan el mismo diff sin ver las revisiones de los demás
5. Triaje → correcciones → nuevas pruebas
6. Informe final

El informe final llega con una forma como esta (ejemplo).

Tests      ✓ 12 passed
Reviews    4/4 ✓
Triage     5 findings → 2 accepted, 2 rejected, 1 duplicate
Models     architect Claude/fable, implementer + fixer Claude/opus
Changed    src/calc.py, tests/test_calc.py
Remaining  none

Incluso informa de qué observaciones se aceptaron y cuáles se rechazaron, así que si alguna te llama la atención, puedes preguntar el motivo.

Como ejecuta varios revisores, consume más tokens que hacerlo todo con una sola IA. Te recomiendo empezar con peticiones pequeñas.

Funciones y limitaciones propias de Claude Code

Estos son los puntos que conviene conocer al usarlo con Claude Code (a fecha de dev-orchestra 1.0.0; los detalles están en providers.md).

	Detalle
Ventaja: la imposición de solo lectura más fuerte	El diseño y la revisión se ejecutan con solo 3 herramientas (Read / Grep / Glob) y no usan MCP
Ventaja: los modelos se indican por nombre	Si escribes opus / sonnet / fable, se usa el más reciente de esa línea
Ventaja: el diseño puede retomarse donde se quedó	Al revisar un plan, puede heredar la conversación del diseño anterior (en las versiones de Claude Code verificadas)
Precaución: tu propio permissions.deny no se aplica en el diseño ni la revisión	Porque no se lee ninguna de las configuraciones de usuario, de proyecto ni local (settings.json). El arquitecto y los revisores pueden leer cualquier archivo del repositorio, así que traslada las reglas que ocultan archivos secretos a managed settings (se explica abajo)
Precaución: el implementador no ejecuta comandos de shell automáticamente	Para ejecutar pruebas, añade tu comando de pruebas (p. ej. Bash(npm test:*)) a permissions.allow en .claude/settings.json
No disponible: el diseño y la revisión no funcionan en un Claude Code antiguo	En versiones sin los flags necesarios, doctor indica NOT ENFORCEABLE y detiene la ejecución

Usa managed settings para ocultar .env

Managed settings es un archivo de configuración para administradores. La configuración de usuario o de proyecto no puede sobrescribirlo, y se sigue cargando con --restricted cuando se ejecutan el arquitecto y los revisores.

SO	Ubicación
macOS	/Library/Application Support/ClaudeCode/managed-settings.json
Linux / WSL	/etc/claude-code/managed-settings.json
Windows	C:\Program Files\ClaudeCode\managed-settings.json (para escribirlo se necesitan permisos de administrador)

Para evitar que el modelo lea .env y archivos similares, escribe esto.

{
  "permissions": {
    "deny": ["Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)"]
  }
}

La ubicación puede cambiar entre versiones de Claude Code. Compruébala en la documentación oficial.

Resumen

• Instalarlo en Claude Code lleva 2 líneas. No hace falta clave de API
• La primera vez, solo elige un preset. Si dudas, standard
• Aunque no tengas Codex, los revisores se montan automáticamente solo con Claude
• El diseño y la revisión se fuerzan a solo lectura mediante flags de Claude Code
• Después, solo haz una petición en una frase. El plan no pasa a la implementación hasta que lo apruebes
• Si quieres que se ejecuten pruebas, permite tu comando de pruebas en .claude/settings.json
• permissions.deny no se aplica en el diseño ni en la revisión. Traslada las reglas que ocultan .env y similares a managed settings

El uso detallado está en el README. La próxima vez lo probaré con Codex.

Para saber cómo actualizar cuando salga una versión nueva, consulta Actualizar dev-orchestra.

Todas las entradas de esta serie están en la lista de entradas de «dev-orchestra».

GitHub: istb16/dev-orchestra (una estrella siempre se agradece)