How to Set Up a Memory Bank So Cline Remembers Your Project

Set up Cline’s Memory Bank as a project-local rule plus a memory-bank/ directory committed to the repository. It gives Cline a repeatable place to reload the project’s current state after a new task or a compacted conversation—but only if you keep the files short, specific, and current.

The useful version is not an AI diary. It is a small operational handoff: what this system is, where the risky edges are, what changed, what is being worked on next, and how to verify it. If those facts are already easy to find in the repo, don’t duplicate them.

Put the instruction in the repo, not in your personal settings

Create .clinerules/memory-bank.md. Cline’s Memory Bank documentation recommends a Cline Rules file such as this one, rather than relying solely on global custom instructions. That matters because the rule travels with the branch, is visible in code review, and does not cause your service-specific conventions to leak into the next repository you open.

Start with this deliberately shorter rule. Cline’s official example is more exhaustive; use that if you want its complete workflow. This version is easier to maintain and makes the important behavior explicit: read the files before acting, and update them only after meaningful work.

# Project Memory Bank

Before planning or editing code, read every file in `memory-bank/` that is relevant to the task.

If `memory-bank/` does not exist, create it with the six core files described below. Do not invent product decisions: mark unknowns as questions.

When a task changes architecture, constraints, interfaces, deployment behavior, or the next implementation step, update the relevant Memory Bank file before finishing.

Keep entries concise and factual. Prefer file paths, commands, issue IDs, decisions, and verification steps over narrative.

When asked to "update memory bank", review all Memory Bank files, remove stale statements, and update `activeContext.md` and `progress.md`.

Commit that file. Don’t put it in a global configuration and hope everybody’s Cline happens to share the same instruction. Also don’t assume the rule is an enforcement mechanism. An agent can miss a rule, decide a file is irrelevant, or write a bad summary. The rule increases the odds of a useful workflow; your review still decides whether the repository now contains a false statement.

Initialize the six files, then cut what you do not need

Open Cline in the repository and say: initialize memory bank. The documented structure has six Markdown files. Keep that structure initially because it separates stable facts from the work-in-progress notes that change every session.

• projectbrief.md: scope, non-goals, users, and the constraints that should not be silently redesigned.
• productContext.md: the user problem and behavior that makes a change correct beyond “the test is green.”
• systemPatterns.md: architectural boundaries, conventions, critical data paths, and decisions worth preserving.
• techContext.md: runtime versions, package manager, local setup, commands, external dependencies, and operational constraints.
• activeContext.md: the task currently in flight, files touched, decisions still open, and the exact next step. This should change most often.
• progress.md: delivered work, remaining milestones, known failures, and verification still required.

For a small service, you can often merge productContext.md into projectbrief.md. For a mature monorepo, do the opposite: keep these six as an index and add focused files such as memory-bank/billing-webhooks.md or memory-bank/infra-preview-environments.md. A 1,500-line systemPatterns.md is just a README Cline has been instructed to reread at the least helpful moment.

Seed it with facts Cline cannot safely infer

The first initialization pass will produce generic prose unless you give it anchors. In the same request, provide the commands and boundaries you would give a new teammate on their first meaningful ticket. For example:

Initialize the Memory Bank for this repository.

Start by reading README.md, package.json, docs/architecture.md,
and .github/workflows/ci.yml.

Record these facts exactly:
- Node 22 and pnpm are required.
- `pnpm test` is the unit-test command.
- `pnpm test:e2e` requires Docker and is not run in the normal PR job.
- API schema changes require updating `packages/contracts` first.
- Do not add a database migration without a rollback note.

Flag anything else as an assumption or question rather than presenting it as fact.

Then read the generated files once. Delete boilerplate like “the goal is to build a robust, scalable application.” Replace it with something a future agent can act on: “Tenant resolution happens in apps/api/src/middleware/tenant.ts; unauthenticated routes must be registered before it.” That sentence has an owner, a location, and a failure mode.

Use it at handoff points, not after every tiny edit

Cline documents three phrases for the workflow: initialize memory bank, update memory bank, and follow your custom instructions. The last one is useful at the beginning of a fresh conversation: it tells Cline to reload the Memory Bank before it starts proposing edits.

My practical rhythm is to update after a merged vertical slice, a design decision, a failed debugging path worth avoiding, or right before switching tasks. On a multi-file refactor, ask for an update before you start a new task or intentionally reduce context. Then start fresh and say: follow your custom instructions; summarize the current task, open questions, and verification command before editing anything.

That last clause is a cheap check that the Memory Bank is doing work. If the summary gets the branch’s current state wrong, fix the Markdown first. Continuing anyway only lets the wrong fact become the premise for the next set of edits.

What a Memory Bank is bad at

It is not automatic durable memory. Cline is reading regular repository files, and regular files can be stale, contradictory, overlong, or simply skipped. It also does not replace tests, issue tracking, Architecture Decision Records, runbooks, or a README. Put durable policy in the document developers already use for that policy; have the Memory Bank point to it and state when it applies.

It is especially weak for rapidly changing facts: a live incident, a deployment status, a rotating on-call owner, or a third-party API response you have not verified today. Link to the source of truth or make the agent run the command. Don’t turn progress.md into a second, less trustworthy incident channel.

Finally, don’t ask Cline to read every historical decision for a one-line CSS change. The Memory Bank’s value is a compact working model, not maximal repository lore. If a file has stopped helping the agent choose the next safe action, split it, shorten it, or remove it.

Add one review step to your normal agent workflow

When Cline changes Memory Bank files, review them like code. Check that paths exist, commands run, decisions name the trade-off, and completed work is actually complete. A useful diff often removes text: yesterday’s next step should not still be today’s plan after it shipped.

Once it is in place, the everyday loop is simple: begin a new task by having Cline read the bank, do the implementation work, run the relevant verification, and request an update before the context or task disappears. It takes less attention than re-explaining the repository every morning, and it gives the next developer—or the next Cline session—a starting point you can inspect in Git.