Workflow Obsidian para CLAUDE.md com Claude Code

Se o vault Obsidian tem as notas de trabalho, mas toda sessão Claude Code começa com a mesma explicação, existe uma lacuna entre gestão de conhecimento e implementação. Este fluxo transforma notas livres em contexto operacional curto para CLAUDE.md.

Quem chega por Obsidian não quer apenas integração. Quer que notas melhorem a qualidade da implementação. A resposta não é enviar o vault inteiro, mas extrair decisões atuais, restrições e comandos de prova.

Leituras relacionadas: claude-code-obsidian-integration, claude-code-claude-md-starter-template, claude-md-best-practices.

Por que este padrão vem antes da primeira edição

Claude Code funciona melhor quando a tarefa tem uma fronteira clara. Uma boa fronteira nomeia arquivos que pode ler, arquivos que pode editar, operações proibidas e a prova que encerra o trabalho. Sem isso, um prompt pequeno de iniciante pode virar reescrita ampla, e uma mudança de conteúdo pode quebrar PDF gratuito, Gumroad ou consultoria.

Esse padrão também ajuda receita porque conecta prova técnica com prova para o leitor. Uma página que builda localmente mas envia o leitor ao produto errado não está pronta. Ao registrar scope, comando, URL pública e CTA, amanhã você melhora por evidência, não por memória.

Fluxo prático

1. No Obsidian, separe fatos, decisões, perguntas abertas e próximas ações
2. Uma vez por semana, extraia só o contexto que Claude Code deve ver
3. Regras estáveis vão para CLAUDE.md; estado temporário vai para handoff
4. Em conteúdo, inclua decisões de CTA e regras de routing de produto
5. Apague decisões antigas para manter o contexto leve

Situação	Movimento seguro	Prova
Operações de conteúdo	Use Obsidian para pensar intenção de busca, produto e CTA. Em CLAUDE.md ficam apenas regras recorrentes de revenue.	build, diff, URL
Engenharia em equipe	Histórico completo fica no Obsidian; Claude Code recebe regras atuais e áreas proibidas.	screenshot, test
Debugging	Histórico de hipóteses fica nas notas; a próxima sessão recebe fatos verificados e próximo comando.	log, command, handoff

A primeira passada deve ser curta. A auditoria deve gerar uma decisão, não um relatório gigante. Se depois de 20 minutos a decisão ainda está confusa, o passo seguro é ler mais um arquivo, não começar a editar.

Prompt e código copiáveis

Leia esta nota do Obsidian e separe em regras para CLAUDE.md, estado temporário de handoff e informação antiga que não deve seguir.

const note = {
  title: "Checkout copy bug",
  facts: ["mobile CTA wraps", "Gumroad link still works"],
  decisions: ["keep paid CTA after free PDF"],
  commands: ["npm.cmd run build"],
};

export function toClaudeMdBlock(item) {
  return [
    "## Current operating note",
    `- Topic: ${item.title}`,
    `- Facts: ${item.facts.join("; ")}`,
    `- Decisions: ${item.decisions.join("; ")}`,
    `- Proof command: ${item.commands[0]}`,
  ].join("\n");
}

console.log(toClaudeMdBlock(note));

O código é pequeno de propósito. Ele transforma uma ideia operacional em objeto verificável: existe scope, existem áreas protegidas e existe ao menos um comando de prova. Você pode adaptar para publicação, app, debug ou handoff.

Três exemplos reais

Operações de conteúdo

Use Obsidian para pensar intenção de busca, produto e CTA. Em CLAUDE.md ficam apenas regras recorrentes de revenue.

O ponto importante é a prova. Guarde um comando, uma página visível ou uma nota mostrando que o trabalho chegou ao leitor.

Engenharia em equipe

Histórico completo fica no Obsidian; Claude Code recebe regras atuais e áreas proibidas.

O ponto importante é a prova. Guarde um comando, uma página visível ou uma nota mostrando que o trabalho chegou ao leitor.

Debugging

Histórico de hipóteses fica nas notas; a próxima sessão recebe fatos verificados e próximo comando.

O ponto importante é a prova. Guarde um comando, uma página visível ou uma nota mostrando que o trabalho chegou ao leitor.

Falhas que devem ser evitadas

• Enviar o vault inteiro mistura decisões antigas com restrições atuais.
• Transformar CLAUDE.md em diário esconde regras importantes.
• Deixar CTA só nas notas desalinha artigo e produto.

Outra falha sutil é drift de localização. O artigo em inglês pode explicar o produto correto enquanto outro idioma mantém CTA antigo. Por isso a verificação pública precisa ler h1, abertura e CTA em cada idioma, não só frontmatter lang.

Como levar o leitor ao PDF, Gumroad e consultoria

Se o leitor ainda precisa dominar comandos, envie para o cheatsheet gratuito. Se o bloqueio está em setup, permissões, CLAUDE.md, hooks, MCP ou CI/CD, o melhor próximo passo pago é o Setup Guide. Para prompts repetidos de review, debugging e refactor, use 50 Prompt Templates. Para rollout de equipe, desenho de workflow ou rota de receita, use a consultoria. Para comparar opções, veja products.

Não empurre todo leitor direto para produto pago. Iniciantes geralmente precisam primeiro de um PDF simples. Quem repete prompts está mais perto de templates. Quem trava em permissões, CLAUDE.md, hooks, MCP ou CI/CD está mais perto do Setup Guide. Times com dúvidas de processo estão mais perto da consultoria.

O que verificar antes e depois de publicar

Verificar este artigo significa conferir h1, abertura do texto, heroImage, links internos, links Gumroad e caminho de consultoria. HTTP 200 não basta se o CTA aponta para a próxima ação errada.

Na publicação multilíngue, verifique japonês, inglês, chinês, coreano, espanhol, francês, alemão, português, hindi e indonésio separadamente. O slug pode bater e o corpo ainda estar antigo. Screenshots mobile mostram abertura e CTA juntos.

Métricas para observar depois

Observe inícios de PDF, cliques Gumroad, visitas a products, visitas a training, origem de busca, países e taxa de clique de artigo para CTA. Se PV sobe sem Gumroad, falta ajuste de produto. Se consulta sobe a partir de artigo técnico, o leitor provavelmente precisa de desenho de workflow.