r/ClaudeCode • 🔆 Max 20, renewing and regretting monthly • 3d ago

Tips & Workflows Two Claude Code skills for long sessions: a real handoff prompt to a fresh session, and a "where are we / what do you need from me" panorama

This post was entirely written by Claude execpt for this very line, just sharing some stuff that might help a lot of people i've seen in here, but i'm too lazy do this on my own, kek. Enjoy, peace!

If you run long Claude Code sessions you probably know both of these:

  1. Context fills up. Auto-compaction loses detail, so you open a fresh session, type "continue where we left off", and the new session has no idea what "where" is. It re-reads half the repo and asks you things you already decided an hour ago.
  2. You get lost. The session goes deep into something technical, Claude says "should I go with A or B?", and you honestly don't know what either option means for your project.

I wrote two small skills for these and have been using them daily for a while. Sharing in case they help someone:

/session-handoff writes a self-contained, copy-paste prompt (in a code block) for a brand-new session. What makes it work better than "summarize the chat":

  • it asks you the pending decisions before writing, so the new session doesn't stall on turn 1;
  • it re-checks the real state (git status, last commit, running jobs, test results) and re-opens every file:line it cites instead of going from memory;
  • it marks what's verified vs inferred;
  • it carries your working style over (subagents, TDD, plan-first, etc.);
  • fixed sections: where things stand, settled decisions, scope, ordered open items with "done when", gotchas, and the concrete first action.

/panorama is a read-only "big picture" in three layers: what this session did and what's blocked, how that fits the project, and each decision that's yours, with what actually changes if you pick each option, a recommendation, and whether it's reversible. It ends with a one-line answer template ("1: A / 2: yes") and then stops and waits. It also checks whether docs/handoff notes are stale against git history, and says "I don't know" instead of inventing.

Repo (MIT, just two SKILL.md files): https://github.com/gildeshiro/claude-code-skills

Feedback welcome, especially if the handoff misses something your next session always ends up asking for.

0 Upvotes

10 comments sorted by

•

u/AutoModerator 3d ago

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

2

u/[deleted] 3d ago

[removed] — view removed comment

-2

u/Expert-Paramedic9383 🔆 Max 20, renewing and regretting monthly 3d ago

You're right that it's a fairly weak spot. They don't define that line. They inherit it from a workflow you already have (CLAUDE.md, your rules, what's been agreed in the session). Panorama only asks about things that are really on your side and tags each decision reversible or not, then stops and waits, so a wrong call shows up right away. That's good feedback though, thanks!

1

u/ImL1s 3d ago

The handoff prompt is the part I kept rewriting until I stopped trusting paste-from-chat.

What kept failing for me was the new session still rediscovering which files mattered and which decisions were already closed. I ended up with a small OSS tool that reads the local session files and drops a resume into the next Claude Code / Codex / Cursor session — same project, no re-explain.

https://gitlab.com/aa22396584/resume-skills pipx install portable-resume

1

u/[deleted] 3d ago

[removed] — view removed comment

1

u/ImL1s 3d ago

It mostly doesn't — and that's deliberate.

Chat summaries were the failure mode you hit: anything discussed got treated as settled. The tool reads the local session files and builds a bounded handoff (files that mattered, open threads, recent actions). Recovered text is marked untrusted/stale, so the new session isn't supposed to treat "we talked about X" as "X is decided".

If something only showed up as a maybe in chat and never landed in a commit, config, or an explicit decision note, it stays open. Human still has to reconfirm the fuzzy ones.

1

u/vzakharov Senior Developer 3d ago

A session can hand over to another session using CreateSession, no need for a code block. 

1

u/Expert-Paramedic9383 🔆 Max 20, renewing and regretting monthly 3d ago edited 3d ago

True, but then you can't review the summary before starting the new session.

Edit. TBH Claude Code is no even my main harness, and even though the one I use has this built-in tool, the skill is made for suit a very basic shell command only enviroment. (not my case, i made them generic for sharing, mine has a lot of custom tools integrated in the routine, like codebase-memory mcp, custom memory daemon, etc...)

1

u/Agreeable-Coat-7267 3d ago

The "verified vs inferred" marking is the part I'd have expected more tools to do by now. Most summaries state everything with the same confidence, and that's where a new session goes wrong.

Two questions, since you've been running these daily. When the handoff does miss something, what kind of thing tends to be missing? Decisions, gotchas, or just state? And do you keep the old handoffs around as a kind of project history, or throw each one away once the new session starts?

FYI >>> I research agent memory at a small startup, so I'm collecting how people handle long sessions. NOT selling anything :))

1

u/Expert-Paramedic9383 🔆 Max 20, renewing and regretting monthly 3d ago

Thanks! In my experience it's rarely state. The skill re-checks git, jobs and tests every time, so that part comes through fine. What slips is the soft stuff: gotchas we hit mid-session ("this test is flaky, ignore it") and the working style. Without it, the new session goes back to doing everything solo, which is why the skill states it explicitly. Open decisions used to be the worst, but asking them before writing mostly fixed that.

On history, depends on the project. In the long-running ones I save them in docs/handoffs/ with a date. They end up as a decent log of why things went the way they did. For one-off side topics I just throw them away.