Construí mi sistema operativo de IA con Claude Code
Durante nueve años probé cada stack de productividad del mercado. Notion. ClickUp. Obsidian encima de Notion. Sunsama conectado al Calendar. Siete suscripciones SaaS simultáneas que prometían ser la "única fuente de verdad" y ninguna lo fue jamás. La verdad honesta es que ninguna de esas herramientas realmente pensaba conmigo — solo almacenaban cosas que yo ya había pensado.
Eso cambió hace tres meses cuando reconstruí todo mi flujo de trabajo dentro de una sola herramienta: Claude Code. No como asistente de programación. Como sistema operativo. Uno real — con skills, rutinas, agentes en la nube programados, un wiki de conocimiento en markdown y dashboards en vivo que extraen datos de ClickUp, Stripe, QuickBooks, Fireflies y Slack bajo demanda.
Este es el plano completo. Los frameworks que usé (las Tres M's y las Cuatro C's), los siete bloques de datos con los que empecé, la estructura exacta del repositorio, los skills que publiqué primero y el sistema de puntuación de auditoría que ejecuto cada domingo por la mañana para ver si el sistema operativo de IA Claude Code realmente se comporta como uno.
Si has estado intentando pegar ChatGPT más Zapier más siete dashboards y preguntándote por qué sigues sintiéndote ocupado — esto es lo que construiría en su lugar, sabiendo lo que sé ahora.
Por qué los stacks de productividad me fallaron en 2026
Esto es lo que nadie me dijo cuando compré mi cuarta plantilla de Notion. El cuello de botella en 2026 no es el almacenamiento de información. Es la recuperación de información en el momento de la decisión. Cuando un cliente envía un email a las 4:47 PM preguntando por qué el entregable tres tiene dos días de retraso, no necesito abrir mi "segundo cerebro". Necesito una respuesta en nueve segundos.
Las herramientas de productividad tradicionales comparten el mismo defecto fatal — asumen que yo soy el motor. La herramienta almacena. Yo pienso. Yo cruzo referencias. Yo sintetizo. Yo escribo el email. La página de Notion no redacta la respuesta. La tarea de ClickUp no concilia con la factura de Stripe. La transcripción de Fireflies no extrae la única decisión de una llamada de 47 minutos que realmente importa esta semana.
Cuando aparecieron los primeros runtimes de agentes útiles — Anthropic lanzó el Claude Agent SDK a finales de 2025, luego abrió los skills como primitivo de primera clase, y después lanzó rutinas alojadas en la nube el 14 de abril de 2026 — el costo de construir tu propio sistema colapsó. Lo que antes requería un stack de $40K con Zapier-más-Make-más-tres-ingenieros ahora cabe en un solo repositorio de archivos markdown.
Así que eliminé la mitad de mi stack SaaS y empecé de nuevo. El resultado es lo que llamo un AIOS: un sistema operativo de IA que piensa junto a mí, no detrás de mí.
Qué es realmente un AIOS (y qué no es)
Un sistema operativo tiene tres trabajos. Gestionar recursos. Mediar entre tú y tu hardware. Ejecutar programas en tu nombre cuando lo pides.
Un sistema operativo de IA hace lo mismo — pero los recursos que gestiona son cognitivos. Tus contextos. Tus decisiones. Tus relaciones. Tus proyectos. El hardware que media es tu cerebro más las docenas de APIs SaaS sobre las que funciona tu negocio. Los programas que ejecuta son skills, rutinas y tareas programadas que se ejecutan estés en tu escritorio o dormido.
Esa es la parte que la gente no ve. Un AIOS no es un chatbot con memoria. No es un reemplazo de Notion. Es un runtime que mantiene tu contexto, posee tus conexiones, expone tus capacidades como skills nombrados y los ejecuta en una cadencia que tú estableces.
Cuatro propiedades separan un AIOS real de una plantilla de prompt sofisticada:
- Mantiene tu contexto entre sesiones. Sin volver a explicar quién eres.
- Se conecta a datos en vivo. Extrae de tus herramientas reales, no de exportaciones obsoletas.
- Expone capacidades como skills nombrados y reutilizables. No prompts de un solo uso.
- Ejecuta en su propia cadencia. Algunos skills los disparas tú; otros se ejecutan solos a las 6 AM.
Si un sistema que estás construyendo no hace las cuatro cosas, tienes un chatbot. Útil — pero no un sistema operativo.
La buena noticia: Claude Code ya te da el runtime gratis. El trabajo está en la arquitectura que construyes dentro de él. Lo que me lleva a los dos frameworks que organizaron todo para mí.
Las Tres M's: Mentalidad, Método, Máquina
Antes de cualquier código, cualquier estructura de carpetas, cualquier skill — tres capas. Sáltalas y la construcción colapsa en la semana dos. Lo aprendí por las malas cuando mi primer intento se convirtió en 31 archivos markdown desorganizados que ni siquiera Claude podía navegar.
Mentalidad
El cambio de mentalidad es pequeño pero fundamental: la IA no es una máquina expendedora. Es un mentor.
Una máquina expendedora toma una moneda y da un snack. Preguntas, obtienes. Un mentor toma la pregunta, te hace tres de vuelta, te hace defender tu razonamiento y a veces te dice que la pregunta misma está mal. Esa es la relación que quieres con tu AIOS. No quieres un sistema que siempre diga sí. Quieres uno que diga "antes de redactar esta propuesta, ¿estás seguro de que el nivel de precio B se ajusta a la etapa de este cliente? Su última factura fue de $2,400."
Esto suena filosófico. Es profundamente práctico. Cada skill que escribes se configura por defecto para "ejecutar la solicitud" o para "interrogar la solicitud primero." Un sistema mentor se construye sobre el segundo modo.
Método
Método es el playbook de cómo tú y el AIOS trabajan juntos. El mío tiene cuatro reglas:
- Planificar antes de ejecutar. Cada skill no trivial devuelve un plan primero. Yo apruebo el plan, luego ejecuta.
- Citar la fuente. Cada afirmación está vinculada a un archivo, una transcripción o una respuesta de API. Sin vibraciones.
- Actualizar el wiki. Cada decisión significativa se convierte en un archivo markdown que futuras sesiones pueden leer.
- Auditar con cadencia. Puntuación semanal de las Cuatro C's (más sobre eso abajo). El número no miente.
Estas reglas viven en el CLAUDE.md raíz de mi repositorio AIOS. Cada sesión de Claude Code las lee automáticamente.
Máquina
La máquina es el stack real — el IDE, el repositorio, los skills, los conectores, el cronograma. Construiremos la máquina en un momento. El punto de las Tres M's es que Mentalidad y Método van primero. Si vas directo a la Máquina construirás una máquina expendedora más rápida. Que es precisamente lo que hice la primera vez.
Las Cuatro C's: La arquitectura real
Donde las Tres M's tratan de cómo piensas, las Cuatro C's tratan de qué construyes. Context. Connections. Capabilities. Cadence. En ese orden exacto. Tienen una dependencia secuencial — no puedes saltar adelante.
Context (el fundamento)
Context es todo lo que el sistema sabe sobre ti. Tu negocio, tus clientes, tus objetivos, tu tono, tus decisiones, tus restricciones. Sin Context, el AIOS trata cada prompt como una primera cita.
Context vive en markdown. Siempre markdown. Karpathy tenía razón cuando dijo que el formato amigable para LLM es texto plano en una carpeta que tú controlas — hay una ganancia de eficiencia de tokens de 70x sobre RAG y bases de datos vectoriales para bases de conocimiento a escala personal, y es más fácil de depurar porque puedes leer los archivos tú mismo.
Connections
Una vez que el sistema sabe quién eres, necesita alcanzar el mundo. Connections son tus APIs e integraciones — ClickUp, Google Workspace, Fireflies, Slack, Stripe, QuickBooks. Sin Connections, el AIOS es un cuaderno inteligente. Con Connections, puede leer tu calendario en vivo, extraer los ingresos de ayer, escanear las transcripciones de esta mañana y actuar.
Capabilities
Capabilities son skills — competencias nombradas y reutilizables que el sistema puede ejecutar. "Redactar un plan diario." "Auditar mi puntuación de Cuatro C's." "Generar el calendario de contenido de la próxima semana a partir de mis comentarios de YouTube." Cada uno es una carpeta con un archivo SKILL.md. El patrón de divulgación progresiva de Anthropic significa que cientos de skills pueden estar en tu repositorio y solo el relevante se carga en el contexto para cualquier tarea dada.
Cadence
Cadence determina cuándo se ejecutan las cosas. Algunos skills los disparas tú ("/daily-plan"). Algunos se ejecutan por cron ("cada lunes a las 6:00 AM, auditar la semana pasada"). Algunos viven en la nube y responden a eventos de GitHub. Cadence es lo que convierte a un asistente inteligente en un sistema operativo que trabaja mientras duermes.
La dependencia secuencial es lo que la mayoría de la gente hace mal. No puedes tener Cadence útil sin Capabilities. No puedes construir Capabilities útiles sin Connections. No puedes usar Connections inteligentemente sin Context. Así que los construimos en orden. Uno a la vez. Sin saltar.
Aquí también entra la auditoría — pero guardaré el esquema de puntuación para el final, después de que hayamos construido la cosa.
Paso 1: Los datos del plan — Siete bloques Tier-Uno
Antes de cualquier carpeta, cualquier código, cualquier skill — me senté y listé cada tipo de información que mi trabajo toca. Luego lo reduje despiadadamente a siete bloques. Siete, porque ese es aproximadamente el límite antes de que el sistema empiece a sentirse como un laberinto. Los tuyos podrían ser seis u ocho. El ejercicio importa más que el número.
Mis siete bloques Tier-Uno:
- Ingresos — Pagos de Stripe, libro mayor de QuickBooks, MRR, cuentas por cobrar
- Clientes — lista de clientes, estado, último contacto, valor de vida del cliente, entregables actuales
- Calendario — Feed de Google Calendar, esta semana, próximas dos semanas, bloques recurrentes
- Comunicación — Hilos de Gmail, DMs de Slack, notificaciones de comentarios que vale la pena seguir
- Tareas — Listas de ClickUp por proyecto, lista de hoy, lista de esta semana, elementos bloqueados
- Reuniones — Transcripciones de Fireflies, decisiones extraídas, elementos de acción extraídos
- Conocimiento — el wiki mismo: clientes, productos, decisiones, referencias, lecciones
Cada skill que escribo toca al menos uno de estos bloques. A menudo tres o cuatro. La lista de bloques se convirtió en el contrato: si una pregunta no puede responderse desde uno de estos siete, mi AIOS no tiene permitido inventarla. O me dice qué bloque llenar, o pregunta. Sin alucinaciones porque la forma de los datos es finita y nombrada.
Esto suena aburrido. Es el paso más importante con diferencia. Si te lo saltas, construirás skills que extraen de lugares aleatorios y tu contexto se convierte en papilla. Los bloques fuerzan disciplina.
Paso 2: VS Code, Claude Code y la estructura del repositorio
La máquina en sí es vergonzosamente simple. VS Code como editor. Claude Code (npm install -g @anthropic-ai/claude-code) como runtime. Un solo repositorio Git como todo el sistema operativo.
Aquí está la estructura exacta de carpetas que uso:
aios/
├── CLAUDE.md # prompt del sistema raíz: mentalidad + método
├── .env # claves API (gitignored)
├── .gitignore
├── .cloud/ # configuraciones de rutinas en la nube (sincronizadas con Anthropic cloud)
│ └── routines/
├── context/ # los siete bloques, como markdown
│ ├── revenue.md
│ ├── customers.md
│ ├── calendar.md
│ ├── communication.md
│ ├── tasks.md
│ ├── meetings.md
│ └── knowledge/ # el wiki LLM vive aquí
│ ├── clients/
│ ├── products/
│ ├── people/
│ └── _index.md
├── decisions/ # un .md por decisión importante, fechado
│ └── 2026-04-19-pricing-tier-update.md
├── references/ # referencia estática: SOPs, guías de marca, prompts
│ └── brand-voice-mejba-me.md
├── archives/ # cosas con más de ~90 días
└── .claude/
├── skills/ # skills personales (locales)
│ ├── onboard/
│ ├── daily-plan/
│ ├── four-cs-audit/
│ ├── linkedin-post/
│ └── youtube-comment-analysis/
└── agents/ # subagentes
Cinco reglas gobiernan este layout, y he roto cada una de ellas una vez y me arrepentí:
CLAUDE.mdraíz es corto. Menos de 200 líneas. Se carga en cada sesión — inflar lo y sangrarás tokens.- Los archivos de
context/son los bloques. Un archivo por bloque, máximo 800 líneas, luego dividir. decisions/es solo para agregar. Nunca edites un archivo de decisión. Nueva decisión, nuevo archivo, fechado.archives/existe por una razón. Cualquier cosa con más de ~90 días que no se referencia activamente se mueve allí. El sistema no debería releer tus pensamientos de enero cada mayo..cloud/se sincroniza con Anthropic. Solo pon rutinas en la nube y los skills que quieras ejecutables en sesiones cloud allí. Los skills locales se quedan en.claude/skills/.
La distinción de .cloud/ importa. Las rutinas en la nube de Anthropic (preview de investigación abierta el 14 de abril de 2026) solo acceden a skills a nivel de proyecto committed al repositorio. Los skills personales en ~/.claude/skills/ no viajan. Si quieres que una rutina ejecute un skill en la infraestructura de Anthropic durante la noche, ese skill debe estar registrado en el repositorio.
Si nunca has configurado un repositorio de Claude Code antes, mi guía de configuración de equipos de agentes cubre los básicos con más profundidad. De aquí en adelante asumo que tienes claude funcionando en una carpeta nueva.
Paso 3: El skill de onboarding — Enseñar al sistema quién eres
El primer skill que construí no hace nada impresionante. Me entrevista. Eso es todo.
Lo llamé onboard. Cuando ejecuto /onboard, Claude recorre unas 40 preguntas sobre los siete bloques — cuál es mi modelo de negocio, quiénes son mis cinco principales clientes, cuál es mi tarifa por hora, cuál es mi voz de marca, cómo se ve una "buena semana", qué estoy deliberadamente no persiguiendo, cuáles son mis innegociables. Cada respuesta va al archivo de contexto correspondiente como markdown estructurado.
¿Por qué guiado por entrevista? Porque si me sentara a escribir customers.md desde cero, procrastinaría tres semanas. La conversación no tiene fricción. El skill convierte mi hablar en contexto estructurado que el sistema puede usar para siempre.
Aquí está el SKILL.md abreviado:
---
name: onboard
description: Interview the user across the seven AIOS buckets and populate the context/ folder with structured markdown. Use when the user types /onboard or asks to set up their AIOS for the first time.
---
# Onboarding Skill
You are interviewing the user to populate their AI operating system's context.
Work through the seven buckets in order: Revenue, Customer, Calendar,
Communication, Tasks, Meetings, Knowledge.
For each bucket:
1. Ask 4-7 specific questions, one at a time.
2. After each answer, restate what you heard in one sentence.
3. When the bucket is done, write the markdown file to context/[bucket].md.
4. Show the user the file. Ask if anything's wrong before continuing.
Rules:
- Never invent answers. If the user doesn't know, write "TBD" with a date.
- Cite the source of every fact (e.g., "per user, 2026-04-15").
- Keep each context file under 800 lines. If longer, split.
Output format: structured markdown with H2 sections per topic, bulleted facts.
Eso es todo. ~25 líneas incluyendo frontmatter. El skill se carga solo cuando se llama, cuesta esencialmente cero tokens al inicio de sesión y produce el fundamento del que depende todo lo demás. Después de ejecutar /onboard una vez, cada sesión futura comienza sabiendo exactamente quién soy y en qué estoy trabajando.
Este es también el beneficio más subestimado del primitivo de skills: puedes escribir un skill cuyo único trabajo es poblar el contexto que futuros skills leerán. El sistema se auto-inicializa.
Paso 4: La capa de Connections — Conecta tus herramientas reales
Aquí es donde la mayoría de los builds de AIOS personales se estancan. La gente imagina que necesita un servidor MCP personalizado para cada herramienta. No es así. En el 90% de los casos la respuesta correcta es una llamada API directa desde un skill, con credenciales en .env.
Explicaré por qué elegí API-first sobre MCP, y luego repasaré las integraciones reales.
Por qué API > MCP para connections a escala personal
Los servidores MCP son maravillosos para sistemas de agentes distribuidos donde múltiples clientes necesitan un protocolo compartido. Para un AIOS personal donde controlas ambos extremos, los servidores MCP añaden overhead de tokens — el esquema de herramientas de cada servidor se carga en el contexto lo uses o no. Una llamada directa curl o fetch dentro de un skill no cuesta nada hasta que el skill se ejecuta.
Regla general a la que llegué: si una herramienta la usan más de tres skills y quiero que sea accesible desde cualquier sesión sin prompting, escribo un wrapper MCP. De lo contrario, llamada API directa desde dentro del skill relevante. Para un AIOS en solitario, eso significa que casi todo se queda como llamada API directa.
Las integraciones reales que conecté
| Herramienta | Propósito | Cómo conecto |
|---|---|---|
| ClickUp | Tareas, proyectos | REST API v2, token personal en .env |
| Google Workspace | Calendario, Gmail, Drive | Google Workspace CLI + cuenta de servicio |
| Fireflies | Transcripciones de reuniones | GraphQL API, bearer token |
| Slack | Notificaciones, DMs | Slack Web API, bot token en workspace AIOS dedicado |
| Stripe | Ingresos, facturación de clientes | REST API, clave restringida (solo lectura en la mayoría de recursos) |
| QuickBooks | Libro mayor contable | OAuth 2.0, refresh token almacenado encriptado |
La disciplina del .env
Cada clave API en .env. .env está en .gitignore. Sin excepciones. Si alguna vez como yo en 2022 subiste un .env a GitHub — sabes que el escáner de secretos de GitHub te atrapa en minutos, tu clave se revoca y pasas un sábado rotando credenciales. No seas el yo de 2022.
Para Stripe y QuickBooks uso claves restringidas/solo-lectura para todo lo que el AIOS hace autónomamente. Las operaciones de escritura requieren una sesión interactiva donde apruebo la acción. Esto no es paranoia — es el mismo principio de no darle acceso de escritura a producción a un ingeniero junior el primer día.
Cuentas dedicadas para el AIOS
Esta es la parte que más tiempo me tomó descubrir. Para Slack, Fireflies y (donde sea posible) Google Workspace, creé una cuenta de servicio dedicada usada solo por el AIOS. ¿Por qué? Porque en el momento en que dejas que tu AIOS publique en Slack como tú, cada notificación de Slack se registra en tu log de auditoría como acciones que tú realizaste. Eso es un desastre para la rendición de cuentas y peor si alguna vez necesitas depurar si tú enviaste el mensaje o tu AIOS lo hizo.
La cuenta dedicada se llama "Mejba (AIOS)" y tiene un avatar claramente diferente. Cuando publica en un canal, todos saben que es el AIOS. Cuando publico yo, soy yo. Los equipos de cumplimiento y tu yo futuro agradecen a tu yo presente.
Para más profundidad sobre asegurar credenciales de agentes y webhooks, mi guía de onboarding seguro de agentes IA cubre el modelo de amenazas en detalle.
Paso 5: Capabilities — Los skills que realmente se ganan su lugar
Esta es la sección que más tiempo me llevó en la construcción real, y la que más gente me pregunta. Los skills son donde el AIOS deja de ser teórico y empieza a ahorrarte horas. Mostraré la estructura y luego repasaré cinco skills reales que publiqué.
Anatomía de SKILL.md
Según la documentación oficial de skills de Anthropic, cada skill es una carpeta con al menos un archivo SKILL.md que contiene:
---
name: kebab-case-name
description: One-sentence trigger description. Claude reads this to decide when to use the skill.
allowed-tools: Read, Write, Bash, WebSearch # optional
---
# Skill Name
[Instructions Claude follows when this skill loads]
## When to use
## What to do
## Output format
## Constraints
Mantén SKILL.md por debajo de 500 líneas según la recomendación de Anthropic. ¿Necesitas más? Agrega REFERENCE.md, EXAMPLES.md o scripts ejecutables en la misma carpeta. Claude solo carga los archivos adicionales cuando realmente los necesita — ese es el patrón de divulgación progresiva y la razón por la que puedes ejecutar cientos de skills sin gastar tokens.
Skill 1: /daily-plan
El skill que primero se ganó su lugar. Cada mañana a las 6:30 AM (activado por cron) produce un plan diario de una página que:
- Lee
context/calendar.mdy el feed en vivo de Google Calendar para hoy - Lee
context/tasks.mdy extrae las 8 principales tareas de ClickUp ponderadas por fecha límite + prioridad - Escanea las transcripciones de Fireflies de ayer en busca de elementos de acción comprometidos
- Cruza referencias contra
decisions/para cualquier cosa que dije que revisaría esta semana - Redacta un plan de 3 bloques: bloque de trabajo profundo, bloque de comunicaciones, bloque administrativo
- Lo escribe en
daily/2026-04-19.mdy me envía un resumen por Slack a las 7:00 AM
Tiempo ahorrado por día: ~20 minutos del overhead de "qué debería trabajar primero", con decisiones de prioridad mediblemente mejores porque el sistema realmente sabe a qué me comprometí en la llamada del cliente del martes pasado.
Skill 2: /linkedin-post
Escribo un post de LinkedIn casi todos los días. La primera versión de este skill producía basura genérica. La versión actual lee:
context/knowledge/brand-voice-mejba-me.md(mis reglas de voz)- Los últimos 30 días de posts de LinkedIn que realmente publiqué (extraídos vía exportación)
- El plan de hoy
daily/[date].md, más el archivo de decisión más reciente - URL opcional que el usuario pasa
Devuelve tres borradores en tres ángulos diferentes — contrario, historia, táctico — y etiqueta a cuál post anterior se parece más cada borrador en estilo. Elijo uno, edito, publico. ~12 minutos para un post terminado versus los 35 que tomaba antes.
Skill 3: /youtube-comment-analysis
Recibo unos cientos de comentarios de YouTube por semana a través de videos. La mayoría son ruido. Algunos son oro para ideas de contenido. Este skill extrae los comentarios de los últimos 7 días vía la API de YouTube Data, los agrupa por temas, destaca los tres hilos con más engagement y propone ángulos de contenido para cada uno. Se ejecuta el domingo por la noche. La idea del video del martes usualmente se elige de este output.
Skill 4: /slide-deck
Para propuestas de clientes. Lee el archivo del cliente en context/knowledge/clients/[slug].md, el alcance del trato de context/customers.md y una plantilla de diapositivas en references/. Produce un esquema estructurado como markdown, luego genera diapositivas Marp. Redujo un flujo de trabajo de 90 minutos para decks a 25.
Skill 5: /four-cs-audit
Este es el skill que audita al AIOS mismo. Lo profundizaremos en un momento porque es el que convierte todo el sistema en un ciclo de retroalimentación. Por ahora: puntúa Context, Connections, Capabilities y Cadence cada uno sobre 25 y escribe el resultado en audits/[date].md.
Skill 6: /level-up
Gemelo de la auditoría. Lee el último archivo de auditoría, identifica la dimensión con menor puntuación y propone las tres acciones de mayor impacto para mejorar esa puntuación antes de la auditoría de la próxima semana. Así es como el sistema me dice qué construir a continuación.
Tengo ~22 skills en total ahora. La lista crece de 1 a 3 por semana. Algunos mueren rápido porque no se ganan su lugar. Está bien. Un skill es un archivo markdown de 30 líneas — el costo de escribir uno es tan bajo que "eliminar y reescribir" supera a "planificar cuidadosamente."
Paso 6: Cadence — Rutinas, Cron y la nube
Los skills los puedes activar. Las rutinas se ejecutan solas. Esto es lo que gradúa un AIOS de útil a autónomo.
Rutinas locales vs. en la nube
Dos variantes de ejecución programada existen desde mayo de 2026:
- Tareas programadas locales — tu laptop las ejecuta vía cron o un trabajo launchd que invoca
claudesin interfaz. Funcionan bien si tu laptop está encendida. No funcionan si no lo está. - Rutinas en la nube — alojadas por Anthropic, abiertas en preview de investigación el 14 de abril de 2026. Se ejecutan en la infraestructura de Anthropic, siguen funcionando cuando tu laptop está cerrada, configuradas en
claude.ai/code/routineso vía/schedule.
Según la propia documentación de rutinas de Anthropic, cada rutina es una configuración guardada de Claude Code — un prompt, uno o más repositorios y un conjunto de conectores. Los triggers pueden ser programados (cron o lenguaje natural como "cada lunes a las 6 AM"), API (HTTP POST con bearer token) o eventos de GitHub (PRs, releases). Límites del plan en el preview: Pro 5/día, Max 15/día, Team y Enterprise 25/día.
Mi cadencia actual
| Cadencia | Qué se ejecuta | Dónde |
|---|---|---|
| 6:30 AM diario | /daily-plan |
Local |
| 8:00 AM Lun | Barrido semanal de estado de clientes | Rutina en la nube |
| Cada hora 9-18 entre semana | Ingesta de nuevas transcripciones (Fireflies) | Local |
| Domingo 7:00 AM | /four-cs-audit + /level-up |
Rutina en la nube |
Al abrir PR en repo aios |
Verificación de salud del repo | Nube (trigger GitHub) |
| Cada 3 días máx | Skill de loop (tareas de larga duración) | Local |
El límite de loop de 3 días merece una nota. Las tareas de larga duración que hacen loop indefinidamente quemarán presupuesto de tokens más rápido de lo que esperas. Limito cualquier skill de loop a máximo 3 días, con una condición de salida estricta. Para trabajo genuinamente a largo plazo, programa una rutina nueva — no dejes que una sesión corra por una semana.
Programación en lenguaje natural
El comando /schedule acepta lenguaje natural. "Ejecuta /four-cs-audit cada domingo a las 7 AM y envíame el resultado por Slack." Eso se traduce a una expresión cron detrás de escenas. Ya no necesitas memorizar sintaxis cron. (Aunque saber 0 7 * * 0 no está de más.)
Monitoreo y depuración
Cada rutina escribe un log de ejecución en .cloud/runs/[date]/[routine-name].md (o su equivalente en la nube visible en claude.ai/code/routines). Reviso las ejecuciones fallidas una vez por semana. El modo de fallo más común por lejos son los límites de velocidad de API — Stripe es el mayor culpable. La solución casi siempre es "agregar un retraso de 200ms entre llamadas" o "agrupar la solicitud."
Si una rutina falla tres veces seguidas, me notifican por Slack. El fallo silencioso es peor que el fallo ruidoso.
Para más sobre automatizar trabajo recurrente específicamente con la capa de programación de Claude Code, mi tutorial sobre verificaciones SEO vía rutinas muestra el mismo patrón aplicado a un solo dominio.
El wiki de conocimiento LLM — Mi segundo cerebro estilo Karpathy
Esta es la parte de mi AIOS que más me sorprendió. Esperaba que los skills y las rutinas fueran la ganancia. Lo que realmente cambió cómo pienso es el wiki.
A finales de 2025, Andrej Karpathy publicó el gist del LLM Wiki — un patrón donde en vez de meter notas en una base de datos vectorial, mantienes archivos markdown simples en una carpeta y dejas que el LLM los lea directamente. VentureBeat cubrió el enfoque poco después. La afirmación benchmarkeada, repetida a través de implementaciones, es aproximadamente 70x más eficiente en tokens que RAG para bases de conocimiento a escala personal que caben en la ventana de contexto de un modelo.
Alojo mi wiki bajo context/knowledge/ y lo visualizo a través de Obsidian para la vista de grafos. Claude Code lee los mismos archivos directamente a través del sistema de archivos.
Qué va en el wiki
- Clientes — un archivo por cliente, con todos los hechos relevantes, historial, decisiones, normas de comunicación
- Productos — cada producto/servicio que vendo, con posicionamiento, niveles de precio, objeciones comunes
- Personas — referidos, proveedores, colaboradores, con contexto de relación
- Lecciones — cosas que aprendí por las malas, escritas para que el yo futuro no repita el error
- Decisiones — cada decisión no trivial, fechada, con razonamiento preservado
Por qué markdown supera a una base de datos vectorial a esta escala
Tres razones que importan en el uso diario:
- Puedes leerlo. Cuando algo se ve mal, haces
catal archivo. Con una base de datos vectorial estás consultando embeddings. - El LLM puede reescribirlo limpiamente. La perspicacia completa de Karpathy fue que los LLMs ahora son lo suficientemente buenos para mantener un wiki, no solo consultarlo. El mío reorganiza sus propios archivos semanalmente.
- Carga texto exacto en el contexto. Sin hand-waving de similitud de embeddings. El modelo ve el archivo y razona sobre él.
Para cobertura más profunda de este patrón específico, ve Obsidian + Claude Code como memoria persistente y el enfoque de super-skills que combina el wiki de Karpathy con los primitivos de skills de Claude Code.
El wiki me tomó unos tres fines de semana para poblar. Ahora es la parte más referenciada de mi AIOS y la parte que perdería al último.
Artefactos y dashboards — Extracciones en tiempo real
A veces no quiero un chat. Quiero un dashboard. Los skills pueden devolver artefactos de Claude — paneles interactivos HTML/JS que se renderizan en la vista de chat y se actualizan bajo demanda al volver a ejecutar las llamadas API subyacentes.
Mis cinco dashboards más usados:
- MRR Pulse — Ingresos de Stripe últimos 30/60/90 días, tasa de churn, principales clientes contribuyentes
- AR Aging — Facturas pendientes agrupadas por 0-30 / 31-60 / 60+ días
- Client Health — Para cada cliente activo: días desde último contacto, estado actual de entregables, bloqueadores abiertos de ClickUp
- Densidad de calendario — Próximos 14 días, % tiempo en reuniones vs trabajo profundo, codificado por colores
- Backlog de decisiones — Cada etiqueta "TBD" o "revisitar antes de X" de
decisions/que está vencida
Cada uno es un skill que obtiene datos en vivo y renderiza un artefacto. Sin herramienta de dashboard SaaS. Sin servicio de terceros. Los datos viven donde viven; el dashboard se genera bajo demanda. El costo total se mide en llamadas API, no en tarifas de suscripción.
El loop diario y semanal
Aquí está el ritmo que surgió después de unas seis semanas. Lo muestro porque el loop es el sistema. Sin él, tienes una carpeta elegante de markdown.
Diario
| Hora | Qué sucede | Trigger |
|---|---|---|
| 6:30 | /daily-plan se ejecuta, escribe daily/[date].md |
Cron local |
| 7:00 | DM de Slack con resumen | Rutina |
| 7:30 | Lo leo, edito si es necesario, hago commit de cambios | Manual |
| Durante el día | Activo skills según necesidad (/linkedin-post, /slide-deck, etc.) |
Manual |
| 17:30 | Skill /end-of-day: registrar qué se hizo, qué no, por qué |
Manual |
| Cada hora 9-18 | Ingesta de transcripciones de Fireflies, extracción de elementos de acción | Cron local |
Semanal
| Hora | Qué sucede | Trigger |
|---|---|---|
| Dom 7:00 | /four-cs-audit se ejecuta, puntúa el AIOS |
Rutina en la nube |
| Dom 7:15 | /level-up lee la auditoría, propone 3 mejoras |
Rutina en la nube |
| Dom 8:00 | Reviso auditoría + propuestas, elijo qué construir esta semana | Manual |
| Lun 8:00 | Barrido semanal de estado de clientes | Rutina en la nube |
| Vie 16:00 | Skill /weekly-review: resumir la semana contra objetivos |
Manual |
El sistema funciona esté yo involucrado o no. Las auditorías me obligan a involucrarme el domingo por la mañana. Ese es todo el loop.
La puntuación de auditoría de las Cuatro C's — Cómo sé que realmente funciona
Cada domingo a las 7 AM el skill /four-cs-audit se ejecuta y me da un número de 100. Veinticinco puntos cada uno para Context, Connections, Capabilities, Cadence. El número es brutal porque debería serlo.
Esquema de puntuación (simplificado)
Context (de 25)
- Los 7 bloques poblados y actualizados en los últimos 14 días: 15 pts
- Wiki tiene ≥1 archivo por cliente/producto activo: 5 pts
- Sin etiquetas "TBD" con más de 30 días: 5 pts
Connections (de 25)
- Cada integración probada en los últimos 14 días: 4 pts cada una (máx 20)
- Todas las credenciales en
.env, ninguna en skills: 5 pts
Capabilities (de 25)
- ≥10 skills funcionando: 5 pts
- Cada uno de los 5 skills más usados se ejecutó exitosamente ≥3 veces esta semana: 15 pts
- ≥1 skill nuevo publicado en los últimos 14 días: 5 pts
Cadence (de 25)
- ≥1 rutina diaria ejecutándose: 5 pts
- ≥1 rutina semanal ejecutándose: 5 pts
- Auditoría + level-up ejecutándose automáticamente: 10 pts
- Cero fallos silenciosos (cada fallo te notificó): 5 pts
Mi primera auditoría (números reales)
Cuando puntué mi AIOS por primera vez — seis semanas después del inicio de la construcción — aterrizó en 54.5/100:
- Context: 18/25 — Los bloques estaban poblados pero el wiki tenía tres archivos de clientes "TBD" con más de un mes
- Connections: 16/25 — Stripe y ClickUp eran sólidos, el OAuth de QuickBooks había estado fallando durante 9 días y no lo había notado
- Capabilities: 15.5/25 — 12 skills construidos, pero 4 de ellos nunca los había usado desde la semana uno
- Cadence: 5/25 — Tenía trabajos cron pero no rutinas en la nube propiamente, y el fallo silencioso de QuickBooks probó que mi monitoreo estaba roto
54.5 de 100. Después de seis semanas de trabajo. Ese número fue la retroalimentación más útil que el sistema me ha dado jamás. Me dijo exactamente dónde enfocarme en la semana siete (arreglar monitoreo, configurar rutinas en la nube, eliminar los cuatro skills muertos).
Para la semana diez estaba en 81. La auditoría es el ciclo de retroalimentación que hace que todo mejore con el tiempo. Sin ella, habría seguido construyendo skills que nadie — incluyéndome — realmente usaba.
Mi opinión — Las lecciones que me tomaron tres meses ganar
Seis semanas adentro casi renuncié. La productividad empeoró antes de mejorar. Estaba pasando 12 horas por semana en el AIOS mismo en vez de en trabajo de clientes, y los skills tempranos aún no ganaban su lugar. Este es el bajón de productividad y es real. Planifícalo.
La forma es aproximadamente:
- Semanas 1-3: Neto negativo. Estás construyendo, depurando, poblando contexto, aprendiendo las peculiaridades de Claude Code.
- Semanas 4-7: Punto de equilibrio. Los primeros skills empiezan a ahorrar tiempo real. El sistema te conoce lo suficiente para ser útil.
- Semanas 8+: Ganancias compuestas. Cada nuevo skill toma menos tiempo de construir porque reutilizas contexto. Cada rutina agrega margen a tu semana.
Para la semana diez estaba recuperando ~14 horas por semana de overhead administrativo. Para la semana doce, ~19. El bajón es la cuota de entrada. Págala a propósito, no por accidente.
Tres lecciones más que me tatuaría en el antebrazo si pudiera:
1. Apunta a 30-75% de automatización por tarea, no 100%. Intentar automatizar completamente el trabajo creativo produce output plano. Intentar automatizar completamente la toma de decisiones produce sistemas frágiles. El punto dulce es automatizar las partes de trabajo pesado de una tarea — investigación, redacción, formateo, sincronización de estado — y mantener las partes de juicio humanas. Un flujo de trabajo 50% automatizado ejecutado consistentemente supera a un flujo 100% automatizado que se rompe cada tercera semana.
2. Trata al AIOS como mentor, no como máquina expendedora. Ya lo dije. Lo digo de nuevo. Los skills que más me enseñaron fueron los que empujaron de vuelta. /daily-plan es genial porque a veces se rehúsa a programar lo que le pedí que programara y explica por qué ("te comprometiste a trabajo profundo en el entregable de Acme en la llamada del martes — mover la reunión a ese bloque contradice ese compromiso"). Una máquina expendedora simplemente habría movido la reunión.
3. La auditoría supera a la construcción. Me avergüenza genuinamente cuánto construí antes de construir el skill de auditoría. La auditoría es lo que convirtió al AIOS de un toolkit ingenioso en un sistema que se mejora a sí mismo. Si solo construyes un skill de todo este post, construye la auditoría.
También hay una meta-lección que vale la pena decir en voz alta — construir esto no me hizo más productivo de la noche a la mañana. Me hizo más honesto. La puntuación del domingo no miente. No puedes convencerte de que tuviste una gran semana cuando la auditoría dice Cadence es 5/25 y tres de tus rutinas fallaron silenciosamente.
Eso, más que el tiempo ahorrado, es por lo que nunca volvería atrás.
Preguntas frecuentes
¿Qué significa AIOS?
AIOS significa AI Operating System — un runtime personal construido sobre Claude Code que mantiene tu contexto, se conecta a tus herramientas en vivo, expone capacidades como skills nombrados y se ejecuta en una cadencia que tú estableces. A diferencia de un chatbot, gestiona recursos cognitivos entre sesiones y puede ejecutarse autónomamente.
¿Necesito ser desarrollador para construir un AIOS en Claude Code?
Necesitas comodidad básica con la terminal, Git y editar archivos markdown. No necesitas escribir código de producción — cada skill es un archivo markdown con un encabezado YAML. Si has desplegado un sitio WordPress o usado VS Code, tienes suficiente base.
¿En qué se diferencia esto de Notion AI o ChatGPT con memoria?
Tres cosas: Claude Code lee tu sistema de archivos real (sin paso de carga), los skills se ejecutan como código con acceso API (no solo generación de texto), y las rutinas se ejecutan en un horario estés en tu laptop o no. La memoria de ChatGPT es uno de los cuatro pilares (Context). Un AIOS es los cuatro.
¿Cuánto cuesta ejecutar un AIOS personal?
Claude Pro a $20/mes cubre la mayoría del uso personal incluyendo 5 rutinas en la nube por día; los planes Max extienden a 15 rutinas/día. Los costos de API para herramientas conectadas (Stripe, ClickUp, etc.) son típicamente gratuitos a volumen personal. Mi costo mensual total ronda los ~$45-80 dependiendo de la carga de rutinas.
¿Cuánto tiempo toma construir uno?
Planifica 30-50 horas durante 4-8 semanas de trabajo a tiempo parcial para alcanzar una base útil. Espera un bajón de productividad en las semanas 1-3, punto de equilibrio en la semana 5-7, y ganancias compuestas después de la semana 8. El paso a paso completo está en las secciones de construcción arriba.
¿Puedo ejecutar rutinas en la nube en el plan Free?
No — las rutinas en la nube requieren Pro, Max, Team o Enterprise desde mayo de 2026. El plan Free aún puede ejecutar skills locales y usar programación con cron en tu propia máquina.
Trabajemos juntos
¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudar.
- Fiverr (builds personalizados e integraciones): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (soluciones empresariales): ramlit.com
- ColorPark (diseño y branding): colorpark.io
- xCyberSecurity (servicios de seguridad): xcybersecurity.io