---
title: "Mantén tus repositorios independientes del entorno"
description: "Uso cuatro herramientas de codificación con IA diferentes en una semana normal. Tres prácticas mantienen mis repositorios compatibles con todas ellas, y un problema que aún no he resuelto."
date: 2026-08-12
language: es
canonical: https://gduv.club/es/articles/harness-agnostic-workspaces
source: gduv.club
---
Utilizo cuatro entornos de IA en una semana normal. Un IDE con navegación rápida de archivos cuando estoy explorando, una CLI para proyectos personales, una aplicación de escritorio para el trabajo y, ocasionalmente, una cuarta cuando quiero una segunda opinión sobre el mismo repositorio.

No es una recomendación, es simplemente mi situación. Y tiene una consecuencia: cualquier cosa que configure dentro de uno de ellos es invisible para los otros tres. Una memoria de sesión guardada, una habilidad en el formato de alguna plataforma, un archivo de configuración por herramienta. Todo desaparece en el momento en que abro la misma carpeta en otro lugar.

Así que la regla que sigo es sencilla. **Solo los archivos reales del repositorio se comparten entre entornos.** Todo lo demás es una conveniencia que estoy alquilando.

De ahí se derivan tres cosas.

## 1. Las habilidades son Markdown simple, no un formato de plataforma

Una habilidad aquí es simplemente un procedimiento: cómo importar una exportación bancaria, cómo publicar una entrada, cómo ejecutar una traducción. Actualmente, cada entorno serio tiene su propio formato para esto, y todos son diferentes.

Escribirlas en el formato de un proveedor te da el autocompletado, pero te quita la portabilidad. Por eso utilizo una versión más simple: un archivo Markdown por procedimiento, en una carpeta `skills/` en el repositorio.

```
skills/
  transaction_import_skill.md
  linkedin_post_skill.md
  video_editing_skill.md
```

Luego los enumero en el archivo de instrucciones con una ruta y una línea sobre cuándo usarlos:

| Habilidad | Usar cuando |
| :--- | :--- |
| `skills/transaction_import_skill.md` | integrar una exportación bancaria en el libro mayor |
| `skills/linkedin_post_skill.md` | convertir una idea o una fuente en una publicación publicable |

Cualquier agente, en cualquier herramienta, puede leer esa tabla, abrir el archivo que necesite y seguirlo. No hay tiempo de ejecución ni nada que registrar. Cuando aparece un nuevo entorno, funciona desde el primer día.

## 2. Un solo archivo de instrucciones, mediante enlace simbólico

`AGENTS.md` se está convirtiendo en la convención, y varias herramientas lo leen directamente. Una de las herramientas que utilizo busca `CLAUDE.md` en su lugar.

Eso deja de ser un problema con un simple `ln -s`:

```bash
ln -s AGENTS.md CLAUDE.md
```

Ahora hay un solo archivo, cuatro lectores y una regla escrita en la parte superior: **solo se edita `AGENTS.md`**. El enlace simbólico se actualiza solo.

Lo que esto evita no es dramático, y por eso merece la pena hacerlo. Dos archivos de instrucciones divergen en unas pocas semanas, y terminas con dos agentes siguiendo con seguridad dos convenciones diferentes en el mismo repositorio.

## 3. Asumir que ninguna memoria sobrevive a la sesión

Cada entorno tiene alguna forma de memoria persistente y ninguno la comparte. Por eso, cualquier cosa importante la escribo en un archivo: decisiones en un registro, convenciones en las instrucciones, procedimientos en una habilidad.

Esto 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. Las cosas escritas para que las lea un agente resultan ser cosas que yo puedo leer seis meses después. Mis propias notas mejoraron porque empecé a escribirlas para un lector sin contexto alguno.

## La parte que no he resuelto: servidores MCP

Cada entorno necesita que sus conexiones MCP se configuren por separado. Mismos servidores, mismas credenciales, cuatro configuraciones, y acaban divergiendo.

También es ineficiente de una manera que se nota en la factura. Un servidor de analítica que utilizo expone 275 herramientas. Cada una de esas definiciones, con su descripción y esquema, ocupa contexto en cada solicitud, y yo llamo a quizá cuatro de ellas.

Mi previsión de hacia dónde va esto: un único servidor MCP que conectas una vez en cada entorno, el cual gestiona qué subservidores y qué subconjunto de sus herramientas se exponen por proyecto. Algo como el modo de código de Cloudflare ayudaría aquí, sustituyendo un aluvión de definiciones de herramientas por una interfaz pequeña que el modelo llama programáticamente. También solucionaría una segunda molestia: ejecutar el mismo servidor con diferentes cuentas dependiendo del proyecto.

Si alguien ya ha resuelto esto, me gustaría saberlo. Es la última pieza de mi configuración que sigue teniendo forma de herramienta en lugar de forma de archivo.