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.