whutlichao/worksplice

中文文档
pi gives you one session at a time. worksplice puts several of them in one local room — and adds the three things that keep a room from going wrong: **who has read what, who may write, who verifies**.
**Run it locally:** npx worksplice · Star on GitHub
It is a local workspace for collaborating with persistent pi coding agent sessions: channels, a task board with review, reminders, and an inbox-cursor wake model — plus a browser workspace for session browsing, real-time chat, model configuration, skill management, and project file preview.
What This Is
One agent, one conversation, one working directory is a good default — and a hard ceiling the moment a second agent shows up. Two agents pointed at the same checkout do not fail loudly. Each one believes it is the only actor, each plan is valid against the version of the repo it read, and the human ends up merging two diffs that each look correct alone.
worksplice does not replace pi. It puts several pi sessions into shared channels, and adds the handful of semantics that multi-agent work needs but that message passing alone cannot give you:
- **Wake, not push**: a hint tells an agent that something moved without carrying the body, so a wake that turns out to be irrelevant stays cheap.
- **A cursor, not a list**: each agent records how far it has read, so "what have I already seen" survives a restart instead of being re-derived from the log.
- **Freshness on concurrent writes**: every write states which version of the room it was based on. If the room moved first, the write is held and the author chooses what to do instead of silently overwriting.
- **Review before done**: a task is not finished because its author says so. It moves through a state machine, and approving it requires someone other than the author.
worksplice is deeply dependent on pi. It reads pi's session files, drives pi's agent sessions, and takes pi's config, model, and skill model as given. It is not a general-purpose agent framework, it does not bring its own runtime for running agents, and pointing it at a different coding agent means replacing the substrate rather than swapping a plugin.
When to use it
- You run more than one pi session against the same repository and they overwrite each other.
- You want one agent to hand work to another without you relaying it by hand.
- You want a review trail: who claimed a task, who approved it, what was decided and when.
- You want a UI for a directory of existing pi sessions instead of reading ~/.pi/agent/sessions by hand.
When not to use it
- You work with a single agent in a single directory. The pi TUI is enough, and worksplice only adds a server to keep running.
- You are not running pi. There is no adapter for another coding agent.
- You need several people to reach it over the internet. It binds to loopback by default and is built for a machine you trust.
- You want hosting, accounts, or a shared database. This is a local workspace over one SQLite file.
How It Relates to Other Tools
worksplice sits at a different layer from tools you may already use. agent-chat deliberately stays a peer-to-peer messaging layer — discovery and transport, no orchestrator. Parallel terminal managers (vibe-kanban, claude-squad) answer a different question: how to run many agents at once. worksplice answers a third one: what has to be true for several agents to share one repo without overwriting each other — or rubber-stamping each other's work.
| Question | The usual answer | worksplice |
| --- | --- | --- |
| What does a wake carry? | The message body, pushed at the agent | A hint — {agentId, targetId, seq} — and the agent reads the room itself |
| How does an agent know what it missed? | "The last message", or re-reading everything | A durable cursor: reading does not advance it, an ack does |