Mantén tus repositorios independientes del entorno de IA
En una semana normal uso cuatro entornos de IA. Un IDE con navegación rápida por los archivos para explorar, una CLI para proyectos personales, una aplicación de escritorio para el trabajo y, de vez en cuando, una cuarta herramienta para pedir otra opinión sobre el mismo repositorio.
No lo recomiendo, simplemente es mi situación. Y tiene una consecuencia: lo que configuro dentro de una herramienta es invisible para las otras tres. La memoria de una sesión guardada, una habilidad en el formato de alguna plataforma, un archivo de configuración específico de una herramienta. Todo desaparece en cuanto abro la misma carpeta en otro sitio.
Así que sigo una regla sencilla: solo se comparten entre los entornos los archivos reales del repositorio. Todo lo demás es una comodidad que tengo alquilada.
Dónde abro la carpeta
- Un IDE
- Una CLI
- Una aplicación de escritorio
- Lo que salga el mes que viene
El repositorio
- skills/, un archivo Markdown por procedimiento
- AGENTS.md, con CLAUDE.md como enlace simbólico
- Decisiones y convenciones documentadas
Qué recibe cada uno
- Los mismos procedimientos
- Las mismas convenciones
- Desde el primer día, sin configurar nada
De ahí se desprenden tres cosas.
Un archivo en el repositorioCompartido
- Todos los entornos lo leen
- Se conserva aunque aparezca una nueva herramienta
- Está en el diff, así que se revisa
- Puedes volver a leerlo dentro de seis meses
Todo lo que está dentro de un entornoAlquilado
- La memoria guardada de una sesión
- Una habilidad en el formato de esa plataforma
- Un archivo de configuración específico de una herramienta
- Servidores MCP y sus credenciales
Solo se comparten entre entornos los archivos reales, así que
tres reglas
1. Habilidades en Markdown sin formato, no en el formato de una plataforma
Aquí, una habilidad no es más que un procedimiento: cómo importar un extracto bancario, publicar un artículo o ejecutar una traducción. Todos los entornos de IA importantes tienen ya su propio formato para estas cosas, y todos son distintos.
Escribirlas en el formato de un proveedor te da autocompletado, pero te hace perder portabilidad. Por eso uso una versión más sencilla: un archivo Markdown por procedimiento, dentro de una carpeta skills/ en el repositorio.
skills/
transaction_import_skill.md
linkedin_post_skill.md
video_editing_skill.mdDespués las enumero en el archivo de instrucciones, con una ruta y una línea que indique cuándo usarlas:
| Habilidad | Cuándo usarla |
|---|---|
skills/transaction_import_skill.md | al integrar una exportación bancaria en el libro mayor |
skills/linkedin_post_skill.md | al convertir una idea o una fuente en una publicación lista para publicar |
Cualquier agente, con cualquier herramienta, puede leer esa tabla, abrir el archivo que necesita y seguir sus instrucciones. No hay que instalar nada ni registrar nada. Cuando aparece un nuevo entorno de ejecución, funciona desde el primer día.
2. Un archivo de instrucciones con enlaces simbólicos
AGENTS.md se está convirtiendo en la convención, y varias herramientas lo leen directamente. Una de las herramientas que uso busca CLAUDE.md en su lugar.
Basta con un ln -s para dejar de tener ese problema:
ln -s AGENTS.md CLAUDE.mdAhora hay un archivo, cuatro lectores y una regla escrita al principio: solo se edita AGENTS.md. El enlace simbólico se actualiza solo.
Qué buscan las herramientas
- AGENTS.md, directamente
- CLAUDE.md, y nada más
- AGENTS.md, pero solo si no existe CLAUDE.md
Un solo archivo en disco
- AGENTS.md es el archivo
- CLAUDE.md es un enlace simbólico a él
- Solo se edita AGENTS.md
Qué evita
- Que dos archivos diverjan
- Dos agentes y dos convenciones
- Actualizar una regla en solo uno de ellos
Lo que se evita no es nada espectacular, y por eso merece la pena hacerlo. Al cabo de unas semanas, los dos archivos de instrucciones divergen y acabas con dos agentes que siguen con total seguridad convenciones distintas dentro del mismo repositorio.
3. Da por hecho que la memoria no sobrevive a la sesión
Cada entorno de ejecución tiene algún tipo de memoria persistente, pero ninguna la comparte con las demás. Así que dejo por escrito en archivos todo lo que importa: las decisiones, en un registro; las convenciones, en las instrucciones; y los procedimientos, en una habilidad.
Parece trabajo extra. En la práctica, es el mismo trabajo hecho una vez en lugar de cuatro, y tuvo un efecto secundario que no esperaba. Lo que escribo para que lo lea un agente también resulta útil para que lo lea yo seis meses después. Mis notas mejoraron cuando empecé a redactarlas para alguien sin ningún contexto.
Lo que aún no he resuelto: los servidores MCP
Hay que configurar las conexiones MCP por separado en cada entorno de ejecución. Los mismos servidores, las mismas credenciales, cuatro configuraciones que acaban divergiendo.
Además, supone un gasto innecesario que se nota en la factura. Uno de los servidores de analítica que uso ofrece 275 herramientas. Las definiciones de todas ellas, con sus descripciones y esquemas, ocupan espacio en el contexto en cada solicitud, aunque quizá solo use cuatro.
Un servidor MCP en cada solicitudantes de que haya preguntado nada
- 275 definiciones de herramientasCada una con su descripción y su esquema de carga útil
- Las cuatro que uso de verdadYa están incluidas arriba. A escala.
- Left for your actual work
Mi hipótesis sobre cómo evolucionará esto: un único servidor MCP al que te conectas una vez en cada entorno de ejecución y que luego gestiona qué subservidores y qué subconjunto de sus herramientas se exponen en cada proyecto. Algo parecido al modo de código de Cloudflare ayudaría: sustituiría el aluvión de definiciones de herramientas por una interfaz reducida a la que el modelo llamaría mediante código. También resolvería otra molestia: ejecutar el mismo servidor con cuentas distintas según el proyecto.
Si alguien ya ha resuelto esto, me gustaría saber cómo. Es la última pieza de mi configuración que sigue dependiendo de herramientas en vez de archivos.