Construí Meu Sistema Operacional de IA Com Claude Code

Construí meu sistema operacional de IA com Claude Code

Durante nove anos tentei cada stack de produtividade do mercado. Notion. ClickUp. Obsidian em cima do Notion. Sunsama conectado ao Calendar. Sete assinaturas SaaS simultâneas que todas prometiam ser a "única fonte da verdade" e nenhuma jamais foi. A verdade honesta é que nenhuma dessas ferramentas realmente pensava comigo — elas apenas armazenavam coisas que eu já tinha pensado.

Isso mudou três meses atrás quando reconstruí todo o meu fluxo de trabalho dentro de uma única ferramenta: Claude Code. Não como assistente de programação. Como sistema operacional. Um real — com skills, rotinas, agentes na nuvem programados, um wiki de conhecimento em markdown e dashboards ao vivo que puxam dados do ClickUp, Stripe, QuickBooks, Fireflies e Slack sob demanda.

Este é o plano completo. Os frameworks que usei (os Três M's e os Quatro C's), os sete blocos de dados com que comecei, a estrutura exata do repositório, os skills que publiquei primeiro e o sistema de pontuação de auditoria que executo todo domingo de manhã para ver se o sistema operacional de IA Claude Code está realmente se comportando como um.

Se você tem tentado colar ChatGPT mais Zapier mais sete dashboards e se perguntando por que ainda se sente ocupado — isto é o que eu construiria no lugar, sabendo o que sei agora.

Por que stacks de produtividade falharam comigo em 2026

Aqui está o que ninguém me disse quando comprei meu quarto template do Notion. O gargalo em 2026 não é o armazenamento de informação. É a recuperação de informação no momento da decisão. Quando um cliente envia um email às 16:47 perguntando por que a entrega três está dois dias atrasada, não preciso abrir meu "segundo cérebro". Preciso de uma resposta em nove segundos.

Ferramentas de produtividade tradicionais compartilham o mesmo defeito fatal — elas assumem que eu sou o motor. A ferramenta armazena. Eu penso. Eu cruzo referências. Eu sintetizo. Eu escrevo o email. A página do Notion não redige a resposta. A tarefa do ClickUp não reconcilia com a fatura do Stripe. A transcrição do Fireflies não extrai a única decisão de uma chamada de 47 minutos que realmente importa esta semana.

Quando os primeiros runtimes de agentes úteis surgiram — Anthropic lançou o Claude Agent SDK no final de 2025, depois abriu skills como primitivo de primeira classe, e então lançou rotinas hospedadas na nuvem em 14 de abril de 2026 — o custo de construir seu próprio sistema desmoronou. O que antes exigia um stack de $40K com Zapier-mais-Make-mais-três-engenheiros agora cabe em um único repositório de arquivos markdown.

Então deletei metade do meu stack SaaS e comecei do zero. O resultado é o que estou chamando de AIOS: um sistema operacional de IA que pensa junto comigo, não atrás de mim.

O que um AIOS realmente é (e o que não é)

Um sistema operacional tem três trabalhos. Gerenciar recursos. Mediar entre você e seu hardware. Executar programas em seu nome quando você pede.

Um sistema operacional de IA faz a mesma coisa — mas os recursos que gerencia são cognitivos. Seus contextos. Suas decisões. Seus relacionamentos. Seus projetos. O hardware que media é seu cérebro mais as dezenas de APIs SaaS em que seu negócio roda. Os programas que executa são skills, rotinas e tarefas programadas que rodam esteja você na sua mesa ou dormindo.

Essa é a parte que as pessoas não percebem. Um AIOS não é um chatbot com memória. Não é um substituto do Notion. É um runtime que mantém seu contexto, possui suas conexões, expõe suas capacidades como skills nomeados e os executa em uma cadência que você define.

Quatro propriedades separam um AIOS real de um template de prompt sofisticado:

1. Mantém seu contexto entre sessões. Sem re-explicar quem você é.
2. Conecta-se a dados ao vivo. Puxa de suas ferramentas reais, não de exportações obsoletas.
3. Expõe capacidades como skills nomeados e reutilizáveis. Não prompts de uso único.
4. Executa em sua própria cadência. Alguns skills você dispara; outros rodam sozinhos às 6 da manhã.

Se um sistema que você está construindo não faz todos os quatro, você tem um chatbot. Útil — mas não um sistema operacional.

A boa notícia: Claude Code já te dá o runtime de graça. O trabalho está na arquitetura que você constrói dentro dele. O que me leva aos dois frameworks que organizaram tudo para mim.

Os Três M's: Mentalidade, Método, Máquina

Antes de qualquer código, qualquer estrutura de pastas, qualquer skill — três camadas. Pule-as e a construção desmorona na semana dois. Aprendi isso da maneira difícil quando minha primeira tentativa virou 31 arquivos markdown desorganizados que nem o Claude conseguia navegar.

Mentalidade

A mudança de mentalidade é pequena mas fundamental: a IA não é uma máquina de vendas. É um mentor.

Uma máquina de vendas pega uma moeda e dá um lanche. Você pergunta, você recebe. Um mentor pega a pergunta, te faz três de volta, te faz defender seu raciocínio e às vezes te diz que a pergunta em si está errada. Esse é o relacionamento que você quer com seu AIOS. Você não quer um sistema que sempre diga sim. Você quer um que diga "antes de redigir esta proposta, tem certeza que o nível de preço B se encaixa no estágio deste cliente? A última fatura dele foi de $2.400."

Isso soa filosófico. É profundamente prático. Cada skill que você escreve ou tem como padrão "executar a solicitação" ou "interrogar a solicitação primeiro." Um sistema mentor é construído sobre o segundo modo.

Método

Método é o playbook de como você e o AIOS trabalham juntos. O meu tem quatro regras:

• Planejar antes de executar. Cada skill não trivial retorna um plano primeiro. Eu aprovo o plano, depois ele executa.
• Citar a fonte. Cada afirmação é vinculada a um arquivo, uma transcrição ou uma resposta de API. Sem achismo.
• Atualizar o wiki. Cada decisão significativa vira um arquivo markdown que sessões futuras podem ler.
• Auditar com cadência. Pontuação semanal dos Quatro C's (mais sobre isso abaixo). O número não mente.

Essas regras vivem no CLAUDE.md raiz do meu repositório AIOS. Cada sessão do Claude Code as lê automaticamente.

Máquina

A máquina é o stack real — o IDE, o repositório, os skills, os conectores, o cronograma. Vamos construir a máquina em um momento. O ponto dos Três M's é que Mentalidade e Método vêm primeiro. Se você for direto para a Máquina vai construir uma máquina de vendas mais rápida. Que é precisamente o que fiz da primeira vez.

Os Quatro C's: A arquitetura real

Onde os Três M's são sobre como você pensa, os Quatro C's são sobre o que você constrói. Context. Connections. Capabilities. Cadence. Nessa ordem exata. Eles têm uma dependência sequencial — você não pode pular adiante.

Context (a fundação)

Context é tudo que o sistema sabe sobre você. Seu negócio, seus clientes, seus objetivos, seu tom, suas decisões, suas restrições. Sem Context, o AIOS trata cada prompt como um primeiro encontro.

Context vive em markdown. Sempre markdown. Karpathy estava certo quando disse que o formato amigável para LLM é texto puro em uma pasta que você controla — há um ganho de eficiência de tokens de 70x sobre RAG e bancos de dados vetoriais para bases de conhecimento em escala pessoal, e é mais fácil de depurar porque você pode ler os arquivos você mesmo.

Connections

Uma vez que o sistema sabe quem você é, ele precisa alcançar o mundo. Connections são suas APIs e integrações — ClickUp, Google Workspace, Fireflies, Slack, Stripe, QuickBooks. Sem Connections, o AIOS é um caderno inteligente. Com Connections, ele pode ler seu calendário ao vivo, puxar a receita de ontem, escanear as transcrições desta manhã e agir.

Capabilities

Capabilities são skills — competências nomeadas e reutilizáveis que o sistema pode executar. "Redigir um plano diário." "Auditar minha pontuação dos Quatro C's." "Gerar o calendário de conteúdo da próxima semana a partir dos meus comentários do YouTube." Cada um é uma pasta com um arquivo SKILL.md. O padrão de divulgação progressiva da Anthropic significa que centenas de skills podem estar no seu repositório e apenas o relevante é carregado no contexto para qualquer tarefa.

Cadence

Cadence determina quando as coisas rodam. Alguns skills você dispara ("/daily-plan"). Alguns rodam por cron ("toda segunda às 6:00 AM, auditar a semana passada"). Alguns vivem na nuvem e respondem a eventos do GitHub. Cadence é o que transforma um assistente inteligente em um sistema operacional que trabalha enquanto você dorme.

A dependência sequencial é o que a maioria das pessoas erra. Você não pode ter Cadence útil sem Capabilities. Você não pode construir Capabilities úteis sem Connections. Você não pode usar Connections inteligentemente sem Context. Então construímos na ordem. Um de cada vez. Sem pular.

Aqui também entra a auditoria — mas vou guardar o esquema de pontuação para o final, depois de termos construído a coisa.

Passo 1: Os dados do plano — Sete blocos Tier-Um

Antes de qualquer pasta, qualquer código, qualquer skill — sentei e listei cada tipo de informação que meu trabalho toca. Depois reduzi impiedosamente a sete blocos. Sete, porque esse é aproximadamente o limite antes que o sistema comece a parecer um labirinto. Os seus podem ser seis ou oito. O exercício importa mais que o número.

Meus sete blocos Tier-Um:

1. Receita — Pagamentos Stripe, livro-razão QuickBooks, MRR, contas a receber
2. Clientes — lista de clientes, status, último contato, valor vitalício, entregáveis atuais
3. Calendário — Feed do Google Calendar, esta semana, próximas duas semanas, blocos recorrentes
4. Comunicação — Threads do Gmail, DMs do Slack, notificações de comentários que valem acompanhar
5. Tarefas — Listas do ClickUp por projeto, lista de hoje, lista desta semana, itens bloqueados
6. Reuniões — Transcrições do Fireflies, decisões extraídas, itens de ação extraídos
7. Conhecimento — o wiki em si: clientes, produtos, decisões, referências, lições

Cada skill que escrevo toca pelo menos um desses blocos. Frequentemente três ou quatro. A lista de blocos virou o contrato: se uma pergunta não pode ser respondida a partir de um desses sete, meu AIOS não tem permissão de inventar. Ele me diz qual bloco preencher, ou pergunta. Sem alucinação porque a forma dos dados é finita e nomeada.

Isso soa chato. É o passo mais importante de longe. Se você pular, vai construir skills que puxam de lugares aleatórios e seu contexto vira papa. Os blocos forçam disciplina.

Passo 2: VS Code, Claude Code e a estrutura do repositório

A máquina em si é vergonhosamente simples. VS Code como editor. Claude Code (npm install -g @anthropic-ai/claude-code) como runtime. Um único repositório Git como todo o sistema operacional.

Aqui está a estrutura exata de pastas que uso:

aios/
├── CLAUDE.md                    # prompt do sistema raiz: mentalidade + método
├── .env                          # chaves API (gitignored)
├── .gitignore
├── .cloud/                       # configs de rotinas na nuvem (sincronizadas com Anthropic cloud)
│   └── routines/
├── context/                      # os sete blocos, como markdown
│   ├── revenue.md
│   ├── customers.md
│   ├── calendar.md
│   ├── communication.md
│   ├── tasks.md
│   ├── meetings.md
│   └── knowledge/                # o wiki LLM vive aqui
│       ├── clients/
│       ├── products/
│       ├── people/
│       └── _index.md
├── decisions/                    # um .md por decisão importante, datado
│   └── 2026-04-19-pricing-tier-update.md
├── references/                   # referência estática: SOPs, guias de marca, prompts
│   └── brand-voice-mejba-me.md
├── archives/                     # coisas com mais de ~90 dias
└── .claude/
    ├── skills/                   # skills pessoais (locais)
    │   ├── onboard/
    │   ├── daily-plan/
    │   ├── four-cs-audit/
    │   ├── linkedin-post/
    │   └── youtube-comment-analysis/
    └── agents/                   # subagentes

Cinco regras governam este layout, e eu quebrei cada uma delas uma vez e me arrependi:

• CLAUDE.md raiz é curto. Menos de 200 linhas. Ele carrega em cada sessão — inflar e você sangra tokens.
• Arquivos de context/ são os blocos. Um arquivo por bloco, máximo 800 linhas, depois dividir.
• decisions/ é somente para adicionar. Nunca edite um arquivo de decisão. Nova decisão, novo arquivo, datado.
• archives/ existe por uma razão. Qualquer coisa com mais de ~90 dias que não é ativamente referenciada vai para lá. O sistema não deveria reler seus pensamentos de janeiro todo maio.
• .cloud/ sincroniza com Anthropic. Só coloque rotinas na nuvem e os skills que você quer executáveis em sessões cloud lá. Skills locais ficam em .claude/skills/.

A distinção do .cloud/ importa. As rotinas na nuvem da Anthropic (preview de pesquisa aberto em 14 de abril de 2026) só acessam skills a nível de projeto commitados no repositório. Skills pessoais em ~/.claude/skills/ não viajam. Se você quer que uma rotina execute um skill na infraestrutura da Anthropic durante a noite, esse skill deve estar registrado no repositório.

Se você nunca configurou um repositório Claude Code antes, meu guia de configuração de equipes de agentes cobre o básico com mais profundidade. A partir daqui assumo que você tem claude funcionando em uma pasta nova.

Passo 3: O skill de onboarding — Ensinando ao sistema quem você é

O primeiro skill que construí não faz nada impressionante. Ele me entrevista. Só isso.

Chamei de onboard. Quando executo /onboard, Claude percorre cerca de 40 perguntas sobre os sete blocos — qual é meu modelo de negócio, quem são meus cinco principais clientes, qual é minha taxa horária, qual é minha voz de marca, como é uma "boa semana", o que estou deliberadamente não perseguindo, quais são meus inegociáveis. Cada resposta vai para o arquivo de contexto correspondente como markdown estruturado.

Por que orientado por entrevista? Porque se eu sentasse para escrever customers.md do zero, procrastinaria três semanas. Conversa não tem fricção. O skill transforma minha fala em contexto estruturado que o sistema pode usar para sempre.

Aqui está o 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.

É isso. ~25 linhas incluindo frontmatter. O skill carrega apenas quando chamado, custa essencialmente zero tokens no início da sessão e produz a fundação da qual tudo mais depende. Depois de executar /onboard uma vez, cada sessão futura começa sabendo exatamente quem eu sou e no que estou trabalhando.

Este é também o benefício mais subestimado do primitivo de skills: você pode escrever um skill cujo único trabalho é popular o contexto que futuros skills lerão. O sistema se auto-inicializa.

Passo 4: A camada de Connections — Conecte suas ferramentas reais

Aqui é onde a maioria das construções de AIOS pessoal estagna. As pessoas imaginam que precisam de um servidor MCP personalizado para cada ferramenta. Não precisam. Em 90% dos casos a resposta certa é uma chamada API direta de dentro de um skill, com credenciais no .env.

Vou explicar por que escolhi API-first sobre MCP, e depois percorrer as integrações reais.

Por que API > MCP para connections em escala pessoal

Servidores MCP são maravilhosos para sistemas de agentes distribuídos onde múltiplos clientes precisam de um protocolo compartilhado. Para um AIOS pessoal onde você controla ambos os lados, servidores MCP adicionam overhead de tokens — o esquema de ferramentas de cada servidor é carregado no contexto use você ou não. Uma chamada direta curl ou fetch dentro de um skill não custa nada até o skill rodar.

Regra geral que adotei: se uma ferramenta é usada por mais de três skills e eu quero acessível de qualquer sessão sem prompting, escrevo um wrapper MCP. Caso contrário, chamada API direta de dentro do skill relevante. Para um AIOS solo, isso significa que quase tudo fica como chamada API direta.

As integrações reais que conectei

A disciplina do .env

Cada chave API no .env. .env está no .gitignore. Sem exceções. Se você alguma vez como eu em 2022 fez push de um .env pro GitHub — sabe que o scanner de segredos do GitHub te pega em minutos, sua chave é revogada e você passa um sábado rotacionando credenciais. Não seja o eu de 2022.

Para Stripe e QuickBooks uso chaves restritas/somente-leitura para tudo que o AIOS faz autonomamente. Operações de escrita requerem uma sessão interativa onde aprovo a ação. Isso não é paranoia — é o mesmo princípio de não dar acesso de escrita em produção a um engenheiro júnior no primeiro dia.

Contas dedicadas para o AIOS

Esta é a parte que mais demorei para descobrir. Para Slack, Fireflies e (onde possível) Google Workspace, criei uma conta de serviço dedicada usada apenas pelo AIOS. Por quê? Porque no momento em que você deixa seu AIOS postar no Slack como você, cada notificação do Slack aparece no seu log de auditoria como ações que você realizou. Isso é uma bagunça para prestação de contas e pior se você precisar depurar se você enviou a mensagem ou seu AIOS.

A conta dedicada se chama "Mejba (AIOS)" e tem um avatar claramente diferente. Quando posta em um canal, todos sabem que é o AIOS. Quando eu posto, sou eu. Equipes de compliance e seu eu futuro agradecem ao seu eu presente.

Para mais profundidade sobre proteger credenciais de agentes e webhooks, meu guia de onboarding seguro de agentes IA cobre o modelo de ameaças em detalhe.

Passo 5: Capabilities — Os skills que realmente se provam

Esta é a seção que mais tempo levou na construção real, e a que mais pessoas me perguntam. Skills são onde o AIOS deixa de ser teórico e começa a te economizar horas. Vou mostrar a estrutura e depois percorrer cinco skills reais que publiquei.

Anatomia do SKILL.md

De acordo com a documentação oficial de skills da Anthropic, cada skill é uma pasta com no mínimo um arquivo SKILL.md contendo:

---
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

Mantenha SKILL.md abaixo de 500 linhas conforme recomendação da Anthropic. Precisa de mais? Adicione REFERENCE.md, EXAMPLES.md ou scripts executáveis na mesma pasta. Claude só carrega os arquivos adicionais quando realmente precisa — esse é o padrão de divulgação progressiva e a razão pela qual você pode rodar centenas de skills sem gastar tokens.

Skill 1: /daily-plan

O skill que primeiro se provou. Toda manhã às 6:30 AM (ativado por cron) produz um plano diário de uma página que:

• Lê context/calendar.md e o feed ao vivo do Google Calendar para hoje
• Lê context/tasks.md e puxa as 8 principais tarefas do ClickUp ponderadas por prazo + prioridade
• Escaneia as transcrições do Fireflies de ontem em busca de itens de ação comprometidos
• Cruza referências com decisions/ para qualquer coisa que eu disse que revisitaria esta semana
• Redige um plano de 3 blocos: bloco de trabalho profundo, bloco de comunicações, bloco administrativo
• Grava em daily/2026-04-19.md e me envia um resumo no Slack às 7:00 AM

Tempo economizado por dia: ~20 minutos do overhead de "no que devo trabalhar primeiro", com decisões de prioridade mensuravelmente melhores porque o sistema realmente sabe a que me comprometi na chamada do cliente na terça passada.

Skill 2: /linkedin-post

Escrevo um post no LinkedIn quase todo dia. A primeira versão deste skill produzia porcaria genérica. A versão atual lê:

• context/knowledge/brand-voice-mejba-me.md (minhas regras de voz)
• Os últimos 30 dias de posts do LinkedIn que realmente publiquei (puxados via exportação)
• O plano de hoje daily/[date].md, mais o arquivo de decisão mais recente
• URL opcional que o usuário passa

Retorna três rascunhos em três ângulos diferentes — contrário, história, tático — e marca qual post anterior cada rascunho mais se assemelha em estilo. Escolho um, edito, publico. ~12 minutos para um post finalizado versus os 35 que levava antes.

Skill 3: /youtube-comment-analysis

Recebo algumas centenas de comentários do YouTube por semana em vídeos. A maioria é ruído. Alguns são ouro para ideias de conteúdo. Este skill puxa os comentários dos últimos 7 dias via API YouTube Data, agrupa por temas, destaca os três threads com mais engajamento e propõe ângulos de conteúdo para cada. Roda domingo à noite. A ideia do vídeo de terça geralmente é escolhida deste output.

Skill 4: /slide-deck

Para propostas de clientes. Lê o arquivo do cliente em context/knowledge/clients/[slug].md, o escopo do negócio de context/customers.md e um template de slides em references/. Gera um esquema estruturado como markdown, depois gera slides Marp. Reduziu um fluxo de trabalho de deck de 90 minutos para 25.

Skill 5: /four-cs-audit

Este é o skill que audita o próprio AIOS. Vamos aprofundar em um momento porque é o que transforma todo o sistema em um ciclo de feedback. Por enquanto: pontua Context, Connections, Capabilities e Cadence cada um de 25 e grava o resultado em audits/[date].md.

Skill 6: /level-up

Gêmeo da auditoria. Lê o último arquivo de auditoria, identifica a dimensão com menor pontuação e propõe as três ações de maior impacto para melhorar essa pontuação antes da auditoria da próxima semana. É assim que o sistema me diz o que construir a seguir.

Tenho ~22 skills no total agora. A lista cresce de 1 a 3 por semana. Alguns morrem rápido porque não se provam. Tudo bem. Um skill é um arquivo markdown de 30 linhas — o custo de escrever um é tão baixo que "deletar e reescrever" supera "planejar cuidadosamente."

Passo 6: Cadence — Rotinas, Cron e a nuvem

Skills você pode disparar. Rotinas rodam sozinhas. Isso é o que gradua um AIOS de útil para autônomo.

Rotinas locais vs. na nuvem

Duas variantes de execução programada existem desde maio de 2026:

• Tarefas programadas locais — seu laptop as executa via cron ou um job launchd que invoca claude sem interface. Funcionam bem se seu laptop está ligado. Não funcionam se não está.
• Rotinas na nuvem — hospedadas pela Anthropic, abertas em preview de pesquisa em 14 de abril de 2026. Rodam na infraestrutura da Anthropic, continuam funcionando quando seu laptop está fechado, configuradas em claude.ai/code/routines ou via /schedule.

De acordo com a própria documentação de rotinas da Anthropic, cada rotina é uma configuração salva do Claude Code — um prompt, um ou mais repositórios e um conjunto de conectores. Triggers podem ser programados (cron ou linguagem natural como "toda segunda às 6 AM"), API (HTTP POST com bearer token) ou eventos do GitHub (PRs, releases). Limites do plano no preview: Pro 5/dia, Max 15/dia, Team e Enterprise 25/dia.

Minha cadência atual

O limite de loop de 3 dias merece uma nota. Tarefas de longa duração que fazem loop indefinidamente vão queimar orçamento de tokens mais rápido do que você espera. Limito qualquer skill de loop a no máximo 3 dias, com uma condição de saída rígida. Para trabalho genuinamente de longo prazo, programe uma rotina nova — não deixe uma sessão rodar por uma semana.

Programação em linguagem natural

O comando /schedule aceita linguagem natural. "Execute /four-cs-audit todo domingo às 7 AM e me envie o resultado no Slack." Isso se traduz em uma expressão cron nos bastidores. Você não precisa mais memorizar sintaxe cron. (Embora saber 0 7 * * 0 não faça mal.)

Monitoramento e depuração

Cada rotina grava um log de execução em .cloud/runs/[date]/[routine-name].md (ou seu equivalente na nuvem visível em claude.ai/code/routines). Reviso execuções falhadas uma vez por semana. O modo de falha mais comum de longe são limites de taxa de API — Stripe é o maior culpado. A correção quase sempre é "adicionar um atraso de 200ms entre chamadas" ou "agrupar a solicitação."

Se uma rotina falha três vezes seguidas, sou notificado no Slack. Falha silenciosa é pior que falha barulhenta.

Para mais sobre automatizar trabalho recorrente especificamente com a camada de programação do Claude Code, meu tutorial sobre verificações SEO via rotinas mostra o mesmo padrão aplicado a um único domínio.

O wiki de conhecimento LLM — Meu segundo cérebro estilo Karpathy

Esta é a parte do meu AIOS que mais me surpreendeu. Esperava que os skills e rotinas fossem a vitória. O que realmente mudou como eu penso é o wiki.

No final de 2025, Andrej Karpathy publicou o gist do LLM Wiki — um padrão onde em vez de enfiar notas em um banco de dados vetorial, você mantém arquivos markdown simples em uma pasta e deixa o LLM lê-los diretamente. VentureBeat cobriu a abordagem logo depois. A afirmação benchmarkada, repetida através de implementações, é aproximadamente 70x mais eficiente em tokens que RAG para bases de conhecimento em escala pessoal que cabem na janela de contexto de um modelo.

Hospedo meu wiki em context/knowledge/ e o visualizo pelo Obsidian para a visão de grafos. Claude Code lê os mesmos arquivos diretamente pelo sistema de arquivos.

O que vai no wiki

• Clientes — um arquivo por cliente, com todos os fatos relevantes, histórico, decisões, normas de comunicação
• Produtos — cada produto/serviço que vendo, com posicionamento, níveis de preço, objeções comuns
• Pessoas — indicações, fornecedores, colaboradores, com contexto de relacionamento
• Lições — coisas que aprendi da maneira difícil, escritas para que o eu futuro não repita o erro
• Decisões — cada decisão não trivial, datada, com raciocínio preservado

Por que markdown supera um banco de dados vetorial nesta escala

Três razões que importam no uso diário:

1. Você pode ler. Quando algo parece errado, você faz cat no arquivo. Com um banco de dados vetorial você está consultando embeddings.
2. O LLM pode reescrevê-lo limpa mente. A percepção inteira de Karpathy foi que LLMs agora são bons o suficiente para manter um wiki, não apenas consultá-lo. O meu reorganiza seus próprios arquivos semanalmente.
3. Carrega texto exato no contexto. Sem hand-waving de similaridade de embeddings. O modelo vê o arquivo e raciocina sobre ele.

Para cobertura mais profunda deste padrão específico, veja Obsidian + Claude Code como memória persistente e a abordagem de super-skills que combina o wiki de Karpathy com os primitivos de skills do Claude Code.

O wiki me custou cerca de três finais de semana para popular. Agora é a parte mais referenciada do meu AIOS e a parte que eu perderia por último.

Artefatos e dashboards — Consultas em tempo real

Às vezes não quero um chat. Quero um dashboard. Skills podem retornar artefatos do Claude — painéis interativos HTML/JS que renderizam na visão de chat e atualizam sob demanda ao reexecutar as chamadas API subjacentes.

Meus cinco dashboards mais usados:

• MRR Pulse — Receita Stripe últimos 30/60/90 dias, taxa de churn, principais clientes contribuintes
• AR Aging — Faturas pendentes agrupadas por 0-30 / 31-60 / 60+ dias
• Client Health — Para cada cliente ativo: dias desde último contato, status atual de entregáveis, bloqueadores abertos do ClickUp
• Densidade de calendário — Próximos 14 dias, % tempo em reuniões vs trabalho profundo, codificado por cores
• Backlog de decisões — Cada tag "TBD" ou "revisitar até X" de decisions/ que está vencida

Cada um é um skill que obtém dados ao vivo e renderiza um artefato. Sem ferramenta de dashboard SaaS. Sem serviço de terceiros. Dados vivem onde vivem; o dashboard é gerado sob demanda. O custo total é medido em chamadas API, não em taxas de assinatura.

O loop diário e semanal

Aqui está o ritmo que surgiu depois de cerca de seis semanas. Mostro porque o loop é o sistema. Sem ele, você tem uma pasta elegante de markdown.

Diário

Semanal

O sistema funciona esteja eu envolvido ou não. As auditorias me forçam a me envolver domingo de manhã. Esse é todo o loop.

A pontuação de auditoria dos Quatro C's — Como sei que realmente funciona

Todo domingo às 7 AM o skill /four-cs-audit roda e me dá um número de 100. Vinte e cinco pontos cada para Context, Connections, Capabilities, Cadence. O número é brutal porque deveria ser.

Esquema de pontuação (simplificado)

Context (de 25)

• Todos os 7 blocos populados e atualizados nos últimos 14 dias: 15 pts
• Wiki tem ≥1 arquivo por cliente/produto ativo: 5 pts
• Sem tags "TBD" com mais de 30 dias: 5 pts

Connections (de 25)

• Cada integração testada nos últimos 14 dias: 4 pts cada (máx 20)
• Todas as credenciais no .env, nenhuma em skills: 5 pts

Capabilities (de 25)

• ≥10 skills funcionando: 5 pts
• Cada um dos 5 skills mais usados rodou com sucesso ≥3 vezes esta semana: 15 pts
• ≥1 skill novo publicado nos últimos 14 dias: 5 pts

Cadence (de 25)

• ≥1 rotina diária rodando: 5 pts
• ≥1 rotina semanal rodando: 5 pts
• Auditoria + level-up rodando automaticamente: 10 pts
• Zero falhas silenciosas (cada falha te notificou): 5 pts

Minha primeira auditoria (números reais)

Quando pontuei meu AIOS pela primeira vez — seis semanas após o início da construção — ficou em 54,5/100:

• Context: 18/25 — Blocos estavam populados mas o wiki tinha três arquivos de clientes "TBD" com mais de um mês
• Connections: 16/25 — Stripe e ClickUp estavam sólidos, OAuth do QuickBooks tinha falhado por 9 dias e eu não tinha notado
• Capabilities: 15,5/25 — 12 skills construídos, mas 4 deles eu nunca tinha realmente usado desde a semana um
• Cadence: 5/25 — Tinha jobs cron mas não rotinas na nuvem propriamente, e a falha silenciosa do QuickBooks provou que meu monitoramento estava quebrado

54,5 de 100. Depois de seis semanas de trabalho. Esse número foi o feedback mais útil que o sistema já me deu. Me disse exatamente onde focar na semana sete (corrigir monitoramento, configurar rotinas na nuvem, eliminar os quatro skills mortos).

Na semana dez estava em 81. A auditoria é o ciclo de feedback que faz tudo melhorar com o tempo. Sem ela, eu teria continuado construindo skills que ninguém — incluindo eu — realmente usava.

Minha opinião — As lições que me custaram três meses

Seis semanas dentro quase desisti. A produtividade ficou pior antes de melhorar. Estava gastando 12 horas por semana no AIOS em si em vez de trabalho de clientes, e os skills iniciais ainda não estavam se provando. Este é o mergulho de produtividade e é real. Planeje-o.

A forma é aproximadamente:

• Semanas 1-3: Negativo líquido. Você está construindo, depurando, populando contexto, aprendendo as peculiaridades do Claude Code.
• Semanas 4-7: Ponto de equilíbrio. Os primeiros skills começam a economizar tempo real. O sistema te conhece o suficiente para ser útil.
• Semanas 8+: Ganhos compostos. Cada novo skill leva menos tempo para construir porque você reutiliza contexto. Cada rotina adiciona margem à sua semana.

Na semana dez estava recuperando ~14 horas por semana de overhead administrativo. Na semana doze, ~19. O mergulho é a taxa de entrada. Pague-a de propósito, não por acidente.

Três outras lições que tatuaria no meu antebraço se pudesse:

1. Mire em 30-75% de automação por tarefa, não 100%. Tentar automatizar completamente trabalho criativo produz output plano. Tentar automatizar completamente tomada de decisão produz sistemas frágeis. O ponto ideal é automatizar as partes de trabalho braçal de uma tarefa — pesquisa, rascunho, formatação, sincronização de status — e manter as partes de julgamento humanas. Um fluxo de trabalho 50% automatizado rodando consistentemente supera um 100% automatizado que quebra a cada terceira semana.

2. Trate o AIOS como mentor, não como máquina de vendas. Já disse. Dizendo de novo. Os skills que mais me ensinaram foram os que empurraram de volta. /daily-plan é ótimo porque às vezes se recusa a agendar o que pedi e explica por quê ("você se comprometeu com trabalho profundo no entregável da Acme na chamada de terça — mover a reunião para esse bloco contradiz esse compromisso"). Uma máquina de vendas teria simplesmente movido a reunião.

3. A auditoria supera a construção. Tenho genuinamente vergonha de quanto construí antes de construir o skill de auditoria. A auditoria é o que transformou o AIOS de um toolkit inteligente em um sistema que se melhora. Se você construir apenas um skill de todo este post, construa a auditoria.

Há também uma meta-lição que vale dizer em voz alta — construir isso não me tornou mais produtivo da noite para o dia. Me tornou mais honesto. A pontuação de domingo não mente. Você não pode se convencer de que teve uma ótima semana quando a auditoria diz Cadence é 5/25 e três das suas rotinas falharam silenciosamente.

Isso, mais que o tempo economizado, é por que eu nunca voltaria atrás.

Perguntas frequentes

O que significa AIOS?

AIOS significa AI Operating System — um runtime pessoal construído sobre Claude Code que mantém seu contexto, conecta-se às suas ferramentas ao vivo, expõe capacidades como skills nomeados e executa em uma cadência que você define. Diferente de um chatbot, gerencia recursos cognitivos entre sessões e pode executar autonomamente.

Preciso ser desenvolvedor para construir um AIOS no Claude Code?

Você precisa de conforto básico com o terminal, Git e edição de arquivos markdown. Não precisa escrever código de produção — cada skill é um arquivo markdown com um cabeçalho YAML. Se você já fez deploy de um site WordPress ou usou VS Code, tem base suficiente.

Como isso é diferente de Notion AI ou ChatGPT com memória?

Três coisas: Claude Code lê seu sistema de arquivos real (sem etapa de upload), skills rodam como código com acesso API (não apenas geração de texto), e rotinas executam em um cronograma esteja você no laptop ou não. Memória do ChatGPT é um dos quatro pilares (Context). Um AIOS é todos os quatro.

Quanto custa rodar um AIOS pessoal?

Claude Pro a $20/mês cobre a maioria do uso pessoal incluindo 5 rotinas na nuvem por dia; planos Max estendem para 15 rotinas/dia. Custos de API para ferramentas conectadas (Stripe, ClickUp, etc.) são tipicamente gratuitos em volume pessoal. Meu custo mensal total fica em torno de ~$45-80 dependendo da carga de rotinas.

Quanto tempo leva para construir um?

Planeje 30-50 horas durante 4-8 semanas de trabalho parcial para alcançar uma base útil. Espere um mergulho de produtividade nas semanas 1-3, ponto de equilíbrio na semana 5-7 e ganhos compostos após a semana 8. O passo a passo completo está nas seções de construção acima.

Posso rodar rotinas na nuvem no plano Free?

Não — rotinas na nuvem requerem Pro, Max, Team ou Enterprise desde maio de 2026. O plano Free ainda pode rodar skills locais e usar programação por cron na sua própria máquina.

Vamos trabalhar juntos

Procurando construir sistemas de IA, automatizar fluxos de trabalho ou escalar sua infraestrutura tecnológica? Adoraria ajudar.

• Fiverr (builds personalizados e integrações): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (soluções empresariais): ramlit.com
• ColorPark (design e branding): colorpark.io
• xCyberSecurity (serviços de segurança): xcybersecurity.io