Claude no Obsidian,
do jeito que funciona

Por que arquivar site não é segundo cérebro

O vídeo que eu comentei mostrava um vault crescendo sozinho: o Claude visitava sites, salvava cada página como nota, e o gráfico do Obsidian ia ficando cheio de bolinhas conectadas. Parece conhecimento acumulando. Na prática, três coisas acontecem.

A nota envelhece no dia seguinte. Preço, versão, regra, tudo que estava no site muda, e a sua cópia não. Quando você precisa da informação, precisa da versão de hoje. O agente consegue visitar o site na hora e trazer a versão fresca. Guardar a cópia só cria a chance de ele responder com dado velho, com a mesma confiança de sempre.

Cada nota arquivada custa contexto. O Claude não "sabe" o que está no seu vault. A cada pedido, ele lê arquivos e coloca o conteúdo na janela de contexto, que tem limite. Uma página da web média, clipada em markdown, ocupa entre 3 e 7 mil tokens. Trinta páginas lidas num pedido comem a maior parte de uma janela de 200 mil. Um vault cheio de cópia de site é um vault em que o agente gasta a janela lendo lixo antes de chegar no que importa.

Ninguém relê. Eu já tentei. A pasta de "leituras" vira um cemitério com gráfico bonito. O gráfico do Obsidian mede quantas notas se citam; não mede se alguma delas foi aberta de novo.

E o Obsidian, por si só, não é segundo cérebro nenhum. É um editor de markdown que abriu em beta em março de 2020, dois anos e meio antes do ChatGPT. Excelente editor. O que faz uma pasta de arquivos virar cérebro é a estrutura que você impõe nela, e é sobre isso que este playbook trata.

O que vai no vault, e o que não vai

Teste de entrada para qualquer nota: só guarde o que só você sabe. Se a informação existe num site, o agente busca lá. Se ela só existe na sua cabeça, na sua reunião ou na sua decisão, ela precisa estar no vault, senão morre.

Repare que a coluna da esquerda é pequena e cresce devagar. É assim que deve ser. Eu rodo esse modelo desde maio nas três empresas que toco e o vault continua legível para uma pessoa. Se o seu cresce mais rápido do que você consegue explicar, alguma cópia está entrando.

Setup em 20 minutos

Sem plugin, sem servidor MCP, sem sincronização de terceiros. O Obsidian já salva tudo como arquivo .md numa pasta comum. O Claude Code, que é a versão de terminal do Claude, abre nessa pasta e lê e escreve os arquivos direto. Os dois olham para o mesmo disco. É isso.

1. Instale o Claude Code

Precisa de uma assinatura Claude (Pro, Max ou Team) ou de créditos de API. No Mac ou Linux, cole no terminal:

copiarcurl -fsSL https://claude.ai/install.sh | bash

No Windows, no PowerShell:

copiarirm https://claude.ai/install.ps1 | iex

Confirme com claude --version. Na primeira vez que rodar claude, ele abre o navegador para você entrar na sua conta.

2. Baixe o vault inicial e abra no Obsidian

Baixe o zip, descompacte onde quiser (fora do iCloud e do Google Drive, explico na seção 07) e no Obsidian escolha "Abrir pasta como vault". O zip já vem com a configuração do Obsidian para usar links em markdown comum, que é o formato que qualquer agente lê sem tropeçar.

Se preferir criar do zero, a estrutura é esta:

copiarmeu-vault/
├── CLAUDE.md              o mapa: quem sou, regras, onde fica o quê
├── projetos/
│   ├── CLAUDE.md          como operar aqui (carrega só quando entra)
│   └── nova-loja/
│       └── CONTEXT.md     estado, decisões, próximo passo
├── diario/
│   ├── CLAUDE.md
│   └── 2026-09-08.md      um arquivo por dia, só acréscimo
├── memoria/
│   ├── CLAUDE.md
│   ├── INDEX.md           uma linha por fato
│   └── resposta-curta-primeiro.md
└── pesquisa/
    ├── CLAUDE.md          regras do modo pesquisa (seção 06)
    └── _modelo/           raw/ e wiki/ para copiar por tema

3. Abra o terminal dentro do vault e rode o Claude

copiarcd caminho/para/meu-vault
claude

Primeiro pedido, para conferir que ele entendeu o mapa:

copiarleia o CLAUDE.md e me diga como este vault funciona, sem abrir as outras pastas

Se ele resumir as quatro pastas e a regra de leitura sem sair vasculhando o vault, está funcionando. Dentro da sessão, /context mostra exatamente quais arquivos foram carregados. Use isso sempre que suspeitar que ele leu demais.

4. Troque o bloco "Quem sou"

Abra o CLAUDE.md raiz no Obsidian e substitua as duas linhas de exemplo pelas suas. Cargo, empresa, o que ocupa o seu dia. Só isso. O resto do arquivo é regra, e as regras funcionam para qualquer pessoa.

As quatro peças que fazem o vault virar cérebro

O que separa uma pasta de notas de um segundo cérebro são quatro arquivos com papéis fixos. O vault inicial já vem com todos. Aqui vai o que cada um faz e por que existe.

Peça 1. O CLAUDE.md raiz é mapa, não depósito

É o único arquivo que o Claude lê em toda sessão, automaticamente, antes do seu primeiro pedido. Por isso ele precisa ser curto: o do vault inicial tem 47 linhas e uns 650 tokens. A documentação oficial recomenda ficar abaixo de 200 linhas, e por experiência eu diria que a metade disso já é muito.

O que vai nele: quem você é em três linhas, a tabela de pastas com "quando entrar" em cada uma, a regra sobre web, o formato de escrita e o que fazer ao terminar uma tarefa. O que não vai: qualquer conteúdo. Se você se pegar colando informação no CLAUDE.md, ela pertence a uma pasta, e o CLAUDE.md só precisa apontar para lá.

Peça 2. Um CLAUDE.md por pasta, carregado sob demanda

Esta é a peça que a maioria pula, e é a que protege a janela de contexto. O Claude Code carrega o CLAUDE.md de uma subpasta apenas quando lê algum arquivo dentro dela. Então as regras de como escrever no diário só entram na sessão quando o pedido é sobre o diário. As regras de compilação da pesquisa só entram quando você abre uma pesquisa.

É carregamento em camadas. O agente carrega o mapa, decide a pasta, carrega o contrato daquela pasta, e só então lê os arquivos. Cada pedido custa o mínimo que aquele pedido exige.

Peça 3. O diário, um arquivo por dia, só acréscimo

Aqui vai o que aconteceu: o que foi feito, o que foi decidido, o próximo passo. Uma entrada tem hora, assunto e três a seis linhas. Nunca se edita entrada antiga; se algo mudou, entra uma entrada nova dizendo que mudou.

O diário é a peça que faz o agente lembrar de ontem sem você repetir. "O que a gente decidiu na terça?" vira uma leitura de um arquivo, não uma conversa do zero. E como cada dia é um arquivo, ele lê só os dias que o pedido cobre.

Ao final de cada tarefa, o CLAUDE.md raiz manda o agente registrar no diário se houve decisão. Você não precisa lembrar de pedir.

Peça 4. A memória, um fato por arquivo, com índice

Fatos duráveis sobre você e sobre como você quer trabalhar: "resposta curta primeiro", "nunca sugerir ferramenta paga sem eu pedir", "o financeiro fecha dia 5". Um arquivo por fato, com o motivo e o que muda no comportamento do agente. Um INDEX.md com uma linha por fato.

O agente lê o índice, que é minúsculo, e abre o arquivo só quando aquele fato importa para o pedido. É a mesma lógica do mapa: índice leve na frente, detalhe atrás, sob demanda.

E o CONTEXT.md de cada projeto

Não é uma peça nova, é onde as quatro se encontram. Cada projeto tem um único arquivo com estado atual, decisões datadas e próximo passo. Quando você pede algo sobre o projeto, o agente lê esse arquivo e nada mais. Quando uma decisão é tomada, ele atualiza esse arquivo e registra no diário. O CONTEXT.md é a única fonte de verdade sobre o projeto, e é por isso que ele fica legível: se está lá, é o estado real.

Como pedir as coisas

O vault certo com pedido errado continua gastando janela à toa. Cinco pedidos que funcionam e dois que não.

• Funciona"Registra no diário o que a gente acabou de decidir sobre a loja." O agente escreve três linhas no arquivo de hoje e atualiza o CONTEXT.md do projeto.
• Funciona"Visita a página de preços da plataforma X e me diz o que mudou desde a decisão que está no CONTEXT.md. Não salva a página." Web fresca, comparada com a sua decisão, sem cópia.
• Funciona"Lê só o CONTEXT.md da nova loja e me lista os próximos passos." O "só" evita a varredura.
• Funciona"Guarda na memória: eu não quero sugestão de ferramenta paga sem pedir." Vira um arquivo e uma linha no índice.
• Funciona"O que aconteceu na semana passada? Lê os dias 1 a 5 do diário." Escopo declarado, cinco arquivos lidos.
• Não funciona"Lê o vault inteiro e me diz o que você acha." Ele vai ler, gastar a janela e responder algo genérico. Nunca há motivo para um pedido precisar do vault inteiro.
• Não funciona"Salva esse artigo aqui para a gente usar depois." O "depois" não chega. Peça a conclusão em duas linhas com o link, ou abra um tema de pesquisa (próxima seção).

A dica que mais muda o resultado: diga onde ler. "No CONTEXT.md da loja", "nos dias 1 a 5", "no índice da memória". O mapa do CLAUDE.md já ajuda o agente a decidir sozinho, mas o pedido que nomeia o arquivo nunca erra.

Modo pesquisa: quando salvar fonte faz sentido

Existe um caso em que juntar fontes no vault é a coisa certa, e ele tem nome. Em abril de 2026 o Andrej Karpathy descreveu como usa LLMs para montar bases de conhecimento: as fontes vão para uma pasta raw/, o agente compila um wiki de arquivos markdown em cima delas, com resumos, artigos por conceito e links cruzados, e depois responde perguntas lendo o wiki. O Obsidian é a interface; o agente escreve e mantém o wiki, e ele quase nunca edita à mão.

Parece o que o cara do vídeo fazia. Não é. A diferença cabe numa palavra: arquivar é acumular, compilar é destilar. O cara do vídeo salvava páginas e olhava o gráfico. O Karpathy salva fontes para um tema delimitado, manda o agente transformar em artigos, e daí em diante consulta os artigos, não as fontes. Eu faço o mesmo quando abro uma pesquisa de verdade, e são poucas por ano.

Como funciona no vault inicial

A pasta pesquisa/ tem um _modelo/ para copiar a cada tema. Dentro dele, raw/ recebe as fontes (você coloca, o agente não mexe) e wiki/ é do agente. O CLAUDE.md da pasta, que só carrega quando você entra nela, diz a regra de compilação: a cada fonte nova, um resumo de até 15 linhas em wiki/fontes/, os artigos de conceito afetados em wiki/conceitos/ atualizados citando a fonte, e o wiki/INDEX.md com uma linha por artigo e por fonte.

Para perguntar, o agente lê o índice e abre só os artigos relevantes. Só volta ao raw/ se o wiki não bastar. O raw/ nunca é lido inteiro.

Três regras que evitam que o modo pesquisa vire o problema da seção 01

1. Tema com pergunta e critério de fim. O CONTEXT.md do tema começa com "a pergunta que esta pesquisa responde" e "fecha quando". Sem isso é coleção, não pesquisa.
2. O agente só lê o wiki. Se você se pegar pedindo "lê o raw inteiro", o wiki está mal compilado. Peça "revisa o wiki": ele procura contradições, fatos sem fonte e conexões que ainda não viraram artigo, e lista antes de mudar.
3. Quando acaba, o raw sai. O agente escreve um CONCLUSAO.md, o wiki fica, e o raw/ vai para fora do vault ou para o lixo. O que sobra no vault é o que você aprendeu, não o que você baixou.

Para levar um artigo da web para o raw/, a extensão Obsidian Web Clipper resolve, e é a que o próprio Karpathy usa. O erro nunca foi a extensão. Foi clipar sem ter para onde compilar.

As armadilhas

Todas essas eu vi acontecer, e em algumas eu caí primeiro.

• 01Arquivar web sem compilarÉ a do vídeo. A nota envelhece, custa contexto e não é relida. Web é sob demanda; a exceção é o modo pesquisa, com regra de compilação e data para acabar.
• 02CLAUDE.md que vira depósitoEle é lido em toda sessão. Cada linha que você acrescenta é cobrada em todo pedido, para sempre, mesmo nos pedidos que não têm nada a ver. Conteúdo vai para a pasta; o mapa só aponta.
• 03Vault sem mapaSem a tabela de "quando entrar", o agente decide sozinho o que ler, e a tendência é ler muito. É o caso em que cada pedido consome o vault inteiro sem necessidade. O /context denuncia: se aparecem arquivos que o pedido não pedia, falta roteamento.
• 04Sincronização brigando com o agenteiCloud, Google Drive e Dropbox sincronizam enquanto o agente escreve. Resultado: arquivos duplicados com "conflicted copy" no nome e trechos perdidos. Vault fica em pasta local. Se precisa de backup ou de vários computadores, use git; o vault inicial já vem com o .gitignore certo.
• 05Segredo dentro do vaultO agente lê o que está no vault e pode reproduzir em qualquer lugar: numa resposta, num arquivo, num commit. Senha, token e chave de API ficam fora, num gerenciador de senhas ou num .env ignorado. O CLAUDE.md do vault inicial manda o agente avisar e não salvar se aparecer um.
• 06Deixar o agente criar pasta onde quiserEm duas semanas você tem notas/, notes/, anotações/ e misc/. A regra no mapa é "arquivo novo só onde o mapa diz; em dúvida, pergunte". Pasta nova é decisão sua, não dele.
• 07Links no formato do ObsidianO padrão do Obsidian é [[nota]]. Funciona lá dentro e confunde fora: outro agente, outro editor, o GitHub. O vault inicial já configura links em markdown comum, [texto](caminho.md), que todo mundo lê.
• 08Confiar no gráficoO gráfico mostra citações entre notas. Um vault de cópias de site tem gráfico lindo e zero conhecimento seu. Um vault bem roteado tem gráfico feio e responde qualquer pergunta sobre a sua operação. Prefira o feio.
• 09Plugin que dá ao agente "acesso total ao vault"Servidores MCP e plugins que expõem o vault inteiro como uma ferramenta de busca parecem mais poderosos. Na prática duplicam contexto e tiram de você o controle de o que é lido. O sistema de arquivos já é a integração. Não precisa de mais camada.

Se você não quer terminal

Dá para fazer com o app de desktop do Claude apontando para a pasta do vault, seja pelo modo de trabalho em pastas do app, seja por um servidor MCP de arquivos. A estrutura de pastas e os quatro arquivos são os mesmos, e valem do mesmo jeito.

A troca que você faz: o app não carrega o CLAUDE.md sozinho nem o CLAUDE.md de cada pasta sob demanda. Você cola o conteúdo do mapa nas instruções do projeto e o agente carrega tudo o que decide carregar, sem a camada. Funciona, mas a proteção da janela de contexto passa a depender de você nomear o arquivo em cada pedido. Se em algum momento você abrir o terminal, a pasta já está pronta; nada precisa ser refeito.

O que eu quero de volta

Eu rodo este modelo no meu próprio sistema desde maio de 2026, para as três empresas em que sou CTO e para os projetos pessoais. Ele é a razão de eu conseguir trocar de assunto vinte vezes num dia sem reexplicar nada ao agente. Não porque o vault é grande. Porque cada pedido lê pouco.

Monta o seu. Vinte minutos com o vault inicial, um projeto real dentro, uma semana de diário. Depois me manda uma mensagem no Instagram contando o que quebrou e o que ficou de pé. Eu leio tudo, e é dali que saem os próximos playbooks.