WorkBay
I move coding work between AI tools and sessions. While developing projects such as AltContext, I found that a recap could describe a task as nearly finished while leaving out the review finding that still blocked it. The next session needed the finding and its evidence, not just an account of progress.
I built WorkBay to keep that record outside the conversation. It stores the active task and the decisions made against it, along with review findings and test evidence. A later session can retrieve what remains unresolved, including when I change coding tools.
Keep a record the next session can use
Each repository has a SQLite database at .task-state/handoff.db. A task identifies the work, its branch, and its working copy. Decisions preserve their rationale. Review findings retain their severity and resolution status, while test records keep commands and results.
A session loads a selected context packet from that database. The packet gives it relevant recorded history without requiring the entire earlier conversation. Optional semantic retrieval can find an older decision when the new question uses different wording.
I keep retrieval separate from approval. Finding a similar earlier fix can help a session decide what to inspect, but it cannot close a review finding or authorise a merge. The retrieved record has to be considered against the code being changed now.
Resume in another coding tool
WorkBay exposes the database through Model Context Protocol (MCP) tools. Supported clients include Claude Code, Codex, Cursor, and VS Code Copilot. They can read the same project record even though they do not share a conversation.
This makes a change of tool less dependent on access to the previous tool’s transcript. It also helps after a long session has compressed its context: WorkBay can reload the recorded state from the database.
The continuity is limited to what was recorded. Authentication, available tools, and model capabilities still differ between clients, and unrecorded reasoning does not reappear. The useful property is that changing a coding tool does not mean abandoning the project’s accumulated task and review history.
Carry a review finding through to a change
An authoring agent can submit work to a reviewing agent without passing over its conversation. The reviewer writes findings against the task. When the author resumes, those findings are available to address rather than buried in a separate review transcript.
A finding carries commit references for the fix on the branch and its later merge. That lets another reviewer inspect the code history behind a reported resolution. The review gate checks for unresolved high- and medium-severity findings, including whether a finding has been explicitly deferred or otherwise given an allowed disposition.
I also moved routine task operations into commands that can run without a model turn. Creating a working copy, checking merge readiness, and closing a task do not need an agent to improvise the bookkeeping. Git hooks check the normal development path while they are installed and configured. An unrestricted shell can disable or bypass them; they are not a security boundary.
For self-contained work, WorkBay can hand a bounded task to another backend under a token cap. That worker does not merge its own changes. Review and merge authority remain outside the worker, so producing a change and accepting it are separate steps.
Review the interface as well as the code
A code review may miss a problem that only becomes apparent when the interface is considered as a sequence of screens and states. I use WorkBay’s UX-map workflow to inventory an existing interface or examine a proposed change. The inventory describes screen regions, the states they can show, and the actions and flows between them.
It can be rendered as ASCII screens, Mermaid flow diagrams, and Markdown. People and AI tools can inspect these representations against Heuristics Canon. Findings can then be attached to the task, addressed in implementation, and checked again after the change.
Validation checks whether the map has an acceptable structure. Rendering makes it readable, while critique considers the decisions represented in it. A limited automated check pack can catch an action pointing to a nonexistent screen. None of those operations implements the proposed repair or establishes that the interface will work for its users.
The public WorkBay repository contains the workflow instructions. The renderer and critique implementation belong to a companion Design Canvas package outside the public mirror. The VSW interaction reference shows how text drawings can accompany a product explanation.
Use and evaluation
I use WorkBay in my own development practice. Wider adoption and quantified effort savings have not been established. The useful evidence available so far concerns persistence, retrieval, and checks against the recorded state.
Project Memory Outside the Conversation explains the mechanism. Five Questions I Ask the Project Record follows its use, and Testing Whether Project Memory Saves Work sets out the proposed evaluation. Installation instructions and current package details are in the WorkBay repository.