Crear tu propio ecosistema

El junior ya está en casa. Ahora móntale el puesto de trabajo#

En el capítulo anterior conociste las cuatro piezas con las que se construye un asistente que ya conoce tu proyecto: el CLAUDE.md, los skills, los MCPs y las memorias. Las viste por separado.

En este capítulo las combinas. El resultado es lo que llamamos un ecosistema: el conjunto de piezas configuradas para que el asistente conozca tu proyecto y tu forma de trabajar antes de que abras la boca.

La diferencia entre un chatbot genérico y un compañero a medida es exactamente eso: el ecosistema. Piénsalo como montar el puesto de trabajo del junior. No le basta con saber que existe el proyecto; necesita tener a mano las herramientas, conocer las normas y saber cómo se hacen las cosas aquí.

Lo construiremos capa a capa, aplicado al Team Builder.

Capa 1: el CLAUDE.md, la base de todo#

El CLAUDE.md es lo primero que el asistente lee al arrancar en tu proyecto. Si no existe, trabaja en el vacío y propone soluciones genéricas que no respetan tu stack ni tus decisiones.

Para el Team Builder, este sería un punto de partida razonable:

# Team Builder — reglas del proyecto

## Stack

# El frontend usa React con Vite
# Los estilos son siempre Styled Components, nunca CSS modules ni librerías de UI
# TypeScript en modo estricto
# Tests con Vitest

## Datos

# Los héroes viven en src/data/heroes.ts
# Cada héroe tiene: nombre, rol, partidas, victorias
# Roles posibles: Tanque, Daño, Apoyo

## Convenciones

# Commits en castellano, con prefijo feat/fix/refactor
# Componentes siempre menores de 200 líneas; la lógica va en hooks
# Sin dependencias externas salvo las ya instaladas

Fíjate en lo que hace: le dice al asistente el stack, dónde viven los datos y cómo trabajáis. Desde la primera línea de la sesión, el asistente ya sabe cosas que sin este fichero tendría que preguntarte o adivinar.

Hay dos niveles de CLAUDE.md:

• El global (~/.claude/CLAUDE.md): aplica en todos tus proyectos. Útil para normas de empresa o preferencias personales que se repiten en todos los repositorios.
• El del proyecto (en la raíz o en una subcarpeta): matiza o complementa el global para ese repositorio concreto.

Los dos se leen. El del proyecto no cancela el global: los suma. Así puedes tener “nunca añadas Co-Authored-By” en el global y “en este proyecto los commits en inglés” en el del proyecto.

Capa 2: los skills, los flujos empaquetados#

Una vez el asistente conoce el contexto, el siguiente paso es automatizar los flujos que repites. Si cada vez que añades un héroe tardas los primeros dos minutos explicando lo mismo, un skill lo resuelve.

# skill: añade-héroe
# Descripción: añade un héroe al fichero de datos del Team Builder
#
# Pasos:
#   1. Abre src/data/heroes.ts
#   2. Añade el objeto del héroe con los campos: nombre, rol, partidas, victorias
#   3. Comprueba que no hay duplicados por nombre
#   4. Actualiza el tipo HeroeData si el campo nuevo lo requiere
#   5. Guarda el fichero
#
# Ejemplo de uso:
#   /añade-héroe nombre='Tracer' rol='Daño' partidas=120 victorias=84

Con este skill, /añade-héroe ya encapsula todo el flujo. Sin él, cada sesión empieza repitiendo los pasos 1-5 de memoria.

Los skills también se pueden combinar. Si tienes uno que añade héroes y otro que formatea los commits, un flujo de “añade héroe y genera el commit” puede invocar los dos en secuencia.

Capa 3: las memorias, lo que persiste entre sesiones#

Las memorias guardan hechos dinámicos: decisiones que tomasteis, contexto que cambió, preferencias que no conviene meter en el CLAUDE.md porque son temporales o específicas de una fase.

Para el Team Builder, las memorias útiles son distintas de las normas del CLAUDE.md:

# memory: decisiones-team-builder

# Sprint actual: fase de filtrado por rol
# Decidimos el 2026-06-10 que el filtro no colapsa en móvil; permanece visible
# El color de acento actual es #b8336a; no cambiar hasta revisar con el equipo
# Pendiente: añadir el héroe 'Illari' cuando se confirmen sus stats

Esto no pertenece al CLAUDE.md (es demasiado específico del momento), pero sí queremos que el asistente lo recuerde la próxima vez que abramos una sesión. Las memorias cubren ese espacio.

La diferencia práctica: el CLAUDE.md contiene lo que siempre es verdad en el proyecto; las memorias contienen lo que es verdad ahora.

Capa 4: un MCP, cuando necesitas conectar algo externo#

Un MCP tiene sentido cuando el asistente necesita hacer algo que no puede hacer por sí solo: consultar una base de datos, controlar el navegador, llamar a una API interna.

Para el Team Builder en su estado actual, puede que no lo necesites. Pero cuando el proyecto crezca y los héroes pasen a vivir en una base de datos, querrás que el asistente pueda consultarla directamente sin que tengas que copiarle los datos a mano.

El momento de añadir un MCP es claro: cuando te encuentras copiando y pegando información de una herramienta externa al chat, o cuando el asistente te pide datos que ya existen en algún sitio pero que no puede leer. Ahí es donde un servidor MCP elimina el paso manual.

Así se vería esa configuración en los settings de Claude Code, apuntando a una base de datos SQLite del proyecto:

{
  "mcpServers": {
    "sqlite": {
      "command": "npx",
      "args": ["@modelcontextprotocol/server-sqlite", "./data/team-builder.db"]
    }
  }
}

Con esa configuración, el asistente puede consultar la base de datos del Team Builder directamente; sin ella, tendrías que copiarle los datos a mano cada vez que los necesita.

La ruta exacta, el nombre del paquete y la versión disponible dependen del servidor MCP concreto; consulta su documentación antes de configurarlo.

Cómo se refuerzan las piezas entre sí#

Las cuatro piezas no son alternativas: son capas. Cada una cubre una necesidad distinta y se refuerzan:

• El CLAUDE.md establece el terreno de juego: el asistente sabe desde el primer momento qué stack usáis, dónde viven los datos y qué convenciones seguís.
• Los skills eliminan la fricción de los flujos repetibles: no hay que explicar nada, solo invocar el nombre.
• Las memorias llevan el contexto vivo de una sesión a otra: decisiones recientes, trabajo pendiente, cosas que cambian.
• Los MCPs abren el acceso a lo que está fuera: bases de datos, APIs, herramientas del sistema.

Puedes empezar solo con el CLAUDE.md y añadir las demás piezas cuando las necesites. No hace falta montar el ecosistema completo desde el primer día. Lo que sí conviene hacer desde el primer día es escribir el CLAUDE.md: es la pieza con mayor retorno inmediato.

Cuándo usar cada pieza#

Antes de añadir algo al ecosistema, la pregunta útil es: ¿qué problema concreto estoy resolviendo?

Una guía rápida:

• ¿Tengo que explicarle al asistente el stack, las convenciones o dónde viven los datos? CLAUDE.md.
• ¿Tengo un flujo que repito varias veces por semana y siempre explico lo mismo? Skill.
• ¿Hay una decisión reciente o un contexto temporal que quiero que recuerde la próxima sesión? Memoria.
• ¿Necesito que el asistente acceda a algo externo que no puede leer por sí solo? MCP.

Si ninguna pregunta dispara, probablemente no necesitas añadir nada todavía. El ecosistema crece con el proyecto: empieza pequeño y añade piezas cuando la ausencia de una te cueste tiempo real.

Comprueba lo que sabes#

Tu turno#

En el capítulo anterior añadiste un CLAUDE.md al Team Builder y, opcionalmente, tu primer skill. Ahora vas a ampliar ese ecosistema con una pieza más.

Este ejercicio parte directamente de lo que hiciste en el capítulo 3. No empieces desde cero: abre lo que tienes y añade encima.

Lo que vas a añadir:

Elige la pieza que más sentido tenga para tu situación actual:

Opción A — Un segundo skill (si en el cap. 3 creaste solo el CLAUDE.md o un skill muy básico):

Piensa en otro flujo que repitas. Puede ser:

• Ejecutar los tests del proyecto y resumir qué ha fallado.
• Crear un componente nuevo respetando las convenciones del CLAUDE.md.
• Revisar que un Pull Request respeta el estilo de commits del equipo.

Escribe el skill en .claude/skills/ con el mismo formato que el del capítulo 3: nombre, descripción, pasos y un ejemplo de uso.

Opción B — Tu primera memoria (si ya tienes CLAUDE.md y al menos un skill):

Crea un fichero de memoria en .claude/memory/ que guarde algo relevante del estado actual de tu Team Builder:

• Una decisión reciente que tomaste sobre el diseño o la arquitectura.
• Algo que tienes pendiente para la próxima sesión.
• Una restricción temporal que no encaja en el CLAUDE.md porque puede cambiar.

No inventes: usa algo real del proyecto, aunque sea pequeño.

Lo que debes comprobar al terminar:

• El skill o la memoria están en la carpeta correcta y el asistente los detecta (puedes pedirle que te diga qué skills tiene disponibles o que lea tu memoria).
• El contenido es concreto y específico del Team Builder, no genérico.
• Si añadiste un skill, prueba a invocarlo una vez para verificar que el flujo funciona como esperabas.

No hay solución única: el ecosistema es tuyo y depende de cómo trabajas. Lo que importa es que la pieza que añades resuelve un problema real, no que el fichero exista por existir.