Cómo fusionar tus carpetas de reglas de Windsurf y Devin para que gane la correcta (Guía 2026)

La precedencia documentada está clara una vez que la encuentras. La sección de descubrimiento de reglas de Devin Desktop lo establece directamente:

"Devin Desktop descubre automáticamente reglas de múltiples ubicaciones para proporcionar una organización flexible. El directorio .devin/ es la ubicación preferida y tiene precedencia, manteniéndose .windsurf/ como una alternativa para compatibilidad con versiones anteriores."

Esa es una sola frase, y resuelve la pregunta del titular. El problema es todo lo que la rodea.

El descubrimiento no se detiene en una sola carpeta. Cubre "todos los directorios .devin/rules (y los heredados .windsurf/rules) dentro de tu espacio de trabajo actual y sus subdirectorios", y para los repositorios de git "también busca hacia arriba hasta el directorio raíz de git para encontrar reglas en los directorios padres". Cuando hay varias carpetas abiertas a la vez, "las reglas se deduplican y se muestran con la ruta relativa más corta".

Hay un tercer archivo en el alcance del espacio de trabajo del que la mayoría de los equipos se han olvidado por completo:

"El archivo único heredado .windsurfrules en la raíz del espacio de trabajo también se sigue leyendo."

Por encima del espacio de trabajo se encuentra un archivo global con sus propias reglas: ~/.codeium/windsurf/memories/global_rules.md, descrito como un "Archivo único, aplicado en todos los espacios de trabajo. Siempre activo. Limitado a 6,000 caracteres". Los archivos de reglas del espacio de trabajo tienen su propio límite: 12,000 caracteres cada uno.

Luego está AGENTS.md, que no es en absoluto un sistema independiente. Su documentación hace que la relación sea explícita:

"Cuando creas un archivo AGENTS.md (o agents.md), Devin Desktop lo descubre automáticamente y lo introduce en el mismo motor de Reglas que alimenta .devin/rules/ (y el heredado .windsurf/rules/), solo que con el modo de activación inferido a partir de la ubicación del archivo en lugar del frontmatter."

El nivel raíz significa siempre activo. Un subdirectorio significa "una regla glob con un patrón autogenerado de <directory>/**".

And para las empresas hay una capa de sistema, desplegada por el departamento de TI y de solo lectura para los usuarios, que tiene el mismo par de carpetas antigua y nueva: /Library/Application Support/Devin/rules/ en macOS con Windsurf como alternativa heredada, /etc/devin/rules/ en Linux con /etc/windsurf/rules/ como alternativa, y el par equivalente en Windows. Las reglas del sistema "se fusionan con las reglas del espacio de trabajo y globales, proporcionando contexto adicional a Cascade sin anular las reglas definidas por el usuario".

Cuenta las superficies: .devin/rules, .windsurf/rules, .windsurfrules, cualquier cantidad de archivos AGENTS.md, global_rules.md y dos directorios del sistema. Cada una de ellas está activa. Dos de los pares existen solo porque ocurrió un cambio de nombre y no se podía permitir que nada fallara.

Hay un detalle más que facilita la desviación. Las nuevas reglas no van a donde podrías suponer:

"Cuando creas una nueva regla, se guardará en el directorio .devin/rules de tu espacio de trabajo actual, no necesariamente en la raíz de git."

Así que en un monorepo, una regla creada mientras estás dentro de un paquete específico termina en ese paquete, no en la raíz.

Eliminar la carpeta heredada de inmediato. Tentador y generalmente prematuro. La carpeta antigua todavía se lee, lo que significa que cualquiera que use un cliente más antiguo, o cualquier compañero de equipo que no haya hecho un pull, podría estar dependiendo de ella. Elimínala después de haber confirmado que el contenido está representado en la nueva ubicación, no antes.

Asumir que el archivo más nuevo gana. No es así. La precedencia es por ubicación, no por hora de modificación. Una regla que escribiste esta mañana en .windsurf/rules pierde frente a una obsoleta en .devin/rules.

Poner todo en global_rules.md para evitar el dilema de las carpetas. Esto cambia un problema por otro peor. El archivo global siempre está activo, se aplica en todos los espacios de trabajo y está limitado a 6,000 caracteres. Es el contenedor incorrecto para convenciones específicas del proyecto y será lo primero en alcanzar el límite.

Asumir que AGENTS.md queda fuera de la discusión. No es así. Pasa por el mismo motor de reglas, y uno a nivel de raíz siempre está activo, por lo que compite por el mismo presupuesto de contexto que tus archivos de reglas siempre activos, con su activación inferida de dónde se encuentra en lugar de ser declarada.

Tratar las memorias autogeneradas como la capa duradera. La documentación es inusualmente directa al respecto, y vale la pena citarla porque es el propio proveedor diciéndote para qué sirve su función:

"Para el conocimiento que deseas que Cascade reutilice de manera confiable, escríbelo como una Regla o agrégalo a AGENTS.md en tu repositorio en lugar de depender de las Memorias autogeneradas. Las Reglas están controladas por versiones, se pueden compartir con tu equipo y te brindan un control explícito sobre la activación."

Las memorias autogeneradas también son locales: viven bajo ~/.codeium/windsurf/memories/, y "las memorias generadas en un espacio de trabajo no están disponibles en otro, y no se confirman en tu repositorio". Si perder el contexto entre sesiones es el síntoma que te trajo aquí, por qué Cascade pierde el contexto cubre ese aspecto directamente.

Tres pasos. Hazlos en orden: el inventario es lo que hace que el segundo paso sea seguro.

Paso 1: Inventariar cada superficie antes de mover nada

Recorre las siete superficies y anota qué hay en cada una. Específicamente: cada directorio .devin/rules en el espacio de trabajo y en los directorios padres hasta la raíz de git, cada directorio .windsurf/rules en los mismos lugares, el archivo .windsurfrules en la raíz del espacio de trabajo si existe, cada AGENTS.md o agents.md en cualquier nivel, global_rules.md y, si tu organización los despliega, los directorios del sistema, tanto actuales como heredados.

Dos cosas a registrar para cada regla: su modo de activación y si ya existe un equivalente en otro lugar. El modo de activación importa porque se declara en el frontmatter a través del campo trigger, y los cuatro valores tienen costos muy diferentes. La documentación detalla la compensación: always_on coloca la regla completa en el prompt del sistema en cada mensaje; model_decision coloca solo la description en el prompt y lee el archivo completo cuando Cascade decide que la descripción es relevante; glob aplica la regla cuando Cascade lee o edita un archivo que coincide con el patrón; manual la mantiene fuera del prompt por completo hasta que escribes @rule-name.

Ten en cuenta las dos excepciones mientras haces el inventario: "El archivo de reglas globales (global_rules.md) y los archivos AGENTS.md a nivel de raíz no usan frontmatter; siempre están activos". Esos dos no se pueden limitar. Lo que esté en ellos estará en cada mensaje.

Paso 2: Mover cada regla a .devin/rules y resolver los duplicados a mano

Copia cada regla heredada en el directorio .devin/rules al nivel al que realmente pertenece, que para la mayoría de las convenciones es la raíz de git, no el paquete en el que te encontrabas cuando la creaste.

Donde encuentres la misma regla en ambas carpetas, lee ambas versiones antes de elegir una. Este es el paso donde la desviación se vuelve visible, y con frecuencia no es un duplicado limpio: la versión heredada tiene un detalle que la nueva perdió, o la nueva tiene una corrección que la heredada nunca recibió. Fusiona deliberadamente y luego elimina la copia heredada.

.windsurfrules necesita una decisión propia. Es un archivo único sin frontmatter, por lo que todo lo que contiene se comporta como un bloque indiferenciado. Divídelo en archivos de reglas individuales con activadores declarados a medida que lo mueves; ese es todo el beneficio del formato más nuevo.

Para los archivos AGENTS.md, decide si cada uno es realmente material para estar siempre activo. Un AGENTS.md a nivel de raíz no se puede limitar, por lo que cualquier cosa en él que solo se aplique a una parte del árbol debería convertirse en un AGENTS.md de subdirectorio (que obtiene el auto-glob para ese directorio) o en un archivo de reglas con un activador glob explícito.

⚠️ Una advertencia entre herramientas mientras tocas estos archivos. Devin Desktop es flexible con el nombre: "No distingue entre mayúsculas y minúsculas: se reconocen tanto AGENTS.md como agents.md". Otras herramientas no lo son. La documentación de Kilo Code lo establece claramente: "El nombre del archivo debe estar en mayúsculas (AGENTS.md), no en minúsculas (agents.md)". Si tu repositorio se comparte con personas que usan otros agentes, usa mayúsculas. No cuesta nada aquí y es la diferencia entre que un archivo se lea o se ignore silenciosamente en otro lugar. El mismo tipo de desajuste aparece cuando las reglas se mueven entre proveedores: mover las reglas de Cursor a Windsurf cubre la parte del frontmatter.

Paso 3: Declarar un modo de activación para todo lo que pueda tener uno

Una vez consolidado, revisa .devin/rules y verifica que el trigger de cada archivo sea una elección deliberada en lugar de una opción predeterminada.

La prueba de fuego es una pregunta por regla: ¿es necesario que esto esté en el prompt en cada mensaje? La mayoría de las reglas no lo necesitan. Una convención sobre archivos de prueba es una regla glob. Un runbook es manual. Una explicación larga del modelo de datos es model_decision, donde solo su descripción está siempre presente y el cuerpo se lee bajo demanda.

Este paso es lo que recupera el presupuesto de contexto que siete superficies superpuestas consumían silenciosamente, y solo es posible una vez que los duplicados han desaparecido: no puedes razonar sobre los costos de activación mientras la misma regla exista tres veces.

La consolidación soluciona las carpetas. No soluciona la razón por la que no pudiste resolver los duplicados rápidamente: cuando la misma regla existía en dos lugares con dos redacciones diferentes, nada registraba qué versión era la actual o qué había cambiado entre ellas.

MemoryLake mantiene ese registro completamente fuera de la capa de reglas y lo sirve a cualquier agente que lo solicite, a través de MCP o la API. Tus archivos .devin/rules se quedan donde están y siguen funcionando exactamente como está documentado; esto contiene la parte que el motor de reglas nunca fue diseñado para almacenar: para qué sirve cada regla, qué reemplazó y cuándo.

Paso 1: Crear una clave API

Genera una clave y realiza tu primera solicitud en unos treinta segundos. Hazlo antes del Paso 2 de la consolidación, para que puedas capturar las decisiones a medida que resuelves los duplicados.

Paso 2: Subir tus primeras memorias

A medida que fusiones cada par de duplicados, registra qué conservaste, qué descartaste y por qué. Añade las reglas que surgieron de un incidente específico; esas son las que nadie se atreve a cambiar de redacción porque nadie recuerda el motivo. Los documentos y otros archivos van al mismo lugar.

Paso 3: Conectar tu IA y agentes

Dale acceso a Claude, Codex, OpenClaw y a tus sesiones de Devin Desktop a través de MCP o la API. Una vez conectados, el razonamiento detrás de una regla se puede recuperar bajo demanda, lo que permite que el archivo de reglas en sí se mantenga lo suficientemente corto como para justificar un activador always_on.

El cambio inmediato es que la pregunta de "qué regla está realmente en vigor" se puede responder en un solo lugar. Una carpeta, un archivo por regla, cada uno con un modo de activación declarado.

El segundo cambio es el presupuesto de contexto. Siete superficies superpuestas con un número desconocido de archivos siempre activos es mucho prompt gastado en pautas que se aplican a una fracción del trabajo. Deduplicar y luego declarar activadores es la única forma de reducir eso, y generalmente recupera más espacio del que la gente espera.

El tercer cambio es que el próximo cambio de nombre será aburrido. Esto volverá a suceder: los proveedores se fusionan, los productos cambian de nombre, las rutas se mueven, y lo responsable que debe hacer un proveedor es seguir leyendo la ruta antigua. Si tus reglas están consolidadas y tu razonamiento vive fuera de la carpeta, el próximo cambio de ruta será una operación de copia en lugar de otro proyecto de arqueología.

Consolidar en .devin/rules, ya que es la ubicación preferida documentada y la que tiene precedencia. No luches contra el orden de precedencia; muévete al lado ganador.

Coloca las reglas de todo el proyecto en la raíz de git. Las nuevas reglas se guardan en el directorio del espacio de trabajo actual, "not necesariamente en la raíz de git", que es como los monorepos terminan con convenciones enterradas dentro de un solo paquete.

Divide .windsurfrules en lugar de portarlo completo. Un solo archivo indiferenciado no puede expresar modos de activación, y eso es lo principal que te ofrece el formato más nuevo.

Usa AGENTS.md en mayúsculas. Devin Desktop acepta cualquier caso; otros agentes en un repositorio compartido pueden requerir mayúsculas.

Conserva global_rules.md únicamente para preferencias genuinamente personales y de múltiples proyectos. Siempre está activo, se aplica en todas partes y está limitado a 6,000 caracteres.

Elimina las copias heredadas solo después de verificar que el contenido se haya movido. Las rutas antiguas todavía se leen, lo que significa que una consolidación a medias es peor que cualquiera de los dos extremos.

No utilices memorias autogeneradas como el registro de tu equipo. La documentación recomienda reglas o AGENTS.md para conocimiento duradero y compartible, y señala que las memorias autogeneradas son locales del espacio de trabajo y no se confirman. Para la segunda mitad de esa división (lo que pertenece a un almacén que el agente consulta en lugar de a un archivo de reglas), herramientas de memoria para usuarios de Windsurf cubre las opciones.

Devin Desktop lee siete superficies de reglas, y dos de los pares entre ellas existen solo porque ocurrió un cambio de nombre y se preservó la compatibilidad con versiones anteriores. .devin/ tiene precedencia sobre .windsurf/, se leen ambos, .windsurfrules se sigue leyendo además de eso, y los archivos AGENTS.md alimentan el mismo motor con su activación inferida a partir de la ubicación.

Nada de eso está roto. Todo es una desviación esperando a suceder, especialmente porque las nuevas reglas se guardan en cualquier directorio del espacio de trabajo en el que te encuentres.

Inventarea las siete superficies, consolida en .devin/rules al nivel adecuado, divide el archivo único heredado, declara un modo de activación para todo lo que pueda tener uno y mantén el razonamiento detrás de cada regla en algún lugar que el motor de reglas no posea. Entonces la respuesta a "cuál gana" es corta: solo hay una.