Alex Bristow

mdplane

A shared markdown worklog for people and coding agents. Tasks, claims and blockers stay in one file that everyone can read.

Year
2026
Type
Open source product
Website
mdplane.dev ↗
The worklog as a task board, with claims and blockers visible.

A file people could work in together

I wanted to send a markdown file to a friend so he could open it in Claude Code. The tools I found either rendered it badly, plastered it with ads or made it public. I started building a better way to share one.

The file-sharing idea grew arms and legs. I got interested in what agents would need to work together: a way to claim tasks, raise blockers and leave answers where everyone could find them. That became mdplane, a shared worklog.

The file is the interface

At the time, agent work could end up scattered across prompts, terminal output and local files. Handing a task to another agent on a different machine meant piecing that state back together. Markdown made sense because coding agents already read and write it, and I could inspect the same file myself.

I built workspaces around those files. A file held the brief and constraints at the top, while new work accumulated below it. I kept that activity append-only because silent edits are bad for coordination. mdplane turned the history into a board where I could see what was claimed or stuck. The file stayed readable without the board.

The service also handled permissions and emitted events when work changed. A separate watcher picked up an event, ran an agent and appended the result. I could change the agent or the way it ran without changing the shared worklog.

StackNext.js, TypeScript, Bun, Elysia, SQLite, Drizzle ORM, Tailwind, WebSockets, OpenAPI, BetterAuth, Railway

Context stays at the top; new activity collects below it.

The agents needed checking

I built mdplane with coding agents in late 2025. Claude Code, Codex and OpenCode wrote most of it; I directed the work and reviewed it. It took a month, roughly 2,000 commits and 5,000 prompts. Agents are a bit better now, so I wouldn't use those numbers to judge what they can do today. At the time, the idea that one could build a serious app in one shot felt miles away from what I was seeing.

Routes, query params and response shapes kept drifting apart. Opus 4.5 even called a half-migrated change bulletproof. I made OpenAPI the source for generated types and docs, then added checks for route coverage, enums, query params and docs drift. Thousands of tests backed the contracts up because I stopped trusting a confident summary very early on.

I also had to think about how a public service like this gets abused. Claims expire, writes are idempotent, capability links have narrow permissions and file paths are checked for traversal.

I rewrote the docs several times to make the workflow understandable.

Where I'd put it now

Coding agents now handle much more of this coordination themselves. If I started again, I'd put the worklog inside the coding tool rather than ask people to adopt a separate service. I still like the append model because I can see who claimed a task, what blocked it and what happened next. I'm keeping mdplane online as a record of the idea.