How we built /share

Lore started as a social network for AI prompts and sessions: perhaps these would be the 2026 equivalent of open-source Github repos. The /share command was step 1.

We've since evolved away from the social network idea, but /share remains useful for us and our early users:

• We run it on every Claude Code session that creates a PR and add the Lore link to the corresponding PR for context.
• Our users use it to hand off work — one person starts an investigation, and then passes it to someone else (or a different agent) to finish.
• Some of our users are building their own skills/plugins as products distributed to their users, and use /share (or related components like our SDK) for observability on how well their products are working for their users.

A lot of detail goes into that seemingly-simple command: table-stakes stuff like finding the right file on disk, reconciling repeated shares, and auth (the other four-letter word); quality-of-life stuff like automatically copying the shared link, letting you specify a title for the shared thread, and letting you specify blocks that you want to highlight in the shared link.

Let's dive into how it's built and the lessons we learned along the way.

Architecture

/share is made up of three main layers:

• A skill, wrapped in a plugin, which is the command that users actually invoke (e.g. via /share in Claude Code or $share in Codex).
• A local MCP server that implements on-device functionality (reading session files; copying the output URL to clipboard).
• A remote MCP server that orchestrates our underlying API.

Plugin + Skill

/share is a skill; its source is on Github.

The first version of this skill just asked the agent to read its own session file and upload it to our API. This broke down quickly on real-world sessions: reading the session file immediately doubled the context usage of the agent, and that caused problems, especially when the agent tried to compact the resulting session.

We fixed this by adding a script that read a given transcript file from our computers' local filesystem and uploaded it; the skill would simply invoke this script. That script evolved into our CLI, and later into our local MCP server (more on this below).

Now we had a skill which depended on a script, and we wanted an easy way to install them both. We bundled them into a plugin; Claude and Codex provide built-in ways to install plugins. The plugin also namespaces our skills (so it's actually /lore:share and $lore:share), which was something that one of our early users requested.

Our plugin now comes with two additional skills:

• /read, which lets you prompt something like "look at what Matt did in thread th_123 and apply that on my system".
• /fork, which generates an intent-based summary of an existing thread. Instead of generically summarizing threads up-front, which indiscriminately discard information, many Lore features summarize content for specific purposes (some of which are baked in; some of which, like this one, are user-supplied).

Local MCP Server

Local script/CLI hit a wall when we went to add support for Claude Cowork: Cowork sessions ran into a sandbox (originally on your computer, now remotely by default). A script/CLI in this environment doesn't have access to your local filesystem, so it can't read transcript files.

Cowork uses the Claude Desktop app as a bridge to your local computer:

Local MCP servers bundled with plugins and desktop extensions run on your computer with the same permissions as any other program you run (Source)

We converted our transcript-reading code into a local (stdio) MCP tool named share_session, and bundled that into our plugin.

share_session finds the transcript file for your session on disk, uploads it to our server, gets back a URL, and then invokes a local copy command (e.g. pbcopy on macOS) to automatically put it onto your clipboard.

Importantly, the local MCP server is also responsible for authentication. It'll trigger a login flow when needed, and use that to retrieve and save a token to disk. Originally, we directly stored the OAuth access and refresh token we got back from our server, but refreshing auth tokens was unreliable and would occasionally require interrupting the user with a synchronous login flow. Fortunately, we had separately built an Upload API Key (UAK) system to support our SDK at the request of one of our users; we now programmatically generate a long-lived UAK upon initial login, and persist that value for future session uploads.

Hosted MCP Server

We technically didn't need the hosted MCP server … but we already had it, and it abstracts over our underlying API. For example, the remote share_session tool covers 11 steps:

1. Create an upload session.
2. Obtain a presigned storage URL to S3.
3. PUT the transcript bytes to that presigned URL.
4. Complete the upload session (which is the trigger for further server-side processing on the uploaded content).
5. Verify the content hash.
6. Create or update the thread.
7. Schedule parsing.
8. Apply title and visibility behavior.
9. Optionally wait for a background job to finish parsing the transcript and resolve a natural-language highlight.
10. Record plugin activation analytics.
11. Return a canonical absolute URL.

Abstracting that away server-side makes our plugin bundle smaller and easier to evolve.

Repo

The lore-plugin repo is on Github. It contains:

• the contents of our bundled skills;
• the source and built artifact of the local MCP server (a Bun binary); and
• manifests for a Claude and Codex plugin. We also have an plugin for Amp, although this is experimental and not yet supported outside of our team.

This repo is a subtree mirrored out of our private monorepo, in which we do all our development. This monorepo setup allows us to rapidly make cross-cutting changes across our whole product; more on this on a later post.

Where We're Going

Thread sharing is a foundational piece of what we're building at Lore, but there's a lot more to come.

We believe that agents and AI-native workflows are resulting in new primitives. Before AI, work revolved around constructs like meetings, files, and runbooks/SOPs; AI-native workflows introduce threads, skills, and artifacts. Some of these have analogs in pre-AI constructs; others do not (or at least, not entirely). In both cases, AI-native teams and individuals will need the right tools to work with these new primitives. We don't yet know exactly what this will look like (capabilities and workflows are changing very quickly at the frontier), but we plan on building — for ourselves, and for knowledge workers at the frontier of what's possible — and finding out.

If this speaks to you, give Lore a try and let us know what you think.