decision-logger
por alirezarezvanidecision-logger é uma skill de suporte a decisões para decisões aprovadas pelo conselho. Ela separa transcrições brutas de um índice de decisões Layer 2, acompanha responsáveis, prazos, opções rejeitadas e acompanhamentos, e inclui um rastreador em Python para resumos, itens em atraso, conflitos, filtros por responsável e busca.
Esta skill recebe 80/100, o que a torna uma boa candidata para usuários de diretório que precisam de memória estruturada de decisões de conselho e revisão de itens de ação. Ela oferece mais capacidade de ação para agentes do que um prompt genérico, com gatilhos definidos, um formato durável para decisões aprovadas e um script de relatórios, embora a adoção seja mais simples dentro do fluxo de trabalho C-Level Advisor ao redor.
- Condições de acionamento claras na descrição: após reuniões de conselho, ao revisar decisões aprovadas ou ao verificar itens de ação em atraso.
- Há substância operacional: SKILL.md define um modelo de memória de decisões em duas camadas, bruta/aprovada, além de comandos, palavras-chave e casos de uso.
- Inclui suporte executável via scripts/decision_tracker.py e um modelo de registro de decisão com regras de preenchimento para entradas consistentes na Layer 2.
- Não há comando de instalação nem README no caminho da skill, então os usuários precisam inferir a instalação a partir da estrutura mais ampla do repositório.
- O fluxo de trabalho parece feito sob medida para o ecossistema C-Level Advisor/reuniões de conselho e para comandos slash como /cs:decisions e /cs:review, o que pode limitar a utilidade em uso independente.
Visão geral da skill decision-logger
O que a decision-logger faz
decision-logger é uma skill de Decision Support para transformar resultados de reuniões de conselho em uma memória de decisões durável, organizada em duas camadas. A Camada 1 preserva o contexto bruto da reunião; a Camada 2 armazena apenas decisões aprovadas, responsáveis, prazos, opções rejeitadas e itens de acompanhamento. A utilidade é bem prática: reuniões futuras assistidas por IA devem se apoiar em decisões confirmadas, não em debates em aberto nem em consensos inventados.
Melhor uso em fluxos de conselho e liderança executiva
A skill decision-logger funciona melhor para founders, chiefs of staff, operadores de conselho e agentes de IA que dão suporte a reuniões executivas recorrentes. Ela se encaixa em fluxos em que as decisões precisam atravessar várias reuniões, ser pesquisáveis depois e permanecer separadas das anotações de discussão. É especialmente útil quando um processo no estilo board-meeting termina com aprovação do founder e depois precisa virar um registro limpo e auditável.
Principal diferencial: só memória aprovada
A escolha de design mais forte é a separação entre transcrições brutas e o índice aprovado da Camada 2. Revisões futuras leem a camada aprovada, não todos os argumentos levantados na reunião. Isso ajuda a evitar que ideias antigas já rejeitadas reapareçam como se ainda fossem viáveis. O template também inclui DO_NOT_RESURFACE, campos de substituição, datas de revisão e acompanhamento por responsável, o que o torna mais operacional do que um prompt genérico para “resumir atas de reunião”.
O que verificar antes de instalar
Antes de adotar decision-logger, confirme se sua equipe está confortável em manter um índice local de decisões em ~/.claude/decisions/approved/decisions.md. O helper em Python incluído lê esse arquivo e consegue reportar itens atrasados, conflitos, ações por responsável e buscas por palavra-chave. Se o seu processo ainda não separa decisões aprovadas de notas de discussão, talvez seja preciso ajustar o fluxo de reunião primeiro.
Como usar a skill decision-logger
Instalação da decision-logger e arquivos para inspecionar primeiro
Instale a skill a partir do caminho do repositório:
npx skills add alirezarezvani/claude-skills --skill decision-logger
Depois da instalação, leia estes arquivos nesta ordem:
SKILL.md— explica o modelo de memória em duas camadas, a intenção dos slash commands e os locais de armazenamento esperados.templates/decision-entry.md— mostra o formato exato de uma entrada da Camada 2.scripts/decision_tracker.py— oferece comandos de relatório para resumo, itens atrasados, conflitos, filtros por responsável e busca.
O script usa apenas a biblioteca padrão do Python, então não há configuração de dependências além de ter Python disponível.
Entradas que a skill precisa para funcionar bem
Para usar bem a decision-logger, dê ao agente mais do que um resumo superficial da reunião. Informe o item de pauta, a decisão final aprovada, o responsável accountable, a data-limite, a data de revisão, a justificativa, as alternativas rejeitadas e qualquer override do founder. O template espera uma decisão por entrada, então separe resultados agrupados em registros distintos.
Entrada fraca: “Registre que discutimos pricing e decidimos testar alguma coisa.”
Entrada melhor: “Registre a decisão aprovada na reunião de conselho de 2026-03-05: mudar de preço flat para um piloto de três tiers para novos clientes. Owner: CRO. Deadline: 2026-04-15. Review: 2026-05-01. Rationale: melhora o caminho de expansão enquanto limita o risco de migração. Rejected: migração imediata de todos os clientes existentes porque a carga de suporte é alta demais. Raw transcript path: ~/.claude/decisions/raw/2026-03-05-pricing.md.”
Fluxo prático depois de uma reunião
Use decision-logger depois da aprovação, não durante um debate em aberto. Um fluxo confiável é:
- Salvar ou referenciar a transcrição bruta na Camada 1.
- Pedir ao agente que extraia apenas os resultados aprovados pelo founder.
- Criar uma entrada de Camada 2 usando
templates/decision-entry.md. - Marcar opções rejeitadas com motivos e
DO_NOT_RESURFACE. - Rodar o script de tracking para verificar resumos, ações atrasadas ou conflitos.
Comandos úteis do repositório incluem:
python scripts/decision_tracker.py --demopython scripts/decision_tracker.py --summarypython scripts/decision_tracker.py --overduepython scripts/decision_tracker.py --conflictspython scripts/decision_tracker.py --owner "CTO"python scripts/decision_tracker.py --search "pricing"python scripts/decision_tracker.py --due-within 7
Padrão de prompt para entradas melhores
Uma boa chamada deve pedir uma entrada de decisão, não um resumo narrativo. Por exemplo:
“Use the decision-logger skill to create a Layer 2 approved decision entry. Include one clear decision statement, one accountable owner, deadline, review date, rationale, rejected proposals with DO_NOT_RESURFACE, action items, supersedes fields if applicable, and the raw transcript path. Do not include unapproved discussion points.”
Esse enquadramento reduz ambiguidades e mantém a Camada 2 limpa o suficiente para Decision Support posterior.
FAQ da skill decision-logger
A decision-logger serve apenas para reuniões de conselho?
Ela foi desenhada em torno da memória de decisões de conselho e C-level, mas também pode funcionar para comitês de investimento, reuniões de liderança, conselhos de produto ou revisões de governança. O requisito principal é que as decisões sejam formalmente aprovadas e precisem de acompanhamento. Ela é menos útil para sessões de brainstorming em que nenhuma decisão final é tomada.
Por que isso é melhor do que pedir para a IA resumir atas?
Um resumo comum muitas vezes mistura discussão, recomendações, objeções e decisões. decision-logger força uma estrutura: decisão aprovada, responsável, prazo, justificativa, opções rejeitadas, itens de ação, substituição e link para a transcrição bruta. É essa estrutura que permite revisão posterior, checagem de atrasos e detecção de conflitos.
A skill decision-logger exige um banco de dados?
Não. As evidências do repositório apontam para armazenamento baseado em markdown e um script em Python que usa a biblioteca padrão. O principal índice da Camada 2 é esperado em ~/.claude/decisions/approved/decisions.md, com suporte legado para outro caminho de arquivo via --file. Isso a torna leve, mas equipes que precisam de permissões multiusuário, dashboards ou logs de auditoria podem precisar de ferramentas adicionais.
Quando eu não devo usar decision-logger?
Não use como depósito para toda e qualquer nota de reunião. Ela também não é uma boa opção se as decisões mudam constantemente sem responsáveis ou datas, ou se sua organização não consegue identificar o que foi realmente aprovado. Nesses casos, uma skill de notas de reunião ou uma integração com gestão de projetos pode ser mais adequada antes de adicionar memória de decisões.
Como melhorar a skill decision-logger
Melhore os resultados da decision-logger com aprovações mais claras
O fator de qualidade mais importante é a clareza da aprovação. Antes de registrar, verifique: o que exatamente foi decidido? Quem é responsável? Até quando? O que foi explicitamente rejeitado? O que agentes futuros devem evitar trazer de volta? Se qualquer um desses pontos estiver faltando, faça uma pergunta de follow-up em vez de criar uma entrada vaga.
Modos comuns de falha a evitar
Fique atento a entradas que colocam várias decisões em um único parágrafo, responsabilidade compartilhada sem uma pessoa accountable, prazos como “em breve”, justificativas que apenas repetem a decisão ou ideias rejeitadas sem motivo. Isso enfraquece buscas e revisões futuras. Vale tratar as regras de campos do template como restrições, não como sugestões.
Itere depois da primeira entrada gerada
Depois que o agente rascunhar uma entrada, revise como se fosse um registro operacional. Aperte a decisão em uma única frase, converta nomes ou papéis em um único responsável, substitua datas relativas por YYYY-MM-DD e garanta que os itens de ação sejam verificáveis. Em seguida, rode --summary, --overdue ou --conflicts para confirmar que a entrada funciona bem no tracker.
Adapte a skill ao seu modelo operacional
Equipes podem melhorar decision-logger adicionando tags consistentes de pauta, rótulos de comitê do conselho, nível de risco, tipo de decisão ou links para tickets de projeto. Mantenha as extensões compatíveis com o índice em markdown e evite adicionar campos que ninguém vai manter. O objetivo não é documentação mais rica por si só; é Decision Support mais limpo para a próxima reunião.