Meeting Digest

Ferramentas: chamadas de passo a função de função (pm.*, email.*, calendar.*, docs.*, files.*, comms.*). Resolva cada uma através de Context/agent-config.md → Tool Stack e o adaptador que ele nomeia (.claude/adapters/README.md). Uma função definida como none → pule essa etapa.

Busque todas as reuniões de um dia alvo, encontre as notas ou transcrições de cada uma, produza um resumo estruturado e salve-o localmente. O dia alvo padrão é hoje; passe "yesterday" para processar o dia anterior.

Configuração

Leia Context/agent-config.md no início. Use:

timezone — para todos os cálculos de data
base_directory — para construção de caminhos de arquivo e verificação de idempotência
calendar_exclusions — lista de padrões de título de reunião a pular
Tool Stack → Meeting notes — de onde vem o conteúdo da reunião

Leia o arquivo de metas (caminho em agent-config) para reconhecer nomes de projetos e marcos na Etapa 4.

Instruções

Execute todas as etapas em sequência. Não peça confirmação entre as etapas, a menos que explicitamente instruído a pausar.

Etapa 1 — Buscar todas as reuniões não processadas do dia alvo

Fase A — Calendário: obter a lista de reuniões

Calcule a data alvo no fuso horário do usuário. Padrão = hoje; se o usuário passou "yesterday", subtraia um dia.
calendar.events(início da data alvo, fim da data alvo) no fuso horário do usuário.
Filtrar apenas reuniões reais. Remova qualquer evento onde:
- summary corresponda a um padrão em calendar_exclusions
- seja um bloco de foco ou local de trabalho
- a lista attendees esteja vazia ou contenha apenas o usuário (blocos solo)
Ordenar cronologicamente (mais antigo primeiro). Esta é a lista ordenada de reuniões a processar.

Fase B — Verificação de idempotência

Para cada reunião:

Derive o nome de arquivo de notas esperado: YYYY-MM-DD - [Nome da Reunião].md usando o summary do evento do calendário. Sanitize o nome: substitua /, \, : e | por -, remova emojis, colapse espaços repetidos.
Verifique se um arquivo com esse nome já existe em [base_directory]/Context/Meeting Notes/.
Se existir e já tiver uma seção ## Summary → pule esta reunião. Saída: "Notas já existem para [nome da reunião] — pulando."
Se existir como notas brutas (sem ## Summary) → use seu conteúdo como fonte e prossiga.
Se não existir → prossiga para a Fase C.

Fase C — Encontrar o conteúdo da reunião

Verifique as fontes nesta ordem e use a primeira que tiver conteúdo:

Arquivo de notas brutas — da Etapa B passo 4.
Fontes configuradas — cada entrada em agent-config → Meeting notes sources, em ordem. Típicas:
- Anexos do calendário — um documento de notas anexado ao evento → files.read com seu ID de arquivo. "Não encontrado" significa que não foi compartilhado com o usuário — pule silenciosamente
- docs.meeting_notes(date) — corresponda por título ou janela de tempo (±30 min); leia com docs.read
Descrição do evento do calendário — use apenas se contiver notas reais, não apenas uma agenda ou link de vídeo.
Pergunte ao usuário — liste as reuniões que ainda não têm conteúdo em uma mensagem: "Nenhuma nota encontrada para: [lista]. Cole notas ou uma transcrição para qualquer uma que deseje resumir, ou diga skip."

Se uma reunião ainda não tiver conteúdo → marque como "no notes available" e pule-a.

Fase D — Relatório

Após processar todas as reuniões, relate:

Quantas foram resumidas
Quantas foram puladas (com motivo: já existe / sem notas)

Etapa 2 — Ler contexto

Antes de processar qualquer conteúdo de nota, leia:

GOALS.md — para entender projetos e metas ativos
Context/Memory/brain.md — para entender como o usuário pensa, seu vocabulário e o que ele considera uma decisão vs. uma discussão

Etapa 3 — Analisar o conteúdo da nota

Para cada reunião com conteúdo, extraia quatro coisas:

A. Resumo 2–3 frases. Sinal primeiro: sobre o que foi a reunião e qual foi o resultado ou mudança principal. Não é uma lista de tópicos abordados — uma declaração de resultado coerente. Use a voz do usuário: direta, sem enquadramento de esforço, lidera com resultado.

B. Decisões Compromissos explícitos que mudaram direção, travaram algo ou encerraram uma questão em aberto. Apenas decisões reais — não sugestões, não talvez. Formato: o que foi decidido e quem tomou a decisão (se atribuível).

C. Itens de ação Próximos passos concretos com um responsável nomeado. Aplique esta lógica por item:

Se a nota nomeia uma pessoa específica como responsável com alta confiança → atribua a eles
Se a responsabilidade é ambígua ou compartilhada → atribua ao usuário
Inclua apenas um item ou projeto de gerenciamento de projeto se foi explicitamente mencionado na reunião (por chave, nome ou referência clara). Não infira ou adivinhe — se nenhum foi mencionado, deixe a coluna Projeto em branco (—)
Anote a data de vencimento sugerida se mencionada na reunião, caso contrário deixe em branco

D. Perguntas em aberto / bloqueadores Perguntas não resolvidas, bloqueadores levantados ou tópicos adiados para uma reunião futura. Estes vão apenas no arquivo de notas.

Etapa 4 — Referências a projetos

Registre apenas uma chave de item ou nome de projeto quando foi explicitamente mencionado na reunião — por chave (ex. ENG-123), por nome (ex. "o marco da reformulação de onboarding") ou por referência inequívoca.

Não infira, procure ou adivinhe projetos a partir do contexto da reunião. É melhor deixar em branco do que atribuir um errado.

Etapa 5 — Escrever o arquivo de notas da reunião

Salve o resumo em Context/Meeting Notes/ usando este formato de nome de arquivo: YYYY-MM-DD - [Nome da Reunião].md

Use o summary do evento do calendário como nome da reunião.

Formato do arquivo:

# [Nome da Reunião]
*[YYYY-MM-DD] | [Duração se disponível] | [Participantes do calendário se disponíveis]*

## Resumo
[Resumo de 2–3 frases com sinal primeiro. O que aconteceu e o que mudou.]

## Decisões
- [Decisão 1 — quem a tomou se conhecido]
- [Decisão 2]

## Itens de Ação
| # | Tarefa | Responsável | Projeto | Vencimento |
|---|--------|-------------|---------|------------|
| 1 | [Descrição da tarefa] | [Nome / me] | [Nome do projeto (KEY-123) ou —] | [Data ou —] |
| 2 | ... | ... | ... | ... |

## Perguntas em Aberto e Bloqueadores
- [Pergunta ou bloqueador — o que não está resolvido e por que é importante]

## Contexto
[Qualquer contexto, links ou enquadramento da reunião que seja útil para referência futura. Máximo de 3–5 bullets.]

Se notas brutas foram a fonte (Etapa B passo 4), mantenha-as sob uma seção ## Notas brutas no final — nunca exclua as notas do usuário.

Antes de salvar, adicione [[wiki-links]] à nota para conectividade de gráfico do Obsidian:

Todas as pessoas mencionadas pelo nome → [[Nome]]
Todas as chaves de item → [[KEY-123]]
Conceitos-chave, projetos e temas que se repetem entre notas → [[Conceito]]
Apenas links para menções significativas — não cada palavra, não dentro de blocos de código ou URLs

Confirme ao usuário: "Notas da reunião salvas em Context/Meeting Notes/[nome do arquivo].md"

Etapa 6 — Composto ao toque

Após salvar:

Verifique se alguma decisão ou bloqueador desta reunião se relaciona a uma tarefa aberta em Tasks/ — se sim, anote inline.
Se um bloqueador foi levantado que já existe em GOALS.md como bloqueador conhecido, sinalize: "Este bloqueador ([nome]) também foi levantado em [contexto anterior]. Considere se é sistêmico."
Se a reunião é um 1:1 recorrente com uma pessoa nomeada que tem um documento em Context/121s/, anexe uma entrada de registro de sessão ao seu documento: data, resumo de 1 linha, quaisquer loops abertos adicionados.

As notas da reunião contêm dados pessoais e nunca são commitadas ou enviadas.

Etapa 7 — Mostrar resumo no chat

Após salvar todas as notas localmente, exiba um resumo combinado para o resumo completo do dia.

Estrutura: reunião → tópico → decisões + ações sob cada tópico.

📝 **Resumo de reuniões completo — [YYYY-MM-DD]** | [N] resumidas | [N] puladas

*[Nome da Reunião]*
  [Tópico / meta ou marco]
    Decisões
      - [Decisão]
      - [Decisão]
    Itens de ação
      - [tarefa] → [responsável] [vencimento se conhecido]

  [Tópico 2]
    Decisões
      - [Decisão]
    Itens de ação
      - [tarefa] → [responsável]

Notas salvas em `Context/Meeting Notes/`

Regras de agrupamento:

Primeiro nível: nome da reunião
Segundo nível: tópico, meta ou marco discutido dentro daquela reunião — use o nome simples, nunca uma chave de issue nua
Terceiro nível: Decisões e Itens de ação como subseções rotuladas sob cada tópico
Se um tópico não tiver decisões, omita a subseção Decisões. Se não tiver itens de ação, omita a subseção Itens de ação.
Se uma reunião tiver apenas um tópico, ainda mostre o nome do tópico — não o colapse
Omita a coluna Projeto dos itens de ação no resumo do chat — ela pertence apenas ao arquivo de notas

Etapa 8 — Oferecer atualização do log de decisões

Esta etapa só é executada se pelo menos uma decisão foi extraída em todas as reuniões resumidas.

Pergunte uma vez, em uma única mensagem:

"Deseja registrar alguma dessas decisões em um log de decisões de um PRD?

Decisões de hoje:

[Nome da Reunião] [Tópico] 1. [Decisão] 2. [Decisão]

Se sim, informe-me qual documento (um arquivo local em Context/Document Hub/ ou uma página na ferramenta de documentos) e quais números de decisão adicionar."

Numere as decisões sequencialmente em todas as reuniões para que o usuário possa referenciá-las por número.

Aguarde a resposta do usuário.

Se não / pular: encerre o skill.
Se sim: prossiga com as etapas abaixo para cada documento que ele especificar.

Para cada documento fornecido:

A. Buscar o documento

Arquivo local → leia-o.
Página na ferramenta de docs → docs.read.

B. Localizar o Log de Decisões

Escaneie por uma seção cujo cabeçalho contenha "Decision Log", "Decisions Log" ou "Decisions" (sem distinção de maiúsculas/minúsculas).

Se uma seção Log de Decisões com uma tabela existir: novas linhas serão anexadas a ela.
Se uma seção Log de Decisões existir mas não tiver tabela: insira a tabela imediatamente abaixo do cabeçalho.
Se nenhuma seção Log de Decisões existir: insira uma nova seção ## Log de Decisões e tabela no final do documento.

C. Construir as linhas

Para cada decisão selecionada pelo usuário, crie uma linha de tabela:

| [YYYY-MM-DD] | [Texto da decisão] | [Status] |

Data: a data da reunião.
Decisão: texto exato do resumo — não parafraseie.
Status: Decidida se explícita e final. Pendente se o texto contiver "TBD", "a confirmar", "pendente", "aguardando" ou foi marcado como não resolvido.

Se a tabela ainda não existir, crie-a com esta linha de cabeçalho primeiro:

| Data | Decisão | Notas/Status |
|------|---------|--------------|

D. Visualizar, depois atualizar

Mostre as linhas a serem adicionadas. Para um arquivo local, escreva-as. Para uma página da ferramenta de docs, aguarde o OK explícito do usuário, então docs.update(ref, "Log de Decisões", rows) — altere apenas aquela seção.

E. Confirmar

"Log de Decisões atualizado em [título do doc] — [N] decisão(ões) adicionada(s)."

Casos extremos

Nenhuma decisão encontrada: Escreva "Nenhuma decisão tomada — reunião de discussão/atualização." Não invente decisões.
Nenhum item de ação encontrado: Escreva "Nenhum item de ação."
Reunião é uma daily ou <5 min: Ainda execute o resumo, mas mantenha o resumo em 1 frase.
Múltiplas notas correspondem ao mesmo evento: Use a mais próxima do horário de início do evento.
Uma fonte não está disponível: Pule-a silenciosamente e vá para a próxima na Fase C.
Página de docs não encontrada (Etapa 8): Relate o erro, peça ao usuário para verificar a URL e ofereça-se para tentar novamente.
Seção Log de Decisões ambígua (Etapa 8): Se vários cabeçalhos puderem corresponder (ex. "Decisões Principais" e "Log de Decisões"), mostre ambos e pergunte em qual anexar.
Decisões duplicadas (Etapa 8): Antes de inserir, escaneie as linhas existentes. Se o mesmo texto de decisão já aparecer, pule-o e anote a omissão.

priscilarwagner/meeting-digest

O que é meeting-digest?

Perguntar na sua IA favorita

Documentação