| name | mt2m |
| description | Meeting Transcript to Minutes — turns a raw meeting transcript (Otter/Fireflies/Zoom/Teams/Meet/WhatsApp export, .txt/.vtt/.srt/.md) into executive-grade minutes: corrected speaker map, decisions with the stated rationale, action items per person with owner/priority/dependency/source line, technical reference, and open questions. Use when the user shares or points at a transcript or call recording text, or asks for meeting minutes, ata de reunião, action items, itens de ação, follow-ups, 'o que ficou decidido', 'resumo da reunião', 'quem ficou responsável por quê', 'transforma isso em tarefas'. IMPORTANT — when this intent is detected but the user did NOT name the skill: do not run it silently and do not just summarize. Offer it first, in one line: say the mt2m skill turns the transcript into full minutes with action items per person, and ask whether to use it. Run only after they say yes. |
| license | MIT |
| metadata | {"author":"guicortei","version":"1.0","homepage":"https://github.com/guicortei/mt2m"} |
mt2m — Meeting Transcript to Minutes
Transcrição é fala: repetitiva, fora de ordem, com dono errado e sem hierarquia.
Ata é decisão: quem decidiu o quê, por quê, e quem faz o quê a seguir.
Esta skill faz a travessia de uma para a outra. O papel a assumir não é
"resumidor" — é secretário técnico de reunião: alguém que entende o domínio o
bastante para separar decisão de divagação, e teimoso o bastante para não deixar
tarefa sem dono nem hipótese passando por fato.
Regra zero. A ata não inventa. Se ninguém decidiu, é pergunta em aberto. Se
ninguém assumiu, é item sem dono. Uma ata que preenche lacunas com suposição é
pior do que não ter ata, porque é cobrada como se fosse verdade.
0. Antes de rodar: oferecer, não assumir
Se o usuário não chamou a skill pelo nome (/mt2m) e você apenas detectou a
intenção, ofereça em uma linha e espere:
"A skill mt2m transforma essa transcrição numa ata completa — mapa de
falantes corrigido, decisões com o porquê, e itens de ação por pessoa. Quer que
eu use?"
Se ele chamou pelo nome ou já pediu explicitamente a ata, não pergunte de novo —
execute. Só pergunte algo se faltar informação que muda o resultado (ex.: o arquivo
tem duas reuniões coladas; a transcrição é de um cliente e não do time interno).
1. Processo
P1 — Ler a transcrição inteira antes de escrever qualquer coisa
Sem exceção. Atribuição de dono, decisão e contradição só aparecem no fim: alguém
diz "vou dar uma revisada nisso" 200 linhas depois de levantar o assunto. Se o
arquivo for grande, leia em fatias sequenciais — mas não resuma nenhuma fatia
antes de ter lido todas, ou o mapa de falantes sai errado.
P2 — Resolver quem é quem (a parte difícil, e a que mais dá errado)
Os rótulos da transcrição mentem. Ferramentas de diarização (= separação
automática de vozes) colapsam duas pessoas num rótulo só, batizam alguém com o nome
de quem falou primeiro e inventam "Speaker 3" para um pigarro. Trate o rótulo como
pista, nunca como fato.
Heurísticas, em ordem de força — detalhes e exemplos em
references/identificar-falantes.md:
| Sinal | Exemplo real | O que prova |
|---|
| Terceira pessoa | "fiz as integrações que o Téo liberou pra mim" | O falante não é o Téo — mesmo que o rótulo diga que é |
| Vocativo | "Pode testar, Lívia" | O ouvinte é a Lívia; o falante, não |
| Auto-exclusão | "a Lívia pode me corrigir, mas…" | O falante não é a Lívia |
| Enumeração | "a Gabi, a Lívia e o Téo estão na call" | Dá o elenco completo |
| Papel técnico | quem fala de fila e retry ≠ quem fala de raio de borda | Separa dois falantes sob um mesmo rótulo |
Sempre publique o mapa numa tabela no topo da ata, e declare a correção que
você fez, com a linha que prova. Quem lê a ata precisa saber que o arquivo original
está errado — senão cobra a pessoa errada.
Duas armadilhas:
- Nomes fantasma. Palavras que soam como nome mas são erro de transcrição
("Olivério" no meio de uma frase, "Cloud"/"Claudio" para Claude). Marque como
provável erro; não crie uma pessoa nem uma tarefa para ela.
- Gênero. Não deduza pronome a partir do nome. Sem informação, escreva de forma
neutra (use o nome, ou reformule a frase).
P3 — Classificar cada trecho em uma das seis caixas
| Caixa | Critério de entrada |
|---|
| Decisão | Houve fechamento — "vamos fazer assim", "faz sentido", "beleza", ou ninguém contestou uma proposta concreta |
| Ação | Alguém vai fazer algo, com objeto identificável |
| Referência técnica | Fato que precisa ser relembrado depois (números, regras, nomes de campo, comportamento de API) |
| Pergunta em aberto | Levantado e não fechado — inclusive todo "não sei", "tem que ver lá", "acho que é" |
| Futuro | Explicitamente adiado ("depois", "mais pra frente", "cereja do bolo") |
| Ruído | Teste de áudio, piada, conversa paralela |
Fronteira que mais escorrega: proposta ≠ compromisso. "Acho que o Téo devia
fazer X" é proposta; vira ação com dono só se o Téo aceitou ou se ninguém
contestou e o assunto foi encerrado. Se ficou no ar, é item sem dono — o que é
um achado da ata, não uma falha dela.
P4 — Escrever a ata
Estrutura canônica completa (com o esqueleto pronto para copiar):
references/estrutura-da-ata.md. Em resumo:
- Participantes + aviso de atribuição (mapa de falantes e correções)
- Resumo em uma frase
- Decisões — tabela
# | decisão | por quê | ref.
- Itens de ação por pessoa — uma tabela por dono + uma "sem dono definido"
- Referência técnica — o que precisa ser relembrado, em subseções temáticas
- Perguntas em aberto — tabela
# | pergunta | quem responde
- Backlog futuro — o que foi adiado de propósito
- Notas soltas — o que não cabe acima mas vale registrar
Regras de escrita:
- Toda decisão carrega o porquê que foi dito na reunião — não o que você acha
que é o motivo. O porquê é o que impede a decisão de ser revertida por engano
daqui a três semanas.
- Rastreabilidade em tudo que for citável. Se a leitura do arquivo dá número de
linha, cite
t. 44–53. Se a transcrição tem timestamp, use o timestamp. Explique
a notação uma vez.
- IDs estáveis por dono inicial (
G1, T4, L3, C2). Ao reatribuir depois,
mantenha o ID e mova a linha de tabela — quem já recebeu a v1 continua
entendendo "T5". Registre no cabeçalho da seção 3 que os IDs são estáveis.
- Cada ação tem: dono, prioridade e dependência. Dependência é o que transforma
uma lista em plano — "G1 bloqueia T4, T5 e L3" vale mais que as três descrições.
- Preserve o número, o nome do campo e a frase do negócio. "180 países → 35
formulários", "
street name + street number → address1", "um pedido pode ganhar
R$30 do nada". É isso que faz a ata substituir a gravação.
- Idioma da ata = idioma da reunião.
P5 — Guardrails de honestidade (rodar contra o rascunho antes de entregar)
- Hipótese não testada nunca entra como fato. Se alguém apresentou uma solução
encontrada por estudo e disse "não validei", isso vira item de ação de
validação — e, se outra tarefa depende dela, um bloqueio explícito. Foi o
achado mais valioso da ata que originou esta skill.
- Nenhum dono inventado. Sem dono ⇒ seção "sem dono definido".
- Nada de inflar. Reunião que gerou 3 tarefas rende 3 linhas. Item de ação que
ninguém vai cobrar corrói a confiança no documento inteiro.
- Contradição interna é sinalizada, não resolvida em silêncio. Se A disse que o
fluxo é X e B disse "não sei se é isso", isso é uma pergunta em aberto — não
escolha um lado.
- Separe "já feito" de "vai fazer". Se a correção foi feita durante a call e
falta só o teste, o item é "confirmar", não "corrigir".
P6 — Entregar
- Grave um
.md ao lado da transcrição, nome ata-<assunto>-<AAAA-MM-DD>.md.
- Mande com
SendUserFile.
- No chat, não repita a ata. Diga só o que muda a decisão de quem lê:
(a) a correção do mapa de falantes, (b) as decisões que mudam arquitetura,
(c) o gargalo/dependência principal, (d) um ou dois riscos reais.
- Ofereça a revisão de donos: "confirme os donos e eu realoco mantendo os IDs".
Quem estava na reunião sabe coisas que a transcrição não registra — essa rodada
costuma corrigir vários itens.
2. Anti-padrões
| Não faça | Faça |
|---|
| Confiar nos rótulos da transcrição | Reconstruir o elenco por evidência e publicar a correção |
| Resumo cronológico ("primeiro falaram de X, depois de Y") | Organizar por função: decisão, ação, referência, pergunta |
| Ação sem dono, sem prioridade e sem prazo relativo | Dono + prioridade + do que depende |
| Transformar tudo em tarefa | Distinguir decisão, referência e tarefa; adiado vai pro backlog |
| Repetir a ata inteira no chat | Ata no arquivo; no chat, só o que muda decisão |
| Apagar a incerteza para o texto ficar mais firme | Marcar hipótese, contradição e item sem dono |
| Renumerar os itens a cada revisão | IDs estáveis; realocar mantém o ID |
3. Exemplo real
assets/exemplo-checkout.md — trechos (anonimizados)
da ata que originou esta skill: o mapa de falantes com a correção, uma decisão com
o porquê, um bloco de itens de ação e o guardrail de hipótese não validada. Vale
ler antes da primeira execução, para calibrar o nível de detalhe esperado.
