GSD Task Manager: a task list your agent can read too

What is different

A task app is something a user uses on a screen. When you want to hand tasks to an agent, the most common way is a single markdown file the agent edits, and the first comment on the Show HN thread said as much. A reply added that todo.txt works for humans and robots alike. One file is simple, but it has no structure. Whether something is urgent or important lives only in the writer's head, and what the agent changed is known only after it changed. The app the user works in and the file the agent sees live apart.

GSD Task Manager leaves the app the user works in as it is and gives the agent access to the same app. The browser app places tasks in a matrix with urgent and important as its two axes, and the MCP server opens the same list as 19 tools: 7 read, 5 write, 5 analytics, 3 system, and all five write tools take dryRun and show the outcome before applying it. When the agent creates or moves a task, the change is validated against a schema, and the user sees it in the same matrix. Instead of a markdown file, it offers validated tools and the structure of a matrix.

There is a condition. The user and the agent look at different stores. The browser app keeps every task in IndexedDB, the browser's local database, and works with no account and no server. That is why the header says "Saved locally". The MCP server is a Node process, so it cannot reach the browser's IndexedDB, and it connects only to the optional PocketBase sync server, a backend shipped as a single binary. The design record ADR 0005 states this limit and the alternatives weighed: a browser extension, reading IndexedDB through WASM, a localhost WebSocket server. All three were dropped for a separate package over stdio transport. What this idea buys is letting the agent read and write the task list a user already uses, with the same tools. The condition is giving up local-first and running a sync server.

How it was built

669 commits run from 2025-10-04 to the day before. 188 of them carry Claude in a Co-authored-by trailer, and the label moves from Claude Opus 4.5 through 4.6 and 4.8 to Fable 5.1. 17 carry Cursor Agent, 12 Copilot, and 7 Devin. The repository root has CLAUDE.md, AGENTS.md, .claude and .codex directories, and the design decisions are recorded in seventeen ADRs. The README does not describe how it was built.

Running it

bun install took 4.7 seconds, and bun dev started the app straight away. With no account and no key I created four tasks, and they were still there after a reload. In the meantime, all 205 requests the browser sent went to localhost. A task typed with no marker lands in "Eliminate", and only a trailing * sends it to "Schedule". The default for quick capture, in other words, is "discard". I built the MCP server with tsc, connected over stdio, and fetched the tool list. There were 19, not the 20 in the design record; list_devices is gone. With no backend, calling create_task with dryRun returned a preview, and get_sync_status returned healthy false. So the agent side starts, but without a sync server and an OAuth login it cannot read a single task. The README's three claims all held; the only discrepancy is the tool count, 19 in the README and 20 in the ADR. The static build took 38 seconds and produced 4.3 MB.

connected in 274 ms; tools: 19
create_task dryRun -> DRY RUN - Task would be created (not saved)
get_sync_status -> "healthy": false, "authenticated": false

Not checked

Standing up PocketBase, logging in with OAuth, and writing real tasks through the MCP tools was not possible in this environment. The next place to look is the last-write-wins conflict handling in lib/sync/ (ADR 0003), to measure which side survives when an agent and a user edit the same task at once.

Verdict

It runs. The app is two commands and stays local, but for an agent to see the same list, a sync server and an OAuth login come first. It fits when you want to sort priorities in a matrix in the browser and the agent connection can wait. If what you want is an agent managing your tasks, a single markdown file does it with less setup. This product beats that only once you are willing to run the PocketBase sync server yourself.