Hey HN, we're Nars & Nishant, founders of Skillsync (https://skillsync.com)
Skillsync lets you move your AI chats across every coding agent. Most of our work exists as conversations, which are currently scattered across our agents. Though stored locally, these conversations use different formats. This is annoying because you cannot simply switch between agents without starting over. We get locked into a single provider and their agent as we invest in skills and memories over time. Skillsync acts as a universal converter. It moves the entire session, including all the messages, reasoning and tool calls so you can pick up right where you left off.
Skillsync collects all your sessions in one place and makes them searchable. It breaks down what each session is carrying, including which loaded skills the agent is actually using, making stale context easy to spot. You can also create shared workspaces to sync sessions across your team. You can build your own closed loop systems. Everything runs locally except when you share to workspaces.
The core is an open-source Rust engine called txcript (https://github.com/skillsynchq/txcript). It translates a session from one agent's on-disk format into another's, mapping conversation, reasoning, and tool history. Think ffmpeg or pandoc, but for agent sessions.
On top of that engine is a local-first desktop app. Your agent sessions are normally scattered across different tools' folders in formats you'd never read by hand; the app surfaces them in one place with a UI that makes them actually readable, the conversation, the reasoning, and the tool calls, so you can revisit what happened, move a session into another agent, or share it with a teammate.
Skills and memory are stored as portable, human-readable markdown you own, and exposed to any agent over MCP for search and selective retrieval.
Sessions and translation run locally on your machine. The one thing that leaves is what you explicitly share into a team workspace.
It’s been surprising to us to see how locked-in people already are without realizing it. You don't notice you're trapped in one agent or harness until you try to leave, and by then you've got months of sessions stuck in a format only that tool can read. The lock-in is invisible right up until it's expensive.
Once sessions are portable, they stop being disposable logs and become something you can actually build on, spotting patterns in how you work, handing a session off to someone else, letting a non-technical teammate pick up where an engineer left off. The session turns out to be the unit of collaboration, and right now it's being thrown away.
Before Skillsync, Nars and I built an open-source payment orchestrator that let merchants route across many processors instead of getting locked into one (30k+ GitHub stars). Fighting vendor lock-in by making incompatible systems interoperate was the whole job. We came into YC with a different idea, but the more we lived inside coding agents the more we saw the same problem from the other side: your context is locked into whatever agent you start with, because every agent stores sessions differently and none of it moves.
Some of the things we’re seeing people do with Skillsync are:
- Moving a session between Claude Code, Codex, and Cursor mid-task, including when you hit a usage limit on one and want to keep going on another.
- Thinking through a problem in a browser Claude chat, then handing the whole thread to Claude Code or Codex to build.
- Sharing research sessions with a team. Everyone uploads their sessions, so teammates and their agents can build on each other's work instead of repeating it.
It's available as a Mac app, CLI and MCP. Here's the demo: https://youtu.be/7hVhSnSKGl8. Would love to hear your feedback and answer questions!
mmykola872 days ago
I went the opposite way, and I think it's worth mentioning the cost of that choice. My conversation doesn't carry over. Only what a session explicitly recorded does. This includes decisions, open questions, verified items, and what's left to do. Anything that wasn't recorded is gone, and that's a real loss, not just a small part of the process.
I went with this approach because the transcript doesn't go into a file; it goes into another live session, which messes up its flow. We've already talked about this a bit when we were discussing "how to make reading Markdown cheaper." My answer was different: don't bring it over at all. The next session doesn't need to know how we got there—it just needs to know what we decided and what we've actually verified.
I don't think we've talked about this in this thread yet. Portability is all about a session that's already wrapped up. I often have two sessions open at the same time. One is building an endpoint, and the other is the screen that calls it. They need to ask each other before both build on different assumptions. Moving the transcript around won't fix this. What's needed is a message, not a copy.
I made a small open-source layer for this: a mailbox and a "walkie-talkie" for sessions in the clients you've already opened - https://github.com/automatis-tools/agents-can-communicate. It doesn't transfer memory and doesn't detect discrepancies on its own. The session has to check for those things.
[deleted]9 hours agocollapsed
cat-whispererop2 days ago
I agree that the next session wants conclusions, not the whole transcript. What I've seen working with people on this is that a summary only has what the summarizer prompt asked for, and what they need from an old session changes depending on what they're doing when they go back to it. With the full session still around, they can just ask it again.
Porting is also cheap, since it's just a format conversion. Getting a new session back up to speed from notes usually isn't.
Concurrent sessions is a separate problem, and I agree that a message is the right shape there. Where portability helps is that different harnesses are good at different things, so you can start a task in one and move it to another that's better at the next part, without starting over.
mmykola878 hours ago
As for the summary, I agree that it's a big gap. I'm not trying to make a better summary: it's not a separate summarizer rewriting the session afterwards, it's the session itself writing while it's still active.
"Asking the old one again" works as long as it's alive. In my case it's exactly the opposite — either I've hit the limit, or I've switched to a different model. Then there's no one to ask, and whatever wasn't recorded is gone.
And "cheap" is measured from the wrong side. The conversion is cheap, but the transcript doesn't go into a file — it goes into a live session and spends its turn every time it moves.
podviaznikov3 days ago
I have made simple macos app to export my claude sessions to markdown(plus ordinal jsonl) and i just continuously sync it to dropbox.
i do the same for apple notes and imessage. so very portable
https://apps.apple.com/us/app/exporter-notes-to-markdown/id6...
Narsagna3 days ago
Cool! Over here we mean portability in a different sense: being able to continue a session in another agent as if the entire conversation history was there the whole time. You should not get locked into one agent simply because you built up a conversation history + memory with that agent
Also curious, do you further process the synced files on dropbox at all? how are you using them today?
podviaznikov3 days ago
I don't do much with most of the sessions.
In my experience 95% of the session transcript I don't care about.
But there are some that I want to keep and maybe come back one month later.
Usually it's not even engineering-related. Maybe doing some research on visas, relocation.
But sometime also doing project research and sometime I want to come back to the same topic 2 month later(because new things came up) and I want my new agent to go and read prior conversation.
Narsagna3 days ago
Yeah understandable, with skillsync you can choose for it to proactively tell you about past work that's related to what you're doing or just access all your past sessions via mcp. It's like being a musician that has the record button on the whole time for when the crazy idea strikes
solfox3 days ago
Love this. Easily the most annoying thing about modern Agent development across Claude, Codex, etc. One nit: You don't auto-discover "archived" chats from Codex. They have to be unarchived and the app restarted before being found.
cat-whispererop3 days ago
I'll add support for this. On another note, if you know what the issue is, our core is open and I would love for you to contribute: https://github.com/skillsynchq/txcript
solfox3 days ago
Definitely. Issue filed: https://github.com/skillsynchq/txcript/issues/52 Will test locally and implement the fix now.
solfox3 days ago
PRs up!
cat-whispererop3 days ago
Already merge #53, thanks for the assist.
cat-whispererop3 days ago
it's interesting to know that archived sessions are stored different as opposed to the codex cli and desktop app session.
general_reveal3 days ago
I was thinking about doing this. If we treat ChatGPT like your local llm server, you basically open up a browser session, intercept all traffic and stick a local OpenAI compatible rest server that mutilates your input upstream through the ChatGPT ui, and then intercepts downstream and pushes it out your server.
API call to server
Then
Server leverages chrome plugin to send your llm call through the plugin , through the ui, wait for response , intercept, repackage and reroute it back out as a server response.
Then that $20 sub stretches to all uses cases for a developer.
cat-whispererop3 days ago
That's a clever idea, and a different direction from where we are right now. Today it only goes one way, from chat into your coding agent.
The case I hit all the time is that an idea strikes on my commute, so I pull out my phone and start brainstorming in the Claude app. By the time I'm home I've done the research and chased down the tangents in that conversation. I open my laptop, use Skillsync to continue it in Claude Code, and start on the implementation.
deadbabe3 days ago
Good way to be banned
general_reveal3 days ago
How would they know? Only if you use a coding harness, but one could write their own harness with less obvious system prompts.
I’m not encouraging one do this. I mostly route between the free models on OpenRouter and OpenCode free models, and I mostly write simple apps where I can casually oversee even a small model and get awesome results.
But if you are out there spending 200 dollars a month, consider a few hacks, because that’s just overpriced. We are developers after all, they aren’t supposed to be able to trick us :)
Edit:
Piracy, with the above , would look like a universal server that routes between all provider UIs. That means the end user doesn’t even give a shit which provider it goes to, serious token usage, serious theft.
Someone could make this , I suppose. In a way, commodification is a clean solution to the inevitable theft. It’s better it just be so darn cheap and ubiquitous.
cat-whispererop3 days ago
isn't that what they did to opencode? when they were using the subs by reverse engineering their APIs
sdesol3 days ago
This is awesome! You solve an immediate need of mine for:
https://github.com/gitsense/chat/tree/readme-scale-knowledge
Since I only support Pi natively, your solution will make it possible for codex/claude/etc. users to discover their conversations in my app. Will definitely include this as workaround for making codex, claude and other sessions available for discovery.
cat-whispererop3 days ago
we publish a npm package of our core library too: https://github.com/skillsynchq/txcript
you can use that internally for this
sdesol3 days ago
Unfortunately I won't be able to use the npm as I need it for synching which is managed by https://github.com/gitsense/gsc-cli/tree/staging
The only thing that seems to be missing is synching but I have a workaround for that but it won't be near realtime. For example, Pi changes are usually a second or less behind the Pi session log.
With txcript, it will probably be 5 seconds which is fine since the use case will mostly revolve around discovery, organizing and inspection.
bhkdotdev3 days ago
this is awesome! i’ve been working on a tool for cross-harness integration tests - https://dynobox.xyz - and one of the hardest parts has been writing adapters for each harness since their transcript formats are all so different.
really excited to check out txcript… a shared translation layer could make my life sooo much easier!
Narsagna3 days ago
Thank you! let us know if you don’t see your harness / feel free to raise a pr
sean-regents3 days ago
check out Nvidia's version: https://github.com/NVIDIA/NeMo-Fabric
bhkdotdev3 days ago
will do! thanks!
bcorigliano3 days ago
This is good, I like it!! I've been mostly working with Claude and Chatgpt for separate stuff, however sometimes one of them is stuck and I could definitely use this to start a session with the other one and see if it figures it out.
Have you tested to see if there was any degradation happening when switching from one model to the other ? I mean some must be inevitable (maybe not!), but how much?
Narsagna3 days ago
Nars here, one of the co-founders. With longer sessions, the receiving agent sometimes decides to compact it. But the whole transcript still exists and is accessible
bcorigliano3 days ago
that's good to know, will try skillsync out when I get the chance!
cat-whispererop3 days ago
In some cases, harnesses try to obfuscate reasoning, but almost everything goes through.
marknutter3 days ago
Any word on when you'll add support for antigravity? I often switch between harnesses and models and subscriptions, both for work and personal stuff, this is an awesome idea. One thing I do that I don't think you have support for is running sessions on different machines. Do you have support for, or do you plan on adding support for, syncing across machines?
Narsagna3 days ago
Yes you can also ssh into your machines and sync all of those sessions too. Check out the + icon on the left side bar on the desktop app!
cat-whispererop3 days ago
we do support antigravity!
sujee3 days ago
Good idea. I’m working on something similar, but for regular AI chats: https://www.vinaa.ai/. Portability and organization are just as important for these conversations, since they become a personal knowledge base you may want to revisit years later.
Narsagna3 days ago
Fun fact, skillsync works with all kinds of chats :)
vira282 days ago
I use recall https://github.com/viggy28/recall for the following reasons:
1. It's tightly integrated with Pi 2. Creates context automatically from sessions 3. No external dependencies - sqlite and numpy
Narsagna2 days ago
Interesting, I love pi too!
voiceeh3 days ago
Very cool! I created something similar (with the same name), but in 2 tools. One to share skills (skillsync) and another to share context (contextsync).
I like to create a design with one model, sync it to another and iterate on it, then potentially go to another to apply/implement.
Narsagna3 days ago
Curious why you didn’t bundle them?
yoavfr3 days ago
This looks nice! I tried to tackle the same problem with https://usecontinuo.dev (writing my own translation layer) - but Skillsync looks much more powerful.
Narsagna3 days ago
Yeah I like how you have controls on how much of the conversation you want to bring into the next session!
pjm3313 days ago
If I were you I would look into maybe like analyzing sessions across harnesses? I’m not sure, some way to leverage this shared schema work that is not syncing
Because syncing is trivially solved by just telling the agent to keep a work journal in markdown
cat-whispererop3 days ago
We do that, and it's really the point of the portability work. Once every harness's sessions live in one schema, you can manage and search all of them in one place.
The markdown journal is a fair way to do it, and a popular one. It has a couple of limits though.
A journal comes out of a prompt, so it records one way of looking at the session. Whatever that prompt didn't ask about is gone, and you usually find out which detail you needed much later. But the raw session still has it.
Being able to unify the schema lets you do things notes can't. You can continue a teammate's session on your own machine, or pick up a claude.ai conversation in Claude Code or Codex. The new agent gets the transcript: all the decisions in the trajectory, not a summary of it.
Narsagna3 days ago
btw we also have an agent in the mac app that lets you analyze your sessions in all kinds of ways
agentdev0013 days ago
To say what the author said in another way- thats a garbage approach and completely misses the point. Sure, you can completely destroy the session by distilling it into a markdown- but thats like explaining what you did yesterday, vs having an immutable log of what you did yesterday.
Edwinat2313 hours ago
Ola
joas_coder2 days ago
This resonates with an adjacent problem I’ve been exploring: durable project provenance rather than live-session portability. I’m building PromptSourceCode for Codex Desktop; it preserves the human requests, corrections, and attachments as readable local history alongside the project: https://github.com/ironwood-lang/prompt-source-code. It deliberately doesn’t try to translate or resume sessions across agents. Does Skillsync expose stable session and turn identifiers that an external audit history could reference after translation?
Narsagna15 hours ago
can you explain what you mean by turn identifiers? It does allow you to audit the sessions and build your own systems on top after translation
btown3 days ago
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-whispererop3 days ago
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.
btown3 days ago
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-whispererop3 days ago
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
Narsagna3 days ago
> 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
bb-connor2 days ago
the shit they let into YC these days bruh
bks2 days ago
I suspect its about the people not just the pitch. The team seems experienced and have shipped useful products. Good luck to them
Narsagna2 days ago
ok
swyx3 days ago
kudos making the core open source. if you didnt do it, i wouldve. good luck
Narsagna3 days ago
Hahaa thanks :)
ccbakla2 days ago
[dead]
paultnylund3 days ago
[dead]