Cómo mapear qué reglas de Cline están activas antes de comenzar una tarea (Guía 2026)

Comencemos con cuántas cosas cuentan como una regla. La documentación de Cline enumera cuatro tipos que reconoce "para que puedas usar archivos de reglas existentes de otras herramientas": Reglas de Cline en ".clinerules/, .cline/rules/", descritas como "Directorios de reglas de espacio de trabajo compatibles"; Reglas de Cursor en .cursorrules, marcadas como "Detectadas automáticamente"; Reglas de Windsurf en .windsurfrules, también "Detectadas automáticamente"; y AGENTS.md en "AGENTS.md, ~/.agents/AGENTS.md", descrito como el "Formato estándar para compatibilidad entre herramientas."

Eso ya es más superficie de la que la mayoría de la gente imagina, y significa que un .cursorrules sobrante de una herramienta anterior no está inactivo. Los cuatro terminan en el mismo lugar: "Todos los tipos de reglas detectados aparecen en el panel de Reglas, donde puedes activarlos o desactivarlos individualmente."

El primer filtro es ese panel. "Cada regla tiene un interruptor para habilitarla o deshabilitarla. Esto te brinda un control detallado sobre qué reglas se aplican a tu tarea actual sin tener que eliminar el archivo de reglas". La función es útil (la documentación da el ejemplo de "una regla de prueba estricta que deseas deshabilitar al crear prototipos, o una regla específica del cliente que solo necesitas cuando trabajas en las funciones de ese cliente") y el costo es que una regla que desactivaste hace tres semanas se ve idéntica en el disco a una que está activa.

El segundo filtro es la activación condicional a través del front matter de YAML. "Cuando Cline procesa una solicitud, recopila contexto de tu trabajo actual (archivos abiertos, pestañas visibles, rutas mencionadas, archivos editados), evalúa las condiciones de cada regla y activa las reglas que coinciden". El condicional admitido está documentado como uno solo: "Actualmente, paths es el condicional admitido", que toma un array de patrones glob.

Tres comportamientos en torno a ese condicional deciden la mayoría de los casos reales, y los tres se detallan en la documentación. "Sin frontmatter: Las reglas sin frontmatter siempre están activas". "Array de rutas vacío: paths: [] significa que la regla nunca se activa. Usa esto para deshabilitar temporalmente una regla". Y "YAML no válido: si el frontmatter no se puede analizar, Cline falla abriéndose. La regla se activa con el contenido sin procesar visible para ayudar a la depuración".

Este último es el indicio clave. Si el front matter sin procesar de una regla aparece en la salida de Cline, no es que haya fallado al cargarse; se cargó en un formato de depuración porque el YAML no se pudo analizar.

Volver a escribir la regla con más fuerza. Agregar énfasis a una instrucción que nunca llegó al modelo no cambia nada. También empeora el archivo para el día en que sí se aplique.

Copiar la regla en ambos directorios compatibles. Es innecesario, y la documentación lo dice: "Se buscan ambos directorios cuando están presentes, por lo que no es necesario copiar las reglas en ambas ubicaciones". También señalan dónde terminan los archivos nuevos: "El panel de Reglas de VS Code sigue creando nuevas reglas de espacio de trabajo en .clinerules/."

Eliminar el front matter para "hacer que se aplique siempre". Esto funciona y es el comportamiento documentado, pero si se aplica de manera generalizada, recrea el problema que los condicionales deben resolver. La documentación es directa sobre el costo: "A medida que crece tu biblioteca de reglas, cargar cada regla para cada solicitud desperdicia tokens de contexto y puede diluir el enfoque de Cline".

Describir el archivo en prosa en lugar de nombrarlo. La documentación contiene un consejo que parece escrito después de ver a la gente hacer esto: "Sé explícito con las rutas de los archivos en tus instrucciones. 'Actualizar src/services/user.ts' activa de manera confiable las reglas basadas en rutas; 'actualizar el servicio de usuario' puede que no".

Asumir que es un problema de memoria. A veces lo es: una regla que se aplica correctamente y aun así deja a Cline deduciendo nuevamente los hechos del proyecto es un fallo diferente, más cercano al territorio de cómo configurar un banco de memoria de Cline. Pero una regla que nunca se activa es un problema de activación, y la solución está en el panel y en el front matter.

Asumir que es el mismo fallo que en otros editores. El síntoma coincide, el mecanismo no. Cuando otra herramienta descarta las reglas del proyecto a mitad de la sesión, la pregunta suele ser sobre el alcance y el estado de la sesión en lugar de un modelo de activación de dos filtros, como en por qué Cursor olvida las reglas del proyecto.

Paso 1: Enumerar cada archivo que Cline cuenta como una regla, incluidos los que no escribiste

Abre el panel de Reglas y léelo como un inventario en lugar de como una pantalla de configuración. Cada tipo detectado aparece allí, por lo que el panel es donde descubres si todavía se le está ofreciendo al modelo un viejo .cursorrules o .windsurfrules.

Luego verifica ambas ubicaciones del espacio de trabajo en el disco (.clinerules/ y .cline/rules/) porque "Ambos diseños son compatibles con VS Code, Desktop y la CLI", y es posible que un colega haya usado el que tú no abres. Agrega el nivel global: las reglas globales viven en el directorio de Reglas de Cline de tu sistema, y la documentación señala que "Cline también lee instrucciones globales de AGENTS para múltiples herramientas desde ~/.agents/AGENTS.md".

Para cada archivo de la lista, registra dos cosas: si su interruptor está activado y si tiene front matter. Ese par es el mapa. Un archivo con el interruptor activado y sin front matter siempre está activo. Un archivo con el interruptor desactivado está inactivo independientemente de lo que diga el front matter, porque "Desactivar una regla condicional la deshabilita por completo (no se activará incluso si las rutas coinciden)".

Mientras estás aquí, aplica el consejo estructural, ya que hace que el mapa sea mantenible: "Una preocupación por archivo. Divide las reglas por tema: coding.md para el estilo, testing.md para los requisitos de prueba, architecture.md para las decisiones estructurales. Esto facilita activar o desactivar reglas específicas". Un solo archivo de reglas grande te da un único interruptor para seis preocupaciones no relacionadas.

Paso 2: Leer el glob frente al contexto que Cline realmente evalúa

El patrón es solo la mitad de la pregunta; la otra mitad es contra qué lo está comparando Cline. El contexto documentado tiene cinco entradas: "Tu mensaje: rutas de archivos mencionadas en tu instrucción", "Pestañas abiertas: archivos actualmente abiertos en tu editor", "Archivos visibles: archivos visibles en tus paneles de edición activos", "Archivos editados: archivos que Cline ha creado, modificado o eliminado durante la tarea" y "Operaciones pendientes: archivos que Cline está a punto de editar".

De esto se derivan dos consecuencias. Primero, el momento no es fijo: "Las reglas condicionales pueden activarse en tu primer mensaje, cuando los archivos relevantes están abiertos, o a mitad de la tarea cuando Cline comienza a trabajar con archivos que coinciden". Una regla que parecía ausente al principio bien podría haber llegado más tarde. Segundo, una regla puede activarse por una razón que no pretendías, simplemente porque un archivo no relacionado resultó estar abierto en otro panel.

Luego lee el propio glob con la sintaxis documentada a la mano. * "coincide con cualquier carácter excepto /", ** "coincide con cualquier carácter incluyendo / (recursivo)", ? "coincide con un solo carácter", [abc] "coincide con cualquier carácter dentro de los corchetes" y {a,b} "coincide con cualquiera de los patrones". Vale la pena interiorizar los ejemplos: src/**/*.ts cubre "Todos los archivos TypeScript bajo src/", *.md cubre "Archivos Markdown solo en la raíz", **/*.test.ts cubre "Archivos de prueba en cualquier lugar del proyecto" y src/components/*.tsx cubre "Archivos TSX directamente en components (not nested)".

La regla de combinación es generosa: "Una regla se activa si algún patrón coincide con cualquier archivo en tu contexto". Es por eso que los patrones demasiado amplios fallan por activarse de más con más frecuencia de lo que los patrones estrechos fallan por no activarse, que es exactamente el equilibrio que la misma documentación señala en sus notas de resolución de problemas, donde "Regla que se activa inesperadamente" apunta a que "** es recursivo y puede coincidir con más de lo previsto" y a archivos abiertos que coinciden con el patrón.

Paso 3: Demostrarlo con una regla de prueba desechable y buscar la notificación

Cline emite una señal cuando esto funciona, y conocerla convierte las conjeturas en una verificación. Cuando se activa una regla condicional, la documentación dice que "verás una notificación: 'Conditional rules applied: workspace:frontend-rules.md'."

La forma documentada de usar eso es una regla desechable. Crea un archivo pequeño en .clinerules/ cuyo único front matter sea el patrón paths sobre el que tienes dudas, y cuyo cuerpo sea una sola línea obvia (la documentación sugiere algo como "TEST: This rule should activate for your/pattern/here files"). Luego "trabaja con un archivo en esa ruta y verifica si ves la notificación de activación".

Si no aparece nada, la lista de resolución de problemas es corta y ordenada: "Verifica que las rutas de los archivos en tu contexto coincidan con el patrón glob", "Verifica que la regla esté activada en el panel de reglas" y "Asegúrate de que el frontmatter de YAML tenga los delimitadores --- adecuados". Ejecútalos en ese orden, porque el primero es el más común y el tercero es el que produce el síntoma más extraño (recuerda que el front matter que no se puede analizar falla abriéndose con el contenido sin procesar visible).

La documentación también sugiere una forma de construir patrones en lugar de adivinarlos: "Comenzar de forma amplia, luego estrechar", empezando con algo como src/** y refinando a src/features/auth/** una vez que hayas visto qué coincide. Si prefieres no escribir el archivo a mano en absoluto, hay un comando de barra diagonal /newrule para "hacer que Cline cree una regla de forma interactiva".

Las reglas son instrucciones: cómo escribir código aquí, qué evitar, qué convenciones se mantienen. Son un contenedor deficiente para la otra cosa que implican tus reglas: las decisiones y las razones detrás de ellas, que deseas que sean recuperables cuando estés decidiendo si una regla aún se aplica, en lugar de cargarlas en cada tarea. Un almacén en el que escribes entradas de MemoryLake a propósito mantiene esa mitad separada, por lo que ajustar un glob nunca te costará perder el razonamiento detrás de la regla. Escribes las entradas tú mismo, con tus propias palabras. No se lee, escribe ni elimina nada de tus archivos de reglas ni de la configuración de Cline.

Paso 1: Crear una clave API

Inicia sesión y genera una clave API desde la configuración de tu espacio de trabajo. Esta es la credencial que usan tus agentes e integraciones, así que créala antes de comenzar a mover cualquier cosa.

Paso 2: Subir tus primeras memorias

Comienza con el "por qué" que tus archivos de reglas omiten: por qué el directorio heredado está fuera de los límites, qué convención reemplazó a cuál y cuándo, contra qué protege una restricción. Escribe cada una como una nota corta e independiente para que pueda recuperarse por sí sola.

Paso 3: Conectar tu IA y agentes

Conecta los asistentes y agentes que utilizas. El razonamiento viajará contigo a través de las herramientas, independientemente de qué directorio de reglas lea un editor determinado.

La depuración adquiere un orden de operaciones. En lugar de volver a escribir una regla, verificas el interruptor, luego el front matter, luego el glob frente a las cinco entradas de contexto, luego ejecutas una regla de prueba y buscas la notificación. Cuatro comprobaciones, todas con una respuesta documentada.

Los archivos de herramientas antiguos se convierten en una decisión en lugar de un accidente. Un .cursorrules que dejaste atrás se detecta y se ofrece, por lo que o bien pertenece a tu conjunto de reglas a propósito o bien debería eliminarse. Eso también aclara la dirección de la migración cuando mueves reglas entre herramientas, como en cómo migrar reglas de Cursor a Claude Code.

La redacción de las instrucciones se convierte en parte de la configuración. Dado que las rutas mencionadas en tu mensaje cuentan como contexto, nombrar el archivo que pretendes cambiar no es pedantería: es el activador más confiable disponible para ti, según el propio consejo de la documentación.

Las bibliotecas de reglas dejan de crecer por defecto. Una vez que puedes ver qué reglas están siempre activas, el nivel de siempre activas se convierte en un presupuesto que gestionas en lugar de una pila que heredas. Esa es la misma presión que hace que la gente consolide archivos de reglas dispersos en primer lugar, como se analiza en cómo consolidar archivos de reglas de Kilo Code.

Y las quejas recurrentes se vuelven a diagnosticar. "Olvidó nuestro estilo otra vez" a veces es un problema de activación con una causa conocida, no un problema de memoria; una distinción que vale la pena hacer antes de cambiar nada, y que da forma a la solución en por qué Cline olvida tu estilo de codificación.

Mantén un archivo siempre activo y nómbralo como tal. El diseño de ejemplo de la propia documentación termina con universal.md anotado como "Sin frontmatter = siempre activo". Un archivo nombrado por su comportamiento le dice a la siguiente persona qué está mirando.

Coloca el activador previsto en el cuerpo de la regla. Una línea en la parte superior ("se espera que se active para src/components") convierte cada fallo futuro en una comparación de dos segundos en lugar de una investigación.

Prefiere varios archivos estrechos a uno amplio, de modo que el interruptor sea un instrumento preciso. Este es el beneficio práctico de "una preocupación por archivo".

Vuelve a ejecutar la regla de prueba después de las refactorizaciones. Mover un directorio cambia lo que coinciden tus globs, y nada en la cadena de herramientas te dirá que un patrón dejó de coincidir.

Trata los archivos para múltiples herramientas como siempre activos. Un AGENTS.md en la raíz o ~/.agents/AGENTS.md se detecta como una fuente de reglas, y un archivo compartido se comparte precisamente porque no está filtrado por herramienta. Cualquiera que sea la configuración a la que llegues, vale la pena volver a examinar periódicamente la cuestión más amplia de qué pertenece a las reglas, que es el terreno cubierto en las mejores configuraciones de memoria para Cline.

Una regla de Cline llega al modelo solo si su interruptor está activado y su condición coincide. Ambos filtros son silenciosos al cerrarse, y cuatro tipos de archivos diferentes alimentan el mismo panel, por lo que la regla que se está ignorando no siempre es la regla que estabas mirando.

Crea el mapa una vez: cada fuente de reglas, incluidas las heredadas, el estado del interruptor de cada una, el front matter de cada una y el glob leído frente a las cinco entradas de contexto documentadas. Luego, mantén una regla de prueba desechable a mano, porque la notificación de activación es la única señal positiva en el sistema, y una comprobación que puedes volver a ejecutar supera a una regla que volviste a escribir y sobre la que tuviste esperanzas.