DOCSEARCHbyAlgolia
Submit Docs

Cursor Memory Bank

repository·main·Indexed 25 days ago

https://github.com/vanzan01/cursor-memory-bank

A token-optimized, hierarchical task management system for Cursor 2.0. It utilizes a shared memory directory and a sequence of specialized commands (/van, /plan, /creative, /build, /reflect, /archive) to guide developers through structured phases of planning, designing, building, and reflecting based on task complexity levels 1-4.

Tokens
10.3K
Snippets
17
Records
76
Agent score
84%

What's inside cursor-memory-bank

  1. Overview of the Memory Bank System

    main
    The Memory Bank System is a structured documentation architecture designed to provide LLMs with persistent context across different sessions. It overcomes the limitation of LLMs not retaining context by using a set of core documentation files, structured workflows with verification steps, command execution protocols, and specific maintenance rules. The system is optimized to reduce context window usage through a Visual Navigation Layer that allows for selective document loading.

  2. Overview of the Memory Bank System Optimization Journey

    main
    The Memory Bank System is a structured development framework that has evolved through multiple optimization rounds to improve context efficiency and systematic development. It utilizes a modular, graph-based architecture designed to minimize token usage while maximizing decision-making quality through specialized modes and visual process maps.

  3. Understand the Memory Bank directory structure

    main

    The Memory Bank system stores all state and context in a memory-bank/ directory. The structure is divided into Core Files for ongoing context and Generated Files for historical or design-specific documentation.

    Core Files

    • tasks.md: Central source of truth for task tracking, checklists, and component lists.
    • activeContext.md: Maintains focus of the current development phase.
    • progress.md: Tracks implementation status and observations.
    • projectbrief.md: Project foundation and context.
    • productContext.md: Product-specific context and requirements.
    • systemPatterns.md: System patterns and architectural decisions.
    • techContext.md: Technical context and technology stack.

    Generated Files

    • creative/creative-[feature_name].md: Design decision documents (Level 3-4).
    • reflection/reflection-[task_id].md: Reflection documents.
    • archive/archive-[task_id].md: Archive documents for completed tasks.

  4. Understand the Memory Bank Hierarchical Rule Architecture

    main

    The Memory Bank System uses a hierarchical, token-optimized architecture to load rules just-in-time (JIT). This prevents token bloat by only loading necessary rules based on the current complexity level and active mode.

    Hierarchy Structure:

    • Root: Common Rules
    • Core: Shared Rules used across all modes
    • Levels (1-4): Complexity-based rule sets (Level 1 is ultra-compact; Level 4 is for enterprise projects)
    • Mode Visual Maps: Visual representations of current state
    • Phase-Specific Rules: Rules specific to active modes such as VAN, PLAN, CREATIVE, BUILD, REFLECT, or ARCHIVE.

  5. Understand the Modular Memory Bank Architecture

    main

    The Memory Bank system has transitioned from a monolithic architecture to a modular, graph-based system. This new architecture uses Just-In-Time (JIT) Rule Loading to improve efficiency. Instead of loading all rules at once (which previously consumed ~70% of context), the system now only loads 3-7 relevant rules per phase, reducing context usage to approximately 15-20%.

    Key architectural components include:

    • Core Rules: Loaded via main.mdc.
    • Mode-Specific Maps: Rules are loaded based on the active mode (e.g., van-mode-map.mdc, plan-mode-map.mdc, creative-mode-map.mdc, build-mode-map.mdc, qa-mode-map.mdc).
    • Platform Awareness: Includes automated detection for Windows, MacOS, and Linux to ensure accurate command generation.

  6. Use the correct file roles for project management

    main

    The Memory Bank system uses specific files for distinct purposes. Follow these roles to maintain project integrity:

    • .cursorrules: Contains project patterns and intelligence only.
    • activeContext.md: Contains implementation details and the current focus.
    • progress.md: Tracks overall progress and provides references to tasks.
    • tasks.md: The single source of truth for all task status tracking.

  7. Understand the Modular JIT Architecture

    main

    The Memory Bank system has transitioned from a monolithic single-file structure to a modular, Just-In-Time (JIT) architecture. Instead of loading all rules at once, the system loads only the rules relevant to your current development mode. This reduces token waste and improves context efficiency.

    Key architectural shifts:

    • Old System: Monolithic, single file, all rules loaded at once, fixed workflow.
    • New System: Modular, mode-specific rules, JIT loading, visual process maps, and integration with Cursor custom modes.

    Despite the modularity, the system preserves the foundational 4-level complexity scale to determine workflow paths:

    • Level 1: Quick Bug Fix
    • Level 2: Simple Enhancement
    • Level 3: Intermediate Feature
    • Level 4: Complex System

  8. Understand the Memory Bank command workflow

    main

    The Memory Bank follows a progressive workflow designed to optimize context usage through progressive rule loading. The standard sequence is:

    /van $\rightarrow$ /plan $\rightarrow$ /creative $\rightarrow$ /build $\rightarrow$ /reflect $\rightarrow$ /archive

    Complexity Levels per Command:

    • /van: Determines level
    • /plan: Level 2-4
    • /creative: Level 3-4
    • /build: Level 1-4
    • /reflect: Level 1-4
    • /archive: Level 1-4

  9. Core Principles of the Memory Bank System

    main

    The system operates based on five core principles to ensure efficient and structured development:

    1. Methodological Foundation: Uses a structured approach based on proven methodologies.
    2. Mode-Specific Isolation: Maintains a clean separation of concerns through specialized modes.
    3. Visual Processing: Utilizes comprehensive process maps and decision trees for navigation.
    4. Just-In-Time Efficiency: Implements JIT rule loading to only load necessary context when needed.
    5. Continuous Evolution: Employs regular assessment and improvement cycles.

  11. Perform design exploration with /creative

    main

    Use the /creative command to perform structured design exploration for components that require creative phases (e.g., architecture, UI/UX, or algorithm options). This is used after /plan identifies the need for design decisions.

    Workflow Routing:

    • After all creative phases are complete, proceed to /build.
    /creative