Criar Second Brain

Criar um second brain pessoal operado por agente

Um vault por pessoa, na máquina dela. O que esta skill replica é um sistema de memória, não um conteúdo: quem escreve o quê, o que nunca pode ser reescrito, o que o agente lê antes de responder e o que ele escreve antes de encerrar. Empresa, área, projetos e pessoas nascem da entrevista do passo 2 e nunca são copiados de outro vault.

Vault que segue estes contratos é legível por qualquer agente e por qualquer pessoa que abra a pasta daqui a dois anos. Vault que os quebra vira arquivo morto pesquisável, que é o modo de falha mais comum deste tipo de sistema.

Isto é memória pessoal. Cada um tem o seu, com as próprias capturas e o próprio contexto. Quando o pedido for memória compartilhada de time (base que vários alimentam e um sistema consome), o desenho é outro e a skill é criar-estrutura-de-contexto. Misturar os dois quebra a primeira regra do sistema, que trata a palavra de quem capturou como dado primário e imutável.

Arquivos desta skill

• references/contratos.md — o núcleo não negociável e o que cada dono pode adaptar. Ler antes de criar qualquer arquivo.
• references/entrevista.md — os sete blocos de pergunta do bootstrap, com o que fazer quando a resposta não existe.
• references/plugins-obsidian.md — plugins opcionais em três camadas, com o que cada um habilita e o que quebra sem ele.
• assets/CLAUDE-modelo.md — modelo do CLAUDE.md do vault novo, com marcadores {{...}}.
• assets/bootstrap.ps1 e assets/bootstrap.sh — script opcional que cria o esqueleto e copia os arquivos de sistema, no Windows e no macOS ou Linux.
• assets/ e assets/templates/ — arquivos de sistema e templates copiados para o vault novo.

Passo 0: o que precisa existir na máquina

Checar antes de prometer qualquer coisa, e resolver o que faltar com a pessoa presente.

A pasta do vault é também o diretório onde o Claude Code roda. É isso que faz o CLAUDE.md da raiz valer como regra do agente em toda sessão aberta ali.

Passo 1: três decisões antes da primeira pasta

Onde a pasta mora. Sugestão de caminho curto e estável, fora de pasta sincronizada por ferramenta que resolve conflito sozinha. Se a pessoa usa OneDrive ou Drive sincronizado, avisar que sincronia automática sobre markdown editado por agente produz conflito silencioso, e que git resolve isso melhor.

Se versiona, e onde. Vault é markdown em disco. Se for para o git, a escolha entre repositório na organização e conta pessoal é de governança, não de conveniência: conteúdo de trabalho da empresa em conta pessoal é decisão que precisa ser consciente e escrita no CLAUDE.md. Em qualquer caso, registrar o que nunca entra no vault: credencial, token, chave de API, dado pessoal sensível, avaliação de desempenho de terceiro, dado de cliente identificável.

Qual tamanho começa hoje. Pasta nasce quando a primeira nota dela nasce.

Começar no Mínimo é quase sempre a resposta certa. Estrutura vazia por antecipação não organiza nada e ensina a pessoa a ignorar pasta.

Passo 2: entrevistar o dono

Rodar os blocos de references/entrevista.md, em conversa, sem formulário. Vale a mesma regra do vault original: não preencher lacuna com suposição plausível. Resposta que não existe vira ⚠️ a confirmar no CLAUDE.md e continua faltando até alguém responder. Um CLAUDE.md com cinco lacunas marcadas e nenhuma invenção serve melhor que um completo e fantasiado, porque o agente que vier depois vai tratar o texto como verdade.

A entrevista tem duas saídas obrigatórias: o contexto que vai para o CLAUDE.md e a primeira captura real, usada no passo 5.

Passo 3: criar a estrutura e escrever o CLAUDE.md

O script de bootstrap faz o mecânico (pastas, arquivos de sistema, templates, .gitignore, .gitkeep em pasta que nasceu vazia) e não inventa conteúdo. Ele não sobrescreve arquivo existente, então rodar duas vezes é seguro.

powershell -ExecutionPolicy Bypass -File <caminho-da-skill>\assets\bootstrap.ps1 -Destino "C:\Users\<user>\Desktop\SecondBrain" -Tamanho padrao

bash <caminho-da-skill>/assets/bootstrap.sh ~/SecondBrain padrao

Os dois aceitam minimo, padrao ou completo, e -ComGit (--com-git no bash) para já inicializar o repositório local. Fazer à mão também serve, o script só evita esquecimento. Em qualquer caminho:

1. Criar as pastas do tamanho escolhido. Cada pasta nasce com um arquivo dentro, nem que seja o índice. Pasta vazia some do explorador e do git.
2. Copiar assets/Painel.md para a raiz, assets/Como-usar.md para 00-Inbox/ e, do tamanho Padrão para cima, assets/Protocolo-de-Notas.md e assets/templates/*.
3. Escrever o CLAUDE.md a partir de assets/CLAUDE-modelo.md, substituindo todo marcador {{...}} pelas respostas da entrevista. Marcador que sobrou é erro: ou vira resposta, ou vira ⚠️ a confirmar com a pergunta escrita por extenso.
4. Escrever o primeiro 00-Sistema/Estado.md com a foto real do dia da entrevista, e o primeiro log em 00-Sistema/Log/Log-AAAA-MM-DD.md.
5. Abrir a pasta no Obsidian como vault e confirmar que o Painel.md aparece.
6. Se o vault tem estrutura que diverge do padrão (pasta a mais, regra própria), escrever o primeiro ADR explicando a divergência. Estrutura muda por decisão registrada, nunca por conveniência de uma sessão.

O CLAUDE.md fica curto. Regra longa demais é regra ignorada: o essencial mora nele e o detalhe operacional vai para 00-Sistema/Protocolo-de-Notas.md.

Passo 4: plugins do Obsidian, todos opcionais

Ver references/plugins-obsidian.md. O vault funciona em Obsidian pelado, e funciona até sem Obsidian. Instalar plugin é escolha de conforto do dono, com um custo declarado: consulta dataview dentro de nota vira texto cru para quem abrir o arquivo fora do Obsidian, e o agente que lê o arquivo enxerga o código da consulta, não o resultado dela.

Regra que não muda com plugin nenhum: nenhum índice é mantido à mão. Sem dataview, o índice vira uma busca que o agente roda na hora, não uma lista escrita no arquivo. Lista manual de projetos apodrece na primeira semana.

Passo 5: processar a primeira captura junto com o dono

Este passo não é opcional e é o que separa um vault vivo de uma pasta bonita.

1. Pedir uma captura real, agora, no formato que a pessoa já usa: texto colado de reunião, três linhas soltas, um link com um comentário. Salvar em 00-Inbox/ sem editar.
2. Processar na frente dela, dizendo cada decisão em voz alta: o que virou nota atômica, o que virou projeto, o que virou tarefa, o que ficou marcado como a confirmar.
3. Mover o bruto para 00-Sistema/Bruto/AAAA-MM-DD-slug.md sem alterar uma palavra.
4. Devolver as três listas do protocolo: o que foi criado, o que virou proposta esperando confirmação dela, e onde a captura contradiz algo que já estava no vault.
5. Fechar a sessão pelo protocolo completo: log do dia, Estado.md reescrito, notas de projeto tocadas atualizadas.

A pessoa precisa ver o ciclo inteiro uma vez para confiar que pode despejar sem organizar. Enquanto ela achar que precisa formatar antes de capturar, ela não captura, e vault sem entrada morre em três semanas.

Passo 6: checklist de aceite

O vault está de pé quando as seis afirmações abaixo são verdadeiras. Rodar o checklist com o dono, não sozinho.

• Uma captura real foi processada de ponta a ponta, com bruto preservado.
• Estado.md descreve o presente da pessoa, e não o que a skill imaginou.
• O log do dia existe e registra a sessão de montagem, incluindo o que ficou em aberto.
• Painel.md abre no Obsidian e devolve alguma coisa, ou o vault assumiu explicitamente que não usa consulta viva.
• O CLAUDE.md nomeia o dono, o mandato dele, o que o agente nunca pode fazer e onde o vault mora.
• A pessoa responde, sem olhar, onde ela despeja uma ideia de três palavras às onze da noite.

Falhou alguma, o vault não foi entregue. Registrar o que falta no log e combinar quando fecha.

Passo 7: combinar a segunda sessão

Vault morre entre a montagem e o primeiro uso sozinho. Antes de encerrar, fechar duas coisas com a pessoa: quando ela vai capturar pela primeira vez sem ajuda, e quando a sessão de revisão acontece (uma semana depois serve). Na revisão, rodar a seção de auditoria abaixo e corrigir o que apareceu.

Revisar um vault que já existe

Mesmo procedimento, invertido. Ler CLAUDE.md, Estado.md, o último log e uma amostra de dez notas, e checar contra references/contratos.md. Os sintomas que aparecem primeiro, na ordem em que costumam aparecer:

Inbox com resíduo de mais de uma sessão diz que o processamento parou. Nota sem fonte: diz que opinião do agente entrou como fato. Duas notas afirmando a mesma coisa dizem que ninguém buscou antes de criar. Estado.md crescendo por acumulação diz que virou histórico, e histórico é o log. Log reescrito diz que a trilha de auditoria foi perdida e não volta. Diário editado pelo agente diz que o contrato mais importante do sistema caiu.

Entregar como lista de problema com correção proposta, e aplicar só depois do aval do dono.

O que esta skill não faz

• Não copia contexto de outro vault. Empresa, área, projeto e pessoa vêm da entrevista.
• Não cria projeto, área ou nota de pessoa que o dono não nomeou.
• Não decide sozinha onde o vault mora nem o que pode ser versionado.
• Não instala plugin sem o dono escolher, e não trata plugin como requisito.
• Não entrega vault vazio. Sem a captura do passo 5, o trabalho não terminou.
• Não monta base compartilhada de time. Memória pessoal e contexto de sistema são desenhos diferentes.

Como instalar a skill na máquina de quem vai montar o vault

A pasta inteira (SKILL.md, references/, assets/) vai para ~/.claude/skills/criar-second-brain/. No Windows:

Copy-Item -Recurse <origem>\criar-second-brain "$env:USERPROFILE\.claude\skills\criar-second-brain"

Nada aqui depende de caminho absoluto, de conteúdo de outro vault ou de servidor MCP. Vale na sessão seguinte, sem reiniciar nada.

Quem mantém a skill mantém uma cópia canônica só, e corrige nela quando o uso revelar erro. Cópia divergente espalhada por várias máquinas tem o mesmo defeito de um fato duplicado em dois arquivos: as duas versões discordam no instante em que uma muda.