Memory Bank

Structured project documentation that lets Cline maintain context across sessions.

Memory Bank is a documentation methodology that gives Cline persistent memory across sessions. Because every AI session starts fresh, Cline would otherwise lose track of what you built, why you made certain decisions, and what still needs doing. Memory Bank solves this by storing that knowledge in structured markdown files that Cline reads at the start of each task.

Quick setup

1. Copy the custom instructions

   Copy the Memory Bank custom instructions at the bottom of this page.

2. Add to Cline

   Paste the instructions into Cline Settings → Custom Instructions, or save them to a .clinerules file in your project root.

3. Initialize the Memory Bank

   Open a new Cline task and say: initialize memory bank. Cline will create the memory-bank/ directory and populate the core files.

How it works

Memory Bank files are regular markdown files stored in your project. Both you and Cline can read and edit them. They’re organized hierarchically so that each file builds on the others:

memory-bank/
├── projectbrief.md      # Foundation document — goals and requirements
├── productContext.md    # Why the project exists and what it solves
├── activeContext.md     # Current focus, recent changes, next steps
├── systemPatterns.md    # Architecture, design patterns, component relationships
├── techContext.md       # Tech stack, setup, dependencies, constraints
└── progress.md          # What works, what's left, known issues

projectbrief.md is the foundation. Everything else builds on it. activeContext.md changes most frequently — it’s where Cline tracks what you’re working on right now.

Core files

File	Purpose
projectbrief.md	Foundation document with core requirements and goals
productContext.md	Why the project exists, problems it solves, UX goals
activeContext.md	Current focus, recent changes, next steps (updates most often)
systemPatterns.md	Architecture, design patterns, component relationships
techContext.md	Tech stack, setup, constraints, dependencies
progress.md	What works, what’s left to build, known issues

Key commands

Command	What it does
follow your custom instructions	Tells Cline to read the Memory Bank and continue where you left off
initialize memory bank	Creates the initial memory-bank/ structure for a new project
update memory bank	Triggers a full review and update of all Memory Bank files

These work alongside Cline’s built-in slash commands. /newtask and /smol are especially useful for managing the context window without losing progress.

Managing context windows

Every AI model has a context window that limits how much it can hold at once. As a session grows, the window fills with conversation history, file contents, and tool results. Memory Bank helps you preserve important knowledge before that window fills up.

Manual approach

When your context window is getting full:

1. Ask Cline to update memory bank to document the current state
2. Start a new conversation
3. Ask Cline to follow your custom instructions

This captures what matters before the context clears, so you can pick up seamlessly in a fresh session.

Using slash commands

• /smol compresses conversation history while keeping you in the same task. Use this when you want to free up space without starting over.
• /newtask distills key decisions, file changes, and progress into a fresh task with a clean context window — like a developer handoff that preserves what matters.

Pairing with Plan & Act mode

Memory Bank works naturally alongside Plan & Act mode:

• Plan mode: Start here when resuming a project. Ask Cline to read the Memory Bank, review the current state, and discuss strategy before making changes.
• Act mode: Switch to Act once you have a clear plan. Cline carries everything from the planning session into implementation.

For complex features, use /deep-planning to have Cline investigate your codebase and produce a detailed implementation plan. The Memory Bank gives Cline the project context it needs to plan effectively.

Memory Bank and Checkpoints

Memory Bank and Checkpoints solve complementary problems:

• Memory Bank preserves knowledge: project context, decisions, patterns, and progress across sessions.
• Checkpoints preserve code state: file snapshots you can restore if something goes wrong.

Together, they let you experiment freely. If you need to roll back code, your Memory Bank still has the context of what you were trying to do and why.

Reducing your context footprint

Memory Bank works best when your starting context is lean. If Cline loads your entire project — including dependencies, build artifacts, and generated files — you burn through tokens before the real work starts.

Add a .clineignore file. This is the single biggest improvement most users can make. It tells Cline which files to skip when scanning your project. A well-configured .clineignore can drop your starting context from 200k+ tokens to under 50k, which means faster responses, lower costs, and the ability to work effectively with smaller models.

Keep Memory Bank files concise. Each file adds to your context when Cline reads it at session start. Keep projectbrief.md to one page, activeContext.md to current state only (not a running log), and progress.md as a summary rather than a detailed changelog. If a file grows beyond a page or two, split the detail into a separate doc and link to it — Cline can read linked files on demand.

Use Cline Rules strategically. Rules load into every request. Use conditional rules to activate rules only when working with matching files, so frontend rules don’t load when you’re editing backend code.

Best practices

• Start with a basic project brief and let the structure evolve naturally
• Let Cline help create the initial file contents
• activeContext.md changes most frequently — update it at the end of each session
• progress.md tracks milestones — review it when resuming after a break
• Update the Memory Bank after significant milestones or direction changes
• Store the Memory Bank instructions in a per-project .clinerules file to share context with collaborators
• Add a .clineignore early to keep your starting context small

---

Memory Bank custom instructions

Copy the following into Cline Settings → Custom Instructions or save it as a .clinerules file in your project root:

# Cline's Memory Bank

I am Cline, an expert software engineer with a unique characteristic: my memory resets
completely between sessions. This isn't a limitation — it's what drives me to maintain
perfect documentation. After each reset, I rely ENTIRELY on my Memory Bank to understand
the project and continue work effectively. I MUST read ALL memory bank files at the start
of EVERY task — this is not optional.

## Memory Bank Structure

The Memory Bank consists of core files and optional context files, all in Markdown format.
Files build upon each other in a clear hierarchy:

### Core Files (Required)
1. `projectbrief.md`
   - Foundation document that shapes all other files
   - Created at project start if it doesn't exist
   - Defines core requirements and goals
   - Source of truth for project scope

2. `productContext.md`
   - Why this project exists
   - Problems it solves
   - How it should work
   - User experience goals

3. `activeContext.md`
   - Current work focus
   - Recent changes
   - Next steps
   - Active decisions and considerations
   - Important patterns and preferences
   - Learnings and project insights

4. `systemPatterns.md`
   - System architecture
   - Key technical decisions
   - Design patterns in use
   - Component relationships
   - Critical implementation paths

5. `techContext.md`
   - Technologies used
   - Development setup
   - Technical constraints
   - Dependencies
   - Tool usage patterns

6. `progress.md`
   - What works
   - What's left to build
   - Current status
   - Known issues
   - Evolution of project decisions

### Additional Context
Create additional files/folders within memory-bank/ when they help organize:
- Complex feature documentation
- Integration specifications
- API documentation
- Testing strategies
- Deployment procedures

## Documentation Updates

Memory Bank updates occur when:
1. Discovering new project patterns
2. After implementing significant changes
3. When user requests with **update memory bank** (MUST review ALL files)
4. When context needs clarification

REMEMBER: After every memory reset, I begin completely fresh. The Memory Bank is my only
link to previous work. It must be maintained with precision and clarity, as my effectiveness
depends entirely on its accuracy.

FAQ

Custom instructions or .clinerules — which should I use?

Either works. Custom instructions apply globally across all projects. A .clinerules file is project-specific and stored in your repo, which makes it easy to share with collaborators. You can also use conditional rules to activate Memory Bank instructions only when working with memory-bank/ files.

How often should I update the Memory Bank?

After significant milestones or direction changes. For active development, every few sessions is a good rhythm. You can let Auto-Compact handle routine context management and reserve manual update memory bank for important checkpoints.

How does Memory Bank relate to Checkpoints?

Checkpoints save your code state (file snapshots). Memory Bank saves your project knowledge (context, decisions, progress). They’re complementary: checkpoints let you roll back code changes, Memory Bank lets you pick up where you left off intellectually.

Does this work with context window limitations?

Yes — that’s exactly what it’s designed for. Memory Bank stores important information in structured files that Cline loads efficiently at the start of each session. This avoids context bloat while keeping critical information available. For more on context windows, see Task Management.

Does Memory Bank work with other AI tools?

Yes. Memory Bank is a documentation methodology, not a Cline-specific API. Any AI that can read files can use the same approach. Commands may differ between tools but the structure works broadly.

How is this different from a README?

A README documents the project for humans. Memory Bank documents the project for AI sessions — it includes files for active context and progress tracking that change frequently, and it’s structured specifically for efficient AI context loading rather than human onboarding.

Related

• Plan & Act mode — Separate thinking from doing with structured planning sessions
• Checkpoints — Roll back code changes while keeping your conversation context
• Cline Rules — Define persistent instructions including Memory Bank setup
• Task Management — Understand tasks, context windows, and when to start fresh
• Deep Planning — Generate detailed implementation plans from your Memory Bank context