Recently I came across the /handoff skill, which I've been using a lot. I find it much better than /compact.
Basically:
- /handoff file creates a short document with the important context from your current session and maybe next steps as checklist.
- You can then start a fresh session with /continue file
- You can also hand the work from Claude to ChatGPT, or the other way around. Very useful at time of session limits.
- Plus your handoff files becomes a useful piece of project memory that you can reference later.
I find this much more useful than /compact or /clear because the context is saved in something portable instead of being tied to one session and i've seen better results doing this every 20 messages or so than running long sessions.
> Plus your handoff files becomes a useful piece of project memory that you can reference later.
I've been doing this since I started agentic development, and have a whole framework based on this; Simply put I define workflow s that output templated files for everytype of tasks that happens in development.
It's a powerful pattern I'd recommend everyone.
I started doing this and then a colleague of mine recommended me OpenSpec. It might be overkill for small projects but it’s pretty clean and if you have goldfish memory like me, it helps to track changes.
Can you please add more details? Thank you in advance!
I like the handoff flow so much I built it into my agent as a native tool; and going to add it as a auto compaction strategy as well.
/handoff is the skill I use when I plainly are about to run out of token budget to give to a different harness system. Using this to avoid long sessions is something I will need to try, plus maybe "caveman" mode to cull the verbosity.
I have been doing this a lot even without a skill, having Fable write a planning document, then spawning an Opus subagent with instructions to strictly follow the plan and report any deviance at the end. It also helps that then the plan is always saved in an md file so any future agent can look at it and see what happened.
Interestingly, this was tackled in this blog post[0] a month ago. They claim that plan files aren't token-efficient, because after reading the plan the workhorse model then reads all the relevant files anyways.
[0] https://news.ycombinator.com/item?id=48916512
That link just says the planning stage should vet the idea concretely so that the plan focuses on a solution that won’t immediately have to pivot.
And I think plan files should focus on general ideas and invariants, not do “implementation as prose”. That way they perform as mini-ADRs that are useful historically, especially to mine why the system is the way it is.
The trick is to delete all the relevant files after the plan is written.