La configuración de entorno en cuatro partes de Claude Code: CLAUDE.md, Rules, Memory y Hooks

Thu, 23 Apr 2026 10:43:40 +0800

Si usas Claude Code durante un tiempo, pronto notas algo: el modelo importa, pero el entorno que le das, los límites que defines y las reglas que configuras importan igual.

Al principio, mucha gente se centra en “cómo escribo este prompt”. Pero cuando empiezas a usar Claude Code en serio, te importa más otra cosa:

¿Sabe quién eres?
¿Sabe cómo trabajas?
¿Sabe qué reglas no puede romper?
¿Sabe qué acciones requieren confirmación primero?
¿Puede recordar esos límites con el tiempo?

Lo que vuelve maduro a Claude Code no es solo la capacidad del modelo. Es que hay un sistema completo para convertir tu estilo de trabajo en estructura persistente. A alto nivel, ese sistema puede dividirse en cuatro capas:

CLAUDE.md
Rules
Memory
Hooks

Este artículo explica las cuatro.

Por qué la configuración de entorno importa más que prompts únicos

Puedes pensar en Claude Code como un asistente que contrataste.

El primer día no le dirías solo “ayúdame a hacer cosas”. Le darías un manual y explicarías:

quién eres
qué estilo de comunicación prefieres
qué acciones siempre requieren confirmación
qué errores ya ocurrieron y no deben repetirse
dónde están los documentos importantes del proyecto

Por eso, a largo plazo, la configuración de entorno suele importar más que un prompt aislado.

Un prompt resuelve “qué hacemos esta vez”. La configuración de entorno resuelve “cómo trabajamos cada vez desde ahora”.

Capa 1: `CLAUDE.md`

Empieza por la pieza básica. CLAUDE.md es esencialmente un archivo de texto.

Puedes escribir instrucciones para Claude, como:

quién eres
en qué trabajas
tus preferencias de comunicación
reglas obligatorias
contexto especial del proyecto actual
dónde están documentos o directorios importantes

Cada vez que Claude Code arranca, este documento se inyecta automáticamente en el contexto, así que el modelo lo leerá.

Suelo pensarlo como un “archivo de entendimiento compartido”, porque eso es: el acuerdo permanente entre tú y el modelo.

Qué poner en `CLAUDE.md`

Lo mejor para CLAUDE.md suele ser:

identidad y contexto de trabajo
preferencias de tono y salida
reglas globales de comportamiento
contexto de proyecto que aparece a menudo
errores comunes y cómo evitarlos

Por ejemplo:

tu zona horaria
si permites que el modelo envíe emails o mensajes directamente
qué acciones son irreversibles
tus hábitos con documentos y archivos
prácticas de seguridad y límites sobre información sensible

Un principio muy importante: mantenerlo conciso

Un principio clave para CLAUDE.md: mantenlo lo más conciso posible.

La razón es simple: se inyecta en contexto cada vez.

Si crece demasiado, ocupa demasiado espacio de contexto y diluye la información importante. El modelo no lo ignora, pero su atención se dispersa, así que es más probable que pase por alto reglas críticas.

La recomendación oficial suele ser mantenerlo por debajo de 400 líneas.

Mi hábito es aún más conservador: intento mantenerlo por debajo de 200 líneas.

Alcances comunes de `CLAUDE.md`

En la práctica, CLAUDE.md puede existir en distintos niveles, y esos niveles determinan su alcance.

1. Nivel de usuario

Es el nivel global.

Vive en tu entorno de máquina y aplica a todos los proyectos locales.

Es buen lugar para:

información de identidad
preferencias generales de comunicación
hábitos que aplican a todos los proyectos
reglas globales de seguridad

2. Nivel de proyecto

Es el nivel del proyecto.

Está dentro de un directorio de proyecto concreto y solo aplica a ese proyecto.

Es buen lugar para:

contexto específico del proyecto
reglas que solo tienen sentido ahí
explicación de la estructura de directorios
entradas a documentos clave del proyecto

Cómo decidir qué nivel usar

La regla es simple:

Si lo escrito seguiría siendo verdad en otro proyecto, ponlo en el user level.

Si deja de ser verdad al cambiar de proyecto, ponlo en el project level.

Cómo escribir la primera versión

Hay dos formas comunes de empezar:

1. Usar `/init`

Puedes ejecutar /init directamente en la terminal y dejar que Claude escanee el proyecto para generar un CLAUDE.md básico.

2. Dejar que Claude te ayude a organizarlo

También puedes pedirle que busque cómo otras personas estructuran CLAUDE.md, que te haga preguntas según tu situación y organice una versión que encaje contigo.

Un hábito práctico

Al colaborar con Claude, cuando notes algo que debe recordarse o que no debe fallar otra vez, puedes pedirle que lo escriba en CLAUDE.md.

Antes de hacerlo, decide:

¿es una regla global?
¿o solo del proyecto actual?

No lo metas todo en un único archivo.

Capa 2: `Rules`

La siguiente capa es Rules.

La diferencia principal con CLAUDE.md no es el formato, sino cómo se carga.

CLAUDE.md se lee sin importar qué haces.

La ventaja de Rules es que pueden cargarse condicionalmente.

Una regla puede cargarse solo para ciertas rutas, archivos, herramientas o escenarios.

Por qué importa la carga condicional

Porque el espacio de contexto siempre es escaso.

Si todas las reglas entran al contexto todo el tiempo:

el modelo carga más overhead
las reglas realmente importantes se entierran

El valor de cargar reglas bajo demanda es que el modelo ve la información correcta en el momento correcto.

Cuándo mover reglas desde `CLAUDE.md` a `Rules`

Suelen darse dos situaciones:

1. `CLAUDE.md` se volvió demasiado largo

Si empieza a pasar de 200 líneas, sigue creciendo y lo importante se diluye, toca separar reglas.

2. Algunas reglas solo aplican a rutas concretas

Si sabes que ciertas reglas solo tienen sentido para ciertos archivos, por ejemplo:

reglas solo para scripts Python
reglas solo para un directorio de hooks
reglas solo para un subproyecto

entonces pertenecen más naturalmente a Rules.

Dónde encajan mejor `Rules`

El caso típico es “situación específica, ruta específica, tipo de archivo específico”.

Por ejemplo:

convenciones al manejar hooks
reglas de código para cierto tipo de scripts
formas de trabajo que solo aplican bajo un directorio

Mantener ese contenido en CLAUDE.md suele no ser rentable.

Capa 3: `Memory`

La tercera capa es Memory.

Como CLAUDE.md y Rules, también entra al contexto del modelo, pero su diferencia central es:

CLAUDE.md es algo que defines deliberadamente.

Memory se parece más a notas que Claude escribe para sí mismo durante la colaboración.

Qué entra en `Memory`

Cuando Claude juzga que algo vale la pena recordar o conservar por un tiempo, escribe esa información en Memory.

Ejemplos comunes:

una forma de trabajar que corregiste
una preferencia nueva
estado temporal del proyecto actual
algo que no terminaste hoy y debes continuar mañana
con quién colaboraste recientemente
contexto personal aparecido hace poco

Es conocimiento dinámico más que política de largo plazo.

Diferencia con las dos primeras capas

Una distinción simple:

CLAUDE.md / Rules: reglas explícitas, de largo plazo y tipo política
Memory: contexto temporal, dinámico y recién aprendido

Si algo solo importa unos días o cambia con frecuencia, suele pertenecer a Memory, no a una regla permanente.

`Memory` también puede escribirse manualmente

Aunque Memory puede mantenerse automáticamente, también puedes decirle explícitamente:

recuerda lo que debo hacer mañana
recuerda a quién debo hacer seguimiento
recuerda el hito clave de este proyecto este mes

También puedes usar /memory para ver, editar o borrar memorias.

Capa 4: `Hooks`

La última y más avanzada capa es Hooks.

Todo lo anterior, incluido CLAUDE.md, Rules y Memory, sigue siendo guía en lenguaje natural.

Escribes reglas y el modelo normalmente las sigue, pero primero debe interpretarlas.

Mientras la regla viva en lenguaje natural, quedan problemas:

el modelo puede pasarla por alto
demasiadas reglas diluyen atención
puede decidir que no es suficientemente importante

Qué son realmente `Hooks`

Hooks ya no son instrucciones en lenguaje natural. Son scripts.

Son lógica de enforcement a nivel programa, disparada por eventos.

Cuando ocurre cierto evento, esa lógica corre. No se salta porque el modelo la ignore.

Ese es su valor:

convierten “debería seguir esto” en “debe ejecutarse esto”.

Cuándo subir algo a `Hooks`

Si una regla ya está escrita en CLAUDE.md o Rules, pero Claude todavía falla ocasionalmente, y el coste de fallar es real, probablemente debería ser un Hook.

En simple:

comportamiento de bajo riesgo: reglas
comportamiento de alto riesgo: Hooks

Escenarios típicos

Ejemplos obvios:

exigir confirmación antes de enviar un email
exigir confirmación antes de enviar mensajes Slack, Outlook o Gmail
interceptar borrados peligrosos de archivos
bloquear fugas de contraseñas o API keys

Si solo están escritas como reglas, el modelo puede equivocarse algún día. Si son Hooks, el evento se intercepta cada vez.

Puntos de disparo comunes

Hooks pueden engancharse en distintas etapas:

inyectar recordatorios al inicio de una conversación
revisar condiciones antes de ejecutar una herramienta
validar resultados después de ejecutar una herramienta

No necesitas conocer toda la terminología formal. A menudo basta con describir claramente el requisito y preguntar a Claude si debería convertirse en hook.

También puedes usar /hook para inspeccionar hooks configurados.

Una forma práctica de empezar

Recomiendo este orden:

Paso 1: usa `/init` para generar un `CLAUDE.md` básico

No intentes escribir un enorme documento completo desde el inicio.

Deja que Claude escanee el proyecto y genere un punto de partida, luego itera.

Paso 2: añade cosas mientras trabajas

Cuando notes:

esto debe recordarse
este error no debe repetirse
esta preferencia aplicará siempre

pide a Claude que lo añada a CLAUDE.md.

Paso 3: mueve cosas a `Rules` cuando `CLAUDE.md` crezca

Cuando CLAUDE.md se alarga y el modelo no sigue todo con fiabilidad:

¿qué reglas son globales?
¿cuáles solo aplican a ciertas rutas?

Mueve las segundas a Rules para carga condicional.

Paso 4: convierte reglas de alto riesgo en `Hooks`

Si una regla sigue fallando y el coste de fallar es alto, no te quedes en lenguaje natural. Conviértela en Hooks.

Ahí el “recordatorio” se vuelve “enforcement”.

Paso 5: deja que `Memory` maneje estado temporal

Para cosas que expiran, cambian a menudo o no son política permanente, no lo metas todo en CLAUDE.md.

Es más limpio dejar que Memory guarde:

progreso actual del proyecto
colaboradores recientes
preferencias recién añadidas
planes y to-dos de corto plazo

Qué debería guardar cada capa

Modelo mental rápido:

CLAUDE.md: entendimiento compartido de largo plazo, instrucciones globales, contexto base del proyecto
Rules: reglas especializadas cargadas por ruta o escenario
Memory: conocimiento dinámico, estado temporal, cosas aprendidas recientemente
Hooks: enforcement programático para acciones de alto riesgo

Cierre

Mucha gente trata Claude Code como “una interfaz de chat que escribe código”. Pero al usarlo a fondo, se siente más como una estación de trabajo inteligente de largo plazo.

La clave no es solo cómo formulas cada instrucción. Es si le diste un entorno estable, claro y acumulativo.

Cuando construyes estas cuatro capas:

CLAUDE.md
Rules
Memory
Hooks

la calidad de colaboración suele mejorar mucho.

Porque ya no reexplicas desde cero quién eres, cómo trabajas y qué no debe pasar en cada sesión. Convertiste esas cosas en parte del entorno.

Ese es el paso clave para convertir un modelo fuerte en una herramienta madura.

CLAUDE.md on KnightLi Blog

La configuración de entorno en cuatro partes de Claude Code: CLAUDE.md, Rules, Memory y Hooks

Por qué la configuración de entorno importa más que prompts únicos

Capa 1: CLAUDE.md

Qué poner en CLAUDE.md

Un principio muy importante: mantenerlo conciso

Alcances comunes de CLAUDE.md

1. Nivel de usuario

2. Nivel de proyecto

Cómo decidir qué nivel usar

Cómo escribir la primera versión

1. Usar /init

2. Dejar que Claude te ayude a organizarlo

Un hábito práctico

Capa 2: Rules

Por qué importa la carga condicional

Cuándo mover reglas desde CLAUDE.md a Rules

1. CLAUDE.md se volvió demasiado largo