When you say "context" do you essentially just mean skills? Like everything that goes to an agent is prompt right? So you want to know how we are managing a library of prompts (which the industry calls skills) so we don't type the same thing over and over?

I created skillzmouse to do this:

https://bitbucket.org/workingsoftware/skillzmouse/src/main/

It's a git backed tool with a custom protocol that can be externally accessed over a Cloudflare tunnel.

You an connect your sm client to any endpoint, and each endpoint runs a server inside a git repo, so you can have as many separate instances per client as you like, just switch your ~/.skillzmouse.json file and it will point to a different server.

It also has a script distribution and patching system. Skills and scripts constitute what I would refer to as my "standard operating procedures" which broadly transcend harness (and I have used this with multiple harnesses).

It "plugs in" by including a header at the top of AGENTS.md that tells the agent how to use it, and the first step is for the agent to load the agents skill, which is a bunch of stuff applicable everywhere, and then that also builds the skills header describing the list of skills, and then skills can refer to libs which are not listed and can be loaded on a case by case basis.

I am not using it with multiple harnesses anymore though because I built a harness, which integrates skillzmouse and has "factory workflows" that are loaded as skillzmouse scripts. My harness can be described as "deterministic control of intelligent agents", ie. the agent can't spawn sub agents, the agents can't talk to each other, and the workflow scripts can build and pass context in a deterministic way between sessions that are created during the execution of a given workflow.

But you could use skillzmouse in any harness. I've used it in pi, Junie and Kimi Code. Junie CLI had problems with compliance.