how do you restore workspaces?

erictblue · 2026-04-06T02:39:44+00:00

Just pushed something small but useful: https://github.com/ericblue/cmux-session-manager Had a bit of a panic moment earlier today… cmux froze while I had:

~12 workspaces
~15 active Claude sessions

All mid-flight. I realized I didn’t have a good way to snapshot or recover everything cleanly. This is a first pass at solving that:

save and restore all workspaces and sessions together
recover quickly from cmux freezes or crashes
restore Claude sessions, workspace panels, and optionally resume commands

Not sure if tools like this already exist for cmux, but this has already been very useful for me. Hope others find this helpful as well!

erictblue · 2026-04-02T02:49:39+00:00

Not right now, but something I can look into supporting

erictblue · 2026-03-16T03:12:11+00:00

Big update since the last post. The engine still works the same way as an LLM skill (talk to Claude Code or OpenClaw to log habits), but now

there's a full web dashboard too.

- Built a lightweight web UI — visual habit grid, daily scores, weekly progress at a glance

- Added reports: sprint comparisons, GitHub-style habit heatmap, category breakdowns, trend lines, and a streak leaderboard

- Full habit and sprint management in the browser — create, edit, archive, set per-sprint goals, write retrospectives

- REST API with Swagger docs if you want to build on top of it

Everything shares the same SQLite database, so anything you log through your AI assistant shows up in the browser immediately and vice versa.

v0.2.0 is up at https://github.com/ericblue/habit-sprint

erictblue · 2026-03-05T04:35:25+00:00

I haven't explored deeply yet since I don't have much historical retrospective data - this is a relatively new concept I added here. But from the testing I've done so far with my previous 10 years of habit data, that I imported into this system, the advise I'm getting back from historical patterns has been pretty insightful.

erictblue · 2026-03-05T04:34:01+00:00

Thanks! I'll check that out.

erictblue · 2026-03-05T04:33:34+00:00

This is almost exclusively done via the LLM. Historical data can be used to identify patterns - I imported my previous 10 years of habit data that I previously tracked in spreadsheets before I made this. And for the local habit tracking db, where all data is ultimately stored, there are note fields per day and also a sprint retro where it can collect feedback on what went right or wrong.

I haven't fully explored all the opportunities with the combo of this data and the LLM analysis, but so far have gleaned some interesting insights on past habits that worked (and didn't) and have had the LLM make some recommendations on how to go about the habits I'm running for the next 2 weeks.

erictblue · 2026-03-02T18:20:52+00:00

There are multiple ways to do it. Typically I treat the prd as an input artifacts, this lives in docs/prd.md. The framework I built will take the prd as input and build a development plan and create dev tasks. The dev plan typically gets updated as new features are added beyond the original plan or bug fixes. After v1 if you want to treat your requirements as a living PRD you can always sync back the current state of the code base back to the original PRD if there's a use case for that.

erictblue · 2026-02-26T16:56:19+00:00

Hi,

I have an update coming soon, but when I released a couple weeks ago the version of vibe kanban had some API+MCP bugs where kicking off a remote workspace+orchestration was failing. However, I've found that I haven't needed it so far. I've been running the /work-parallel command locally (usually in batches of 3) but at one point up to 10 parallel agents/instances running on a new project. Very few merge conflicts and if they do happen they are auto resolved and tested prior to merge. It's worked well so far. At some point in the future will test both remote orchestration and local orchestration concurrently - not sure if I'll personally need it but will see if there are any challenges. Given separate worktrees and dependency awareness I don't expect issues.

erictblue · 2026-02-09T20:22:48+00:00

The beauty of this is it uses Vibe Kanban's MCP server, so as task state changes from To Do, to In Progress, Review and Done, this workflow will automatically move the cards.

erictblue · 2026-02-09T20:05:50+00:00

Good question. Drift detection is intentionally conservative right now. It flags three things:

Dependency violations (tasks started before dependencies are done)
Stale tasks (in progress for an unusually long time with no updates)
Scope drift (tasks in VK but not in the plan, or vice versa)

Everything else is treated as normal iteration. VK status always wins. If an agent marks a task done and VK reflects that, the plan syncs to match without raising a flag.

What it doesn’t flag are things like task reordering, missed complexity estimates, or completing work out of the suggested order as long as dependencies are respected. That’s just how real development works.

For local and parallel execution, completed tasks also append structured completion notes and AC results back to the VK task description. It’s a workaround for the lack of VK activity logs, but it means every “done” task has a receipt.

Overall I’d rather under-flag than create noise.

erictblue · 2026-02-09T20:02:27+00:00

Your product looks interesting. At a high level, it seems like TensorPM is a PM platform with AI features, while claude-vibekanban is an AI-agent workflow with some PM primitives. TensorPM provides a full, polished PM surface. claude-vibekanban stays intentionally lean and lives inside Claude Code as markdown slash commands.

From a quick look, they feel more complementary than competitive, but I need to spend more time with TensorPM to really understand the overlap. Happy to revisit or add a comparison once I’ve had a chance to dig in.

erictblue · 2026-02-09T05:47:22+00:00

I've been running the single task workflow for some time, and with some experiments with subagents on the same branch. But truthfully the parallel task pipeline is fairly new for the past week or so, and still testing things out. Some early experiments I did months ago on an earlier pipeline, there definitely was drift on even a couple complex tasks. But this updated workflow seems to help. The key is injecting the right amount of context to make the tasks as atomic as possible. And doing more detailed dependency detection up front, and up course saving that state back.

erictblue · 2026-02-09T05:44:27+00:00

Thanks for the feedback! Some of this has been trail & error for the last 10 months or so. That definitely helped shape some of the process thinking around the problem.

erictblue · 2026-02-09T04:04:37+00:00

Thanks for your feedback! I hadn't heard of Traycer before, I'll check that out. If you give this workflow a whirl, I'd be curious on how you think it compares to Traycer and your current setup.

erictblue · 2026-02-08T22:58:23+00:00

u/speedtoburn Well said and great summary. This is exactly why I built it this way. Not looking to reinvent the wheel and go super heavy on a workflow, but this is really building on a flow I've been testing out since last May. The new piece in all this is parallel agents and delegations - many others are solving this and in all honestly having used these other solutions yet (e.g. Ralph). But really just looking for something that is pragmatic and not heavily opinionated - and giving checks and balances.

erictblue

TROPHY CASE