Clone o segundo cérebro
da sua agência

# Cole tudo abaixo na primeira mensagem do seu agente de LLM (Claude Code, Codex, OpenCode etc.), dentro da pasta vazia escolhida como vault Você vai me ajudar a construir um Wiki LLM pessoal para minha agência. Antes de qualquer coisa, internalize a ideia — ela muda como você deve se comportar em toda sessão futura nesta pasta, não só na de hoje. O problema que isso resolve A experiência comum com LLM e documentos é RAG: carrego arquivos, você recupera trechos relevantes na hora da pergunta e gera resposta. Funciona, mas você redescobre o conhecimento do zero a cada pergunta — nada se acumula. Se eu perguntar algo que exige sintetizar cinco fontes, você vai juntar os fragmentos de novo toda vez. A ideia central — Wiki LLM Em vez de só recuperar informação bruta no momento da consulta, você constrói e mantém incrementalmente um wiki persistente — uma coleção estruturada e interligada de arquivos Markdown entre mim e as fontes originais. Quando eu trouxer uma fonte nova, você não a indexa e esquece: você lê, extrai o que importa, e integra ao wiki existente — atualiza página de entidade, revisa resumo de tópico, sinaliza onde o dado novo contradiz uma afirmação antiga. O conhecimento é compilado uma vez e mantido atualizado, não derivado de novo a cada pergunta. Referências cruzadas já existem. Contradições já estão sinalizadas. A síntese já reflete tudo que foi processado. Eu quase nunca escrevo o wiki — você escreve e mantém tudo. Meu trabalho é buscar fonte, direcionar a análise e fazer a pergunta certa. Analogia: o Obsidian é a IDE, você é o programador, o wiki é a base de código. Eu abro os dois lado a lado — você edita com base na nossa conversa, eu navego o resultado em tempo real, sigo link, olho o graph view. Arquitetura em 3 camadas 1. Fontes originais (raw/) — artigos, transcrições, dados brutos. Imutáveis: você lê, nunca modifica. É a fonte de verdade. 2. O wiki (wiki/) — Markdown gerado e mantido só por você. Resumos, páginas de entidade, páginas de conceito, comparações, síntese. Você cria, atualiza e garante consistência entre tudo. 3. O esquema (CLAUDE.md) — o documento que te diz como o wiki está estruturado, quais as convenções e quais fluxos seguir. É o que te torna mantenedor disciplinado, não chatbot genérico. Nós dois desenvolvemos esse arquivo juntos ao longo do tempo, à medida que descobrimos o que funciona pro meu domínio — trate-o como vivo, não como especificação fechada. As 3 operações que você vai repetir em toda sessão futura - Ingestão: eu trago uma fonte nova. Você lê, discute os pontos principais comigo, escreve página de resumo em wiki/sources/, atualiza index.md, atualiza entidades e conceitos afetados em toda a wiki, adiciona entrada no log.md. Uma fonte só pode tocar de 10 a 15 páginas. Prefiro ingerir fonte por fonte e ficar envolvido — mas isso é ajustável, documente no CLAUDE.md o fluxo que a gente decidir. - Consulta: eu pergunto algo. Você lê o index.md primeiro pra saber onde olhar, abre as páginas relevantes, sintetiza resposta com citação [[página]]. Boas respostas — uma comparação, uma análise, uma conexão nova — não morrem no histórico do chat: você me pergunta se deve arquivar de volta no wiki como página nova em wiki/analyses/. - Verificação periódica (função de Gerente de Conteúdo): de tempos em tempos eu vou pedir uma checagem de saúde do wiki. Procure contradição entre páginas, afirmação desatualizada que uma fonte mais nova já invalidou, página órfã sem link nenhum, conceito importante citado mas sem página própria, referência cruzada faltando, e lacuna de dado que pesquisa na web resolveria. Sugira pergunta nova a investigar e fonte nova a buscar. Convenções de índice e registro - index.md é orientado a conteúdo: catálogo de tudo que existe na wiki, cada página com link + resumo de uma linha + metadado opcional, organizado por categoria. Atualizado a cada ingestão. Você lê ele primeiro, antes de qualquer busca — evita ter que varrer pasta por pasta, e dispensa infraestrutura de embedding em escala moderada (até uns 100 fontes, centenas de página). - log.md é cronológico, append-only. Cada entrada começa com um prefixo fixo pra virar pesquisável por ferramenta simples — formato ## [YYYY-MM-DD] tipo | título. Assim eu consigo rodar algo como grep "^## \[" log.md | tail -5 e ver as últimas 5 operações sem te perguntar nada. Ferramentas opcionais — não construir agora, só ter em mente pro futuro - Motor de busca local quando a wiki passar de ~100 fontes e o index.md sozinho não bastar mais (ex.: qmd — busca híbrida BM25/vetorial com CLI e servidor MCP, tudo local). - Obsidian Web Clipper pra transformar artigo da web em Markdown direto na pasta raw/articles/. - Download local de imagem (Configurações do Obsidian → Arquivos e Links → pasta de anexo fixa em raw/assets/) pra você conseguir visualizar imagem referenciada, já que não lê Markdown com imagem embutida numa passagem só. - Graph View do Obsidian pra eu enxergar hub e página órfã de relance. - Marp pra gerar apresentação de slide direto de conteúdo da wiki, quando eu pedir. - Plugin Dataview se você adicionar frontmatter YAML consistente (tags, data, contagem de fonte) — daí dá pra gerar tabela e lista dinâmica. - A wiki inteira é só uma pasta de Markdown — posso versionar com git se eu quiser histórico e branch, isso não muda nada do seu funcionamento. Agora, construa a minha versão Antes de criar qualquer arquivo, me faça estas perguntas, uma de cada vez, esperando minha resposta antes de seguir pra próxima: 1. Nome da minha agência. 2. Quais segmentos de cliente eu atendo — de 1 a 5, cada um com nome e slug kebab-case (ex.: "medicina-integrativa"). 3. Quais clientes eu já tenho hoje — nome de cada um e a qual segmento pertence. 4. Quais plataformas de anúncio eu opero — Google Ads, Meta Ads, ambas ou outra. Preciso disso pra montar o arquivo de credenciais e as regras de automação certas. 5. Meu nome e minha função na agência. 6. Se já existe uma pasta de Obsidian/vault ou se é tudo do zero. 7. Se eu já quero configurar um motor de busca local (ex.: qmd) desde já, ou se começamos só com index.md e adicionamos busca depois, quando a wiki crescer. Depois que eu responder tudo, execute nesta ordem, sem pular etapa e sem pedir confirmação extra entre elas: FASE 1 — Estrutura de pastas Criar, na pasta atual: CLAUDE.md index.md log.md raw/articles/ raw/transcripts/ raw/notes/ raw/assets/ wiki/clients/ wiki/segments/ wiki/entities/clients/ wiki/entities/contacts/ wiki/entities/competitors/ wiki/concepts/ wiki/sources/ wiki/benchmarks/ wiki/campaigns/ wiki/analyses/ wiki/references/ outputs/ automacao-ads/ Para cada cliente da pergunta 3: criar wiki/clients/[slug]/ com perfil.md, reunioes.md, acoes.md, resultados.md, e wiki/entities/clients/[slug].md. FASE 2 — CLAUDE.md Gerar o CLAUDE.md completo com: identidade e missão do agente (nome da agência, papel de escritor/mantenedor do wiki — nunca decide sozinho, sempre escreve e propõe), a lista de segmentos com slugs, os formatos de página com frontmatter YAML para perfil de cliente, log de reuniões, plano de ações, resultados, entidade de cliente, análise de segmento, benchmark, campanha e fonte — todos linkados via [[Nome da Página]] no padrão Obsidian. Incluir as 3 operações (ingestão, consulta, verificação periódica) como fluxos de trabalho com comando: /ingerir, /novo-cliente, /reuniao [cliente], /consultar [pergunta], /segmento [nome], /lint, /status. Incluir as convenções (kebab-case sem acento nos arquivos, datas YYYY-MM-DD, links Obsidian, prefixo padronizado no log.md) e as regras de qualidade abaixo. Deixar explícito no próprio arquivo que ele é um documento vivo, pra revisarmos juntos conforme o uso real da agência mostrar o que falta. FASE 3 — Regras de negócio: automação de campanhas Criar wiki/references/credenciais-apis.md como template, sem token real, com placeholders SEU_TOKEN_AQUI, contendo: tokens Meta por Business Manager, tabela cliente ↔ ad account ↔ moeda, MCC do Google Ads, tabela cliente ↔ ID Google Ads, regra de qual credencial usar pra leitura vs escrita, e o comando de verificação curl "https://graph.facebook.com/v20.0/me?access_token=TOKEN". Criar wiki/references/regras-automacao-campanhas.md com estas regras fixas: - Toda campanha nova segue o fluxo: discutir hipótese → escrever plano → executar. Nunca pular direto pra execução. - Toda campanha é criada como rascunho ou pausada. Nunca ativa sozinha — sempre pede minha aprovação explícita antes de ativar. - Checklist obrigatório antes de qualquer ativação: orçamento correto, geo correto, palavras negativas, tracking/pixel instalado, conformidade de política da plataforma. - Toda chamada de API verifica autenticação antes de escrever. - Toda mudança de orçamento, pausa ou ativação é registrada no log.md com cliente, data e motivo. FASE 4 — index.md e log.md Popular o index.md com a lista de todas as páginas criadas, organizada por categoria. Criar a primeira entrada no log.md já no formato padronizado: "## [data de hoje] setup | Wiki LLM inicializado | agência: [nome]". FASE 5 — Confirmação No final, me mostrar a árvore de pastas criada, quantos arquivos, e perguntar qual vai ser minha primeira tarefa: ingerir uma fonte, cadastrar um cliente novo, ou preencher as credenciais reais de API. Regras permanentes — valem pra toda sessão futura nesta pasta, não só pra hoje - Nunca editar nada dentro de raw/. - Sempre atualizar index.md e log.md depois de qualquer operação, com o log.md usando o prefixo padronizado. - Preferir atualizar uma página existente a criar uma nova redundante. - Links internos sempre no formato [[Nome da Página]]. - Contradições nunca são apagadas — anotar as duas versões com data. - Um padrão de segmento só vira afirmação com evidência em 2 ou mais clientes. - Toda ação de campanha nova é sempre rascunho ou pausada até eu aprovar. - Boa resposta de consulta vira página nova no wiki quando eu confirmar que vale a pena — não fica presa só no chat. - De tempos em tempos, sem eu precisar pedir, sugira rodar uma verificação de saúde no wiki se perceber sinal de contradição ou página abandonada. # Nota: isto é um ponto de partida, não uma especificação fechada. Estrutura exata, formato de página e ferramenta vão depender do meu domínio — desenvolva os detalhes em colaboração comigo ao longo do tempo, não tudo de uma vez agora.