Cómo migrar de Zed a Claude Code sin perder el contexto (2026)

Tus habilidades (Skills), como un movimiento de directorio. Las habilidades de Zed se instalan "en ~/.agents/skills/ para uso global, o en la carpeta .agents/skills/ de tu proyecto para uso local del proyecto", y una habilidad es "una carpeta que contiene un archivo SKILL.md con metadatos e instrucciones". El diseño de Claude Code es la misma idea en una ruta diferente: personal en ~/.claude/skills/<skill-name>/SKILL.md, de proyecto en .claude/skills/<skill-name>/SKILL.md. Copia las carpetas, cambia el nombre del directorio principal y listo.

Ambos lados también las cargan de la misma manera. Zed: "Por defecto, el agente detecta las habilidades de forma autónoma. Ve un catálogo de cada habilidad instalada (nombre y descripción) en su prompt del sistema, y llama a la herramienta skill cuando una tarea coincide con la descripción de una habilidad". Claude Code: "Claude utiliza habilidades cuando es relevante, o puedes invocar una directamente con /skill-name ".

El contenido de tus instrucciones, con un cambio de nombre. Lo que sea que estuviera en el archivo que Zed realmente estaba leyendo se convierte en CLAUDE.md. Si ese archivo ya era CLAUDE.md, has terminado y deberías verificar la siguiente sección, porque significa que Zed lo estaba leyendo solo si no existía nada anterior en la lista.

Tu capa personal, a un hogar diferente. Las instrucciones personales de Zed viven en ~/.config/zed/AGENTS.md, o %APPDATA%\Zed\AGENTS.md en Windows. El equivalente de Claude Code es ~/.claude/CLAUDE.md, descrito como "Preferencias personales para todos los proyectos".

Nada más se transfiere limpiamente, y dos cosas se comportan de manera diferente.

La precedencia se invierte, en ambas direcciones. Zed lo establece claramente: "Las instrucciones del proyecto anulan las AGENTS.md personales cuando entran en conflicto". Claude Code no anula en absoluto: "Todos los archivos descubiertos se concatenan en el contexto en lugar de anularse entre sí", ordenados desde la raíz del sistema de archivos hacia abajo, y si dos archivos no están de acuerdo "Claude puede elegir uno arbitrariamente".

Y para las habilidades se invierte en la otra dirección: la regla de Claude Code es "Entre niveles, la empresarial anula a la personal, y la personal anula a la del proyecto", con el ejemplo práctico de que "con una habilidad deploy tanto en ~/.claude/skills/ como en el .claude/skills/ de tu proyecto, /deploy ejecuta la personal". En Zed, tu archivo con alcance de proyecto ganaba el conflicto. En Claude Code, gana tu habilidad personal. Si tú y un compañero de equipo tienen una habilidad con el mismo nombre, obtendrán un comportamiento diferente del mismo repositorio.

Los archivos de compatibilidad de Zed dejan de leerse. .rules, .cursorrules, .windsurfrules y .github/copilot-instructions.md son cosas que Zed cargará con gusto como instrucciones del proyecto. Claude Code no lee ninguno de ellos por defecto. .clinerules es la única excepción parcial: /init lo detecta solo cuando CLAUDE_CODE_NEW_INIT=1 está configurado, y lo omite silenciosamente en caso contrario. Si tus instrucciones han estado viviendo en un nombre de archivo de compatibilidad todo este tiempo, están a punto de volverse invisibles.

Los mecanismos de distribución de habilidades de Zed no se trasladan. Zed puede entregar una habilidad a un compañero de equipo como un enlace zed://skill?data=… autónomo que "incrusta el contenido completo de SKILL.md (codificado en base64url), por lo que el destinatario no necesita acceso a tu proyecto ni a ningún registro", con la agradable propiedad de que "No se escribe nada en el disco hasta que lo guarden explícitamente, por lo que un enlace compartido nunca puede instalar silenciosamente instrucciones en el agente de alguien". También se instala desde skills.sh, un registro comunitario. Esas son rutas de distribución, no las habilidades en sí; los archivos se transfieren, el flujo de trabajo para compartir no.

El comportamiento de los permisos por habilidad difiere. En Zed, "Cuando el agente invoca una habilidad que creaste o instalaste, Zed te pide que la permitas o la deniegues, utilizando el mismo flujo de permisos que otras herramientas", y puedes establecer valores predeterminados por habilidad. Claude Code tiene su propio modelo de permisos; el interruptor disable-model-invocation que hayas configurado en una habilidad de Zed no tiene un equivalente directo en el archivo que estás copiando.

Paso 1: Descubre qué archivo estaba leyendo realmente Zed

Esto lo es todo, y solo requiere un comando.

Enumera los candidatos en la raíz de tu repositorio, en el orden de prioridad de Zed, y toma nota del primero que exista:

ls -1 .rules .cursorrules .windsurfrules .clinerules \
      .github/copilot-instructions.md AGENT.md AGENTS.md CLAUDE.md GEMINI.md 2>/dev/null

La primera línea de salida es tu archivo de instrucciones activo. Todo lo que esté debajo ha sido peso muerto en Zed, posiblemente durante meses, y posiblemente contradiciendo al archivo que estaba ganando.

Tres resultados para planificar. Si el ganador es CLAUDE.md, no hay nada que hacer. Si es AGENTS.md, Claude Code no lo leerá, y la solución es un cambio de nombre o una importación (siguiente paso). Si es un archivo de compatibilidad como .cursorrules, su contenido debe moverse a CLAUDE.md, porque ese nombre de archivo no tiene lector en el otro lado.

También verifica tu archivo personal en ~/.config/zed/AGENTS.md. La precedencia de proyecto sobre personal de Zed significa que cualquier cosa allí que entrara en conflicto con el archivo del proyecto ha estado perdiendo, y en Claude Code ahora se concatenará, por lo que una preferencia que pensabas que estaba anulada está a punto de activarse nuevamente.

Paso 2: Mueve las habilidades y luego reconstruye la capa de instrucciones

Primero las habilidades, porque es algo mecánico. Copia ~/.agents/skills/* en ~/.claude/skills/, y cualquier .agents/skills/* del proyecto en .claude/skills/. El nombre del directorio se convierte en el comando que escribes, y Claude Code lee la description en el frontmatter para decidir cuándo cargarlo automáticamente, por lo que las mismas descripciones siguen funcionando.

Dos cosas que debes saber una vez que estén dentro. Los comandos personalizados y las habilidades son ahora la misma cosa en el lado de Claude Code: "Un archivo en .claude/commands/deploy.md y una habilidad en .claude/skills/deploy/SKILL.md crean /deploy y funcionan de la misma manera". Y las habilidades anidadas se cargan contextualmente: "Las habilidades también se cargan desde directorios .claude/skills/ anidados debajo de tu directorio de trabajo", lo cual está disponible "Cuando Claude lee o edita un archivo en un subdirectorio". Eso está más cerca del alcance de proyecto de Zed de lo que sugieren los directorios de nivel superior.

Cuidado con las colisiones de nombres con el conjunto integrado. Una habilidad de proyecto puede reemplazar a una integrada: "una habilidad code-review en el .claude/skills/ de tu proyecto reemplaza a la /code-review integrada". Por lo general está bien, ocasionalmente es una sorpresa.

Luego el archivo de instrucciones, y elige una forma. Dos opciones limpias.

Cambia el nombre a CLAUDE.md si Claude Code es ahora tu único agente en ese repositorio. O mantén AGENTS.md como la fuente de verdad y agrega un CLAUDE.md que lo importe; el patrón documentado es una sola línea @AGENTS.md en la parte superior, después de la cual "Claude carga el archivo importado al inicio de la sesión y luego añade el resto". Esa es la opción correcta si tus compañeros de equipo todavía usan Zed o si otro agente lee AGENTS.md, porque mantiene un solo archivo como autoridad en lugar de dos copias que divergen.

Divide lo que era un solo archivo en reglas con alcance. Claude Code te ofrece un contenedor que Zed no tiene: archivos en .claude/rules/ con un campo paths: en el frontmatter para patrones glob, los cuales "solo se aplican cuando Claude está trabajando con archivos que coinciden con los patrones especificados". Las reglas sin un campo paths "se cargan al inicio con la misma prioridad que .claude/CLAUDE.md". Si tu archivo de instrucciones de Zed tenía una sección "cuando se trabaja en el frontend...", esa sección es ahora una regla con alcance de ruta en lugar de un texto siempre activo.

Y ten en cuenta lo que se activa por sí solo. Claude Code tiene un segundo mecanismo que Zed no tiene: la memoria automática (auto memory), que está activada por defecto y almacena notas que Claude escribe para sí mismo en ~/.claude/projects/<project>/memory/. Registra cuatro tipos: user, feedback, project y reference, y "omite cualquier cosa que pueda derivar del código base" además de "any cosa que tus archivos CLAUDE.md ya digan". Ejecuta /memory después de una semana y léelo. El funcionamiento general se encuentra en por qué Claude Code olvida el contexto del proyecto.

Para confirmar qué se cargó realmente, ejecuta /context y verifica la lista bajo Memory files. Esa es la respuesta definitiva, y la documentación lo utiliza como el primer paso de depuración porque "Si falta un archivo allí, Claude no puede verlo".

Da un paso atrás y analiza lo que realmente fue la migración. Se cambió el nombre de un archivo. Se movió una carpeta. Y la parte arriesgada —aquella en la que el comportamiento cambió silenciosamente— se debió por completo a qué archivo eligió un cargador.

Eso no es un problema de Zed ni de Claude Code. Es lo que sucede cuando el conocimiento duradero vive en archivos cuyas reglas de descubrimiento difieren según la herramienta. Zed toma la primera coincidencia de una lista de nueve. Claude Code concatena todo lo que encuentra y elige arbitrariamente entre las contradicciones. Ambos limitan lo que transportan, porque el contenido siempre activo se envía con cada solicitud.

Eso es lo que MemoryLake almacena: el conocimiento duradero de tu proyecto en una capa que tus herramientas consultan, de modo que el nombre del archivo sea una preferencia en lugar de aquello de lo que depende la comprensión de tu agente. La configuración consta de tres pasos.

Paso 1: Crea una clave API

Inicia sesión en MemoryLake y crea una clave API. Una sola credencial para todas las herramientas que conectes.

Paso 2: Sube tus primeras memorias

Entradas cortas, una afirmación cada una. Qué escribir mientras la auditoría del Paso 1 está fresca:

Las decisiones enterradas en el archivo que estaba perdiendo. Si .cursorrules había estado eclipsado por AGENTS.md durante seis meses, contiene restricciones que nadie ha estado aplicando. Léelo antes de eliminarlo.

Decisiones con la razón adjunta. "Las migraciones son solo aditivas porque la réplica de lectura se retrasa bajo carga". Una instrucción establece la política; solo esto evita que se vuelva a proponer la alternativa.

Enfoques ya rechazados en esta base de código. La categoría que no aparece en ningún archivo de instrucciones ni en ningún mensaje de commit, y que se vuelve a proponer en cada nueva sesión.

Hechos del entorno que nadie anuncia. La prueba que solo falla en CI, el límite de velocidad no documentado, el requisito de orden entre dos migraciones.

Paso 3: Conecta tu IA y agentes

Conecta las herramientas que utilizas. Se puede acceder a MemoryLake a través de MCP y de una API, por lo que los agentes nativos de MCP —entre ellos Claude Code, Codex y OpenClaw— se conectan apuntando al servidor MCP, mientras que otros asistentes leen la misma memoria a través de la API. Lo que significa que puedes ejecutar Zed y Claude Code de forma paralela en el mismo repositorio sin tener que mantener dos copias del mismo razonamiento.

Tres límites honestos. MemoryLake no escribe tu CLAUDE.md, tu AGENTS.md ni tus habilidades —así es como diriges cada herramienta, y el comportamiento del cargador mencionado anteriormente es de ellas, no algo que una capa de memoria cambie. Solo contiene lo que tú o tus agentes introducen en ella, por lo que el Paso 2 es manual. And las instrucciones son contexto en lugar de una configuración forzada; para cualquier cosa que deba cumplirse siempre, la propia respuesta de Claude Code es un hook, no un archivo.

"¿Qué archivo está activo?" se convierte en una comprobación de una sola línea. Zed toma la primera coincidencia de nueve candidatos. Ahora conoces la lista y el orden.

Los archivos eclipsados dejan de ser minas terrestres. Una vez que hayas leído los archivos descartados y fusionado lo que importaba, no habrá ningún .cursorrules olvidado esperando para confundir a la siguiente persona.

Las habilidades dejan de ser específicas de una herramienta. El mismo SKILL.md se ejecuta en Zed, Claude Code, Cursor y Codex. Lo escribiste una vez.

Los archivos de instrucciones se vuelven más cortos. Las reglas con alcance de ruta significan que las secciones "cuando se trabaja en X" dejan de cargarse en cada mensaje.

Un compañero de equipo en un editor diferente no es una bifurcación. Un archivo de instrucciones autoritativo más una capa de memoria consultable es mejor que dos archivos que se van distanciando; el formato cubierto en lo que realmente significa la memoria persistente.

Encuentra el archivo ganador antes de cambiar nada. Zed lee la primera coincidencia desde .rules hasta GEMINI.md; todo lo que venía después estaba inerte.

Lee los archivos eclipsados y luego elimínalos. Pueden contener restricciones que no se han aplicado en meses.

Cambia el nombre a CLAUDE.md o importa AGENTS.md desde él. Importa cuando otros agentes o compañeros de equipo todavía lean AGENTS.md; cambia el nombre cuando no lo hagan.

Mueve las habilidades carpeta por carpeta, luego verifica si hay conflictos de nombres. Las habilidades personales superan a las de proyecto en Claude Code, lo cual es lo opuesto a la precedencia de instrucciones de Zed.

Espera que tu archivo personal importe más, no menos. Las instrucciones del proyecto de Zed lo anulaban; Claude Code concatena ambos.

Divide el texto siempre activo en reglas con alcance de ruta. Un campo paths: en el frontmatter es el contenedor que Zed no tenía.

Verifica con /context, no con la memoria. La lista de archivos de memoria (Memory files) es lo que realmente se cargó.

Abre la carpeta de memoria automática después de una semana. Está activada por defecto y contiene lo que tu archivo de instrucciones deliberadamente no incluye.

Mantén el razonamiento fuera del archivo de instrucciones. Ambas herramientas limitan lo que transportan, y el razonamiento es lo primero que se recorta; el problema general detallado en por qué los agentes ignoran los archivos de instrucciones que escribiste.

La transición de Zed a Claude Code parece un simple cambio de nombre y en su mayor parte lo es, pero en el cambio de nombre es donde reside el riesgo. Zed elige el primer archivo de instrucciones de proyecto que coincida de una lista de nueve elementos en la que AGENTS.md precede a CLAUDE.md; Claude Code lee CLAUDE.md y no AGENTS.md. Por lo tanto, el archivo que ha estado guiando a tu agente puede no ser el archivo que lo guiará mañana, y la documentación de Zed ya te advierte que no asumas que su cargador controla a otros agentes.

Las habilidades son la mitad fácil: ambas herramientas son carpetas que contienen SKILL.md, por lo que ~/.agents/skills/ se convierte en ~/.claude/skills/ y las descripciones siguen funcionando. Presta atención a la inversión de la precedencia —las habilidades personales ganan en Claude Code, mientras que las instrucciones del proyecto ganaban en Zed— y recuerda que los nombres de archivo de compatibilidad de Zed no tienen lector en el otro lado.

Audita qué archivo estaba activo, fusiona los que no lo estaban, decide entre cambiar el nombre e importar, divide el texto siempre activo en reglas con alcance de ruta y coloca las decisiones y los enfoques rechazados en un lugar que ambos editores puedan consultar. Así, la lista de prioridad del cargador dejará de ser algo que tengas que recordar de memoria.