cursor-memory-bank: a six-command workflow for Cursor 2.0

What cursor-memory-bank is for

Cursor's chat loses context between sessions, and a long task spread over several days has no record of how the earlier decisions were reached. cursor-memory-bank addresses that by making the assistant write to files. Each phase of work reads from and updates a shared memory-bank/ directory, so the state of a task survives a restart of the editor and a change of model. The README describes it as a "token-optimized, hierarchical task management system" built on Cursor 2.0 commands.

The audience is narrow. You need Cursor 2.0 or higher, because the workflow depends on the commands feature rather than the older custom modes. The author recommends Claude 4 Sonnet or Claude 4 Opus, particularly for the /creative command. If you work in a different editor, or you want a tool that manages context for you rather than one that asks the model to maintain files, this is not the right fit.

Six commands and the memory-bank/ directory

Version 0.8 replaced Cursor custom modes with commands. The README lists six: /van initializes a project, detects the platform and decides task complexity; /plan produces an implementation plan at that complexity level; /creative explores design options where a decision is needed; /build implements; /reflect reviews the finished work and records lessons; /archive writes documentation and updates the Memory Bank. They are meant to run in that order, and the README calls them "interconnected nodes in a development workflow."

The shared state lives in memory-bank/. The repository's process map names tasks.md, activeContext.md and progress.md, plus creative/ and archive/ directories. Every command reads and writes those files, which is what carries context from one phase to the next instead of relying on the chat transcript.

The other half of the design is rule loading. The README states that version 0.7 introduced hierarchical rule loading, where only essential rules load at first and specialized rules are lazy-loaded, with a figure of about 70 percent token reduction. The mechanism is plausible: a UI task and an architecture task should not both pay for the same rule set, and the README mentions architecture versus UI/UX design as an example of rules loaded only when needed. The number itself comes from the project's own optimization document, not from an independent measurement, so treat it as the author's claim. Complexity is graded in four levels, and the documentation requirements scale with the level.

Installing cursor-memory-bank in your project

The README gives one prerequisite pair: Cursor 2.0 or higher, and a Claude 4 model. Installation is a clone into your project directory.

git clone https://github.com/vanzan01/cursor-memory-bank.git

The README also documents a manual route: extract the ZIP and copy the .cursor folder into your project, since it contains both the rules and the commands. The custom_modes folder is kept for reference only. The remaining markdown files in the repository are explanatory and are not required for the system to run; the README suggests copying them into a folder such as memory_bank_documents if you want them nearby.

After that, the README states that commands are ready immediately with no additional setup. Typing / in the Cursor chat should list them, starting with /van, /plan and /creative. A first real use is to open a project, run /van, and read what it writes into memory-bank/: the initialization, the detected platform and the complexity level it assigned. That output is the input to /plan, so check it before continuing. If /van misjudges the complexity level, every later phase inherits the mistake.

Where the workflow breaks down

The author's own note is the first limitation. Memory Bank is described as a personal hobby project developed for the author's own use, with no issues tracker and no active feedback collection. That is not a disclaimer at the bottom of the page; it is a statement about how the project is run. There is no support channel to escalate to, and the README's answer is that you ask Cursor to modify the rules yourself. If your team needs a maintainer to respond to a bug, this is the wrong tool.

The releases reinforce the point. The most recent is 0.8-beta, published on 2025-12-05, and the two before it are also beta releases. The repository was last pushed on 2026-05-26, so the code has moved since the last release, but the released artifact is a beta.

There is also a structural dependency worth naming. The workflow assumes the model will faithfully read and update files across six phases. The README does not document a validation step that checks whether memory-bank/ was actually updated, nor does it describe rollback if a command writes a wrong plan or a wrong design decision. The files are ordinary markdown, so you can correct them by hand, but nothing in the documented design catches the error for you. And because the whole system is a set of Cursor rules and commands, it does nothing outside Cursor.

How it differs from Cline's Memory Bank and MCP memory servers

The related searches show people comparing this with Cline's Memory Bank and with memory MCP servers, and the difference is in where the workflow lives. Cline's Memory Bank is a set of rules that the assistant follows inside Cline; the memory is a convention the model is instructed to maintain. cursor-memory-bank does the same thing for Cursor, but adds the command layer on top: /van, /plan, /creative, /build, /reflect and /archive are explicit entry points, so the phase you are in is something you choose rather than something the model infers.

A memory MCP server takes the opposite approach. It exposes memory as a tool the model calls, and the storage is a service rather than markdown files in your repository. That can give you retrieval across projects and a single store, at the cost of running and configuring a server. cursor-memory-bank has no server: the state is files you can read, diff and commit alongside the code. For a solo developer that is the advantage. For a team that wants shared memory across machines and editors, it is the limitation, because the files only exist where you put them.

Maintenance, upgrades and licence

The upgrade path is documented but thin. The repository contains memory_bank_upgrade_guide.md and COMMANDS_MIGRATION.md, and the latter exists because 0.8 moved the system from custom modes to commands, which is a breaking change to how you invoke it. If you have an older setup, the migration document is the one to read before pulling. The RELEASE_NOTES.md file covers the version history, and MEMORY_BANK_OPTIMIZATIONS.md explains the token work introduced in 0.7.

The practical cost is that the rules are yours to maintain. Since the author does not run an issue tracker, a rule that misfires in your project is a rule you edit, and those edits live in your copy of .cursor. That means upgrades are a merge problem rather than a package update: you compare your modified rules against the new ones. The repository does not document a mechanism for that, so plan on doing it by inspection.

The repository does not state a licence. The README does not mention one and no licence file appears in the top-level entries, which is a gap you should resolve before using the rules in a commercial codebase, since the default position without a stated licence is not the same as a permissive one. That is a question for whoever handles legal matters where you work, not something to settle from a README.

Editorial conclusion

Adopt it if you already use Cursor 2.0 and want a written record of what the assistant decided across a multi-step task; skip it if you need an issue tracker, a support commitment, or a workflow that works outside Cursor. Before relying on it, clone the repository, read the .cursor folder to see which rules each command loads, and check that /van detects your platform correctly, because the author states the project is maintained for personal use and expects you to edit the rules when they do not fit.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. vanzan01/cursor-memory-bank on GitHub