Built Before Any of This Existed
Todo-mcp was created in a different world. There was no auto-memory. The CLI's task tool was called TodoWrite. Skills did not exist as a concept. Context windows were smaller. The problem was simple and urgent: Claude forgot everything between sessions, and there was no way to persist working state.
Since then, every piece of the landscape has shifted. Claude Code shipped auto-memory — a file-based memory system that auto-loads every session. TodoWrite was renamed to TaskCreate. Context windows expanded. The MCP ecosystem grew. And most recently, skills emerged as a methodology layer for maintaining disciplined, repeatable workflows.
A tool built for the old world should be obsolete by now. Todo-mcp is not. It is more capable today than when it launched — not because it ignored the changes, but because it absorbed each one.
The Pattern: Friction Reveals Requirements
Every version of todo-mcp has followed the same arc. The platform changes. Real usage reveals friction. The friction reveals what needs to adapt. The tool adapts.
This is not a roadmap-driven process. Nobody sat down and planned a four-system architecture or a skills layer. These emerged from using the tool on real projects — seven of them, across hundreds of sessions — and hitting walls that demanded solutions.
The pattern has repeated four times now:
| What changed | What friction it created | How todo-mcp adapted |
|---|---|---|
| Context windows compacted unpredictably | Working state disappeared mid-session | Persistent SQLite store with cheap, durable writes |
| Claude shipped auto-memory | Lessons lived in the wrong system, invisible across sessions | Four-system architecture — each type of state in its correct home |
| Projects grew longer and more complex | Crashes destroyed in-flight progress | Write-ahead breadcrumbs — crash recovery in seconds, not minutes |
| Workflow patterns stabilized across projects | Maintenance discipline drifted between sessions | Skills — versioned procedures that keep the store trustworthy |
Each row is a chapter. Each chapter made the tool more capable than the last. The tool that exists today could not have been designed upfront — it required living through each shift to understand what the next adaptation needed to be.
What Skills Changed
Before skills, todo-mcp was a reliable store with an unreliable operator. The database never lost a byte. But the process of maintaining that database — updating breadcrumbs at the right moments, cleaning up completed tasks, filing lessons into auto-memory, replacing stale sprint-resume notes — depended on the agent remembering to do it. Across sessions and model switches, it often did not.
The result: breadcrumbs went stale. Completed tasks sat open. Sprint-resume notes accumulated instead of replacing each other. The store was trustworthy at the storage level and untrustworthy at the process level.
Skills fix this by externalizing the discipline. A skill is a versioned procedure the agent reads and follows — the same steps, in the same order, every time. The agent does not need to remember the choreography because the skill spells it out.
The iron rules that skills enforce:
- One task in progress at a time. No ambiguity about what was active after a crash.
- A progress breadcrumb for every active task, updated every meaningful step. The write-ahead log stays current.
- On completion, the task closes and its breadcrumbs are cleaned up. No orphaned state for future sessions to sort through.
- A new sprint-resume note replaces the old one. Auto-memory stays current, not cluttered.
None of these rules are new — they existed as conventions before skills formalized them. What changed is that they are now encoded in reusable procedures that work the same way across every project, every session, and every model. The discipline stopped depending on memory and started depending on protocol.
From Store to System
This is the shift that skills represent. Todo-mcp started as a persistent store — a place to put things so they would survive. With four systems dividing state by purpose and skills maintaining each system with consistent discipline, it is now a self-maintaining workflow engine.
The difference matters practically:
- Before skills:
context_resumereturned whatever the last session happened to leave behind. Sometimes accurate. Sometimes stale. You had to verify. - After skills:
context_resumereturns a state that was maintained by the same protocol every time. You can trust it.
That trust is what makes features like model switching and multi-day projects practical. If you cannot trust the store, switching models means re-verifying everything. If you can trust it, switching models is seamless — the new model reads the same trustworthy state and continues.
Why It Survived
Most developer tools are built for a snapshot of the ecosystem. When the ecosystem moves, they become legacy. Todo-mcp has survived four major platform shifts for one reason: it was built by someone who uses it every day on real projects.
That is not a marketing claim. It is the development methodology. Seven projects. Hundreds of sessions. An 875-line friction log documenting every pain point and every adaptation. When auto-memory arrived and lessons stopped auto-loading, the person who felt that friction was the person who could fix it — because they were the same person.
This is why the tool adapts instead of becoming obsolete. The feedback loop is immediate: use it, feel the friction, fix it. No feature request queue. No product committee. Just the gap between what the tool does and what the work demands, closed as fast as it opens.
What Didn't Change
Through four adaptations, the core has stayed the same:
- Local SQLite database. Your data never leaves your machine. No cloud dependency, no latency, no privacy concerns.
- MCP protocol. The same tool interface that worked on day one still works today. Existing installations keep working through every update.
- Permanent task IDs. A task referenced as
#42six months ago still resolves today. References in commits, conversations, and documentation stay valid. - The friction-driven philosophy. Every feature earned its place by solving a real problem encountered in real use.
The surface has grown. The core has not changed. That stability is what lets the tool evolve without breaking the workflows built on top of it.
The Story Continues
If the pattern holds — and after four cycles, it is reasonable to expect it will — the next adaptation is already forming. Some shift in the AI coding landscape will create friction that does not exist yet. That friction will reveal a requirement. And todo-mcp will adapt again.
That is the answer to "why is a tool built before auto-memory still relevant?" It is relevant because it was never frozen in the moment it was built. It was built to evolve — and it has, every time the world asked it to.
If you are evaluating whether to invest in a tool for your AI coding workflow, this is the question worth asking: when the platform changes — and it will — does this tool change with it? Four chapters in, todo-mcp's answer is documented.
The friction log continues.