This is really cool, especially in a world where you're using Claude as a workhorse, but want to be able to bring the entire session context into Codex so you can draft communications with full context but without Claude-isms. (You can train Claude to spawn e.g. a Codex session, but Codex wouldn't know what to ask for from the broader context, beyond the prompt Claude gives it.)

And shipping sessions to colleagues is critical as well. My team relies heavily on a homegrown /resume skill that forces the harness to read every part of a Claude Code JSONL into context, letting us merge colleagues' sessions into our own.

What I thought this might be from the title, though, is a separate but related problem. The more semi-technical people in a company who start to use agentic systems, the more likely they are to create a vital playbook as a "skill" - but one not designed for easy tracking in a repository, that relies on local state, references their name, references other skills and rules that they've developed for their own work, etc. Cleaning these, figuring out what should be promoted across a team, figuring out when someone makes an update whether that's something that deserves human review, syncing across people who haven't used git/pull requests before - it's a big challenge that's highly context-dependent. If skills are the place where guardrails exist, "who watches the watchmen?"

There's an interesting duality here, because a colleague being able to ship a session where they iterated on such a skill, to a colleague who can understand the context of their change, is incredibly valuable. But it still relies on a human in the loop, and doesn't scale as a result. I think there's a really interesting design space here.

▲

cat-whisperer 5 hours ago | parent | next [-]

Yes the name is a giveaway, that's how we started out. We wanted to make it easy for non-technical people to collaborate with technical ones. git pull does bring in some friction here. Skillsync can be used as a shared skills library out of the box. Once someone updates a skill, it hot-reloads and make the latest version available to everyone instantly

Curious about your /resume skill. You said merge, so are you pulling a colleague's session into one you already have open? We only do the other direction today, where you reopen their session and continue from it. I'd love to know which one your team reaches for more.

▲

btown 5 hours ago | parent [-]

Yea, it's Claude Code only, but it runs some Python to turn the JSONL into markdown (importantly, with full tool inputs/outputs) then instructs the session to load every single line of that markdown, which Claude Code will do in chunks.

Certainly we're often resuming the session directly as a handoff, and it works for that, albeit with some context overhead for the markdown reads (though arguably we could just put the JSONL in the session folder and resume it natively). But if both you and a colleague have done independent investigation on the same project, it also makes "mind melds" possible, including their temporary scripts and unmerged changes - just begin the resumption within one's own session.

	▲	cat-whisperer 5 hours ago \| parent [-]
		keeping tool_results help the agent figure out what is being referred too. But, as you said we also faced the problem of context overhead from reading markdown that's why we made continue into a cli command instead. the mind meld thing sounds interesting, it sounds like git merge but for the transcripts

▲

Narsagna 5 hours ago | parent | prev [-]

> because a colleague being able to ship a session where they iterated on such a skill, to a colleague who can understand the context of their change, is incredibly valuable

This is interesting, I've noticed some teams where the power users (usually the ones creating most of the skills) ship an additional skill to help users update their existing skills. This 'update' skill asks them questions to understand the user's context before actually updaing the skill