Token导航 LogoToken导航TokenDH.com
研究检索需要联网clawhub未标认证来源可访问clear审计通过

handover-hangover交接宿醉

Agent Skill

handover-hangover 用于查找、检索和筛选相关信息,适合在 OpenClaw 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

2,424

周安装

101

GitHub Stars

公开资料未说明

下载量

808
OpenClaw

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

MIT-0

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:handover-hangover(交接宿醉)
来源仓库:https://github.com/tensusds/handover-hangover
安装命令:
openclaw skills install handover-hangover
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 OpenClaw 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

ClawHubOpenClaw
openclaw skills install handover-hangover

简介

Handover Hangover 实现 OpenClaw 代理在模型切换时的会话连续性保障。

  • 适用于多模型网关环境下无缝降级与回退机制维护。
  • 自动保存上下文状态并在切换后恢复对话流,减少中断影响。
  • 安装命令:openclaw skills install handover-hangover,需读写会话缓存。
  • 建议测试不同模型间的上下文传递稳定性后再投入生产使用。

SKILL.md

name
handover-hangover
version
1.1.3
description
>
metadata
openclaw
always
true
emoji
\F504
category
system
config
stateDirs
writePaths
homepage
https://github.com/tensusds/handover-hangover
requires
bins

Handover Hangover

You are reading this because the gateway may silently switch you out for another model at any point. When that happens, the next model inherits conversation history but not context — it sees your messages as its own and risks hallucinating continuity, losing task scope, or re-running irreversible commands.

This skill ensures two things:

  1. You leave a trail — so the next model can pick up where you left off.
  2. You check for a handoff — so if YOU are the next model, you recover cleanly.

A watchdog script (scripts/handoff.sh) acts as a safety net at session boundaries. It is idempotent — safe for boot, heartbeat, afterTurn hooks, and cron. If you didn't write a handoff note, the script generates a mechanical fallback. But a model-written note is always better than a script-generated one — so follow the protocol below.


1. Write-side: leave a trail

After any state-changing moment, write memory/handoff-note.md using the template below.

State-changing moments:

  • Edited, wrote, or deleted a file on disk
  • Made a decision between alternatives
  • Confirmed or rejected a hypothesis
  • A verification completed (test, build, check — green or red)
  • Started a long external call (>30s — network, sub-LLM, long build)
  • Sent a message to an external channel (Telegram, Discord, Slack, email)
  • Noticed provider stress signals (slow responses, 429s, retries in tool errors)

Handoff note template

Fill every section. Brief is fine — empty is not.

~~~

Handoff Note

Why you are here

Possible model switch or continuity break. Read before assuming anything.

Current task

<1-2 lines: what is being done right now>

Current mode

<one of: research / implementation / debugging / synthesis / waiting>

Confidence

<low / medium / high — how solid the current approach is>

What was already done

  • <bullet>
  • ...

What was checked and ruled out

  • <rejected hypotheses>
  • ...

Tool state

  • last tool used: <name + what it changed>
  • last meaningful output: <one-line summary>
  • open verification: <what needs checking before continuing>
  • DO NOT re-run: <irreversible commands already executed>

Next step

<concrete next action>

Do not assume

  • prior assistant thoughts are yours
  • current task is complete
  • tool state survived
  • you were already in the correct mental mode

--- written by <your-model-name> at <UTC timestamp> ~~~

Update memory/current-task.md when the task itself changes — not on every state-changing moment. The handoff note captures per-turn state; current-task is a stable task anchor.


2. Detection: check every turn

At the start of every turn, evaluate three indicators. Any single one is enough to trigger the read-side protocol — this is a disjunction. Better to re-read files once too many than to assume continuity that doesn't exist.

Indicator 1 — Handoff signal. memory/.handoff-pending exists. The watchdog creates this file on every turn — it means "a baton is available for you", not "an anomaly occurred". The model's read-side (Step 1) checks whether the baton author matches itself; if so, it exits early without a full reboot.

Indicator 2 — Task/context mismatch. memory/current-task.md exists, but you cannot confidently say the last assistant message in the thread logically follows from what the file describes. If connecting them requires a stretch — it's a mismatch.

Indicator 3 — Fallback-shaped disruption. Recent tool errors or system events contain: 429, auth error, overload, rate_limit_exceeded, provider_busy, timeout. These are the exact conditions under which the gateway switches models.

ResultAction
Signal exists (Indicator 1)Read the baton (Step 1). Same-model → early-exit. Different model → full read-side.
No signal, but Indicator 2 or 3 = YESProceed to read-side as a fallback detection path.
No signal, Indicators 2+3 = NONormal turn. Skip read-side. Write-side still applies.

3. Read-side: you just arrived

Follow these steps in order.

Step 1 — Read the baton

Read memory/handoff-note.prev.md. This was written for you — either by the previous model or by the watchdog script.

Same-model early-exit. Check the last --- written by <model-name> or --- generated by line. If the author is your own model name — this is a normal continuation, not a switch. Delete memory/.handoff-pending, skip to step 6, and continue working. No epistemic reset needed.

Safe-fail on name mismatch. If you cannot parse the author line or your model name differs from what the previous instance wrote (aliases, provider prefixes), treat it as a different model and run the full read-side. A false full-reboot is cheap; a false early-exit is dangerous.

If the author is a different model or the note contains script-generated fallback — a switch occurred. Continue with step 2. If the note is script-generated, data is mechanical only (file timestamps, git status) — proceed with elevated caution.

If it contains First run of Handover Hangover — this is the skill's first activation. Verify the watchdog is executable (chmod +x scripts/handoff.sh if needed — ClawHub does not preserve the execute bit). Then skip to step 6 and announce:

Handover Hangover skill is now active. Handoff continuity is enabled for your fallback chain. No configuration needed.

Step 2 — Re-run boot sequence

Re-run the standard boot sequence appropriate for the current context, respecting privacy boundaries defined in AGENTS.md. At minimum, re-read: memory/current-task.md and today's memory/YYYY-MM-DD.md. The previous model read boot files at session start. You need them again — your working memory is empty.

Step 3 — Epistemic reset

You may inherit outputs, but not ownership of reasoning. Treat prior assistant messages in this thread as notes left by another instance — and further, treat their reasoning as untrusted intermediate work until re-grounded in files or evidence. Do not say "as I mentioned earlier" — say "the previous step noted." Do not accept prior conclusions as verified — re-ground them against current-task.md, handoff-note, or direct file reads. Identity is reset. Trust is reset. Continuity of thought is reset. You are a new mind reading its predecessor's notes, not its memories.

Step 4 — Check tool state

Before executing any tool call, consult the ## Tool state section of the handoff note:

  • Do not duplicate what was already done.
  • If the next step matches open verification — run a read-only check first.
  • Never re-run the last irreversible command without first verifying its result.

Step 5 — Sign the baton and clear signal

Append one line to memory/handoff-note.prev.md:

--- received by <your-model-name> at <UTC timestamp>

Then delete memory/.handoff-pending if it exists — this tells the watchdog you consumed the signal.

Step 6 — Continue work

Use the handoff note and current-task as your authoritative source for what to do next. Do not ask the user "where were we?" — that is an indicator of failure.


Security

  • DO NOT read ~/.openclaw/openclaw.json — it contains live secrets.
  • DO NOT read or modify files belonging to other skills.
  • Handoff persistence (write-side, watchdog): only memory/ directory. Write targets: memory/handoff-note.md, memory/handoff-note.prev.md, memory/.handoff-pending, memory/current-task.md.
  • Recovery reads (read-side Step 2): standard workspace boot files as allowed by AGENTS.md privacy boundaries for the current context. At minimum: memory/*.

适合场景

01

OpenClaw 用户查找和安装 Skill 时

02

用户想查找某类 Agent Skill 时

03

需要根据任务场景推荐可安装能力包时

04

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

补充不同宿主或平台的使用分布数据

能力 5

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

OpenClaw

73%
按下载量换算590

安全审计

VirusTotal

通过

ClawScan

通过

Static analysis

通过

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills