Skip to main content
Memory Bank is a documentation methodology that transforms Cline from a stateless assistant into a persistent development partner. Through structured markdown files, Cline can “remember” your project details across sessions.

​
Quick Setup

  1. Copy the custom instructions below
  2. Add to custom instructions or a .clinerules file
  3. Ask Cline to “initialize memory bank”

​
How It Works

Memory Bank files are regular markdown files in your project that both you and Cline can access. They’re organized hierarchically to build a complete picture of your project: 
memory-bank/
├── projectbrief.md      # Foundation document
├── productContext.md    # Why this project exists
├── activeContext.md     # Current work focus
├── systemPatterns.md    # Architecture & patterns
├── techContext.md       # Tech stack & setup
└── progress.md          # Status & milestones
Memory Bank file hierarchy showing projectbrief.md at the top flowing into productContext, systemPatterns, and techContext, which feed into activeContext and progress

​
Core Files

FilePurpose
projectbrief.mdFoundation document with core requirements and goals
productContext.mdWhy the project exists, problems it solves, UX goals
activeContext.mdCurrent focus, recent changes, next steps (updates most frequently)
systemPatterns.mdArchitecture, design patterns, component relationships
techContext.mdTech stack, setup, constraints, dependencies
progress.mdWhat works, what’s left, known issues

​
Key Commands

  • “follow your custom instructions” - Tells Cline to read Memory Bank and continue where you left off
  • “initialize memory bank” - Creates the initial structure for a new project
  • “update memory bank” - Triggers a full documentation review and update
These work alongside Cline’s built-in slash commands. In particular, /newtask and /smol help you manage context windows without losing progress.

​
Working with Plan & Act Modes

Memory Bank pairs naturally with 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 mode once you have a plan. Cline retains everything from the planning session and can implement changes.
For complex features, use /deep-planning to have Cline investigate your codebase and create a detailed implementation plan. The Memory Bank gives Cline the project context it needs to plan effectively.

​
Managing Context Windows

Every AI model has a context window that limits how much information it can process at once. As you work, this window fills with conversation history, file contents, and tool results. Memory Bank helps you preserve important knowledge when you need to free up space.

​
Manual approach

When your context window fills up:
  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 preserves important context in your Memory Bank files before the window clears, letting you continue seamlessly in a fresh conversation.

​
Using slash commands

Cline’s built-in commands offer more targeted options:
  • /smol compresses your 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. This is like a developer handoff that preserves what matters.

​
Automatic context management

Enable Auto-Compact to let Cline automatically compress context as you work. This reduces how often you need to manually manage the context window, though you should still update the Memory Bank after significant milestones.
Context window progress bar showing usage approaching the limit

​
Memory Bank and Checkpoints

Memory Bank and Checkpoints solve different sides of the same problem:
  • 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. Checkpoints protect your code, and Memory Bank protects your understanding of the project. If you need to roll back code changes, 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 into context, 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. Adding one can drop your starting context from 200k+ tokens to under 50k, which means faster responses, lower costs, and the ability to use smaller models effectively. Keep Memory Bank files concise. Each file adds to your context when Cline reads it at the start of a session. Keep projectbrief.md to one page, activeContext.md to current state only (not a running log), and progress.md to 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 structure evolve
  • Let Cline help create the initial structure
  • activeContext.md changes most frequently; update it after each session
  • progress.md tracks milestones; review it when resuming work
  • Update after significant milestones or direction changes
  • Use Cline Rules to store the Memory Bank instructions per-project
  • Add a .clineignore early to keep your starting context small

​
Memory Bank Custom Instructions

Copy this into custom instructions or a .clinerules file: 
# 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? 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? After significant milestones or direction changes. For active development, every few sessions. You can also 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 complement each other: checkpoints let you roll back code, Memory Bank lets you pick up where you left off intellectually. How does Memory Bank relate to context window limitations? Memory Bank stores important information in structured files that Cline can load efficiently at the start of each session. This prevents context bloat while keeping critical information available. For more on how context windows work, see Task Management. Does this work with other AI tools? Yes. Memory Bank is a documentation methodology that works with any AI that can read docs. Commands may differ but the approach works across tools. Different from README files? Memory Bank provides structured, comprehensive documentation designed for AI context management, going beyond what a single README covers. It includes files for active context and progress tracking that change frequently, unlike a typical README. For more information, see the Memory Bank blog post.
  • 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