session-handover
Skill0 starsChanged 56 days agoApache-2.0View on GitHub
Shift-style continuity notes with ownership, limits, hazards, protected targets, receipts, and exact next action.
3 other projects use a version of this.
Adopted by
Most recently taken up by
- jjuniper-dev/skillstheir own version, first seen Sep 27, 2026
- hideki5123/agent-skill-settheir own version, first seen Jul 9, 2026
- blueincite/claude-skillstheir own version, first seen May 18, 2026
Other versions3 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 3
- hideki5123/agent-skill-set★ 2same name
- jjuniper-dev/skills★ 2same name
- blueincite/claude-skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository12 other files it gives its agents.
- blackboardSkill
- chatterbox-tts-recoverySkill
- check-notes-firstSkill
- council-blackboardSkill
- invariant-guarded-debuggingSkill
- local-model-runtime-profilerSkill
- minimum-sufficient-changeSkill
- openwebui-regression-testSkill
- privileged-operationsSkill
- risk-aware-retrySkill
- symlink-space-saverSkill
- video-clip-editorSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
14 rules. 0 are common, 12 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 3 edited versions we read keep these.
12
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 13
Use this skill when pausing work, changing the lead model, mining session history, or preparing continuity for a fresh model that will wake …
- Distinctive: line 17
Treat the system as a working kitchen staffed in shifts.
- Distinctive: line 35
Remove noise: retries, verbose tool output, duplicated pings, abandoned speculation, and private chain-of-thought.
- Distinctive: line 37
Leave the station usable and the next action executable.
- Very specific: line 49
If a saved run could not be published because the board changed, inspect the current revision and use ucs.publish_run(run_id, …
- Very specific: line 61
Write or update the appropriate durable handover note, normally SESSION_NOTES.md, a daily memory entry, or the active typed blackboard.
- Distinctive: line 63
Use this compact shift sheet:
- Distinctive: line 83
Read current plans, blackboards, locks, service state, and receipts when the task used them.
- Distinctive: line 87
Read authenticated user messages before assistant/tool output.
- Distinctive: line 93
Do not pass guesses as facts.
- Distinctive: line 94
Do not copy private reasoning or verbose transcripts when the operational result suffices.
- Distinctive: line 98
If ownership cannot be established, mark the item unclaimed.
- Distinctive: line 107
Prefer exact paths, revisions, hashes, timestamps, test outcomes, backups, and rollback instructions.
- Distinctive: line 140
If any answer that matters is unclear, the outgoing shift has not finished closing down.
“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Session handover
Use this skill when pausing work, changing the lead model, mining session history, or preparing continuity for a fresh model that will wake up without the outgoing model's private context.
Operating model
Treat the system as a working kitchen staffed in shifts.
The incoming shift does not need the outgoing shift's entire internal monologue. It needs an accurate station state:
- what is done;
- what is still outstanding;
- what is currently in progress and who owns it;
- what failed and must not be repeated blindly;
- what is running low or close to a limit;
- what is hazardous, uncertain, or requires verification;
- what is reserved or explicitly DO NOT TOUCH;
- the exact next safe action.
The purpose is operational continuity, not narrative completeness.
Goals
- Preserve signal: user constraints, decisions, stable workflows, current state, ownership, risks, and receipts.
- Remove noise: retries, verbose tool output, duplicated pings, abandoned speculation, and private chain-of-thought.
- Prevent a fresh model from duplicating work, acting on stale state, exhausting resources, or crossing protected boundaries.
- Leave the station usable and the next action executable.
Inputs
For UCS sessions, ucs.get_handover() or
python scripts/run_ucs.py --memory /path/to/memory.db --handover returns recent
durable run records without calling a model. A finished run means its report
was saved; inspect hard_verifiers_passed, outcome_verifiers_run, actual
verifier details and any model-fallback warning before calling the task complete.
A running record after interruption is unresolved ownership, not permission
to duplicate the operation. Reconcile the worker and external effects first.
If a saved run could not be published because the board changed, inspect the
current revision and use ucs.publish_run(run_id, expected_revision=...).
This republishes the same receipt without repeating model calls or executable
tests. Board publication does not complete the task or claim independent review.
- Session directory:
~/.openclaw/agents/<agentId>/sessions/ - Optional index:
sessions.json - Memory files in the workspace (
memory/*.md;MEMORY.mdonly where allowed) - Current plans, blackboards, receipts, service state, git state, and task artefacts when relevant
Recommended output
Write or update the appropriate durable handover note, normally SESSION_NOTES.md, a daily memory entry, or the active typed blackboard.
Use this compact shift sheet:
- Outcome / station state — what is now true.
- Completed — finished work with receipts.
- In progress / owner — active work and who owns it; say
noneif empty. - Outstanding — bounded remaining jobs.
- Failures / do not repeat — failed approaches and exact boundaries.
- Running low / limits — tokens, time, storage, quotas, hop budgets, locks, deadlines, or other capacity.
- Hazards / verify — uncertain claims and checks required before action.
- Reserved / DO NOT TOUCH — protected files, data, services, credentials, user decisions, and exact target scope.
- Next action — one exact safe first step for the incoming shift.
- Receipts / rollback — paths, revisions, hashes, backups, commands, and status.
- Security redactions — confirm secrets and irrelevant private material were not copied.
Omit empty prose, but never silently omit the protected-target, hazard, resource-limit, or ownership state. Use none known where ambiguity would be dangerous.
Method
- Inventory the station
- List relevant sessions and artefacts by date/size.
- Read current plans, blackboards, locks, service state, and receipts when the task used them.
- Resolve which work is complete, active, abandoned, or blocked.
- Extract user intent and constraints first
- Read authenticated user messages before assistant/tool output.
- Preserve the newest applicable decision.
- Render exact protected targets as
DO_NOT_TOUCH: <target>.
- Separate state from story
- Record observed facts, decisions, actions, failures, evidence, and open questions distinctly.
- Do not pass guesses as facts.
- Do not copy private reasoning or verbose transcripts when the operational result suffices.
- Establish ownership
- Name the active owner for in-progress work.
- If ownership cannot be established, mark the item unclaimed; do not imply it is safe to duplicate.
- Clear stale ownership only with evidence that the prior worker is no longer active.
- Check resources and hazards
- Record remaining budgets, quotas, storage, deadlines, lock/revision state, and recovery boundaries where material.
- Flag anything that could run out, collide, become destructive, or leave the system unrecoverable.
- State what the incoming shift must verify before trusting volatile or high-impact state.
- Attach receipts
- Prefer exact paths, revisions, hashes, timestamps, test outcomes, backups, and rollback instructions.
- A claim such as “fixed” requires proportionate proof.
- Write the shortest complete handover
- Make the exact next action executable without reconstructing the whole session.
- Expire or remove stale notes rather than letting old state masquerade as current state.
- Read it as the incoming shift
- Confirm a fresh model can continue safely without asking what happened.
- Confirm it cannot mistake reserved work for free stock or completed work for outstanding work.
Useful command snippets
ls -lt ~/.openclaw/agents/main/sessions/*.jsonl
jq -r 'select(.message.role=="user") | .message.content[]? | select(.type=="text") | .text' <session>.jsonl
jq -r '.message.content[]? | select(.type=="toolCall") | .name' <session>.jsonl | sort | uniq -c | sort -rnQuality gate
A handover passes only if a fresh model can answer:
- What is true now?
- What was completed, and where is the proof?
- What remains, and who owns it?
- What failed or must not be repeated?
- What resource or limit is close to exhaustion?
- What must be verified before acting?
- What is reserved or forbidden to touch?
- What exact action should happen next?
- How is rollback performed if that action fails?
If any answer that matters is unclear, the outgoing shift has not finished closing down.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

