ahmadrayz007/second-brain-claude-skill

Guardião do Cofre Obsidian

Transforme o Claude Code / Claude Cowork em um co-piloto de anotações para um cofre Obsidian. Em vez de respostas que evaporam quando a sessão termina, o Claude escreve markdown estruturado no cofre — pesquisas, decisões, status de projetos, reuniões e notas diárias — usando convenções que mantêm o cofre pesquisável, linkável e legível por IA.

Quando ativar este skill

Ative em qualquer um destes casos:

• Explícito: "log this", "note this", "save to vault", "add to Obsidian", "catat ini"
• Pesquisa — o usuário compartilha uma URL, pede investigação, resume descobertas ou compara opções.
• Decisão — o usuário diz "vamos com…", "decidimos…", "escolhemos X em vez de Y", "a decisão final é…"
• Progresso de projeto — o usuário relata status, atinge um marco, menciona um bloqueio ou define um próximo passo.
• Reunião — o usuário menciona uma ligação, 1:1, sincronização, daily ou cola uma transcrição.
• Limite de sessão — primeira mensagem substancial de um novo dia (abrir nota diária) ou o usuário finaliza (anexar resumo).

Se uma mensagem contiver múltiplos gatilhos, trate o mais específico primeiro (decisão > pesquisa > projeto > reunião > diário).

Passo 1 — Resolver o caminho do cofre

Antes de qualquer escrita de arquivo, resolva VAULT nesta ordem. Pare no primeiro acerto:

1. Suba a partir do CWD. Começando no diretório de trabalho atual, suba até $HOME. O pai de qualquer pasta .obsidian/ é o cofre. Use esse.

2. Leia a configuração. Verifique ~/.claude/second-brain.config.json por uma chave vaultPath.

3. Pergunte uma vez. Se nada for resolvido, pergunte ao usuário pelo caminho absoluto do cofre. Na resposta, persista:

   mkdir -p ~/.claude
   echo '{"vaultPath": "/absolute/path/to/vault"}' > ~/.claude/second-brain.config.json
   

Nunca escreva fora de VAULT. Nunca modifique as notas existentes do usuário de forma destrutiva — anexe ou crie novos arquivos.

Passo 2 — Respeitar a estrutura existente

Antes de criar pastas, execute ls "$VAULT" uma vez por sessão e armazene os nomes das pastas em cache no contexto. Se o usuário já tiver notes/, decisions/, meetings/ etc., use essas pastas em vez de criar as canônicas abaixo. Crie uma pasta canônica apenas quando não existir nada equivalente.

Layout canônico (crie conforme necessário):

VAULT/
├── Daily/                YYYY-MM-DD.md
├── Research/             tópico, evergreen
├── Decisions/            um arquivo por decisão
├── Projects/
│   └── <Project Name>/
│       ├── README.md     Mapa de Conteúdo (MOC)
│       └── Status.md     status vivo
├── Meetings/             YYYY-MM-DD-<slug>.md
└── Inbox/                captura rápida, não classificado

Passo 3 — Os 5 cenários

Política de escrita padrão (veja Modo de operação abaixo para como sobrescrever):

• Escrita automática silenciosa para: notas diárias (todas as operações), atas de reunião, atualizações de status de projeto e anexos a arquivos de pesquisa existentes. Apenas escreva. Relate o caminho depois.
• Confirmação primeiro para exatamente duas coisas: criar um novo arquivo ADR (Cenário B) e criar um novo arquivo de tópico de pesquisa (Cenário A, primeira vez para aquele tópico). Estes são os únicos arquivos completamente novos e semanticamente pesados — vale uma confirmação de 2 segundos porque são permanentes.

Todo o resto tem baixo risco para interromper. Para cada cenário: carregue o template correspondente de templates/, preencha os placeholders, escreva, depois reporte o caminho relativo ao cofre.

Cenário A — Pesquisa

Gatilho: usuário compartilha uma fonte ou pede para o Claude investigar.

1. Identifique ou crie um slug de tópico (PascalCase ou kebab-case — siga a convenção do cofre).
2. Destino: Research/<Topic>.md. Se existir, anexe uma nova seção datada; se for novo, use templates/research.md.
3. Preencha: contexto, fontes com URLs, descobertas principais, implicações, perguntas em aberto, [[wikilinks]] relacionados.
4. Adicione uma entrada na nota diária de hoje sob ## Notes Created.
5. Reporte o caminho completo de volta ao usuário.

Cenário B — Decisão (ADR)

Gatilho: usuário se compromete com uma escolha.

1. Destino: Decisions/YYYY-MM-DD-<slug>.md usando templates/decision.md.
2. Preencha: contexto, opções consideradas (cada uma com prós/contras), opção escolhida, justificativa, consequências.
3. Se vinculado a um projeto, adicione um backlink em Projects/<Project>/README.md.
4. Anexe à nota diária de hoje sob ## Decisions.

Cenário C — Progresso de projeto

Gatilho: atualização de status, marco, bloqueio ou próximo passo.

1. Destino: Projects/<Project>/Status.md. Crie se estiver faltando usando templates/project-status.md.
2. Atualize o corpo + incremente updated: no frontmatter.
3. Anexe uma linha de entrada na nota diária de hoje sob ## Project Updates com um [[wikilink]] de volta ao arquivo de status.
4. Se um novo marco for concluído, risque-o; não delete.

Cenário D — Reunião

Gatilho: usuário descreve uma reunião ou compartilha uma transcrição.

1. Destino: Meetings/YYYY-MM-DD-<slug>.md usando templates/meeting.md.
2. Preencha: participantes, pauta, discussão, decisões, itens de ação, acompanhamentos.
3. Para cada decisão significativa na reunião → também gere o Cenário B (crie um ADR).
4. Para cada item de ação atribuído ao usuário → anexe à nota diária de hoje sob ## Action Items.

Cenário E — Nota diária

No início da sessão (primeira mensagem substancial de um novo dia calendário):

1. Verifique se Daily/YYYY-MM-DD.md existe. Se estiver faltando, crie a partir de templates/daily.md.
2. Migre tarefas não marcadas da nota diária de ontem para a seção ## Carry-over.
3. Cumprimente o usuário com o foco de hoje + contagem de carry-over.

No final da sessão (usuário finaliza, pressiona /clear ou envia "isso é tudo por hoje", etc.):

1. Anexe uma seção ## Session Summary listando: trabalho principal realizado, decisões tomadas (com links), notas criadas (com links).
2. Se o usuário mencionou próximos passos, preencha ## Tomorrow.

Passo 4 — Convenções universais

Veja conventions.md para o especificação completa. Referência rápida:

• Toda nota tem frontmatter. Mínimo: type, created, updated, tags. Adicione campos específicos por template.
• Datas são ISO. YYYY-MM-DD em todos os lugares. Hoje é resolvido pela data do sistema, não adivinhado.
• Wikilinks [[Note Name]] para qualquer entidade que tenha (ou poderia ter) sua própria nota: projetos, pessoas, conceitos. Prefira wikilinks em vez de duplicar conteúdo.
• Tags são namespaced. #research/competitor, #decision/tech, #project/<slug>, #meeting/1on1.
• Nomes de arquivo: YYYY-MM-DD-slug.md para notas datadas (reuniões, decisões, diárias); PascalCase.md ou kebab-case.md para notas evergreen (pesquisa, MOCs de projeto) — siga o que o cofre já usa.
• Fallback para Inbox. Se você não conseguir classificar um trecho, coloque-o em Inbox/YYYY-MM-DD-<slug>.md com uma tag #inbox — não force o encaixe.

Modo de operação

Padrão: mixed — escrita automática silenciosa para trabalho rotineiro, confirmação apenas para novos ADRs e novos arquivos de tópico de pesquisa (conforme especificado no Passo 3). Isso é o que vem configurado.

Os usuários podem sobrescrever o modo verbalmente durante uma sessão. Fique atento a estas pistas e ajuste para o resto da sessão:

O usuário diz	Comportamento
"modo automático", "modo silencioso", "vai automático", "para de perguntar", "apenas faça"	Desabilite todas as confirmações. Escreva tudo silenciosamente, incluindo novos ADRs e novos arquivos de pesquisa. Ainda reporte os caminhos depois.
"voltar ao padrão", "modo confirmação", "pergunte primeiro"	Restaure o comportamento padrão mixed.
"salve isso" / "registre isso" (um único comando)	Escreva independentemente do modo. Sem confirmação.
"não registre" / "pule isso" (um único comando, referindo-se a algo recém-dito)	Não escreva a nota inferida. Se já foi escrita nesta rodada, reporte que foi escrita e ofereça deletar.

As sobrescrições de modo são válidas apenas na sessão, não são persistidas. Se o usuário quiser uma mudança permanente, ele pedirá — então salve em ~/.claude/second-brain.config.json sob uma chave defaultMode (auto | mixed | manual).

O modo manual existe apenas se um usuário o persistir via configuração: escreva apenas quando o usuário disser explicitamente "save"/"log"/"note this".

Regras de comportamento

• Idempotência. Antes de anexar a uma nota existente, escaneie seu conteúdo. Se a mesma informação já estiver lá, pule ou anexe uma diferença apenas com timestamp.
• Escritas atômicas. Uma escrita por chamada de ferramenta — nunca agrupe atualizações não relacionadas em uma única edição de arquivo.
• Reporte caminhos de volta. Após cada escrita, informe ao usuário o caminho relativo a partir de VAULT/ para que ele possa usar Cmd+O.
• Nunca delete. Se algo precisar ser substituído, marque o conteúdo antigo com ~~strikethrough~~ ou mova para uma seção Archive/ dentro da mesma nota.
• Proteção contra falsos positivos. Se não tiver certeza se algo se qualifica (por exemplo, o usuário disse "talvez tentemos X"), trate como especulação — não crie um arquivo de decisão ou pesquisa. Na dúvida, fique em silêncio e deixe o usuário pedir explicitamente.

Arquivos neste skill

• SKILL.md — este arquivo (carregado automaticamente pelo Claude Code)
• conventions.md — referência completa de convenções
• templates/research.md, decision.md, project-status.md, meeting.md, daily.md
• examples/ — exemplos de notas preenchidas
• README.md — instalação + visão geral para o usuário