cline-memory-bank (nickbaumann98) — Summary

This is a documentation and prompting repository for Cline best practices, maintained by nickbaumann98 (a Cline contributor). The primary artifact relevant to memory is prompting/custom instructions library/cline-memory-bank.md, which contains the canonical "Cline Memory Bank" custom instructions prompt — a self-contained system prompt that turns Cline into a self-documenting development system. The repository itself ships no code, no MCP server, no hooks; it is purely a prompt template and methodology documentation. The Cline Memory Bank pattern defined here was later migrated to the official Cline docs site (docs.cline.bot), making this the historical origin document. With 581 stars and links across the Cline community, this is the most widely cited memory pattern for Cline. Compared to seeds, it is closest to claude-conductor in being a "markdown scaffold, zero primitives" archetype: the value is entirely in the Markdown template content and the agent's discipline in following it.

cline-memory-bank (nickbaumann98) — Overview

Origin

Created by nickbaumann98, a contributor to the Cline project. Originally published as part of a broader Cline documentation and best practices repository. The memory bank prompt became widely circulated in the Cline community and was eventually adopted into the official Cline documentation at docs.cline.bot.

Philosophy

The core philosophy is the "memory resets completely" persona: Cline is instructed to behave as an agent whose memory resets between sessions, and this limitation is reframed as a feature: "my memory resets completely between sessions. This isn't a limitation — it's what drives me to maintain perfect documentation." The implication is that treating memory loss as a forcing function produces better documentation discipline.

Key Manifesto Quote

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.

Core Innovation

The Memory Bank pattern defines a hierarchical dependency structure for context files:

projectbrief.md → productContext.md
projectbrief.md → systemPatterns.md
projectbrief.md → techContext.md
productContext.md → activeContext.md
systemPatterns.md → activeContext.md
techContext.md → activeContext.md
activeContext.md → progress.md

This DAG structure ensures that foundational context (project brief) informs all downstream files, and session state (activeContext, progress) is always derived from stable knowledge.

Key Design Choices

• No code, no server, no hooks — pure prompt engineering
• The .clinerules file provides project-specific rules (version-controlled)
• "Plan Mode" vs "Act Mode" distinction for structuring Cline workflows
• Update triggers: discovering patterns, implementing significant changes, explicit "update memory bank" command
• activeContext.md and progress.md are explicitly the highest-churn files

cline-memory-bank (nickbaumann98) — Architecture

Distribution

Documentation-only repository. No package, no binary, no server. Content copied manually.

Install

1. Open VSCode with Cline extension
2. Copy the custom instructions from prompting/custom instructions library/cline-memory-bank.md
3. Paste into Cline's "Custom Instructions" field in extension settings

Memory Bank Directory Structure (output when initialized)

project-root/
├── memory-bank/
│   ├── projectbrief.md       # Foundation: requirements, goals, scope (source of truth)
│   ├── productContext.md     # Why the project exists, problems solved, UX goals
│   ├── activeContext.md      # Current focus, recent changes, next steps, active decisions
│   ├── systemPatterns.md     # Architecture, technical decisions, design patterns
│   ├── techContext.md        # Technologies, setup, constraints, dependencies
│   └── progress.md           # What works, what's left, status, known issues
└── .clinerules               # Project-specific learning journal (version-controlled)

Plus optional additional files for complex features, integration specs, API docs, testing strategies, deployment procedures.

Required Runtime

None. Cline VSCode Extension + VSCode only.

Target AI Tools

Cline VSCode Extension exclusively. The custom instructions and .clinerules file are Cline-specific concepts (though similar patterns could work with other agents that accept system prompts).

cline-memory-bank (nickbaumann98) — Components

Core Files (6 required)

Special File: .clinerules

The .clinerules file is Cline's "learning journal" for each project. Described as capturing "patterns, preferences, and project intelligence that help me work more effectively." Version-controlled alongside source code. Unlike memory-bank files (which track what is known), .clinerules captures how the agent should behave on this project.

Commands / Hooks / MCP

None — this is a documentation-only framework.

Workflows Defined

Two named modes:

• Plan Mode: Read Memory Bank → check completeness → develop strategy → present approach
• Act Mode: Check Memory Bank → update documentation → update .clinerules if needed → execute task → document changes

Update Triggers

Memory Bank updates occur when:

1. Discovering new project patterns
2. After implementing significant changes
3. When user explicitly requests "update memory bank"
4. When context needs clarification

Note: When "update memory bank" is triggered, ALL files must be reviewed — not just the ones that changed.

cline-memory-bank (nickbaumann98) — Uniqueness

Differs From Seeds

Most similar to claude-conductor (seed) — both are pure Markdown scaffold frameworks with zero code primitives. The delta is two-fold: first, cline-memory-bank defines a DAG dependency hierarchy across its files (projectbrief → productContext/systemPatterns/techContext → activeContext → progress), which claude-conductor does not; second, it adds a project-level learning journal (.clinerules) that captures behavioral patterns rather than project facts. Unlike ccmemory (seed), there is no graph database, no hooks, no automated capture — everything is prompt-enforced through the "memory resets" persona framing.

Historical Significance

This is the origin document for the "Cline Memory Bank" pattern that became widely adopted in the Cline community and later migrated to official Cline documentation. Many subsequent memory systems (dazeb's cline-mcp-memory-bank, ccmemory-plain, and others) cite this pattern as inspiration.

Observable Failure Modes

1. Prompt drift: If Cline's context window fills and compacts, the custom instructions may be deprioritized, causing the agent to stop reading memory bank files.
2. Maintenance debt: With no automated capture, files become stale when developers forget to trigger updates.
3. No conflict detection: Contradictions between files (e.g., techContext says React, systemPatterns says Vue) are not detected automatically.
4. Session-length bias: Short sessions generate little memory; long sessions may generate too much, creating bloated files.