Uma skill do Claude que transforma um export semanal do seu sistema de gestão de matters em um digest de uma página para o General Counsel: formato do portfólio por fase, o que mudou desde a semana passada, clusters de prazo, candidatos a escalação e desvios de gastos com escritórios externos. A skill substitui a thread de sexta à tarde “cada advogado envia uma atualização de status” que ninguém gosta de escrever ou ler. O bundle do artefato em apps/web/public/artifacts/matter-status-digest-claude/ entrega o SKILL.md mais três templates de referência preenchíveis que a equipe de legal-ops adapta à taxonomia de fases da empresa, ao layout preferido do GC e às regras de escalação da empresa.
Quando usar
Use esta skill quando o GC atualmente passa a manhã de segunda-feira lendo e-mails de status de advogados um por um, ou pedindo ao Gerente de Legal Ops um resumo verbal do portfólio, ou tomando decisões com informações desatualizadas porque a thread de status de sexta não destacou o que importava. Especificamente, isso se encaixa quando a empresa tem entre 15 e 200 matters ativos (pequeno o suficiente para o digest permanecer escaneável, grande o suficiente para o formato do portfólio não ser memorizável), quando o sistema de gestão de matters é o sistema de registro (não uma planilha que deriva dos dados de matter) e quando o GC está disposto a gastar 30 minutos por semana ajustando o layout em references/2-sample-digest-format.md durante o primeiro mês antes de o digest se estabilizar.
Também se encaixa como cadência mensal para boutiques onde 8-12 matters não justificam relatórios semanais, mas o GC ainda quer uma visão mensal estruturada ao lado das conversas em andamento.
Quando NÃO usar
Não use esta skill em um deploy do Claude que não tenha sido aprovado pela sua revisão de privilege-e-fornecedor. Os exports de matter contêm work product de advogados, estratégia de acordo e resumos de investigação — executá-los pelo Claude.ai de consumo viola as expectativas de privilege da maioria das equipes in-house. Use Claude no Bedrock, no Vertex ou em um endpoint enterprise da Anthropic contratado com um BAA e DPA executados, e confirme que o deploy aparece na lista de fornecedores Tier-A da empresa antes de agendar o cron.
Não use esta skill para redigir comunicações voltadas ao cliente, correspondências com a parte contrária ou memorandos para o board. Esses públicos requerem tom diferente, threshold de evidência diferente e aprovação de um advogado. O digest é apenas para o escritório do GC.
Não use esta skill como camada de alertas em tempo real. Um snapshot semanal é a ferramenta errada para registros de TRO, intimações regulatórias, gatilhos de notificação de violação ou qualquer matter onde horas importam. Use o sistema nativo de alertas do sistema de gestão de matters para esses — o digest é para consciência estável do portfólio.
Não faça deploy em portfólios que carecem de disciplina para manter os campos phase, last_activity_date e next_deadline_date atualizados. Um digest derivado de campos desatualizados é pior do que nenhum digest, porque o GC vai agir com base nele. Primeiro corrija a higiene de status do matter; depois entregue o digest.
Setup
- Coloque o bundle de
apps/web/public/artifacts/matter-status-digest-claude/no diretório de skills do Claude Code (ou no local equivalente do projeto para seu deploy enterprise do Claude). O bundle contémSKILL.mde uma pastareferences/. - Adapte
references/1-matter-phase-taxonomy.mdaos nomes de fase que seu sistema de gestão de matters realmente usa. O template entregue usa buckets genéricos de litígio e transacional; a taxonomia da sua empresa será diferente. Mapeie cada valor de fase bruto que os advogados digitam para um bucket canônico — valores não mapeados aparecem em um rodapé “Lacunas de mapeamento” no digest até você adicioná-los. - Edite
references/2-sample-digest-format.mdcom o GC. Este é o Markdown literal que a skill renderiza. Negocie o layout neste arquivo, não no corpo da skill — mantenha as escolhas de engenharia e as escolhas editoriais separáveis. - Edite
references/3-escalation-criteria.mdpara o perfil de risco da sua empresa. Os padrões entregues (90% de utilização do orçamento, spike de 25% nos gastos vs. mês anterior, 14 dias de staleness de status) funcionam para equipes in-house de médio porte; portfólios pesados em transações e regulamentados geralmente querem thresholds diferentes. - Configure o export. Aponte a skill para um caminho de CSV/JSON que um job noturno atualiza, ou conecte diretamente à API do sistema de matters. As colunas obrigatórias estão listadas no
SKILL.mdem “Inputs” —matter_id,matter_name,phase,owner,last_activity_date,next_deadline,next_deadline_date,outside_counsel_firm,mtd_spend,budget,risk_tier. - Agende. Execute a skill em um cron de segunda-feira de manhã (07:00 local) e escreva o digest em
outbox/digest-YYYY-MM-DD.md. Peça ao Gerente de Legal Ops que revise os primeiros oito digests antes de enviá-los ao GC; a janela de revisão manual captura deriva de taxonomia, falsos positivos de escalação e descalibração de tom durante o período de calibração.
O que a skill realmente faz
A skill executa cinco subtarefas em ordem, com escolhas de engenharia que são deliberadas em vez de incidentais.
Ela carrega e valida o export, abortando em colunas ausentes ou datas malformadas. O motivo: um digest derivado de um export meio-quebrado é pior do que nenhum digest, porque o GC vai tratá-lo como verdade.
Ela agrega por fase antes de resumir — usando a taxonomia canônica em references/1-matter-phase-taxonomy.md. O motivo de a agregação preceder a sumarização: a primeira pergunta do GC na segunda-feira é “qual é o formato do portfólio”. Uma lista plana de matters não responde a isso; uma visão em buckets (por ex., “12 em discovery, 4 em mediação, 3 em preparação para julgamento”) responde. A agregação também permite que o digest relate deltas, o que uma lista plana não consegue.
Ela calcula clusters de prazo, destacando semanas em que três ou mais prazos caem na mesma janela de sete dias. Semanas com prazo único são FYI. O sinal de cluster é o que importa para decisões de recursos — o GC precisa saber quando a equipe está sobrecarregada antes da sexta antes, não depois.
Ela aplica regras de escalação de references/3-escalation-criteria.md e destaca no máximo cinco itens “Precisa da atenção do GC”, classificados por risk tier, depois impacto em gastos, depois proximidade do prazo. O cap é deliberado: uma seção de escalação ilimitada deixa de ser uma ferramenta de triagem. Itens classificados em sexto lugar e abaixo caem na seção FYI.
Ela renderiza o digest usando o layout literal em references/2-sample-digest-format.md, depois grava uma linha de log somente-de-metadados: timestamp, contagem de matters, contagem de escalações, segundos de geração, modelo e o SHA-256 do digest. O motivo de somente-metadados: o corpo do digest contém conteúdo privilegiado; o log vai para telemetria operacional que pode ter acesso de auditoria mais amplo do que o digest em si. Registrar o SHA prova a proveniência do digest sem armazenar o texto privilegiado no armazenamento de log.
Custo real
Um digest semanal típico de 30 matters executa aproximadamente 6k-12k tokens de input (export de matter mais três arquivos de referência mais o digest da semana passada) e 1,5k-3k tokens de output (o digest renderizado). Com o preço do Claude Sonnet em um endpoint enterprise, fica em torno de 5 a 10 centavos por execução de digest — chame de menos de 5 dólares por ano por portfólio para o gasto com o modelo. O custo dominante é o tempo de calibração do Gerente de Legal Ops nas semanas um a quatro (aproximadamente duas horas por semana revisando o digest com o GC e editando os arquivos de referência) e o tempo de integração para conectar o export de matter ao ambiente de cron (tipicamente meio dia para um caminho CSV, um a dois dias para uma integração via API).
O tempo economizado é o que importa. Uma thread de status de sexta custa a cada advogado 15-30 minutos por semana para escrever e ao GC aproximadamente 45-60 minutos na segunda-feira para ler e sintetizar. Para um departamento jurídico de 12 advogados, são 6-12 horas-advogado por semana de escrita mais uma hora de leitura do GC, substituídas por uma única leitura de 10 minutos do GC na segunda-feira e um custo de escrita quase zero para os advogados (o sistema de matters permanece como fonte da verdade). O ROI é a manhã de segunda-feira do GC de volta, não a conta do modelo.
Métrica de sucesso
Acompanhe três números a partir da oitava semana — quando a janela de calibração tiver fechado.
Tempo do GC na segunda-feira de manhã em revisão de portfólio, antes e depois do deploy. A meta é menos de 15 minutos lendo o digest mais follow-ups direcionados, substituindo o padrão ilimitado de “perguntando por aí”.
Precisão da escalação: dos itens que o digest destaca em “Precisa da atenção do GC esta semana”, qual porcentagem realmente acionou uma ação do GC. Meta acima de 70%. Abaixo de 50% significa que as regras de escalação estão muito sensíveis; aperte os thresholds em references/3-escalation-criteria.md. Acima de 90% significa que as regras podem estar muito apertadas e itens importantes podem estar caindo silenciosamente no FYI; amplie os thresholds.
Incidentes de status desatualizado por trimestre: com que frequência um matter que o digest relatou como “ativo e no prazo” acabou sendo estagnado ou problemático. A meta é zero, com o entendimento de que o rodapé de staleness (matters cujo last_activity_date está há mais de 14 dias) é a rede de segurança que captura os casos onde a disciplina escorrega.
vs alternativas
Comparado aos dashboards de gestão de matters do Ironclad (ou o dashboard nativo equivalente no Brightflag, SimpleLegal, Onit ou seu sistema de registro de matters): dashboards nativos mostram os dados mas não os sintetizam. O GC ainda tem que olhar para seis tiles e inferir a história. O digest conta a história em inglês simples e destaca as três a cinco coisas que precisam de uma decisão esta semana. Use o dashboard para drill-down ad-hoc; use o digest para a camada de síntese semanal que o dashboard não fornece.
Comparado a relatórios de status escritos manualmente pelo GC ou pelo Gerente de Legal Ops: um autor humano produz uma narrativa melhor nos matters que lembra e uma narrativa pior nos matters que esqueceu. A skill é exaustiva em todo o export — não consegue esquecer um matter que não foi tocado em duas semanas, porque a regra de staleness o destaca. O trade-off é voz: um relatório humano tem o enquadramento do GC incorporado. Mitigue editando references/2-sample-digest-format.md para corresponder ao fraseado preferido do GC e mantendo o Gerente de Legal Ops no loop como editor durante a primeira janela de calibração.
Comparado a um relatório de ferramenta de BI (Tableau, Looker, Power BI sobre o sistema de matters): ferramentas de BI respondem a perguntas predefinidas em um agendamento e produzem gráficos. Elas não produzem um briefing em Markdown, não lidam com a camada não estruturada de “o que mudou e por que isso importa” e não se adaptam às regras de escalação da empresa sem trabalho significativo de criação. Use BI para análise de tendências ao longo dos trimestres; use a skill para o digest operacional semanal.
Pontos de atenção
Tratamento de conteúdo privilegiado. Execute a skill apenas em um deploy do Claude aprovado pela sua revisão de privilege. Proteção: a skill se recusa a rodar se a variável de ambiente OOLIGO_DIGEST_DEPLOYMENT_TIER não estiver definida como tier-a. Defina-a explicitamente no ambiente de cron depois que a revisão de privilege aprovar; nunca a ative por padrão.
Status de matter desatualizado produzindo falsa confiança. Proteção: qualquer matter cujo last_activity_date está há mais de 14 dias aparece em uma seção dedicada “Status desatualizado — verifique” no rodapé, independentemente de outras regras de escalação terem disparado. O GC vê o staleness explicitamente em vez de agir com base em sinal desatualizado.
Risco de miss de prazo oculto pela agregação de fase. Proteção: qualquer prazo dentro de cinco dias úteis aparece na seção de cluster de prazo independentemente da fase ou do risk tier — a seção de cluster é a rede de segurança que captura o que as regras de escalação perdem.
Falsos positivos de escalação sobrecarregando o GC com ruído. Proteção: a seção “Precisa da atenção do GC” tem um hard cap de cinco itens. Se mais de cinco matters corresponderem, a skill classifica por risk tier, depois impacto em gastos, depois proximidade do prazo; o restante cai no FYI. Se você se encontrar querendo remover o cap, aperte as regras em references/3-escalation-criteria.md.
Calibração de tom. GCs diferentes leem digests diferentes. Proteção: itere nos arquivos de referência semanalmente durante as primeiras quatro semanas, com o GC na sala. Trate o formato como um artefato vivo — o corpo da skill não deve precisar mudar depois que as referências se estabilizarem.
Envio automático antes da revisão. Proteção: a skill escreve em outbox/digest-YYYY-MM-DD.md; enviar o digest ao GC é uma etapa separada, acionada manualmente, até a janela de calibração fechar (mínimo oito digests). Depois disso, automatize o envio apenas se a métrica de precisão acima de 70% se mantiver por três semanas consecutivas.
Stack
Este workflow se combina naturalmente com sistemas de gestão de matters como fonte da verdade, com stacks de automação de legal-ops para a camada de cron e entrega, e com workflows downstream que operam no mesmo export — por exemplo revisão de faturas de escritórios externos, automações de rastreamento de prazo ou análise trimestral de portfólio. Construa o digest depois que o sistema de matters estiver limpo, não antes.