Install any skill in seconds. Free to start, no credit card required.
Get Started Free →End-of-session ritual. Captures decisions, lessons, gotchas, and open threads. Writes a narrative session log to ~/.origin/sessions/ and stores granular memories via Origin MCP. Previews any unconfirmed captures from the current session before closing. Invoked as `/handoff`.
.claude/skills/davepoon-handoff/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-05 | ✗→✓ | ▲ Improved | 86% | 0% |
| case-08 | ✗→✓ | ▲ Improved | 160% | 0% |
| case-10 | ✗→✓ | ▲ Improved | 85% | 0% |
| case-11 | ✗→✓ | ▲ Improved | 103% | 0% |
| case-12 | ✗→✓ | ▲ Improved | 108% | 0% |
End-of-session debrief. Three artifacts each pass:
~/.origin/sessions/<YYYY-MM-DD-HHmm>-<slug>.md.~/.origin/sessions/_status/.These are orthogonal: captures are queryable atoms, session log is the narrative thread, status file lets the next session see where we left off.
Bash: cd_repo=$(git -C "$PWD" rev-parse --show-toplevel 2>/dev/null); echo "${cd_repo:-no-git}"<project> (e.g. origin).no-git → use the cwd basename. Skip git steps below; rely entirelyon conversation context.
Read ~/.origin/sessions/_status/handoff-<project>.json for lastHandoff timestamp (ISO-8601). If file missing, default to "12 hours ago".
After establishing <lastHandoff>, call:
list_pending(limit=50)The MCP returns memory rows with source_id, content, created_at, and other metadata. Convert lastHandoff (ISO-8601 string, e.g. 2026-05-13T22:50:00Z) to a Unix epoch seconds integer before filtering:
Bash: date -j -f %Y-%m-%dT%H:%M:%SZ "$lastHandoff" +%sOr in your scripting language of choice (Python's datetime.fromisoformat, JavaScript's Date.parse, etc.). Save the result as lastHandoffEpoch.
Then filter the response rows: keep where row.created_at >= lastHandoffEpoch. These are captures this session produced that the quality gate left unconfirmed (untrusted-source captures).
If the filtered list is empty, say nothing. Proceed to Step 2.
If non-empty, render a preview block once, before the existing capture flow:
Pending captures this session (<N> total, top 3 shown):
1. mem_xyz789 "..." (untrusted source: <agent>)
2. ...
Default: proceed (captures stay pending). Opt in by running
`/review captures` before re-invoking /handoff if you want to walk them.Do NOT prompt for per-item action inline. The user proceeds with /handoff regardless; the preview is informational only.
Bash: git -C <repo> log --oneline --since=<lastHandoff>
Bash: git -C <repo> status --short
Bash: git -C <repo> diff --stat HEAD~5..HEAD 2>/dev/null
Bash: git -C <repo> worktree listCapture output. Use it alongside conversation history to infer what happened. If not a git repo, skip — conversation context is the source.
Synthesize silently from git output + conversation. Categorize each item into user-facing groups. Each maps to a daemon memory_type for the capture call:
| Display label | daemon memory_type | What belongs here | |---|---|---| | Decisions | decision | architectural choice, tool/pattern selection (with WHY) | | Lessons | lesson | root cause discovered, workaround found, technical insight | | Insights | gotcha | unexpected behavior, debugging discovery, sharp edge | | Corrections | preference | user pushed back, corrected approach or assumption | | Facts | fact | durable project/people/tool fact worth persisting |
Non-memory items (not stored, session-log only):
Skip purely mechanical facts already in git (file paths, function names, config values). The commit log preserves those.
For each non-trivial item, call with the mapped memory_type:
capture(content="<one self-contained sentence with WHY>", memory_type="<decision|lesson|gotcha|preference|fact>")Atomic: one decision per call. Don't merge multiple items into one memory. The daemon dedups against existing knowledge, so re-storing known facts is a no-op.
Only surface items to the user BEFORE storing if they meet one of these bars:
Otherwise just store and report counts at the end.
Bash heredoc to ~/.origin/sessions/<YYYY-MM-DD-HHmm>-<slug>.md:
markdown# Session <YYYY-MM-DD HH:MM> — <slug> **Project:** <project> **Range:** <lastHandoff> → <now> ## Accomplished - <item> ## Decisions - <decision and rationale> ## Lessons & Gotchas - <root cause / workaround> ## Open Threads - <what's unfinished> ## Captures stored - <source_id_or_brief_summary> ## Git summary <git log --oneline output>
<slug> = kebab-case 2-4 word summary (session-handoff-md-writer).
Overwrite ~/.origin/sessions/_status/<project>.md:
markdown# <Project> — Current Status ## Last session (<date>) - <accomplished bullet> ## Active <!-- Items touched/spawned in the last 1-2 sessions. Real next-move candidates. --> - <item> (added <YYYY-MM-DD>) - <blocked item> (added <YYYY-MM-DD>) (gated: <trigger>) ## Backlog <!-- Older accretion. Not gated, not picked. Promote back to Active when re-engaged. --> - <item> (added <YYYY-MM-DD>)
Single file per project. New session overwrites — this is the current state, not a log.
Two sections, not one flat list: ## Active and ## Backlog separate the two types of tasks that get mixed otherwise. Active = fresh signal worth picking next. Backlog = older parked items, kept for reference but not in the "what next?" frame.
Date stamp every bullet with (added <YYYY-MM-DD>). Use today's date when adding a new item; preserve the original date when carrying an item forward. Dates make age visible at a glance and avoid relative-time drift.
Gated items stay inline-tagged with (gated: <trigger>) — no separate section. The tag tells the reader why it can't move yet; the bullet stays in whichever section reflects its recency.
Promotion / demotion rules:
## Active with today's date## Active that wasn't touched this session AND wasn't touchedthe prior session → demote to ## Backlog (keep original date)
## Backlog that work resumed on → promote back to ## Active(keep original date — staleness is a property of the work, not the bullet text)
Overwrite ~/.origin/sessions/_status/handoff-<project>.json:
json{ "lastHandoff": "<ISO-8601 now>", "project": "<project>", "summary": "<one-line>" }
Per-project file prevents parallel sessions from clobbering each other.
After writing the files above, snapshot the change so the user can git log their memory's life timeline. Defensive — silent skip if git is missing or ~/.origin/ is not a repo yet.
Bash: git -C ~/.origin add -A && \
git -C ~/.origin -c user.name=Origin -c user.email=daemon@origin.local \
commit --quiet -m "session: <slug>" 2>/dev/null || \
(sleep 1 && git -C ~/.origin add -A && \
git -C ~/.origin -c user.name=Origin -c user.email=daemon@origin.local \
commit --quiet -m "session: <slug>" 2>/dev/null) || trueThe retry handles index.lock races — the daemon may be writing to ~/.origin/ at the same moment (auto-commit from captures). One-second wait is enough for the daemon to release the lock.
Print one summary block with captures grouped by display label:
Handoff stored.
Decisions: <N> (brief list)
Lessons: <N> (brief list)
Insights: <N> (brief list)
Corrections: <N> (brief list)
Facts: <N> (brief list)
Session: ~/.origin/sessions/<filename>
Status: ~/.origin/sessions/_status/<project>.md
Git: <commit hash> session: <slug>Show each label only if non-empty. List items as short phrases, not full sentences — the session log has the details.
/capture (single memory)./recall.a stability flag — they never get exported to md.
~/.origin/pages/ by thedaemon when /distill runs. Citations link back to source memory ids.
~/.origin/sessions/. They arethe narrative axis: chronological, not topical. Browse them as a changelog of your work.
| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-01 | fail→fail | 3,956 | 5,270 | +33% | 1 | 1 | 0% | 309 | 2,700 | +774% | 0 | 0 | — |
case-02 | fail→fail | 4,593 | 4,320 | -6% | 1 | 1 | 0% | 276 | 2,729 | +889% | 0 | 0 | — |
case-03 | fail→fail | 12,200 | 2,829 | -77% | 1 | 1 | 0% | 2,455 | 2,639 | +7% | 0 | 0 | — |
case-04 | pass→pass | 6,490 | 2,009 | -69% | 1 | 1 | 0% | 1,104 | 2,873 | +160% | 0 | 0 | — |
case-05 | fail→pass | 10,500 | 3,960 | -62% | 1 | 1 | 0% | 1,700 | 3,156 | +86% | 0 | 0 | — |
case-06 | pass→pass | 8,859 | 3,464 | -61% | 1 | 1 | 0% | 1,598 | 3,111 | +95% | 0 | 0 | — |
case-07 | pass→pass | 9,305 | 3,559 | -62% | 1 | 1 | 0% | 1,564 | 3,099 | +98% | 0 | 0 | — |
case-08 | fail→pass | 7,492 | 6,157 | -18% | 1 | 1 | 0% | 1,374 | 3,578 | +160% | 0 | 0 | — |
case-09 | pass→pass | 6,297 | 2,670 | -58% | 1 | 1 | 0% | 1,085 | 2,937 | +171% | 0 | 0 | — |
case-10 | fail→pass | 9,920 | 3,848 | -61% | 1 | 1 | 0% | 1,697 | 3,131 | +85% | 0 | 0 | — |
case-11 | fail→pass | 8,424 | 2,040 | -76% | 1 | 1 | 0% | 1,409 | 2,854 | +103% | 0 | 0 | — |
case-12 | fail→pass | 7,878 | 2,599 | -67% | 1 | 1 | 0% | 1,440 | 2,990 | +108% | 0 | 0 | — |
case-13 | fail→pass | 10,953 | 4,532 | -59% | 1 | 1 | 0% | 2,075 | 3,533 | +70% | 0 | 0 | — |
case-14 | fail→fail | 6,609 | 2,156 | -67% | 1 | 1 | 0% | 1,110 | 2,827 | +155% | 0 | 0 | — |
case-15 | pass→pass | 14,419 | 2,607 | -82% | 1 | 1 | 0% | 2,388 | 3,023 | +27% | 0 | 0 | — |
case-16 | pass→pass | 10,634 | 2,058 | -81% | 1 | 1 | 0% | 1,739 | 2,810 | +62% | 0 | 0 | — |
case-17 | pass→fail | 9,028 | 3,977 | -56% | 1 | 1 | 0% | 1,404 | 3,274 | +133% | 0 | 0 | — |
case-18 | pass→pass | 9,087 | 3,499 | -61% | 1 | 1 | 0% | 1,517 | 3,105 | +105% | 0 | 0 | — |
case-19 | pass→pass | 3,298 | 3,216 | -2% | 1 | 1 | 0% | 463 | 2,934 | +534% | 0 | 0 | — |
case-20 | pass→pass | 6,856 | 2,997 | -56% | 1 | 1 | 0% | 1,156 | 3,027 | +162% | 0 | 0 | — |
case-21 | pass→pass | 4,302 | 2,806 | -35% | 1 | 1 | 0% | 772 | 2,977 | +286% | 0 | 0 | — |
case-22 | pass→pass | 8,095 | 2,277 | -72% | 1 | 1 | 0% | 1,345 | 2,865 | +113% | 0 | 0 | — |
case-23 | pass→pass | 10,814 | 4,084 | -62% | 1 | 1 | 0% | 1,868 | 3,285 | +76% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 23 cases were attempted, and 20 counted toward the lift figure. The other 3 produced results that are not comparable between the two arms, so they are excluded from the headline rather than averaged into it. The headline lift of +22 percentage points is the difference between those two pass rates over the 20 comparable cases. 1 case got worse with the skill loaded, and it is included in that figure.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.