Arquitectura ~/.claude con más de 200 skills: cómo mantener el prompt del sistema en 50 000 tokens y pagar 0,15 $ por sesión

• Tamaño del prefijo del sistema: 40 000-50 000 tokens (CLAUDE.md 8K + reglas 20-30K + descripciones 15K)
• Ahorro por prompt caching: 10 veces (0,15 $ por sesión en lugar de 1,50 $ sin caché)
• Velocidad de generación de presentaciones: 6 minutos 14 segundos para 12 diapositivas (3,8 MB en PPTX)
• Protección contra inyecciones de prompt: 5 perímetros aislados y 3 bloqueos rígidos de PreToolUse

En la primavera de 2025, cuando el término "vibe coding" recién empezaba a circular y las instalaciones de Claude Code todavía no superaban los quince millones, yo me enfrentaba a un problema puramente de gestión. Como CPO de AlpinaGPT, me ahogaba a diario en decenas de llamadas, hilos de correo y chats de trabajo: los acuerdos se perdían en las costuras entre canales. Necesitaba un cerebro digital activo las 24 horas, apoyado en una única base vectorial, capaz de enlazar por sí mismo las promesas hechas en Zoom con los correos y de recordarme los plazos con antelación —el prototipo de lo que más tarde se convertiría en la arquitectura OpenClaw.

Un agente de terminal desnudo, recién salido de la caja, solo sabe realizar operaciones básicas de lectura y escritura de archivos. Para transformarlo en una máquina de ingeniería, tras un año de experimentos construí en el directorio `~/.claude/` un sistema modular de siete capas: un `CLAUDE.md` de navegación, reglas permanentes en `rules/`, skills que se cargan a demanda en `skills/`, subagentes aislados en `agents/`, comandos slash explícitos en `commands/`, conectores externos vía `mcp.json` y hooks de eventos en `hooks/`.

¿Por qué una biblioteca de más de 200 skills no desborda la ventana de

contexto ni arruina en tokens?

El error principal al configurar un agente es amontonar todas las instrucciones en el `CLAUDE.md` raíz, inflándolo hasta las 4000 líneas. Cualquier edición de ese monolito reinicia la caché de prefijo de Anthropic, obligando a pagar el precio completo en cada paso del diálogo. En mi configuración, el tamaño de la biblioteca de skills en disco y el tamaño del contexto activo están completamente desacoplados.

Al inicio de la sesión solo se carga en memoria un mapa compacto del terreno: un `CLAUDE.md` raíz de 200-300 líneas (unos 8K tokens), 20-25 archivos de reglas básicas en `rules/` (20-30K tokens) y breves anotaciones de skills y servidores MCP (otros 15K). Todo el prefijo inicial cabe en 40 000-50 000 tokens, mientras que el grueso de instrucciones y scripts, con un peso de unos 300K tokens, espera su turno en el disco.

Como el prefijo permanece invariable de una solicitud a otra, se activa el prompt caching: la sesión cuesta 0,15 $ en lugar de 1,50 $, y la respuesta tarda 1-2 segundos. La regla principal de operación es no editar nunca los archivos de `rules/` a mitad de un diálogo en curso y usar el comando `/compact` para comprimir el historial, en vez de borrarlo por completo.

¿Cómo funciona el enrutamiento mediante routing.md y la

autorreplicación de skills?

El eslabón que conecta toda la configuración es la tabla de enrutamiento `rules/routing.md`, con más de 300 líneas, que funciona bajo el principio "disparador clave → herramienta concreta". Si una tarea surge menos de una vez al día, no tiene sentido meterla en las reglas permanentes: se empaqueta como un módulo independiente en `~/.claude/skills/<nombre>/SKILL.md`, con sus propios scripts de trabajo dentro.

Un ejemplo claro es el generador de presentaciones `manus-slides`. Cuando escribo en la terminal una solicitud para un pitch de inversores de 12 diapositivas en estilo pizarra blanca (`whiteboard`), el enrutador detecta el disparador con una confianza de 0,94, carga 4,2K tokens de instrucciones y pone en marcha el pipeline. Claude construye la estructura, envía en paralelo 12 solicitudes a `gemini-3.1-flash-image-preview` y, mediante scripts de Python, ensambla el archivo final `presentation.pptx` de 3,8 MB. Todo el ciclo dura 6 minutos 14 segundos en lugar de una jornada laboral completa.

Con el mismo principio funciona un wrapper sobre Telethon (`tg_client.py`, con más de 50 comandos) para exportar analítica y menciones de canales de Telegram a CSV, así como el meta-skill `skill-creator`. Basta pedirle una vez al agente que construya un skill para analizar extractos bancarios en PDF: él mismo crea la carpeta, escribe el frontmatter YAML con los disparadores, coloca el script correspondiente y añade la línea en `routing.md`. Precisamente esta arquitectura de máquina personal de IA la analizamos en la práctica en [Hamidun Academy](https://academy.hamidun.com) y la seguimos desarrollando dentro de la comunidad de ingeniería [Vibe Club](https://hamidun.com/club).

¿Cómo proteger a un agente autónomo en modo bypassPermissions frente

al borrado de bases de datos y las inyecciones de prompt?

Trabajo en modo `bypassPermissions`, sin confirmación manual en cada paso, porque el seguro se traslada al nivel del entorno de ejecución. Cuando el agente lee correos ajenos, páginas web o código, los datos externos siempre se tratan como contenido no confiable, nunca como órdenes.

La seguridad se sostiene sobre cinco frentes: 1. Aislamiento físico de claves: todos los secretos residen en `~/.claude/.

credentials.master.env`, fuera del repositorio, y se pasan a los scripts mediante `os.

getenv()` —el modelo nunca ve los valores reales de `TELEGRAM_API_ID` ni de las claves de pago dentro del diálogo. 2. Hooks rígidos de PreToolUse: en `settings.

json` hay tres interceptores ligeros que devuelven de inmediato `exit 1` ante cualquier intento de invocar `rm -rf`, `DROP DATABASE` o `DROP TABLE`. 3. Perímetro de solo lectura para revisores: los subagentes de auditoría de código y seguridad reciben en su lista blanca únicamente `Read`, `Glob` y `Grep`, sin permisos de escritura ni de invocar shell.

4. Saneamiento del flujo entrante: antes de pasar el texto de un correo al modelo, el script `gmail_search.py` elimina construcciones como "ignore previous instructions", sustituyéndolas por la marca `[REDACTED:injection]`.

5. Pruebas de aceptación adversarial y delegación: antes de desplegar un bot nuevo lo sometemos a un conjunto de pruebas de ataque, y divido las tareas entre subagentes desde el Nivel 0 (hacerlo yo mismo) hasta el Nivel 3 (orquestador más trabajadores en `git worktree`, con indicación exacta de archivo y línea).