wrap-up

Wrap-up (Encerramento de Sessão)

O usuário está prestes a arquivar este chat. Tudo o que vive apenas na conversa está prestes a ser perdido: o que foi decidido, o que mudou no disco, o que a próxima sessão deve retomar. Várias skills instaladas salvam cada uma uma fatia disso. O trabalho desta skill é encontrá-las, executá-las na ordem correta e parar após uma confirmação.

O conjunto de skills não é fixo: plug-ins vão e vêm, o usuário escreve novas skills. Nunca codifique nomes; descubra-os a cada vez a partir do que está instalado, então compare com as categorias em references/close-out-catalogue.md. O catálogo diz o que cada categoria é, em que ordem e a que custo; este arquivo diz como cada uma é executada em cada ambiente. Se os dois parecerem discordar, siga o catálogo para o quê e a ordem, este arquivo para o como, e nomeie a discordância no relatório para que o usuário possa corrigir o catálogo.

0. Saiba onde você está e quão antiga é a sessão

A maior parte do que se segue muda com o ambiente e com a idade da sessão, então estabeleça ambos primeiro e diga-os em uma linha no topo do plano. Três ambientes:

• Claude Code na máquina do usuário. Um shell nessa máquina, skills em ~/.claude/skills, hooks que executam (incluindo, onde um estiver configurado, um hook SessionEnd que registra cada sessão; o mapa local ou settings.json diz se existe um), repositórios e vault no disco. Tudo abaixo se aplica como escrito.
• claude.ai ou uma sessão em nuvem com um shell de dispositivo. O chat executa em um contêiner Linux, mas uma ferramenta de shell para o computador do usuário está listada, então comandos executam lá, dentro das pastas que o usuário conectou. O vault e qualquer script armazenado em uma pasta conectada são acessíveis. Os próprios arquivos desta skill (o catálogo, scripts/) vivem no contêiner, não nessa máquina. Hooks não executam. A memória passa pelas ferramentas de memória, e uma passada em segundo plano arquiva fatos duráveis após cada turno.
• claude.ai ou uma sessão em nuvem sem esse shell. Arquivos no computador do usuário são acessíveis apenas por meio das ferramentas que preparam um arquivo para o contêiner e o confirmam de volta, e apenas enquanto o aplicativo de desktop estiver vinculado. Caso contrário, nada em seu disco é acessível. Hooks e memória como acima.

Sinais: a plataforma e o diretório de trabalho, quais ferramentas estão listadas (shell de dispositivo, ferramentas de arquivo do dispositivo, ferramentas de memória), o que o prompt do sistema diz sobre memória e sobre um Projeto. Se você não puder dizer, diga e pergunte, porque um palpite errado escreve no lugar errado.

Então a idade. Um fechamento geralmente é solicitado no final do trabalho, mas um chat pode ficar aberto por dias e ser fechado mais tarde, depois que outras sessões trabalharam nos mesmos arquivos, notas e skills. A sessão está obsoleta quando qualquer coisa que ela tocou mudou após seu último trabalho real: compare a data desse trabalho (os carimbos de data/hora da conversa ou notas datadas) com os horários de modificação dos arquivos e entradas de armazenamento que tocou, um commit posterior, uma entrada de armazenamento datada posteriormente, ou uma skill que usou e que a listagem agora mostra renomeada ou não mostra mais. Uma única mudança é suficiente. A idade sozinha é uma razão para olhar, não um veredito: um chat de uma semana que ninguém construiu não está obsoleto. Diga na linha superior com a lacuna ("última atividade em 4 de Novembro; arquivos que tocou mudaram desde então").

Em uma sessão obsoleta, o disco e os armazenamentos são mais novos que a conversa, então eles vencem:

• Antes de planejar qualquer gravação, leia a versão atual de cada arquivo e entrada de armazenamento que a etapa tocaria, e planeje contra o que está lá agora, não contra o que a conversa lembra.
• Uma decisão que a sessão tomou e que uma sessão posterior já registrou está feita: aponte para ela, não a escreva novamente. Uma que uma sessão posterior mudou ou reverteu não é para este fechamento restaurar: nomeie-a como substituída e descarte-a. Quando o registro posterior cobre apenas parte da decisão, ou não está claro quanto cobre, descarte apenas a parte que cobre claramente e nomeie o restante como possivelmente substituído; para que lado vai depende da única pergunta.
• Caminhos, nomes e skills que a sessão usou podem ter sido movidos ou renomeados. Resolva cada um novamente antes de usá-lo. Uma nova forma conta apenas quando algo escrito desde então a declare (memória, uma nota, um commit, a própria descrição de uma skill dizendo como era chamada antes); use essa forma e diga. Quando nada a declarar, nomeie a antiga como não mais resolvendo em vez de adivinhar, e não a escreva em um armazenamento como se fosse atual.
• O que resta para propor é o que a sessão decidiu e nada desde então registrou, mudou ou contradisse. Isso pode ser muito pouco; um fechamento obsoleto que escreve uma linha, ou nada, é um fechamento correto.

O mesmo chat pode já conter um fechamento anterior, executado antes de o usuário continuar trabalhando. Então este fechamento constrói sobre aquele em vez de começar do zero: pegue seu plano e marque cada etapa como feita (seu relatório diz isso e o disco concorda), substituída ou ainda pendente, e verifique apenas o que aconteceu depois dele. Um plano que o fechamento anterior propôs e o usuário nunca respondeu não foi aprovado: carregue suas etapas pendentes para este plano, verificadas novamente contra o disco e as regras acima, em vez de executá-las ou descartá-las silenciosamente, e diga na linha superior que existe um fechamento anterior.

1. Descoberta

Antes de descobrir qualquer coisa, verifique as instruções permanentes do ambiente (no Claude Code os arquivos CLAUDE.md e a memória automática, que conta como permanente aqui; no claude.ai as instruções do Projeto, as preferências e memória do usuário, e uma seção Mapa local para esta instalação que uma cópia empacotada deste SKILL.md pode carregar) em busca de um mapa local desta rotina: uma seção curta nomeando qual skill instalada cobre cada categoria, os armazenamentos, o que está aposentado, custos medidos. Quando um existe, ele substitui a descoberta; verifique se cada skill que nomeia ainda está instalada (e um comando nomeado ou caminho com uma consulta barata somente leitura onde um estiver à mão), e trate o que ele aposenta como resolvido. Um mapa parcial (armazenamentos ou aposentadorias nomeados, mas nenhuma skill por categoria) informa a descoberta em vez de substituí-la: honre o que ele nomeia, descubra o resto, e a oferta da seção 5 se torna completar essa seção, não adicionar uma segunda. Quando nenhum existe, descubra como segue e ofereça no final para escrever um (seção 5). No Claude Code leia os arquivos CLAUDE.md do disco, não apenas do contexto: uma cópia injetada pode ser anterior a uma edição, e uma obsoleta leva você à descoberta completa e a uma oferta para escrever um segundo mapa sobre um que já existe.

A lista de candidatos é a listagem de skills disponíveis já no contexto (nome + descrição). Ela cobre skills locais, skills de plugin e gstack igualmente; não há fonte melhor. Duas peculiaridades da listagem: uma skill mostrada com e sem um prefixo de plugin, mesma descrição, é uma skill, então chame-a pelo nome simples no plano, mas invoque-a com o nome exato que a listagem mostra; e a listagem pode crescer durante a execução quando um comando toca uma pasta carregando suas próprias skills, cujas chegadas tardias mudam o plano apenas se corresponderem a uma categoria.

Leia references/close-out-catalogue.md. Para cada categoria que define, escolha a(s) skill(s) instalada(s) cuja descrição corresponda ao seu propósito. Membros conhecidos são dicas, não a resposta: uma skill instalada não listada lá se qualifica se sua descrição se encaixa, uma listada que não está mais instalada é ignorada. Observe os quase-acertos que o catálogo sinaliza. Quando a listagem mostra uma skill apenas pelo nome (ambos os ambientes fazem isso para algumas), corresponda no nome e nas palavras "Reconhecer por" do catálogo, e marque-a como "(sem descrição)" no plano para que o usuário saiba que a correspondência é mais fraca.

Uma categoria sem skill instalada vai no plano como "pular, não instalada"; não improvise um substituto, a menos que o ambiente tenha seu próprio mecanismo para esse trabalho (seção 2). Algumas categorias não são skills (no Claude Code, a memória automática é escrita com a ferramenta Write e uma atualização de gráfico é um comando); elas são etapas no mesmo plano, apenas onde o ambiente as tem.

Então verifique o que realmente vale a pena fazer nesta sessão:

• Gráficos. No Claude Code na máquina, execute python scripts/find_graphs.py <raiz-do-workspace> (caminho relativo ao diretório desta skill; qualquer Python funciona). A raiz do workspace é a pasta de trabalho da sessão, ou a pasta mais ampla que as instruções do projeto descrevem como contendo cada repositório, quando o fazem. O script lista cada graphify-out/ cuja pasta de projeto está no máximo cinco níveis abaixo dela, e se arquivos mudaram desde seu manifesto: uma linha por gráfico, ATUAL, OBSOLETO com contagens de alterados e excluídos, ou DESCONHECIDO (sem manifesto, ou graphify não importável), ou uma única linha dizendo que nenhum foi encontrado. As contagens não dizem se as alterações são notas, ~85k cada para reextrair, ou código, que não precisa de LLM; diga qual a partir do que a sessão tocou. ATUAL não é uma etapa, mesmo que você se lembre de editar um arquivo com gráfico: o manifesto sabe se o gráfico foi reconstruído depois disso. Sem Python na máquina, os gráficos não são verificados; diga. Em qualquer outro lugar onde o script não pode ver o workspace (executa no contêiner, os gráficos estão no disco do usuário): relate cada gráfico como não verificado, o que não é "nada a atualizar".
• A sessão. Decisões, correções, novos fatos sobre o usuário ou o projeto, arquivos criados ou movidos? Isso decide se as etapas de memória e aprendizados têm algo a escrever. Uma sessão que foi puramente leitura pode não precisar de nada além de um salvamento de contexto.
• Git. git status em cada repositório que a sessão tocou. Trabalho não confirmado não é responsabilidade desta skill confirmar; vai na linha "permanece com o usuário" do plano. Quando a história da sessão e o git discordam (arquivos alterados na sessão, árvore limpa), nomeie a discrepância em vez de reconciliá-la silenciosamente.
• Gravações reivindicadas. Liste o que a sessão disse que escreveu, criou, instalou ou alterou (arquivos, notas, commits, configurações, pacotes instalados), e verifique cada uma com uma olhada somente leitura: existe, e seu conteúdo é aquele que a sessão escreveu (uma linha distinta ou o tamanho, não apenas a existência, já que uma sobrescrita falhada deixa o arquivo antigo no lugar). Uma ferramenta que relatou sucesso não é prova. Quando o conteúdo difere, o horário de modificação decide: alterado após o último trabalho da sessão significa que uma sessão posterior o alterou (seção 0, obsoleto); não alterado após significa que a gravação nunca foi efetivada. Um arquivo que deveria existir e não existe nunca foi efetivado também, a menos que um commit ou nota posterior registre sua remoção. Uma gravação que nunca foi efetivada, ou trabalho que a sessão deixou pela metade (instalado em alguns lugares e não em outros, uma etapa que prometeu e não executou), vai na linha "deixado quebrado" do plano (seção 3). Uma sessão que reivindicou nenhuma gravação pula isso.
• Trabalho em andamento que outra skill espalha por várias sessões (catálogo, "Trabalho em andamento"). Não é uma etapa própria: vai na nota de transferência e no salvamento de contexto.
• Onde o estado já vive. As instruções do projeto podem nomear os armazenamentos que o usuário trata como a fonte: um vault, um banco de dados de projeto, um campo que contém a próxima ação. Leia as instruções antes de planejar qualquer gravação (os próprios armazenamentos são lidos pelas etapas que os escrevem); elas decidem como as categorias 3 e 5 são executadas. Quando dois armazenamentos nomeados poderiam conter o mesmo fato (uma nota de decisões e uma nota de projeto, por exemplo), o plano nomeia qual deles a gravação visa; se as instruções não resolverem, resolva na única pergunta, nunca silenciosamente.

2. O que muda com o ambiente

No Claude Code, execute cada categoria conforme o catálogo descreve; do que se segue, apenas as regras que dizem isso vinculam lá também. Nos outros dois casos da seção 0, ajuste assim.

1 Memória: verifique, não escreva. A passada em segundo plano já arquiva fatos duráveis após cada turno. Leia o(s) arquivo(s) de memória que eles provavelmente usaram (a listagem mostra os caminhos) e diga no plano se as decisões desta sessão estão lá. A passada é executada após cada turno, então o que foi decidido no próprio turno de fechamento ainda não está lá e será arquivado depois dele; isso é normal, não uma lacuna. A plataforma só permite uma gravação de memória mediante solicitação explícita do usuário, então se algo que eles disseram estiver faltando, nomeie no plano e deixe-os dizer "salve isso"; essa frase é a solicitação. Dentro de um Projeto, as gravações vão na própria subárvore do Projeto, na forma que as instruções de memória exigem.

1b Nota de transferência, 2 Aprendizados: pule quando não instalado. Não há substituto; um documento de Projeto, uma nova nota ou um resumo de chat não se tornam um (veja a regra de um lugar).

3 Sincronização de vault: depende do alcance. Com um shell de dispositivo e a pasta do vault conectada, execute a skill de sincronização se estiver instalada; se precisar de algo que este ambiente não possui, ela dirá, e então faça a sincronização manualmente. Sem shell, e apenas enquanto o computador estiver vinculado, faça manualmente com as ferramentas de arquivo. De qualquer forma, leia primeiro a nota de convenções do próprio vault (prepare-a quando não houver shell), e coloque cada alteração proposta no plano como o que permanece, o que muda e o que desaparece, para que a única confirmação cubra as gravações. O registro de sessão que um hook escreve não existe aqui; diga.

4 Gráfico: não verificado, como diz a seção 1. Não é "nada a fazer".

5 Salvamento de contexto: escreva onde o projeto diz. Isso vale também no Claude Code: um lugar que as instruções do projeto nomeiam vence sobre uma skill de snapshot genérica, e sem uma, a skill de snapshot instalada é a etapa. Se as instruções do projeto nomearem um lugar onde "onde parei" vive (um campo em um banco de dados de projeto, por exemplo), esse lugar é o salvamento de contexto. Se uma skill instalada é dona desse lugar (uma rotina de fechamento diário), essa skill é a etapa; se ela já foi executada nesta sessão, pule. Caso contrário, escreva você mesmo. O plano carrega o texto exato proposto para esse lugar, para que a única resposta o cubra; essa regra se aplica quando você escreve o lugar você mesmo, enquanto uma skill que é dona da gravação compõe seu próprio conteúdo, no Claude Code ou em qualquer lugar. Se nenhuma entrada de projeto cobrir o que a sessão trabalhou, diga e proponha...