learning-front

Transversal · Desarrollo asistido por IA

Skills, rules, MCPs, plugins y memorias

Las piezas con las que construyes un asistente que ya conoce tu proyecto y tu forma de trabajar antes de que abras la boca.

En el capítulo anterior instalaste a ese júnior al lado: tiene acceso a tus ficheros, puede leer tu código y ejecutar comandos cuando le das permiso. Pero si le preguntas cómo añadir una tarjeta de héroe al Team Builder sin más contexto, responderá con lo más probable estadísticamente, no con lo que encaja en tu proyecto.

Estas son las cinco piezas con las que le enseñas tu casa.

Las reglas del proyecto: CLAUDE.md#

La primera pieza es también la más importante. CLAUDE.md es un fichero de texto que vive en la raíz de tu proyecto y que el asistente lee al arrancar. Ahí le explicas quién eres, cómo trabajas y qué no debe hacer.

Sin CLAUDE.md, el asistente trabaja en el vacío. Con él, arranca con contexto.

El contraste que lo deja claro#

Imagina que le pides al asistente lo mismo en dos situaciones distintas:

El encargo: “Añade una tarjeta para mostrar el héroe Tracer con su rol, partidas y victorias.”

Sin CLAUDE.md, el asistente responde con lo más probable en el mundo web de 2026:

// Respuesta genérica (sin contexto de proyecto)
import React from 'react';
import { Card, Badge } from 'bootstrap-react';

// El asistente no sabe qué usáis: propone su librería habitual
export function HeroCard({ nombre, rol, partidas, victorias }) {
  return (
    <Card className="shadow-sm p-3">
      <h3>{nombre}</h3>
      <Badge bg="secondary">{rol}</Badge>
      <p>Partidas: {partidas} | Victorias: {victorias}</p>
    </Card>
  );
}

Técnicamente correcto. Pero usa Bootstrap, React y JSX cuando el proyecto es HTML vanilla con Styled Components. El asistente no mintió: simplemente no sabía.

Con un CLAUDE.md como este:

# CLAUDE.md

# Proyecto
Team Builder de Overwatch. Muestra héroes con su rol, partidas y victorias.

# Stack
HTML semántico, CSS con Styled Components, JavaScript vanilla sin bundler.
Datos de héroes en data/heroes.js.

# Convenciones
- Componentes de menos de 200 líneas.
- Sin librerías de componentes (sin Bootstrap, sin Material UI).
- Nombres de variables en castellano cuando describen el dominio.
- Nada de React por ahora: todo en JS vanilla.

La respuesta cambia:

// Respuesta con CLAUDE.md (respeta el stack y las convenciones)
import { styled } from 'styled-components';
import { heroes } from '../data/heroes.js';

// El asistente sabe que usáis Styled Components y datos en ese fichero
const Tarjeta = styled.article`
  border-radius: 0.75rem;
  padding: 1rem;
  background: #fff;
  box-shadow: 0 2px 10px rgba(28, 27, 34, 0.07);
`;

// La función usa JS vanilla, no JSX ni React
export function renderHéroe(héroe) {
  const tarjeta = document.createElement('article');
  tarjeta.className = 'tarjeta-heroe';
  tarjeta.innerHTML = `
    <h3>${héroe.nombre}</h3>
    <span class="rol">${héroe.rol}</span>
    <p>${héroe.partidas} partidas &mdash; ${héroe.victorias} victorias</p>
  `;
  return tarjeta;
}

El mismo encargo, dos respuestas. La diferencia no está en el modelo: está en la información que tiene.

¿Y qué pasa si no tienes CLAUDE.md? El asistente te propone algo genérico que luego tienes que reescribir tú. Pierdes exactamente el tiempo que querías ganar. Lo que el asistente no sabe, lo inventa con lo más probable.

Los skills: flujos de trabajo empaquetados#

Un skill es una capacidad reutilizable que el asistente puede invocar. No le explicas el flujo cada vez: lo defines una vez, le das un nombre, y cuando lo necesitas lo pides por ese nombre.

Ejemplo concreto para el Team Builder: tienes un flujo que repites cada vez que añades un héroe nuevo.

# skill: añade-héroe
# Descripción: añade un héroe al fichero de datos del Team Builder
# Pasos:
#   1. Abre data/heroes.js
#   2. Añade el nuevo héroe al array con los campos: nombre, rol, partidas, victorias
#   3. Comprueba que no hay héroes duplicados por nombre
#   4. Guarda el fichero
# Uso: /añade-héroe nombre='Tracer' rol='Daño' partidas=120 victorias=84

Sin el skill, cada vez que añades un héroe tienes que explicarle dónde están los datos, qué formato usa, qué campos tiene. Con el skill, escribes /añade-héroe y el flujo se ejecuta.

¿Y qué pasa si no tienes el skill? Que cada vez que lo necesitas pierdes los primeros minutos de la sesión explicándole lo que ya sabes. El skill convierte un flujo repetible en una invocación de una palabra.

Los MCPs: el asistente conectado al mundo exterior#

Un MCP (Model Context Protocol) es un estándar para conectar el asistente a herramientas y datos externos. Un servidor MCP expone acciones que el asistente puede usar durante la sesión: consultar una API, leer una base de datos, controlar el navegador.

Ejemplo para el Team Builder: imagina que tienes una API de estadísticas reales de partidas.

# Servidor MCP: estadísticas del Team Builder
# Expone las siguientes acciones al asistente:
#
# get_heroe_stats(nombre)
#   Devuelve las estadísticas actuales de un héroe desde la API
#
# get_top_heroes(rol, limite)
#   Devuelve los N héroes con más victorias en ese rol
#
# update_victorias(nombre, nuevas_victorias)
#   Actualiza el recuento de victorias de un héroe en la fuente de datos

Con este servidor MCP activo, puedes pedirle al asistente: “Actualiza las victorias de Tracer con los datos de la API.” El asistente llama a get_heroe_stats('Tracer'), recibe los datos reales y los usa para escribir el código de actualización.

Sin el MCP, tendrías que copiar los datos de la API, pegarlos en el chat y explicarle qué hacer con ellos. El MCP hace que el asistente pueda consultar la fuente directamente.

Un MCP no es código que el asistente escribe: es una conexión a una herramienta externa que ya existe. Lo volátil (cómo declarar un servidor MCP, qué fichero de configuración usa) cambia con las versiones; la doc oficial (enlazada en la pestaña Fuentes) tiene los pasos exactos.

Los plugins: empaquetar y compartir#

Un plugin agrupa varias piezas (skills, comandos, configuración) para instalarlas juntas. Es la unidad de distribución: en vez de copiar skills sueltos de un proyecto a otro, empaquetas todo en un plugin y lo instalas con un comando.

Ejemplo: podrías tener un plugin team-builder-dev que incluya el skill de añadir héroes, la configuración de las rutas de datos y un comando para verificar el formato de los ficheros. Lo instalas en un proyecto nuevo y el asistente arranca con todo ese contexto.

¿Y qué pasa si no tienes plugins? Que cada proyecto nuevo empieza de cero: copias skills a mano, repites la configuración, vuelves a explicarle las mismas convenciones. El plugin convierte ese trabajo repetido en un solo paso.

Las memorias: lo que el asistente recuerda entre sesiones#

Las memorias son hechos que el asistente guarda entre sesiones. No son código: son contexto que persiste para que no tengas que repetírselo.

Ejemplo práctico: en la sesión del martes decidisteis que los datos de héroes irían en data/heroes.js separados del HTML. El miércoles abres una nueva sesión. Sin memorias, el asistente no sabe eso: propone poner los datos en el HTML de nuevo. Con la memoria guardada, arranca sabiendo que ya lo decidisteis.

# Memoria guardada tras la sesión del martes:
#
# Decisión: los datos de héroes van en data/heroes.js, no incrustados en el HTML.
# Motivo: el equipo quiere poder actualizar los datos sin tocar la vista.
# Fecha: 2026-06-24

¿Y qué pasa si no guardas esa memoria? Que el asistente no puede respetar una decisión que no conoce. Vuelve a proponer lo que parece más probable. Tú corriges. Pierdes el tiempo de nuevo.

Las memorias son la diferencia entre un asistente que aprende de tu proyecto con el tiempo y uno que empieza de cero en cada conversación.

El patrón que une las cinco piezas#

Vuelve a la metáfora del capítulo anterior: el asistente es ese júnior rapidísimo con memoria enorme pero sin criterio ni contexto. Estas cinco piezas son la forma de enseñarle tu casa:

  • CLAUDE.md: el manual de incorporación. “Esto es el proyecto, así trabajamos, esto no hagas.”
  • Skills: los procedimientos estándar. “Cuando añadas un héroe, sigue estos pasos.”
  • MCPs: las llaves de las herramientas. “Puedes consultar esta API para los datos reales.”
  • Plugins: el kit completo. “Todo lo que necesitas para este tipo de proyecto, en un paquete.”
  • Memorias: la agenda de decisiones. “Lo que ya hemos decidido, para no volver a discutirlo.”

Sin ninguna de estas piezas, el júnior arranca cada día sin saber dónde trabaja. Con ellas, en el momento en que abres la sesión ya sabe más de tu proyecto que un contratista al que le acabas de mandar el repositorio.

Comprueba lo que sabes#

Pregunta 1 de 8

¿Cuál es el propósito principal de un fichero CLAUDE.md en la raíz de un proyecto?

Tu turno#

Este ejercicio se hace en local, sobre tu proyecto Team Builder.

Objetivo: escribir un CLAUDE.md mínimo que le dé al asistente el contexto de tu proyecto, y comprobar la diferencia en sus respuestas.

Pasos:

  1. Abre la carpeta de tu proyecto Team Builder en el editor.

  2. Crea un fichero CLAUDE.md en la raíz del proyecto. Incluye al menos estas secciones:

# CLAUDE.md

# Proyecto
[Describe en dos líneas qué hace el Team Builder]

# Stack
[Lista las tecnologías que usas: HTML, CSS, JS, librerías si las hay]

# Dónde están los datos
[Ruta al fichero o la variable donde guardas los héroes]

# Convenciones
[Al menos dos normas que el asistente debe respetar:
por ejemplo, sin librerías de componentes, o nombres en castellano]

  1. Con el CLAUDE.md creado, pídele al asistente: “Añade un héroe nuevo al Team Builder: Mercy, rol Apoyo, 90 partidas y 67 victorias.” Fíjate en si respeta el stack y las convenciones que pusiste.

  2. Si la respuesta no respeta algo que pusiste en el CLAUDE.md, ajústalo y vuelve a probar. Ese ciclo de afinar el fichero hasta que el asistente entiende tu proyecto es exactamente lo que hace un desarrollador con experiencia.

No hay solución correcta única. El CLAUDE.md depende de tu proyecto. El objetivo es ver la diferencia entre “el asistente en el vacío” y “el asistente que conoce tu casa”.