Disclaimer: este post es libre de IA, está 100% hecho artesanalmente por manos humanas así que es muy probable que encuentre typos, errores de redacción y quizás una que otra falta gramatical.

Antes que nada debemos aclarar una cosa, estamos viviendo en los tiempos donde la IA avanza a velocidades verdaderamente exhorbitantes y alarmantes, el modelo/paradigma que puede ser funcional y novedoso hoy, puede que en unas semanas sea algo obsoleto, lo mas importante es tratar de estar siempre actualizado y leyendo las prácticas que van saliendo (aunque muchas veces resulte imposible y abrumante) así que como sugerencia personal, no toman nada como la verdad absoluta, pero si prueben por ustedes mismos y así se darán cuenta el porqué de las cosas.

¿Qué es el modelo orquestador-constructor?

El modelo orquestador-constructor es basicamente un patrón multiagente donde existe un modelo que planifica, organiza y juzga y el otro ejecuta, así de simple.

Como sugerencia general se recomienda que tanto el orquestador como el ejecutor sean modelos diferentes y esto tiene una razón bastante sencilla: permite la revision cruzada del trabajo uno del otro sin los sesgos de cada uno. No tiene sentido que la misma persona que construyo una casa sea la misma que diga si está bien hecha o no, porque siempre va a decir que si.

En este tipo de modelo también aplican otros 3 conceptos que conviene tenerlos en cuenta:

  1. Spec-driven development: antes de escribir codigo se definen los specs, el PRD, las gates, el diseño de la aplicación y los slices/tickets, tener un panorama claro sobre el alcance de tu desarrollo hace que todo sea más fácil a la hora de ponerlo en marcha.
  2. Gates: son los contratos de aceptacion de los tickets/slices creados en la fase de planificación, el modelo no avanza hasta que estos no se cumplan.
  3. "The repo is the memory": este es un principio que nos dice que el estado del repo vive en archivos versionados, no en el chat, muy importante.

Ya cómete la maldita naranja

Ojo: lo que describiré a continuación es lo que a mi me a funcionado en cuestión de skills y metodologias, sé libre de probar y experimentar, entre más pruebes mas aprendes.

Ahora si para lo que nos interesa, los requisitos para poder ejecutar este modelo son los siguientes:

  • Mattt Pocock skills
  • Codex cli
  • Claude Code

Matt Pocock skills:

El santo grial de las skills, su filosofia de "small, easy to adapt, composable" hace que se pueda adaptar a casi cualquier repo perfectamente, no se apropia de ningun proceso, tu sigues teniendo el control de todo y solo te lleva de la mano para poder hacer unas mejores bases para tus proyectos.

En tu repositorio debes correr: npx skills@latest add mattpocock/skills

Te dará una serie de skills a seleccionar para instalar, como regla general, no instales nunca todas, es mejor leer detenidamente que hace cada skill y asi ver cual se adapta a tu proyecto, eso aplica como regla general, recuerda que cada skill son tokens extra de uso en tu ventana de contexto.

Recomendables (no quiero decir must pero funcionan segun tu proyecto)

  • setup-matt-pocock-skills — obligatoria, configura el tracker
  • grill-with-docs — el interrogatorio de diseño (frente de tu flujo)
  • grilling — el motor que usan las skills de grill por debajo
  • to-spec — genera tu PRD
  • to-tickets — parte el plan en slices/issues
  • handoff — compacta el traspaso → alimenta tu HANDOFF.md
  • implement — el loop de implementación
  • research — el research flow
  • codebase-design — cuidar el diseño desde el inicio
  • domain-modeling — modelar tu dominio
  • ubiquitous-language — lenguaje compartido, reduce ambigüedad
  • tdd — para tus gates deterministas del scoring
  • diagnosing-bugs — el loop de depuración

Opcionales

  • git-guardrails-claude-code — barreras de git; clave con tanto git reset/dispatch
  • resolving-merge-conflicts — vas a tener conflictos al mergear lanes paralelas, garantizado
  • code-review — para la revisión cruzada Fable↔Codex
  • wayfinder — contexto de sistema / orientación en el codebase
  • improve-codebase-architecture — rescate cuando algo se enrede
  • setup-pre-commit — hooks que ayudan a hacer cumplir los gates

Despues te preguntara sobre los agentes que quieres correr, en este caso asegurate de que esten seleccionados Claude Code y Codex. También acepta el metodo symlink de instalación.

Para la configuracion de Claude Code y Codex son los siguientes comandos (ya tienes que tener instalados ambos CLI)

Desde Claude Code corre estos comandos, son los necesarios para poder ejecutar codex desde CC:

/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/reload-plugins
/codex:setup

Si te pregunta sobre si quieres activar el codex:setup --enable-review-gate di que si, posteriormente activa claude en tu proyecto corriendo /init.

En tu claude.md agrega esto:

##Roles y paradigma de trabajo
-Orquestador/Arquitecto (Fable/Claude): diseña, descompone, congela gates, juzga.
-Constructor (Codex, vía /codex:rescue): implementa un slice a la vez.
Reporta resultados crudos, no se autojuzga.

Ahora viene la parte más importante de cualquier desarrollo y la magia de todo este paradigma, una vez que todo este listo y dentro de CC que es el cerebro de todo, corre el skill /grill-with-docs, a partir de ahi te hara una serie de preguntas sobre tu proyecto y lo que quieres lograr, te dará recomendaciones sobre si quieres que algo sea solo para MVP o para el proyecto en general, cuando termines esta sesión a partir de ese momento ya tienes un unos .md con el handoff que es el estado de tu repo, el context, y las gates.

Aqui puedes correr el skill /to-spec para poder ver el prd en tu repositorio, y opcionalmente /to-issues, ya que por lo general el grilling ya te crea los slices y las gates para el proyecto.

Si quieres ver a fondo como funcionan los skills de Matt te dejo el link de su página: https://www.aihero.dev/skills-to-spec

A partir de que se termina el grilling ya se puede empezar a trabajar, puedes decirle a claude que congele el slice 0 y ejecute el trabajo via codex, algo que ya esta definido en el claude.md, asi que claude ya sabra que hacer, delegara y juzgara el codigo de codex, se correra automaticamente un agente de codex desde CC y una vez que este termine, CC juzgara la implementacion y la comparara vs el gate establecido, si todo hace match, pasa al siguiente slice, y así hasta que todos los slices sean completados.

Esta es una recomendacion de Claude.md, puedes adaptarla a tus necesidades pero como inicio sirve para que entiendas como funciona este modelo.

##Tooling
.agents/skills/ contains a set of engineering skills (code-review, tdd, implement, diagnosing-bugs, domain-modeling, etc.) sourced from mattpocock/skills and pinned in skills-lock.json. Prefer invoking these skills when the task matches one — except code-review, which is exclusively the orchestrator's role: the builder (Codex) implements and reports raw results without self-reviewing or self-judging.
The Codex plugin (codex@openai-codex) is enabled in .claude/settings.json, with a stop-time review gate active for this project.
##Roles y paradigma de trabajo
Este proyecto usa un flujo de dos modelos:
Orquestador/Arquitecto (tú, Fable/Claude): diseñas, descompones en slices, congelas gates, juzgas resultados y decides merges. Mantén tu contexto ligero.
Constructor (Codex, vía /codex:rescue): implementa un slice a la vez. Reporta resultados crudos, no se autojuzga.
##Memoria del repo
docs/HANDOFF.md → estado y resultados crudos. Si no está aquí, no pasó.
docs/gates/ → criterios de aceptación, congelados ANTES de despachar cada slice.

Hasta este punto llega el concepto de orquestador-ejecutor, como veras, el que se encarga de toda la carga pesada de trabajo es codex, todo lo relacionado con codigo, la labor de claude se resume a ser el cerebro y verificar que todo este bien, como bien se menciono no necesariamente tiene que ser modelos de estas dos compañias, si quieres usar otros solo tienes que cambiar la forma en que se configura y se define cada uno como modelo orquestador y ejecutor.