Claude Code Game Studios: 49 agentes para hacer tu juego

Abres Claude Code, le pides un juego de plataformas y en veinte minutos tienes algo que se mueve en pantalla. Con números mágicos repartidos por todo el código, sin documento de diseño, sin un solo test y sin nadie que te pregunte si ese doble salto encaja con el juego que tenías en la cabeza.

Eso es lo que pasa cuando una sesión de IA no tiene estructura.

Claude Code Game Studios (CCGS para los amigos) es una plantilla de código abierto que intenta arreglarlo convirtiendo una sola sesión de Claude Code en un estudio de videojuegos completo: directores, jefes de departamento, especialistas, revisiones de calidad y un flujo de trabajo que va de la lluvia de ideas al lanzamiento.

En este artículo vas a ver:

• Qué es Claude Code Game Studios y qué trae dentro
• Cómo se organiza su jerarquía de 49 agentes
• Cómo se instala y cuál es el primer comando que tienes que lanzar
• Cómo ajustar cuánto proceso quieres con modes.rigor (y por qué el modo ligero es el de serie)
• Para quién tiene sentido y para quién es matar moscas a cañonazos

¿Qué es Claude Code Game Studios? ¶

Claude Code Game Studios es una plantilla de proyecto para Claude Code que trae configurado un equipo de agentes especializados en desarrollo de videojuegos. No es una app ni un motor ni un servicio: es un repositorio que clonas y sobre el que construyes tu juego.

El proyecto lo mantiene Donchitos en GitHub con licencia MIT. La versión 1.2.0 salió el 19 de octubre de 2026 y su CHANGELOG.md deja claro que está vivo: cada release trae ajustes en skills, hooks y referencias de motor.

La idea de partida la explica su README sin rodeos: hacer un juego en solitario con IA da mucho poder, pero una sesión de chat no tiene estructura. Nadie te frena cuando metes valores a fuego en el código, te saltas el diseño o escribes espaguetis. No hay QA, no hay revisión de diseño, no hay nadie que pregunte “¿esto encaja con la visión del juego?”.

La respuesta de CCGS es darle a tu sesión la forma de un estudio real.

Según su README, el paquete trae esto:

Si ya has trabajado con subagentes en Claude Code, todo esto te sonará: son los mismos ladrillos (agentes en .claude/agents/, skills en .claude/skills/, hooks en settings.json) montados a una escala poco habitual en un repo público.

🔑 Fíjate menos en el número de agentes y más en lo que lleva cada uno: responsabilidades definidas, a quién escalar cuando hay conflicto y qué puertas de calidad tiene que pasar su trabajo.

¿Cómo se organiza el estudio de 49 agentes? ¶

Los agentes se reparten en tres niveles, igual que en un estudio de verdad. Arriba los que protegen la visión, en medio los que llevan cada área y abajo los que se manchan las manos.

Nivel 1 — Directores
  creative-director    technical-director    producer

Nivel 2 — Jefes de departamento
  game-designer        lead-programmer       art-director
  audio-director       narrative-director    qa-lead
  release-manager      localization-lead

Nivel 3 — Especialistas
  gameplay-programmer  engine-programmer     ai-programmer
  network-programmer   tools-programmer      ui-programmer
  systems-designer     level-designer        economy-designer
  technical-artist     sound-designer        writer
  world-builder        ux-designer           prototyper
  performance-analyst  devops-engineer       analytics-engineer
  security-engineer    qa-tester             accessibility-specialist
  live-ops-designer    community-manager

A eso se suman los especialistas de motor. La plantilla trae sets completos para los tres grandes, y tú usas el que toque:

Cada agente es un fichero markdown con frontmatter YAML. El del creative-director, por ejemplo, declara qué herramientas puede usar, qué modelo pide y qué tiene prohibido:

---name: creative-directordescription: "Highest creative authority — vision, tone, aesthetic direction. Use when a decision affects game identity or department leads deadlock."tools: Read, Glob, Grep, Write, Edit, WebSearchmodel: opusmaxTurns: 30memory: projectdisallowedTools: Bash---

Fíjate en el disallowedTools: Bash. El director creativo decide y escribe documentos, pero no ejecuta comandos. Esa separación de funciones está por todo el repo.

¿Qué modelo usa cada agente? ¶

Aquí hay un detalle que conviene leer con calma antes de asustarse por la factura. Según el README, los tres directores piden Opus, el lead-programmer y quince especialistas declaran Sonnet, y los treinta restantes heredan el modelo de tu sesión.

El propio autor lo resume así: los niveles son antigüedad del rol, no un plan de precios. La mayor parte del estudio funciona con el modelo que ya estés usando.

¿Cómo se coordinan entre ellos? ¶

El README describe cinco reglas de coordinación:

1. Delegación vertical: los directores delegan en los jefes y los jefes en los especialistas.
2. Consulta horizontal: agentes del mismo nivel pueden consultarse, pero no tomar decisiones vinculantes fuera de su área.
3. Resolución de conflictos: los desacuerdos suben al padre común (creative-director para diseño, technical-director para lo técnico).
4. Propagación de cambios: los cambios que tocan varios departamentos los coordina el producer.
5. Fronteras de dominio: ningún agente toca ficheros fuera de su área sin delegación explícita.

Es un organigrama, con lo bueno y lo malo que eso tiene. Si te interesa la coordinación de agentes en paralelo más allá de esta plantilla, en el post sobre Agent Teams en Claude Code tienes la versión nativa del propio Claude Code.

Curso en vídeo

¿Y si antes de 49 agentes pruebas un flujo de prompts que repites en cualquier proyecto?

En la primera lección ves el flujo completo con un agente y tus prompts, sin framework, y en la tercera escribes las reglas de la sesión en un AGENTS.md.

Entra en el curso gratis →

¿Cómo se instala Claude Code Game Studios? ¶

La instalación es clonar el repositorio y abrir Claude Code en la raíz. No hay paquete que instalar ni servidor que levantar.

Antes necesitas tener esto en tu máquina:

• Git
• Claude Code: el README recomienda el instalador nativo, aunque npm install -g @anthropic-ai/claude-code también vale con Node.js 22 o superior
• Python 3: lee project.yaml en cada skill y cada hook. Sin Python, todos los ajustes vuelven en silencio a su valor por defecto
• Bash: ejecuta todos los hooks. Viene con macOS y Linux; en Windows llega con Git for Windows
• jq (recomendado): para la validación de los hooks

⚠️ Los hooks fallan con elegancia si te falta alguna herramienta opcional: pierdes esa validación. Hay una excepción deliberada: si haces commit de un JSON de datos y no tienes Python para validarlo, el commit se bloquea.

Con eso listo, son tres pasos.

Paso 1: clona la plantilla ¶

git clone https://github.com/Donchitos/Claude-Code-Game-Studios.git my-game
cd my-game

Paso 2: abre Claude Code en la raíz del proyecto ¶

claude

Esto tiene más miga de lo que parece. Tienes que arrancar en la carpeta que contiene CLAUDE.md y project.yaml. Si arrancas en una subcarpeta como src/, Claude Code no carga los hooks del proyecto, ni las reglas de denegación, ni el modo de permisos que pregunta antes de actuar. Te quedas con 49 agentes y sin cinturón de seguridad.

Paso 3: lanza /start ¶

/start

/start es la puerta de entrada. Te pregunta desde dónde partes (sin idea, con un concepto vago, con un diseño claro o con un proyecto ya empezado) y te señala el siguiente paso. Su propia definición dice que lee el proyecto, te enseña lo que asume y nombra un solo paso siguiente, pero nunca lo ejecuta por ti.

Si ya sabes lo que quieres, puedes saltar directo:

• /brainstorm para explorar ideas de juego desde cero
• /setup-engine godot 4.7 si ya tienes claro el motor
• /project-stage-detect para analizar un proyecto que ya existe

¿Para qué sirve en el día a día? ¶

Sirve para pasar de una idea a un juego que funciona con un proceso que no se te desmorona a la tercera semana. El repo cubre el ciclo completo con skills agrupadas por fase.

Hay comandos para el arranque (/start, /setup-engine, /settings), el diseño (/brainstorm, /map-systems, /design-system), la arquitectura (/create-architecture, /architecture-decision), las historias y sprints (/create-stories, /dev-story, /story-done), la revisión (/design-review, /code-review, /balance-check), el QA (/qa-plan, /smoke-check) y el lanzamiento (/release-checklist, /patch-notes, /hotfix).

Y luego están las skills de equipo, que coordinan varios agentes sobre una misma funcionalidad: /team-combat, /team-narrative, /team-ui, /team-audio, /team-level, /team-qa… Le pides un sistema de combate y no responde un solo asistente, responde un grupo con diseñador de sistemas, programador de gameplay y QA.

El bucle central, en el modo más ligero, queda así:

/start → /setup-engine → /brainstorm → /create-stories → /dev-story ↔ /story-done

Una página de brief, unas historias, y a construir historia por historia.

¿Produce juegos o produce documentos? ¶

Es la pregunta que te harías al ver 62 plantillas de documentos. Y el README la contesta con una medición en lugar de con un ejemplo bonito.

Construyeron cuatro juegos a partir del mismo brief con distintos niveles de modes.rigor y contaron cuántos documentos escribía cada uno antes de la primera línea de código de juego. Estas son las dos filas que publica el README:

Todos acabaron con un juego que funcionaba y con tests. Después, dos revisores a ciegas y una sesión de juego con una persona real clasificaron la versión standard en último lugar.

Los 29 documentos de más compraron trazabilidad. No un juego mejor.

Una plantilla llena de procesos publicando un dato contra su propio proceso. Eso da confianza.

💡 Si solo te llevas una cosa: más documentación no es más calidad de juego. Sube el nivel de proceso cuando el proyecto lo pida, no por defecto.

Lanza el juego y lo mira ¶

La otra mitad de la pregunta es si lo que sale funciona. En un videojuego eso significa que alguien tiene que mirarlo: un test en verde no te dice que el menú se ha dibujado fuera de la pantalla.

Por eso una historia que cambia algo visible para el jugador no se cierra hasta que el juego se ha lanzado, se ha observado y se ha guardado una captura en production/qa/evidence/. Revisar que el código parsea no cuenta como ejecutarlo. Esto se aplica en todos los niveles de rigor, incluido minimal, donde los tests automáticos se pueden saltar pero mirar el juego no.

¿Cómo se ajusta cuánto proceso quieres? ¶

Todo se controla desde project.yaml, en la raíz del repo. Es la fuente única de verdad: motor, convenciones de nombres y un bloque modes que decide cuánto proceso impone cada skill. /start lo rellena por ti, así que rara vez lo vas a editar a mano.

La palanca que importa es modes.rigor, con tres valores:

• minimal (por defecto): velocidad de game jam. Sin GDD obligatorios, documentación escueta, evidencias de QA mínimas y revisión en solitario.
• standard: cinco secciones de GDD obligatorias, documentación equilibrada, evidencias de QA estándar y revisión ligera.
• full: las ocho secciones de GDD, documentación exhaustiva, evidencias completas en cada tipo de historia y revisión de todos los directores.

modes.rigor es una fachada sobre seis mandos internos: qué secciones de GDD se exigen (workflow), la densidad de la documentación, el nivel de QA, la granularidad de las historias, cuántos directores revisan tu trabajo (review_mode) y el tamaño del equipo. /start te pregunta una vez en lugar de seis.

¿Por qué minimal es el de serie? El README lo justifica con la medición de antes: el nivel pesado tarda más en llegar a código que funciona, no da un resultado mejor y tampoco ayuda cuando alguien nuevo entra al proyecto. Cuando tu juego crezca, /help y /gate-check te sugerirán subir de nivel.

¿Y si solo un sistema necesita más rigor? ¶

Para eso está system_overrides: tu sistema de combate recibe el tratamiento completo y el resto del proyecto sigue ligero. Y con testing.strict decides, por tipo de test, si una evidencia que falta bloquea la historia o solo avisa.

Y hay ajustes personales. review_mode y team.size se pueden sobrescribir por desarrollador en un project.local.yaml que está en el .gitignore. Todo se gestiona con /settings:

/settings                                  # ver la configuración efectiva
/settings modes.rigor=full                 # escribir en project.yaml (todo el equipo)
/settings --local modes.review_mode=solo   # escribir en project.local.yaml (solo tú)

Construye agentes con criterio

Entiende por dentro lo que hace un estudio de agentes: capas, guardarraíles y orquestación

Vas a recorrer los seis niveles de arquitectura de un agente, de las tools a los sistemas multiagénticos revisados por otro modelo, para que sepas qué pieza tocar cuando el equipo se descontrola.

Entrar a la masterclass →

Acceso con suscripción Web Reactiva Premium · 6 niveles de arquitectura, en directo

¿Quién decide: tú o los agentes? ¶

Tú. Y esto es lo que separa a CCGS de las demos de “la IA hace un juego sola”.

El repo no es un piloto automático. Cada agente sigue un protocolo de colaboración de cinco pasos:

1. Pregunta antes de proponer soluciones.
2. Presenta opciones, entre dos y cuatro, con pros y contras.
3. Tú decides.
4. Hace un borrador y te lo enseña antes de darlo por bueno.
5. Aprueba: nada se escribe sin tu visto bueno.

El CLAUDE.md del proyecto lo deja por escrito: los agentes tienen que preguntar “¿puedo escribir esto en [ruta]?” antes de usar Write o Edit, los cambios en varios ficheros necesitan aprobación del conjunto y no hay commits sin que tú lo pidas. Incluso hay una regla para las preguntas que ignoras: una pregunta saltada no es una respuesta, así que el agente no actúa y vuelve a preguntar.

¿Pesado? Un poco. Los modos de automatización guided y autonomous cambian parte de esas preguntas por velocidad.

¿Qué hacen los hooks? ¶

Los hooks son la red de seguridad que funciona sin que te acuerdes de ella. Algunos de los quince:

Atento al de lectura. Si un agente lee entero un GDD largo, se come una parte enorme del contexto; el hook le obliga a pedir solo la sección que necesita. En un estudio que vive de leer documentos, ese freno ahorra mucho.

Además, settings.json trae reglas de permisos que dejan ejecutar los tests sin preguntar y bloquean operaciones peligrosas como el force push, rm -rf o leer ficheros .env.

¿Qué son las reglas por ruta? ¶

Son estándares de código que se activan según la carpeta que edites. Un agente que toca src/gameplay/ tiene que usar valores guiados por datos y el delta time; uno que toca src/networking/ trabaja con servidor con autoridad y mensajes versionados. Y en prototypes/ las normas se relajan a cambio de un README con la hipótesis documentada: el código de usar y tirar se queda aislado y no se cuela en producción.

¿Se puede personalizar? ¶

Sí, y es la idea. El README insiste en que es una plantilla, no un framework cerrado: borra los agentes que no uses, edita sus prompts, ajusta las skills a tu proceso, crea reglas por ruta para tu estructura de carpetas o quédate con el set de Godot, Unity, Unreal o ninguno.

Para que tus cambios no rompan nada, existe studio-tests/: un sistema de QA para las propias skills y agentes, no para tu juego. Tiene un linter estructural con siete comprobaciones, rúbricas por categoría y specs de comportamiento:

/skill-test static [name]     # linter estructural
/skill-test spec [name]       # comprobaciones de comportamiento
/skill-improve [name]         # bucle probar-arreglar-reprobar

Si estás pensando en escribir tus propias skills, este enfoque de tests merece un vistazo aunque no vayas a hacer un juego en tu vida. Lo completas con las buenas prácticas para crear skills y tienes un método bastante serio.

¿Para quién tiene sentido y para quién no? ¶

¿Te va a servir a ti? Depende de lo que hagas.

Me quedo con ese último perfil. Aunque no hagas videojuegos, el repo es un catálogo de patrones para cualquier proyecto con agentes: protocolo de colaboración, delegación jerárquica, hooks que protegen el contexto, reglas por ruta, tests para skills. Lo puedes leer como quien lee el código de un framework para entender cómo se organiza algo grande.

🛡️ Antes de lanzarte con 49 agentes, revisa qué permisos y modos tienes activos. La plantilla viene con un modo que pregunta antes de actuar; si lo cambias a autónomo, entiende bien qué estás soltando.

También hay que ser honestos con sus límites. El desarrollo principal se hace en Windows 10 con Git Bash; los hooks están probados en macOS y Linux, pero el hook de notificaciones solo funciona en Windows y en el resto de sistemas no hace nada. Y 74 skills son muchas: la curva para saber cuál usar en cada momento existe, aunque /help y /start te la suavizan.

TL;DR ¶

• 🎮 Claude Code Game Studios es una plantilla MIT que convierte Claude Code en un estudio de videojuegos con 49 agentes, 74 skills, 15 hooks, 14 reglas y 62 plantillas.
• 🏗️ Los agentes se organizan en directores, jefes de departamento y especialistas, con sets propios para Godot 4, Unity y Unreal Engine 5.
• ⚙️ Se instala clonando el repo, abriendo claude en la raíz (no en src/) y lanzando /start.
• 📉 Su propia medición mostró que el modo standard escribió 30 documentos antes de la primera línea de código y acabó último en la valoración; por eso minimal es el modo por defecto.
• 🙋 No es un piloto automático: los agentes preguntan, dan opciones, enseñan borradores y no escriben nada sin tu permiso.

Preguntas frecuentes ¶

¿Qué es Claude Code Game Studios? ¶

Es una plantilla de código abierto para Claude Code que organiza una sesión como un estudio de videojuegos. Trae 49 agentes especializados, 74 skills con comandos /, 15 hooks de validación, 14 reglas de código por ruta y 62 plantillas de documentos. Tiene licencia MIT.

¿Cómo se instala Claude Code Game Studios? ¶

Clonas el repositorio con git clone https://github.com/Donchitos/Claude-Code-Game-Studios.git my-game, entras en la carpeta y ejecutas claude en la raíz del proyecto. Después lanzas /start para que te guíe según el punto del que partas. Necesitas Git, Claude Code, Python 3 y Bash; jq es recomendable.

¿Qué motores de videojuegos soporta? ¶

Trae sets de agentes para Godot 4, Unity y Unreal Engine 5, cada uno con un agente principal y subespecialistas (GDScript en Godot, DOTS en Unity, GAS y Blueprints en Unreal). Usas el de tu motor o ninguno.

¿Necesito pagar Opus para usar los 49 agentes? ¶

No del todo. Según el README, solo los tres directores piden Opus; el lead-programmer y quince especialistas declaran Sonnet, y los otros treinta heredan el modelo de tu sesión. La mayoría del estudio funciona con el modelo que ya uses.

¿Qué hace el comando /start? ¶

Es la puerta de entrada al proyecto. Te pregunta si partes sin idea, con un concepto vago, con un diseño claro o con un proyecto existente, te enseña lo que asume y te señala un único paso siguiente. Nunca ejecuta ese paso por ti.

¿Qué es modes.rigor y qué valor debo usar? ¶

Es el ajuste de project.yaml que decide cuánto proceso impone el estudio: minimal, standard o full. Controla seis mandos internos, como los GDD obligatorios, el nivel de QA o cuántos directores revisan. Empieza con minimal, que es el valor por defecto, y súbelo cuando el proyecto crezca.

¿Claude Code Game Studios crea el juego de forma autónoma? ¶

No. Está diseñado como colaborativo: cada agente pregunta, presenta entre dos y cuatro opciones, espera tu decisión, enseña un borrador y pide permiso antes de escribir. Los modos guided y autonomous reducen esas pausas si quieres más velocidad.

¿Por qué tengo que abrir Claude Code en la raíz del proyecto? ¶

Porque los hooks, las reglas de denegación y el modo de permisos que pregunta antes de actuar solo se cargan cuando Claude Code arranca en la carpeta que contiene CLAUDE.md y project.yaml. Si arrancas en src/ u otra subcarpeta, pierdes esas protecciones.

¿Funciona en macOS y Linux? ¶

Sí. Se desarrolla en Windows 10 con Git Bash, pero los hooks se prueban en macOS y Linux con patrones compatibles con POSIX. Solo el hook de notificaciones de escritorio se queda sin efecto fuera de Windows.

¿Puedo usar sus ideas en proyectos que no son videojuegos? ¶

Sí, y es uno de sus mejores usos. El protocolo de colaboración, la delegación jerárquica, los hooks que protegen el contexto, las reglas por ruta y el sistema studio-tests/ para probar skills son patrones que puedes llevarte a cualquier proyecto con agentes de IA.

Fuentes ¶

• Claude Code Game Studios en GitHub
• README del proyecto
• CHANGELOG del proyecto
• Documentación de Claude Code

🧨 Última oprtunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter