--- name: handoff description: Gera um documento de handoff completo do chat atual para o próximo chat continuar o trabalho sem perguntar nada. Use quando o Vinicius disser "handoff", "passar pro outro chat", "chat tá muito grande", "continuar em outro chat", "resumir tudo pra seguir", ou quando a conversa estiver longa e perto do limite de contexto. --- # Handoff — passar o bastão entre chats Objetivo: o próximo chat abre, lê UM arquivo e já sabe tudo — o que é o projeto, o que foi feito, o que foi decidido, o que deu errado, onde parou e qual é o próximo passo. **Zero perguntas de volta pro Vinicius.** Regra de ouro: escreva para alguém inteligente que **não viu nada** desta conversa. Nada de "como falamos antes", "aquele arquivo", "a opção 2". Sempre nome, caminho e motivo explícitos. ## Passo 1 — Reconstruir o chat inteiro (não só o fim) Releia a conversa do começo ao fim, não só as últimas mensagens. Extraia: - **Pedido original** e como ele evoluiu (o que mudou de rumo e por quê). - **Decisões tomadas** + o motivo de cada uma (e alternativas descartadas, para ninguém reabrir). - **O que foi feito** de fato (arquivos criados/editados, comandos rodados, deploys, configs). - **O que deu errado** (erros, tentativas que falharam, causa raiz, o que NÃO repetir). - **Preferências e correções do Vinicius** neste chat (estilo, tom, "não faça X", "gostei de Y"). - **Pendências e dúvidas em aberto**, incluindo o que ficou esperando resposta dele. - **Exatamente onde parou**: a última coisa feita e a próxima ação imediata. ## Passo 2 — Verificar o estado REAL (não confie só na memória) Antes de escrever, confira o que existe agora. Use as ferramentas, não suposição: - Pasta de trabalho atual (`pwd`) e arquivos relevantes (liste os caminhos absolutos). - Se for repositório git: `git status`, `git branch --show-current`, `git log --oneline -10`, `git diff --stat`. Registre branch, commits recentes e mudanças não commitadas. - Servidores/processos rodando (portas, comandos para subir de novo). - URLs, deploys, IDs de coisas criadas (artifacts, docs, projetos, PRs) — com o link completo. - Variáveis de ambiente / credenciais necessárias: cite **só os nomes** e onde ficam. **Nunca escreva senha, token ou chave no handoff.** Marque cada afirmação como **[verificado]** (conferi agora) ou **[do chat]** (veio da conversa, não revalidei). O próximo chat precisa saber em que pode confiar. ## Passo 2.5 — Mapa do código (Cartographer) Se o trabalho é **projeto de código** (há `package.json`, `pyproject.toml`, `.git`, `src/` ou equivalente), acione a skill `cartographer` **antes** de escrever o handoff, para o próximo chat ter o mapa da arquitetura sem reler tudo: - **Não existe `docs/CODEBASE_MAP.md`** e o projeto tem mais de ~15 arquivos de código → rode `/cartographer` (via Skill) para criar o mapa. - **Existe, mas há mudanças desde `last_mapped`** (confira com `git log --since`) → rode `/cartographer` em modo atualização. - **Existe e está em dia** → não rode; só aponte para ele. - **Projeto pequeno (até ~15 arquivos), ou trabalho que não é código** (design, conteúdo, docs) → pule este passo. Depois, no handoff, não repita a arquitetura: na seção 10 escreva "Arquitetura: ver `docs/CODEBASE_MAP.md` (mapeado em )" e na seção 0 mande o novo chat lê-lo logo após o handoff. O cartographer lê os arquivos com subagentes, então pesa pouco no contexto desta conversa. Se ele falhar (ex.: falta `tiktoken`), siga o handoff mesmo assim e registre na seção 6 que o mapa não foi gerado e como rodar depois. ## Passo 3 — Escrever o arquivo Salve em `HANDOFF.md` na raiz da pasta de trabalho do projeto. Se não houver projeto/pasta (chat solto), salve em `C:\Users\vinni\NeuroOS\handoffs\AAAA-MM-DD-nome-curto.md` (crie a pasta se faltar). Se já existir um `HANDOFF.md`, **não sobrescreva**: renomeie o antigo para `HANDOFF-AAAA-MM-DD-HHMM.md` e crie o novo. Use exatamente esta estrutura (português do Brasil, direto, sem enrolação): ```markdown # Handoff — Gerado em · Pasta: · Branch: ## 0. Comece por aqui (30 segundos) - Em uma frase: o que é isso e qual o objetivo final. - Onde paramos: <última coisa feita>. - Próxima ação imediata: . - Definição de "pronto" desta tarefa: . ## 1. Contexto e objetivo Para quem/para quê é, restrições, prazo, stack, quem decide o quê. ## 2. Linha do tempo (resumida) Cronologia curta: pedido inicial → viradas de rumo → estado atual. ## 3. Decisões tomadas (e por quê) | Decisão | Motivo | Alternativas descartadas | ## 4. O que já está feito Lista com caminhos absolutos dos arquivos e o que cada um faz. [verificado]/[do chat]. ## 5. Estado atual do ambiente Branch/commits/mudanças não commitadas, processos rodando, portas, URLs, IDs, como subir e testar. ## 6. O que deu errado / armadilhas Erro → causa → solução. O que NÃO tentar de novo. ## 7. Pendências (em ordem de prioridade) - [ ] item — por quê — como fazer — arquivos envolvidos ## 8. Preferências do Vinicius neste trabalho Tom, estilo, regras ("não faça X"), coisas aprovadas e reprovadas. ## 9. Perguntas em aberto Só o que realmente depende dele. Para cada uma: sua recomendação padrão, para o chat seguir sem esperar se ele não responder. ## 10. Mapa de arquivos e links Caminhos absolutos, URLs, IDs, comandos úteis (build, teste, deploy). ``` Regras de escrita: - Seja **denso e específico**: caminhos absolutos, nomes exatos, comandos copiáveis, trechos de código/erro quando forem essenciais. Sem adjetivo vazio. - Se o chat for enorme, **priorize decisões, estado e próximos passos** sobre histórico narrativo. Histórico longo vira 1–2 linhas. - Não invente. O que não souber ou não conseguir verificar, escreva "não verificado" em vez de chutar. - Sem segredos. Sem dados pessoais desnecessários. ## Passo 4 — Entregar o prompt de abertura Depois de salvar, responda ao Vinicius com **só isto**, curto: 1. O caminho do arquivo salvo (link clicável). 2. Um bloco de código com o prompt para colar no novo chat, já com o caminho certo: ``` Leia por inteiro o arquivo — é o handoff do chat anterior (e, se existir, leia também docs/CODEBASE_MAP.md para a arquitetura). Depois de ler: confirme em 3 linhas o que entendeu (objetivo, onde paramos, próxima ação) e já execute a "Próxima ação imediata". Não me faça perguntas que o handoff já responde; se algo estiver marcado [do chat], reverifique rápido antes de depender disso. Só pergunte o que estiver na seção "Perguntas em aberto" e só se bloquear de verdade. ``` 3. Se o trabalho está em pasta de projeto, lembre: abrir o novo chat **na mesma pasta**. ## Passo 5 — Checagem final (antes de dizer "pronto") - [ ] O arquivo existe e foi relido uma vez por você. - [ ] Um estranho conseguiria agir só com ele? (nenhuma referência vaga tipo "aquilo", "o de antes") - [ ] Próxima ação imediata é concreta e executável. - [ ] Nenhuma senha/token/chave no texto. - [ ] Todo [verificado] foi de fato verificado agora. ## Variações - **"Handoff rápido"**: só as seções 0, 3, 7 e 9 (versão de 1 tela). - **Handoff para outro agente/subagente**: mesma estrutura, mas com a seção 0 escrita como briefing fechado (objetivo, escopo, o que NÃO fazer, definição de pronto). - **Atualizar handoff existente**: leia o `HANDOFF.md` atual, mescle o que mudou nesta sessão, mantenha as decisões antigas e arquive a versão anterior.