Produz pacote prospectivo de handoff pra outro agente, modelo ou dev humano pegar a task de onde parou — sem contexto da sessao atual. Diferente de session-summary (skill 31) que e retrospectivo: handoff-context monta o briefing acionavel pra quem chega cego. Trigger em: "handoff", "passar bastao", "passar o bastao", "delega pra outro", "delega isso", "transfer context", "passar contexto", "outro dev vai pegar", "outro agente vai continuar", "preciso passar isso", "briefing prospectivo", "sessao fresh", "preparar handoff", "monta o pacote".
64
80%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
Passed
No findings from the security scan
Fix and improve this skill with Tessl
tessl review fix ./skills/45-handoff-context/SKILL.mdInspiracao: mattpocock/skills/productivity/handoff (MIT). Adaptado pra distinguir explicitamente de
skill 31 (session-summary)(retrospectivo).
| Skill 31 session-summary | Skill 44 handoff-context (esta) | |
|---|---|---|
| Foco temporal | Retrospectivo (o que foi feito) | Prospectivo (o que falta + como continuar) |
| Audiencia | Proxima sessao minha (mesmo modelo, contexto recuperavel) | Outro agente / dev humano / sessao fresh cego |
| Formato | Log markdown com decisoes e wikilinks | Pacote acionavel: setup commands + estado + 1 proximo passo |
| Trigger natural | Fim de sessao (auto-save) | "passar bastao", "delega", "outro vai continuar" |
| Output dir | D:\claude-memory\logs\ ou local | docs/handoffs/YYYY-MM-DD-<feature>.md |
| Reuso esperado | "lembrar depois" | "executar agora sem perguntar" |
Resumo: session-summary registra, handoff-context delega.
Segue GLOBAL.md, policies/handoffs.md (canonica), policies/persistence.md,
policies/token-efficiency.md, policies/verification-before-completion.md
(handoff so quando estado e verificavel).
git status --short
git branch --show-current
git log --oneline -5Capturar:
Listar — cada item vem de rodar o comando agora, nao de memoria da sessao (a suite pode ter passado 20 mensagens atras e quebrado desde):
Nao gerar roadmap. Um proximo passo concreto com:
Se houver mais de um proximo passo possivel, escolher o mais bloqueador ou pedir AskUserQuestion.
Coisas que voce descobriu nesta sessao que economizam tempo pra quem chega:
Salvar em docs/handoffs/YYYY-MM-DD-<slug>.md:
---
date: YYYY-MM-DD
feature: <nome>
target: human | agent | fresh-session
status: blocked | in-progress | ready-for-review
inspired-by: skill 44 handoff-context
---
# Handoff: <feature>
## Setup (execute primeiro)
\`\`\`bash
git checkout <branch>
git pull
<comandos de setup>
\`\`\`
## Estado atual
- **Branch:** <branch> (X commits ahead/behind main)
- **Build:** verde | vermelho | nao tentado
- **Testes:** <pass>/<total> passam
- **Modificado:** <arquivos nao commitados>
## O que foi feito
- <decisoes ja tomadas — link pra session log>
- <implementado e funcional>
- <implementado mas nao testado>
## Proximo passo (UM)
<comando ou edicao especifica>
**Resultado esperado:** <output ou comportamento>
**Sucesso:** <criterio verificavel>
## Armadilhas (do que descobri)
- ⚠️ <coisa nao obvia 1>
- ⚠️ <coisa nao obvia 2>
## NAO faca
- ❌ <abordagem ja tentada e rejeitada>
- ❌ <suposicao errada que parece certa>
## Referencias
- session log: [[D:/claude-memory/logs/YYYY-MM-DD-...]]
- spec: <link>
- PRs relacionados: <links>.md salvo + "Continue daqui".md como issue/PR descriptiondocs/handoffs/<arquivo>.mdFonte: bojieli/ai-agent-book, book-en/chapter6.md — conceito absorvido, texto reescrito. Distinto do Output Canônico acima: aquele é um handoff humano-legível entre sessões de trabalho; isto é sobre serializar a trajetória de execução de um agente pra retomada programática por outro provider/harness (failover no meio de uma sessão, replay pra avaliação, extração de dados de treino).
Quando o handoff precisa ser consumido por outro agente/provider, não por um humano lendo o próximo passo, separar a trajetória em duas partes distintas:
{name, args} (nunca a resposta bruta da API do provider original, que pode ter formato proprietário). Isso é o que atravessa a troca de vendor.☐ Um log de trajetória pensado pra handover cross-vendor separa claramente as duas partes
acima — não serializa a resposta bruta do provider como se fosse portável
☐ Falha de um provider no meio de um /loop ou /swarm não perde a trajetória — o texto
portável permite retomar noutro provider a partir do mesmo pontoNível de aplicação: mais baixo que os providers/adapters de patterns/ai-integration/providers.md (que resolvem "qual provider chamar"), mais alto que uma chamada de API isolada — isto é sobre o formato do log de execução completo, não da requisição individual.
felvieira/claude-skills-fv
90329e3
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.