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 Structure

​
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

​
Managing Context Windows

When your context window fills up:
  1. Ask Cline to “update memory bank” to document current state
  2. Start a new conversation
  3. Ask Cline to “follow your custom instructions”
This preserves important context before the window clears, letting you continue seamlessly.
Memory Bank Context Window

​
Best Practices

  • Start with a basic project brief and let structure evolve
  • Let Cline help create initial structure
  • activeContext.md changes most frequently
  • progress.md tracks milestones
  • Update after significant milestones or direction changes

​
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. .clinerules is project-specific and stored in your repo. How often should I update? After significant milestones or direction changes. For active development, every few sessions. 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. For more information, see the Memory Bank blog post.