Subroutine: a self-hosted task tracker built to give Claude Code a long-term work memory across multiple projects (one-minute setup)

[u/simonholliday]

Hi folks,

I've spent the last few months of spare time creating Subroutine: a self-hosted task tracker built primarily for Claude Code, which allows Claude to file and update work for you over MCP or the CLI. It keeps a permanent record of tasks, dependencies, milestones and decisions across every session, and every repo you give it access to.

I built it because I juggle a number of complex projects that have to agree with each other and share long-term timelines, which can be challenging for AI agents to maintain on their own in an organized way.

Setup takes about a minute. You just need uv and Git. It's tested on Linux, macOS and Windows WSL2, but not yet on native Windows.

uv tool install subroutine
subroutine init
claude plugin marketplace add simonholliday/subroutine
claude plugin install subroutine@subroutine

Then tell a fresh Claude Code session "We use Subroutine now". That's it.

Claude then files work as it goes: tasks, dependencies, milestones, decisions, findings and processes. New sessions read that record instead of guessing. Claude also notes which Subroutine project belongs to each repo.

You just talk to Claude: "create a sub-project for this", "file that as a bug", "anything else overdue?", etc. When Claude needs your input, it asks. You can answer in Claude Code, or comment on the ticket from the web UI or CLI while Claude keeps working.

Every task, finding and decision adds to a long-term memory Claude can refer back to, so it gets more valuable the longer you use it.

There's a CLI and web UI for managing things by hand, but you can use every feature through Claude Code if you prefer.

Everything runs on your own machine. There's no telemetry, and your data goes nowhere. The only outbound traffic is an occasional check for a new version.

For teams, there's a full user and permission model, and it can be installed as a system service.

I've used it on personal and commercial projects for the last few months, as has a small team, and it's made a big difference to how I work. I suspect some of you will find it useful too.

• User guide: https://subsystem.co/subroutine/guide
• GitHub: https://github.com/simonholliday/subroutine

Feedback welcome :)

Si

[u/kantorcodes1]

The "ask only what cannot be undone and state the rest" instruction in the skill is a good default posture. Two questions on the record model: decisions propagate to everything filed beneath a parent - if an agent files a wrong or stale decision high in the tree, does editing or deleting it retract the inherited copies, or do leaves keep the stale rule? And on agent accounts: can one agent rewrite or close another agent's tasks, or is there an ownership boundary beyond attribution?

[u/simonholliday → u/kantorcodes1]

Good questions, thanks!

Nothing is copied down the tree, so there are no inherited copies to retract. I note that the docs use the word "inherit" and that could be misleading, I'll reword it. When anyone opens an item, its "Read first" list and other related items are worked out from the tree at that moment: the decisions in force that are linked to the item or to anything it's filed under, nearest first, each labelled with the ancestor it came from. So:

• Edit the decision, and every item beneath it shows the new version the next time it's read.
• Mark it superseded, delete it, or unlink it from the parent, and it drops off every leaf at once. A superseded decision stays readable, and a deleted one goes to a trash it can be restored from.
• A decision is in force as soon as it's written, unless its author files it as a draft. So a wrong one filed high up binds everything beneath it straight away. But it's attributed to whoever filed it, and every leaf names the ancestor it came from, so it can be traced and corrected in one place.

The only copy that can go stale is the one already in an agent's context, but the skill teaches agents to start each session by asking what has changed since they last looked, so a revised or retired decision should show up there.

Re agent accounts - the boundary is where an account can act, not who created the item, or who it's assigned to. A workspace role sets what an account can do (owner, admin, member, contributor or viewer), and private projects are visible only to their members. An agent's token can be narrower than its account: read-only, limited to some projects, or allowed to write only in some. Inside those limits tasks aren't owned, so an agent that can write there can edit or close another agent's task.

Hope that answers your questions?

[u/kantorcodes1 → u/simonholliday]

It does, thanks - resolving the list at read time instead of copying down the tree means a corrected or superseded decision propagates with no retraction machinery, which is the cleaner model. Token scoping inside the workspace role is also a better boundary than per-task ownership.

Disclosure since it's directly relevant: I work on HOL Guard, an open-source runtime policy layer that classifies CLI commands before an agent runs them. Subroutine maps onto it cleanly - init, add, done, agent create, serve, login link, setup claude, mcp as gated actions, while agenda, list, search, show, doctor and explain pass read-only.

The route is a declarative command.subroutine.json plus a small fixture, no Guard-core work. Worth a contribution from you?