Qué son las reglas de Claude Code
La documentación de memoria de Anthropic las presenta así: "Para proyectos más grandes, puedes organizar las instrucciones en múltiples archivos utilizando el directorio .claude/rules/. Esto mantiene las instrucciones modulares y más fáciles de mantener para los equipos".
Una regla es un archivo markdown. Lo colocas en el directorio .claude/rules/ de tu proyecto, un tema por archivo, con un nombre que indique lo que cubre, como testing.md o api-design.md. "Todos los archivos .md se descubren recursivamente, por lo que puedes organizar las reglas en subdirectorios como frontend/ o backend/".
Existen dos tipos:
- Reglas sin frontmatter
paths. Estas se cargan al inicio de cada sesión. - Reglas con alcance de ruta (path-scoped). Estas tienen un campo
pathsy se cargan solo cuando Claude trabaja con un archivo que coincide.
La documentación resume el compromiso en una nota: "Las reglas se cargan en el contexto en cada sesión o cuando se abren archivos coincidentes. Para instrucciones específicas de tareas que no necesitan estar en el contexto todo el tiempo, usa skills en su lugar, que solo se cargan cuando las invocas o cuando Claude determina que son relevantes para tu prompt".
Cuándo se carga una regla sin paths
Una regla sin el campo paths se comporta como parte de las instrucciones de tu proyecto. "Las reglas sin frontmatter paths se cargan al inicio con la misma prioridad que .claude/CLAUDE.md ".
Eso convierte a las reglas sin alcance en una forma de dividir un CLAUDE.md largo sin cambiar lo que Claude ve. El contenido se sigue cargando en cada sesión; simplemente es más fácil de mantener en archivos separados.
Cuándo se carga una regla con alcance de ruta
Una regla con alcance de ruta comienza con un frontmatter YAML que enumera patrones glob:
---
paths:
- "src/api/**/*.ts"
---
- Todos los endpoints de la API deben incluir validación de entrada
- Usar el formato de respuesta de error estándarLa documentación es específica sobre el activador: "Una regla con alcance de ruta se carga cuando Claude utiliza las herramientas Read, Write o Edit en un archivo coincidente". También se carga cuando Claude visualiza un archivo coincidente con un comando Bash que cuente como lectura, como cat o head en un solo archivo, y funciona a través de una ruta con enlace simbólico (symlink) al directorio del proyecto.
Se derivan dos consecuencias:
- Mencionar un archivo no es suficiente. La regla se carga cuando Claude lee, escribe o edita un archivo coincidente, no cuando nombras uno en tu prompt.
- La regla no está ahí al principio. Hasta que Claude toca un archivo coincidente, la regla no está en su contexto.
Cómo se comparan los patrones
Los patrones son relativos al directorio base de la regla. Para las reglas del proyecto, es el directorio que contiene la carpeta .claude de la regla. Para las reglas a nivel de usuario, es el directorio de trabajo principal de la sesión.
Puedes enumerar varios patrones y usar expansión de llaves, como src/**/*.{ts,tsx}. La expansión de llaves tiene un presupuesto: toda la lista de paths de una regla comparte "un presupuesto de 1,000 patrones expandidos y 4 MiB", y un patrón que lo supere se usará sin expandir, por lo que sus llaves no coincidirán con ningún archivo.
Los corchetes son sintaxis glob. Un patrón con un [ que no pueda leerse como una expresión de corchetes es inválido y no coincide con nada, aunque los otros patrones de la regla sigan funcionando. Para coincidir con un [ literal, escápalo.
Los worktrees son un error común. La documentación dice que para que las reglas con alcance de ruta se carguen para archivos en un git worktree hermano, debes iniciar Claude Code en ese worktree o mover la sesión allí con /cd.
Qué puede contener el frontmatter
Solo importa un campo. "paths es el único campo que Claude Code lee de una regla; cualquier otro campo se ignora sin error". Claude Code elimina el frontmatter antes de cargar la regla, por lo que no ocupa contexto.
Si el YAML no se analiza correctamente, la regla no falla silenciosamente. Claude Code "ignora el frontmatter y carga la regla como si no tuviera paths ". Un error tipográfico en el frontmatter convierte una regla con alcance en una que se carga en cada sesión. Ejecuta claude --debug para ver el error de análisis.
Reglas a nivel de usuario
Las reglas no son solo por proyecto. "Las reglas personales en ~/.claude/rules/ se aplican a cada proyecto en tu máquina". Son adecuadas para preferencias que no están ligadas a una sola base de código.
El orden importa cuando las reglas de usuario y de proyecto no coinciden. "Claude Code carga las reglas de nivel de usuario antes que las del proyecto, por lo que una regla de proyecto aparece más tarde en el contexto de Claude que una regla de usuario. Ningún conjunto anula al otro: si una regla de usuario y una de proyecto entran en conflicto, Claude puede seguir cualquiera de las dos, así que mantén ambas consistentes". Nuestra guía para reconciliar capas de CLAUDE.md en conflicto cubre cómo encontrar esos conflictos.
Compartir reglas con enlaces simbólicos
El directorio .claude/rules/ admite enlaces simbólicos, por lo que un equipo puede mantener un conjunto de reglas y enlazarlo en varios proyectos. Si un enlace simbólico apunta fuera de tu directorio de trabajo, Claude Code lo trata como una importación externa: las reglas enlazadas no se cargan hasta que apruebes las importaciones externas para el proyecto, y después de eso, solo se cargan las que no tienen un campo paths. Los enlaces simbólicos a rutas de red no se cargan en absoluto.
Reglas vs. CLAUDE.md
Ambos son instrucciones que tú escribes. Difieren en cómo se encuentran y cuándo se cargan.
| CLAUDE.md | Reglas en .claude/rules/ | |
|---|---|---|
| Ubicación | Directorio de trabajo, directorios superiores y subdirectorios | .claude/rules/ en el proyecto y ~/.claude/rules/ |
| Estructura | Un archivo por ubicación | Tantos archivos de temas como desees, en subcarpetas |
| Cuándo se carga | Al inicio para el directorio de trabajo y superiores; archivos de subdirectorios cuando Claude toca un archivo allí | Al inicio sin paths; cuando Claude toca un archivo coincidente con paths |
| Alcance | Por directorio | Por patrón glob |
Los archivos CLAUDE.md en subdirectorios también se cargan bajo demanda, por lo que el alcance por directorio es posible con ambos. Las reglas añaden el alcance por patrón, que puede atravesar directorios, como todos los archivos de prueba dondequiera que vivan.
Los archivos bajo demanda comparten un límite. Las reglas con alcance de ruta y los archivos CLAUDE.md de subdirectorios tienen cada uno un límite de tamaño por archivo, y Claude recibe solo el inicio de un archivo que lo supere. Nuestra guía sobre el límite de CLAUDE.md en subdirectorios de Claude Code cubre las cifras y cómo verificar las tuyas.
Si compartes instrucciones con otras herramientas de codificación, nuestra guía para compartir una memoria entre Cursor y Claude Code cubre los archivos que lee cada uno.
Qué sucede con las reglas tras la compactación
La compactación trata los dos tipos de manera diferente. La documentación de la ventana de contexto enumera el CLAUDE.md de la raíz del proyecto y las reglas sin alcance como "Reinyectados desde el disco" después de la compactación, y las reglas con frontmatter paths: como recargadas bajo demanda.
Explica por qué: "Las reglas con alcance de ruta y los archivos CLAUDE.md anidados se cargan en el historial de mensajes cuando Claude lee, escribe o edita su archivo activador, por lo que la compactación los resume junto con todo lo demás". Después de una compactación, una regla con alcance de ruta solo regresa una vez que Claude toca de nuevo un archivo coincidente.
La documentación da una instrucción directa para las reglas que no deben desaparecer: "Si una regla debe persistir a través de la compactación, elimina el frontmatter paths: o muévela al CLAUDE.md de la raíz del proyecto". Nuestra guía para orientar el auto-compact de Claude Code cubre el resto de lo que la compactación mantiene.
Lo que la gente intenta primero
Dar alcance a una regla y esperarla al inicio. Una regla con alcance de ruta se carga cuando Claude toca un archivo coincidente, no cuando comienza la sesión.
Añadir campos como description al frontmatter. Solo se lee paths; otros campos se ignoran sin error.
Escribir YAML inválido. La regla se carga entonces como si no tuviera paths, en cada sesión.
Poner una regla de cumplimiento obligatorio bajo paths. Después de la compactación desaparece hasta que se toca de nuevo un archivo coincidente.
Mantener una regla de usuario y una de proyecto que no coinciden. Ninguna anula a la otra; Claude puede seguir cualquiera.
Ejecutar en un worktree hermano. Las reglas con alcance de ruta de otro worktree no se cargan a menos que inicies la sesión allí o la muevas con /cd.
La solución: Dividir por tema, dar alcance solo a lo condicional y verificar qué se cargó
Paso 1: Dividir CLAUDE.md en archivos por tema
Mueve cada sección autónoma de un CLAUDE.md largo a su propio archivo en .claude/rules/, con un nombre que indique lo que cubre. Deja estos sin alcance al principio. Nada de lo que Claude ve cambia todavía; los archivos son simplemente más fáciles de leer y revisar.
Paso 2: Dar alcance a las reglas que solo son relevantes a veces
Añade paths a las reglas que solo importan para ciertos archivos: un módulo de pagos, un framework de pruebas, un directorio de frontend. Deja sin alcance cualquier cosa que Claude deba seguir en cada tarea, incluidas las reglas que necesites que sobrevivan a la compactación. Verifica cada patrón contra una ruta de archivo real de tu repositorio y mantén cada archivo con alcance dentro del límite de tamaño por archivo.
Paso 3: Verificar qué reglas se cargaron realmente
Ejecuta /context para ver qué archivos CLAUDE.md y de reglas se cargaron al inicio. Una regla con alcance de ruta no estará allí hasta que se active. Para observar los activadores mientras ocurren, la documentación sugiere el hook InstructionsLoaded, que registra qué archivos CLAUDE.md y de reglas se cargan, cuándo se cargan y por qué. Si una regla debería haberse cargado y no lo hizo, verifica el patrón, el directorio base, el frontmatter y si --setting-sources excluyó la configuración del proyecto, lo que omite las reglas del proyecto.
Cuando una regla se carga y Claude aún no la sigue, nuestra guía sobre por qué los agentes de IA ignoran los archivos de instrucciones cubre las otras causas. Y si una corrección que le diste a Claude no se mantuvo, nuestra guía sobre Claude Code olvidando tus correcciones explica a dónde van las correcciones.
Configurando esto en MemoryLake
Las reglas son el lugar adecuado para las instrucciones sobre cómo debe escribirse el código en un repositorio. Son menos adecuadas para el razonamiento detrás de ellas: por qué existe una convención, qué alternativas se probaron y qué decisiones surgieron de una reunión en lugar del código. Ese contexto importa a más de un repositorio y a más de una herramienta.
MemoryLake es una capa de memoria para mantener ese tipo de contexto en una lista que tú mantienes, disponible para Claude Code y los otros asistentes que conectes, como Codex y ChatGPT.
Tú mismo escribes las entradas, con tus propias palabras. No se lee nada de, ni se escribe en, ni se elimina de tus archivos .claude/rules/, tus archivos CLAUDE.md, tu memoria automática o el almacenamiento de cualquier proveedor. Claude Code sigue cargando las reglas de la manera que Anthropic describe.
Paso 1: Crear una clave de API
Inicia sesión y genera una clave desde el panel de control. La clave pertenece a tu espacio de trabajo de MemoryLake y es independiente de tu cuenta de Claude.

Paso 2: Sube tus primeras memorias
Comienza con las razones detrás de tus reglas: por qué existe una convención, qué reemplazó y qué salió mal antes de ella. Un punto por entrada, con fecha y etiquetado con el repositorio o archivo de regla que explica.

Paso 3: Conecta tu IA y agentes
Conecta Claude Code y los otros asistentes que utilices. Las reglas permanecen en el repositorio y el razonamiento está disponible dondequiera que ocurra el trabajo.

Qué cambia esto en la práctica
La primera diferencia es que CLAUDE.md se vuelve más corto sin perder nada. Los archivos de temas llevan las mismas instrucciones, y los que tienen alcance dejan de ocupar contexto en sesiones que no los necesitan.
La segunda es que sabes cuándo una regla está en juego. Las reglas sin alcance están allí desde el principio y regresan tras la compactación. Las reglas con alcance llegan con el primer archivo coincidente y pueden desaparecer tras la compactación.
La tercera es que una regla faltante es algo que puedes verificar, con /context y el hook InstructionsLoaded, en lugar de algo que tienes que adivinar.
Mejores prácticas para las reglas de Claude Code
Un tema por archivo. Nombra los archivos según lo que cubren.
Deja las reglas esenciales sin alcance. Se cargan en cada sesión y sobreviven a la compactación.
Da alcance solo a lo que es condicional. Y prueba los patrones contra rutas reales.
Usa solo paths en el frontmatter. Otros campos son ignorados.
Valida el YAML. Un frontmatter inválido hace que una regla con alcance se cargue en todas partes.
Mantén consistentes las reglas de usuario y de proyecto. Ninguna anula a la otra.
Verifica con /context. Y usa el hook InstructionsLoaded para depurar los activadores.
Conclusión
Las reglas de Claude Code son archivos markdown en .claude/rules/ que dividen tus instrucciones por tema. Las reglas sin paths se cargan al inicio con la misma prioridad que .claude/CLAUDE.md y se reinyectan tras la compactación. Las reglas con paths se cargan cuando Claude lee, escribe o edita un archivo coincidente, y la compactación las resume hasta que se activan de nuevo. Las reglas a nivel de usuario en ~/.claude/rules/ se cargan antes que las reglas del proyecto, y ninguna anula a la otra.
Divide las instrucciones largas en archivos por tema, da alcance solo a las que son verdaderamente condicionales, mantén las reglas de cumplimiento obligatorio sin alcance y verifica qué se cargó con /context.