Trabajo a diario en tres equipos distintos. Un Mac de sobremesa, un portátil Surface con Windows 11 sobre arquitectura ARM64, y un PC de sobremesa con Windows 11 sobre arquitectura x86, donde además tengo instalado WSL (un Linux que corre dentro de Windows, lo explico en un minuto). Durante meses, cada cambio de equipo me costaba lo mismo: media hora larga reinstalando cosas, ajustando rutas y descubriendo que un comando que ayer funcionaba hoy no estaba. La frase "en mi equipo sí funciona" dejó de hacerme gracia.
En algún momento me di cuenta de que el problema no era tener tres máquinas. Era tratarlas como si fueran tres proyectos. Lo que quería, y lo que acabamos montando en EuroCastalia, es que la máquina dé igual: que al sentarme en cualquiera de las tres tenga el mismo entorno, las mismas herramientas con los mismos nombres y los archivos en las mismas rutas. Que lo portable sea la persona, no solo sus ficheros. Este artículo cuenta por qué lo hacemos así. El cómo se toca lo justo.
En EuroCastalia, el trabajo con agentes de IA en terminal se reparte entre tres plataformas: macOS, Windows nativo y WSL (Windows Subsystem for Linux, un Ubuntu completo que arranca dentro de Windows). Cada una llega de fábrica con su propio gestor de paquetes, sus rutas y su forma de instalar software. En Mac se usa Homebrew. En Windows, winget. En WSL, apt más algún binario descargado a mano.
El coste de esa diversidad no se ve en una factura. Se ve en el tiempo perdido cada vez que alguien se cambia de sitio o se incorpora al equipo. Se reinstala, se reconfigura, y aun así aparecen diferencias sutiles entre una máquina y otra. Un script que da un resultado distinto. Una ruta que existe en un portátil y en otro no. Un agente que se comporta bien en Mac y raro en Windows.
La pregunta que ordena todo lo que viene: ¿cómo consigues que sea la persona la que se mueve entre máquinas sin tropezar con el entorno, y no solo los archivos que copia de una a otra?
La respuesta no pasa por igualar los tres sistemas operativos. Son distintos y van a seguir siéndolo. Encima de ellos construimos una capa lógica común: un entorno de trabajo que se comporta igual esté sobre el hardware que esté.
Esa capa se apoya en tres principios.
El resto del artículo baja estos tres principios a cinco piezas concretas: WSL como base común, Markdown plano sobre git como sustrato, dos repositorios separados, unidades de red montadas y un repo único de capacidades con un arnés que reparte trabajo entre varios agentes.
Figura 1. Las tres plataformas físicas, a la izquierda. En el centro, un entorno lógico idéntico. A la derecha, lo que de verdad importa: los repos y los agentes.
Windows nativo y macOS se parecen poco cuando bajas al terminal. Los comandos, las rutas y los binarios son otra cosa en PowerShell que en un shell de Unix. macOS y Linux, en cambio, pisan casi el mismo terreno: la shell es compatible, las rutas se escriben igual y la mayoría de herramientas se llaman y se comportan igual.
Por eso la base recomendada para trabajo intensivo es WSL. Al meter un Ubuntu dentro de Windows, ese portátil pasa a comportarse como un Mac a efectos prácticos. El SOP de nueva máquina lo formaliza con una regla: el perfil [WSL] sigue las instrucciones marcadas [MAC] salvo excepción explícita. Un solo cuerpo de instrucciones cubre dos plataformas.
La misma lógica vale hacia los agentes. El entorno que espera Claude Code y el que espera Codex se parecen mucho más en bash que en PowerShell, así que trabajar en WSL reduce los casos raros.
Hay una regla operativa que conviene no saltarse: el repositorio se clona en el sistema de archivos de WSL (por ejemplo ~/CBB_AITeam), nunca en /mnt/c/. Un repo git en /mnt/c/ sufre entrada y salida lenta y problemas de permisos.
Windows nativo no se abandona. Sigue siendo un cuarto perfil válido, con sus propios comandos winget, pero no es la ruta por defecto.
El conjunto de herramientas tampoco es abstracto. Es una carpeta, Tools/, con una subcarpeta autocontenida por herramienta, idéntica en las tres máquinas:
Tools/
├── antigravity-cli/
├── codex-cli/
├── deslop/
├── extract-msg/
├── gh/
├── jq/
├── libreoffice/
├── openpyxl/
├── pandoc/
├── pdfplumber/
├── plaud-cli/
├── playwright-cli/
├── pymupdf/
├── pypdf/
├── python-docx/
├── ripgrep/
├── strava-cli/
├── surge/
└── INDEX.mdListado 1. El catálogo de herramientas: 18 subcarpetas, la misma lista en las tres máquinas. Que el conjunto sea idéntico en todas es buena parte de lo que hace la operativa reproducible y predecible.
| Herramienta | Mac [MAC] |
Windows nativo [WIN] |
WSL [WSL] |
|---|---|---|---|
| pandoc | brew install pandoc |
winget install JohnMacFarlane.Pandoc |
binario oficial de GitHub a ~/.local/bin (no apt) |
| jq | brew install jq |
winget install jqlang.jq |
sudo apt install jq -y |
| playwright-cli | npm install -g @playwright/cli |
npm install -g @playwright/cli |
npm install -g @playwright/cli |
Tabla 1. La misma herramienta en las tres plataformas. Las columnas Mac y WSL casi coinciden. La de Windows nativo es la que va por libre.
Todo el conocimiento del sistema (procedimientos, índices, registros de sesión, notas) vive en Markdown plano dentro de repositorios git. No en la base de datos de una aplicación, ni en un formato propietario.
Markdown plano porque se abre igual en todas partes. Desde VSCode, desde Obsidian (sin necesidad de plantilla ni de plugins) y desde cualquier editor de texto. El día que cambie la herramienta de moda, el texto sigue ahí, legible.
Git porque aporta cuatro cosas que un sistema de carpetas compartidas no da: historial completo, diferencias que un humano lee, sincronización entre máquinas y un mecanismo de resolución de conflictos que se entiende.
La excepción confirma la regla. Hay una base de datos operativa en SQLite, y SQLite es un binario que git no sabe fusionar. Eso obliga a un protocolo estricto: git pull al empezar la sesión, git push al cerrarla, y si aparece un conflicto binario se conserva la copia más reciente. Es un incordio. Precisamente por eso todo lo demás se guarda en texto plano.
Un detalle que ahorra discusiones: el repositorio incluye un .gitattributes con la línea * text=auto eol=lf. Impone finales de línea LF en todos los archivos de texto, así que Mac y Windows dejan de pelearse por el CRLF y el mismo archivo es byte a byte idéntico en las dos.
El sistema del equipo (el repositorio AITeam) y el conocimiento personal del owner (el repositorio PKM) son dos repos git independientes, no dos carpetas dentro del mismo.
Se separan por tema y por privacidad. Quien quiera mantener lo personal aparte de lo profesional tiene la frontera hecha a nivel de repositorio. En cada máquina se clona y se actualiza solo el repo que haga falta. No hay obligación de llevar los dos a todas partes. Una fuente de verdad por asunto, y ya.
El trabajo real toca archivos que no están en ningún repo: servidores de la empresa, un NAS, carpetas compartidas de Windows.
En WSL esos recursos se montan como unidades a través de drvfs y aparecen como rutas locales normales, del estilo /mnt/x o /mnt/y. Para el código, y para las instrucciones que le damos a un agente, un archivo del servidor de administración se referencia igual que uno del disco. No hace falta saber dónde está físicamente.
Para que el montaje sobreviva a un reinicio de WSL, esas unidades se añaden a /etc/fstab.
Y aquí va un matiz que el SOP documenta en lugar de esconder: WSL solo automonta las unidades de red que ya existían cuando arrancó la sesión. Las que se mapean en Windows más tarde se quedan huérfanas hasta que alguien las monta a mano. Pasó el 30 de julio de 2026 con dos unidades nuevas apuntando a un servidor de la empresa: Windows las veía, WSL no. El procedimiento recoge el diagnóstico (mount | grep drvfs contra lo que ve Windows) y el arreglo.
Las capacidades que usan los agentes (skills y plugins) viven en un repositorio único, compartido entre plataformas y entre agentes. No se reinstala capacidad por capacidad en cada máquina: se define una vez.
Desde un mismo entorno (VSCode, u Obsidian con una terminal abierta) se puede lanzar cualquiera de los cuatro CLI que usamos: Claude Code, Codex, Antigravity (el comando es agy) y Copilot.
El patrón de trabajo es este. Eliges el arnés que prefieras, por ejemplo Claude Code, y es el propio agente el que dirige el tráfico hacia los demás según la tarea. Antigravity se lleva la extracción de vídeos de YouTube, el trabajo dentro del entorno de Google, los PDF grandes y las tareas autónomas largas. Codex se lleva la revisión de código, la maquetación de archivos y la generación de imágenes. Copilot se queda con el autocompletado dentro del editor. Cada uno tiene su cuota de uso y su punto fuerte.
El arnés funciona como cabina de mando. Orquesta a los otros agentes en lugar de intentar hacerlo todo dentro de la misma sesión. Así se evita mezclar contextos que no tienen nada que ver.
Figura 2. Un agente en el centro reparte el trabajo. Cada flecha lleva escrito para qué.
El criterio fino de ese reparto (qué agente para qué tarea, y con qué regla se decide) da para un artículo entero, y llegará más adelante.
Todo lo anterior se levanta con un checklist por fases: el SOP de nueva máquina (versión 0.2). Lleva de "repositorio recién clonado" a "sistema operativo" en una máquina nueva. Es la forma concreta del principio de replicabilidad.
No hace falta reproducirlo entero. Tres decisiones de diseño explican cómo está pensado.
Lee los índices vivos, no fija versiones. Cada fase consulta Tools/INDEX.md y Skills/INDEX.md en el momento de ejecutarse. Así el procedimiento no caduca cada vez que sube la versión de una herramienta.
Un solo documento para las tres plataformas. Con marcadores [MAC], [WIN], [WSL] y [ALL], cada paso dice a quién aplica. Y como [WSL] hereda de [MAC], la mayoría de los pasos se escriben una vez.
Aprende con el uso. Cada ejecución real deja una fila en una tabla de aprendizajes: qué funcionó y qué mejorar. Ahí está registrado, por ejemplo, que en WSL no se instala pandoc con apt porque sirve una versión de hace dos años (la 3.1.3 en Ubuntu 24.04), o que hay una máquina, una Ubuntu 24.04 conocida internamente como EC-CBB-GT13, donde el checklist completo pasó sin bloqueos el 12 de julio de 2026.
Figura 3. Las nueve fases del SOP, de los prerrequisitos a la verificación final.
La última fase es una tabla de verificación con checks objetivos. claude --version imprime algo o no lo imprime. La base de datos tiene tablas o no las tiene. La máquina está lista, o no lo está, sin lugar para la opinión.
Hay una pieza que a propósito no viaja con el repo: settings.local.json. Contiene los permisos específicos de cada máquina y está en .gitignore. Se crea a mano en cada sitio. Lo que es de una máquina se queda en esa máquina.
Vuelvo a los tres principios del comienzo, ya con las piezas sobre la mesa.
La estandarización de herramientas es lo que consigue WSL: el mismo set en las tres plataformas porque WSL acerca Windows a Mac. Y el catálogo de utilidades (Tools/) tiene un criterio de entrada que conviene subrayar: entran herramientas deterministas que no gastan tokens de IA. pandoc convierte formatos. jq filtra JSON. Ninguna de las dos necesita un modelo detrás, y eso se mantiene aparte, a propósito, de lo que sí requiere juicio.
Las rutas uniformes salen de tres decisiones pequeñas: el repo siempre en la misma ubicación lógica, las unidades de red montadas como rutas locales y los finales de línea en LF en todas partes. Con eso, ni el código ni las instrucciones necesitan saber en qué disco físico está un archivo.
La replicabilidad hace que incorporar a alguien sea correr un procedimiento versionado, en vez de reconstruir en su cabeza un conocimiento que vivía en la de otra persona.
Debajo de los tres hay una misma intención: que el criterio viva en un solo sitio y no se vaya duplicando y divergiendo máquina a máquina. Que la persona sea portable.
Hay además una apuesta a largo plazo, y es deliberada: texto plano. Las herramientas de IA de este año van a cambiar. Markdown y git llevan más de una década funcionando y no dependen de ninguna de ellas.
Si te acabas de incorporar, la ruta mínima para reproducir la base es corta: instalar WSL, clonar el repositorio (o los dos, si necesitas también el personal), correr el SOP de nueva máquina y autenticar los CLI.
Aunque no adoptes el resto, dos cosas ya cambian la forma de trabajar por sí solas. La pareja Markdown plano más git para todo el conocimiento. Y la idea de un catálogo de herramientas deterministas, separadas de lo que necesita un modelo.
Para ir al detalle: el SOP de nueva máquina sirve como referencia paso a paso, y Tools/INDEX.md es el catálogo con el estado de cada utilidad por plataforma.
Esto no es un manual de instalación. Es la foto de por qué el sistema está montado así y de cuáles son sus piezas principales.
Vuelvo a lo del principio. Cuando cambio del Mac al portátil ya no pierdo la media hora. Abro la terminal, y el entorno es el mismo: las herramientas se llaman igual, los archivos están donde los espero y el procedimiento para poner al día una máquina está escrito. La meta nunca fue tener tres equipos bien configurados. Era que diera igual en cuál me siento. Si mañana quieres empezar por algún sitio, empieza por ahí: instala WSL, crea un repositorio en Markdown y git, y construye a partir de eso.