I'm excited to introduce a significant upgrade to the Memory Bank system – evolving from a monolithic all-in-one approach to a modular, graph-based system that integrates with Cursor's custom modes. This document explains the reasons behind this transition, its benefits, and how to get the most out of the new system.
graph TD
Old["Old System<br>Monolithic Approach"] --> New["New System<br>Modular JIT Architecture"]
Old --- OldFeatures["• Single file structure<br>• All rules loaded at once<br>• Fixed workflow"]
New --- NewFeatures["• Mode-specific rules<br>• Just-in-time loading<br>• Visual process maps<br>• Cursor custom modes integration"]
style Old fill:#f8d486,stroke:#e8b84d,color:black
style New fill:#4da6ff,stroke:#0066cc,color:white
style OldFeatures fill:#ffe6cc,stroke:#ffa64d,color:black
style NewFeatures fill:#cce6ff,stroke:#80bfff,color:black
The old Memory Bank system served well, providing a structured approach to task management with its adaptive complexity levels and comprehensive documentation. However, as projects grew in complexity, I identified several limitations:
- Context Inefficiency: Loading all rules at once regardless of relevance
- Limited Visual Guidance: Text-heavy instructions without visual process maps
- Token Waste: Consuming context window with irrelevant rules
- One-Size-Fits-All Approach: Less tailored to specific development phases
- Scalability Challenges: Difficulty in maintaining a growing single-file system
While the new system offers significant advantages in efficiency and scalability, I acknowledge it does introduce a steeper learning curve. This trade-off is intentional – the increased initial complexity enables more powerful capabilities, better organization, and improved long-term development outcomes for complex projects.
The new system addresses these limitations through a modular, Just-In-Time (JIT) architecture that loads only the rules you need when you need them.
graph TD
Command["User Mode Command"] --> ModeSwitch["Mode Switch"]
ModeSwitch --> LoadRules["Load Only<br>Relevant Rules"]
LoadRules --> ExecuteProcess["Execute Mode-Specific<br>Process"]
ExecuteProcess --> UpdateMemory["Update<br>Memory Bank"]
UpdateMemory --> NextMode["Transition to<br>Next Mode"]
style Command fill:#f8d486,stroke:#e8b84d,color:black
style ModeSwitch fill:#d971ff,stroke:#a33bc2,color:white
style LoadRules fill:#4da6ff,stroke:#0066cc,color:white
style ExecuteProcess fill:#4dbb5f,stroke:#36873f,color:white
style UpdateMemory fill:#ffa64d,stroke:#cc7a30,color:white
style NextMode fill:#ff5555,stroke:#cc0000,color:white
Importantly, the new system preserves the foundational 4-level complexity scale from the original system. This scale (Level 1: Quick Bug Fix, Level 2: Simple Enhancement, Level 3: Intermediate Feature, Level 4: Complex System) remains central to determining workflow paths and documentation requirements, ensuring continuity for users familiar with the original approach.
- Mode-Specific Visual Maps: Clear visual representations for each development phase
- Just-In-Time Rule Loading: Load only the rules needed for your current task
- Visual Decision Trees: Guided workflows with clear checkpoints
- Technical Validation: Dedicated QA processes to verify implementation readiness
- Platform-Aware Commands: Automatically adapts commands to your operating system
A fundamental enabler of the new system's capabilities is its graph-based architecture:
- Optimized Path Navigation: The system uses directed graphs to navigate complex decision trees with minimal overhead
- Contextual Relationships: Graph structures explicitly model relationships between development phases and components, enabling smarter transitions
- Resource Optimization: Each node in the graph loads only the resources needed for that specific step
- Parallel Processing Potential: The graph structure makes it easier to identify components that can be addressed in parallel
graph TD
Start[Entry Point] --> A[Decision Node]
A -->|Condition 1| B[Process B]
A -->|Condition 2| C[Process C]
B --> D[Next Step]
C --> D
style Start fill:#f9d77e,stroke:#d9b95c,color:black
style A fill:#a8d5ff,stroke:#88b5e0,color:black
style B fill:#c5e8b7,stroke:#a5c897,color:black
style C fill:#ffcccc,stroke:#ff9999,color:black
style D fill:#d9b3ff,stroke:#b366ff,color:black
Before: Linear execution paths with redundant rule evaluations.
After: Optimized traversal through decision points with clear conditionals and merge points.
This graph-based approach is particularly effective when working with large, complex projects where different components have varied requirements and dependencies. The system can efficiently navigate these complexities without overwhelming the context window.
One notable aspect of the new system is that the CREATIVE mode is conceptually based on Anthropic's Claude "Think" tool methodology, as described in their engineering blog. This approach has been enhanced and integrated into the Memory Bank workflow:
- Structured Exploration: The CREATIVE mode guides users through systematic exploration of design options
- Explicit Reasoning: Requires documentation of pros and cons for different approaches
- Component Breakdown: Helps break complex problems into manageable components
- Decision Documentation: Creates formal records of design decisions with clear rationales
- Continuous Refinement: The implementation will continue to evolve as Claude's capabilities advance
This methodology has proven particularly effective for complex design decisions, ensuring that all options are thoroughly considered before implementation begins.
The new system takes full advantage of Cursor's custom modes feature, which allows for specialized AI behaviors for different tasks.
Cursor custom modes allow you to configure different AI behaviors with specific tools and custom instructions. The new Memory Bank system creates specialized modes for each development phase:
graph LR
subgraph "Memory Bank Modes"
VAN["VAN MODE<br>Initialization"]
PLAN["PLAN MODE<br>Task Planning"]
CREATIVE["CREATIVE MODE<br>Design Decisions"]
BUILD["BUILD MODE<br>Code Implementation"]
QA["QA MODE<br>Validation"]
end
VAN --> PLAN
PLAN --> CREATIVE
CREATIVE --> BUILD
BUILD --> QA
style VAN fill:#80bfff,stroke:#4da6ff,color:black
style PLAN fill:#80ffaa,stroke:#4dbb5f,color:black
style CREATIVE fill:#d9b3ff,stroke:#b366ff,color:black
style BUILD fill:#ffcc80,stroke:#ffaa33,color:black
style QA fill:#ff8080,stroke:#ff5555,color:black
Each mode loads only its required rule set, optimizing context usage and providing specialized guidance:
| Mode | Purpose | Key Features |
|---|---|---|
| VAN | Initialization | Platform detection, file verification, complexity determination |
| PLAN | Task Planning | Requirements analysis, component identification, implementation strategy |
| CREATIVE | Design Decisions | Multiple options exploration, pros/cons analysis, design recommendations |
| BUILD | Code Implementation | Systematic building, command execution, testing |
| QA | Technical Validation | Dependency verification, configuration validation, build testing |
While Cursor's documentation on custom modes describes them primarily as standalone configurations with adjusted prompts and tool selections, Memory Bank significantly extends this concept:
According to Cursor's documentation, custom modes typically consist of:
- Setting a name, icon, and shortcut
- Enabling or disabling specific tools
- Adding custom instructions (prompts)
Their example modes (Teach, Refactor, Plan, etc.) function as isolated configurations without inherent connections between them. Each mode is essentially a separate AI personality with specific instructions.
graph TD
subgraph "Cursor's Standard Approach"
M1["Mode 1<br>Static Instructions"]
M2["Mode 2<br>Static Instructions"]
M3["Mode 3<br>Static Instructions"]
end
subgraph "Memory Bank's Approach"
MB1["VAN Mode<br>Dynamic Rules"]
MB2["PLAN Mode<br>Dynamic Rules"]
MB3["CREATIVE Mode<br>Dynamic Rules"]
MB4["BUILD Mode<br>Dynamic Rules"]
MB5["QA Mode<br>Dynamic Rules"]
MB1 -->|"Passes Context"| MB2
MB2 -->|"Passes Context"| MB3
MB3 -->|"Passes Context"| MB4
MB4 -->|"Passes Context"| MB5
MemBank["Memory Bank Files<br>(Shared State)"]
MB1 <-->|"Read/Write"| MemBank
MB2 <-->|"Read/Write"| MemBank
MB3 <-->|"Read/Write"| MemBank
MB4 <-->|"Read/Write"| MemBank
MB5 <-->|"Read/Write"| MemBank
end
style M1 fill:#f8d486,stroke:#e8b84d,color:black
style M2 fill:#f8d486,stroke:#e8b84d,color:black
style M3 fill:#f8d486,stroke:#e8b84d,color:black
style MB1 fill:#80bfff,stroke:#4da6ff,color:black
style MB2 fill:#80ffaa,stroke:#4dbb5f,color:black
style MB3 fill:#d9b3ff,stroke:#b366ff,color:black
style MB4 fill:#ffcc80,stroke:#ffaa33,color:black
style MB5 fill:#ff8080,stroke:#ff5555,color:black
style MemBank fill:#f9d77e,stroke:#d9b95c,stroke-width:3px,color:black
Memory Bank transforms custom modes into a comprehensive, interconnected system:
-
Graph-Based Architecture:
- Modes represent nodes in a development workflow with explicit transitions
- Each mode understands its place in the overall development process
- Visual process maps guide users through the appropriate sequence
-
Workflow Integration:
- Modes form a cohesive development process (VAN → PLAN → CREATIVE → BUILD → QA)
- Each mode is aware of preceding and subsequent modes
- Transitions between modes are formalized with specific entry/exit criteria
-
Shared Memory:
- Persistent state maintained across mode transitions via Memory Bank files
- Tasks.md serves as the central source of truth across all modes
- Each mode contributes specific types of information to the shared knowledge base
-
Just-In-Time Rule Loading:
- Each mode dynamically loads only its specific rule set
- Rules are specialized for the current development phase
- Context window is preserved for productive work
- Rules can adapt based on project complexity level
-
Visual Process Maps:
- Each mode contains embedded Mermaid diagrams
- Visual guidance for decision points and workflow options
- Clear checkpoints to track progress within each phase
-
Complexity-Adaptive Behavior:
- Modes adjust their behavior based on the complexity level determined during initialization
- Simpler projects follow streamlined processes
- Complex projects receive more comprehensive guidance
This enhanced approach to custom modes offers several advantages:
- Improved Context Utilization: By loading only relevant rules, more context is available for actual development work
- Coherent Development Process: Modes work together as a unified system rather than disconnected tools
- Phase-Appropriate Guidance: Each development phase receives specialized guidance optimized for its needs
- Knowledge Persistence: Important information is preserved across mode transitions
- Reduced Cognitive Overhead: Developers can focus on the current phase without being distracted by irrelevant guidance
If this approach proves successful through testing, it could potentially inspire several enhancements to how custom modes are used:
- Formalized Mode Transitions: More explicit handoffs between development phases
- Enhanced Visual Guidance: More sophisticated process maps and decision trees
- Deeper Integration with Memory Bank: More specialized document types for different development phases
- Custom Mode Templates: Pre-configured mode sequences for different project types
- Team Collaboration: Coordinated use of modes across multiple team members
While this implementation introduces more complexity in setup compared to standard custom modes, it offers significantly more powerful capabilities for structured development processes. The system transforms custom modes from isolated AI behaviors into components of a comprehensive development methodology.
My testing with real-world projects (including a complex Todo application) demonstrated significant benefits from the new system:
- Enforced Development Discipline: Mode switching created natural phase separations, reducing the tendency to jump directly to implementation
- Comprehensive Documentation: Each mode produced specialized documentation with explicit design decisions
- Systematic Development: Components were built according to plan in logical dependency order
- Flexibility When Needed: Hybrid approaches (like QA in IMPLEMENT) worked effectively without losing structure
From the analysis document:
"I observed tangible differences in development approach between modes. Each mode successfully optimized for its specific phase of development. The quality of the final application benefited from this structured approach."
| Aspect | Old System | New System |
|---|---|---|
| Structure | Single file | Multiple specialized files |
| Context Usage | Loads everything at once | Just-in-time loading |
| Guidance | Text-based instructions | Visual process maps + text |
| Decision Making | Basic decision points | Comprehensive decision trees |
| Technical Validation | Basic verification | Dedicated QA processes |
| Platform Awareness | Limited | Comprehensive adaptation |
| Memory Bank | Same core files | Same core files with improved organization |
| Documentation | Standardized formats | Mode-specific specialized formats |
| Complexity Levels | 4-level scale | Same 4-level scale with enhanced process flows |
graph TD
Start["Which system<br>should I use?"] --> Question{"What's your<br>experience level?"}
Question -->|"Beginner"| Old["Start with Old System<br>• Simpler to understand<br>• All in one place<br>• Easier learning curve"]
Question -->|"Intermediate/<br>Advanced"| New["Use New System<br>• More powerful capabilities<br>• Better for complex projects<br>• Optimized context usage"]
Old --> Progress["As you gain experience..."]
Progress --> New
style Start fill:#f8d486,stroke:#e8b84d
style Question fill:#4da6ff,stroke:#0066cc,color:white
style Old fill:#4dbb5f,stroke:#36873f,color:white
style New fill:#ffa64d,stroke:#cc7a30,color:white
style Progress fill:#d9b3ff,stroke:#b366ff,color:black
- New Projects: The new system works best when starting fresh projects rather than converting existing ones
- Testing Approach: If you want to try it with an existing project, make a backup first and experiment in a safe environment
- No Formal Migration Path: I haven't developed a formal migration path from old to new systems - it's currently designed for new implementations
- Learning Projects: Use the old system for simpler projects if you're still getting comfortable with the Memory Bank concept
- Complex Projects: The new system shines with multi-component projects requiring careful planning
To activate different modes in the new system:
VAN - Initialize project and determine complexity
PLAN - Create detailed implementation plan
CREATIVE - Explore design options for complex components
BUILD - Systematically build planned components
QA - Validate technical implementation
- Begin with
VANto initialize the project and determine complexity - For Level 2-4 tasks, transition to
PLANto create a comprehensive implementation plan - For components requiring design decisions, use
CREATIVEto explore options - Implement the planned changes with
BUILD - Validate the implementation with
QAbefore completing
The complexity level (1-4) determined during the VAN mode will significantly influence your path through the workflow:
- Level 1 tasks may proceed directly to BUILD after VAN
- Level 2-4 tasks follow the full workflow with increasingly comprehensive planning and documentation
For those interested in the technical details, the new system uses a graph-based approach with isolated rule files loaded just-in-time:
graph TD
Main["main.mdc<br>Core Rules"] --> Platform["platform-awareness.mdc<br>OS Detection"]
Main --> FileV["file-verification.mdc<br>File Structure"]
Main --> ComplexityDT["complexity-decision-tree.mdc<br>Task Classification"]
subgraph "Mode-Specific Maps"
VanMap["van-mode-map.mdc"]
PlanMap["plan-mode-map.mdc"]
CreativeMap["creative-mode-map.mdc"]
BuildMap["build-mode-map.mdc"]
QAMap["qa-mode-map.mdc"]
end
Main --> VanMap & PlanMap & CreativeMap & BuildMap & QAMap
VanMap --> VanFiles["Platform Detection<br>File Verification<br>Complexity Determination"]
PlanMap --> PlanFiles["Task Tracking<br>Planning Process<br>Component Identification"]
CreativeMap --> CreativeFiles["Design Patterns<br>Creative Phase Enforcement<br>Options Analysis"]
BuildMap --> BuildFiles["Command Execution<br>Implementation Guide<br>Testing Strategy"]
QAMap --> QAFiles["Dependency Verification<br>Configuration Validation<br>Build Testing"]
style Main fill:#f8d486,stroke:#e8b84d,stroke-width:2px,color:black
style VanMap fill:#80bfff,stroke:#4da6ff,stroke-width:2px,color:black
style PlanMap fill:#80ffaa,stroke:#4dbb5f,stroke-width:2px,color:black
style CreativeMap fill:#d9b3ff,stroke:#b366ff,stroke-width:2px,color:black
style BuildMap fill:#ffcc80,stroke:#ffaa33,stroke-width:2px,color:black
style QAMap fill:#ff8080,stroke:#ff5555,stroke-width:2px,color:black
While the rules are modularized, the Memory Bank files maintain continuity across modes:
graph LR
subgraph "Memory Bank Files"
Tasks["tasks.md<br>Source of Truth"]
Active["activeContext.md<br>Current Focus"]
Progress["progress.md<br>Implementation Status"]
Creative["creative-*.md<br>Design Decisions"]
end
VAN["VAN MODE"] -.-> Tasks & Active
PLAN["PLAN MODE"] -.-> Tasks & Active
CREATIVE["CREATIVE MODE"] -.-> Tasks & Creative
BUILD["BUILD MODE"] -.-> Tasks & Progress
QA["QA MODE"] -.-> Tasks & Progress
style Tasks fill:#f9d77e,stroke:#d9b95c,stroke-width:3px,color:black
style Active fill:#a8d5ff,stroke:#88b5e0,color:black
style Progress fill:#c5e8b7,stroke:#a5c897
style Creative fill:#f4b8c4,stroke:#d498a4,color:black
style VAN fill:#80bfff,stroke:#4da6ff,color:black
style PLAN fill:#80ffaa,stroke:#4dbb5f,color:black
style CREATIVE fill:#d9b3ff,stroke:#b366ff,color:black
style IMPLEMENT fill:#ffcc80,stroke:#ffaa33,color:black
style QA fill:#ff8080,stroke:#ff5555,color:black
Here's how I used the new system to develop a complex Todo application:
- VAN Mode: Analyzed requirements, set up project structure, determined Level 3 complexity
- PLAN Mode: Created comprehensive component hierarchy, identified dependencies, flagged components for creative exploration
- CREATIVE Mode: Explored multiple options for state management and filtering implementation, documented pros/cons
- BUILD Mode: Built components in logical sequence following the plan, with integrated QA validation
- Results: More disciplined development process, better documentation, and higher quality final product
This Memory Bank system is a personal hobby project that brings me joy to build and develop. I plan to continue evolving it based on user needs and my own experiments. Here are some areas I'm exploring for future development:
- Further Optimization of JIT Rules: Refining the rule loading system to provide even more efficient context utilization and faster response times
- User Feedback Integration: Establishing a structured feedback loop to gather insights from early adopters and refine the system based on real-world usage patterns
- PRD Mode Development: Creating a dedicated Product Requirements Document mode that leverages Cursor's advanced AI models to help users construct comprehensive product specifications within the same environment as their development work
- Team Collaboration Features: Enhancing Memory Bank to support multiple users working simultaneously with shared context and coordinated mode transitions
- Customizable Modes: Providing tools for users to create their own specialized modes beyond the current set, with custom rule configurations and process maps
- Cross-Project Memory: Enabling the Memory Bank system to maintain relevant context across different projects, improving knowledge transfer and consistency
- Analytics Dashboard: Developing tools to analyze development patterns, mode usage, and project progression to provide insights and suggest process improvements
- Integration with Version Control: Creating deeper connections between Memory Bank documentation and code version history for better traceability
As I develop these new features, I remain committed to these core principles:
- Creating enjoyable, powerful tools for structured development
- Focusing on new implementations rather than migration paths
- Balancing power and complexity with appropriate learning resources
- Preserving the foundational 4-level complexity scale that has proven effective
I welcome community input on which of these potential directions would be most valuable to prioritize in the development roadmap.
The new isolation-focused Memory Bank system represents a significant evolution in my approach to structured development. While it introduces a steeper learning curve, the benefits in terms of efficiency, guidance, and scalability make it worthwhile for complex projects.
My recommendations:
- Beginners: Start with the old system until comfortable with the core concepts
- New Projects: Use the new system primarily for new projects rather than trying to migrate existing ones
- Testing: If you want to try the new system with an existing project, make a backup first and experiment in a safe environment
- Advanced Users: Consider the new system for substantial development work on complex projects
This is an experimental system that I've created as a personal hobby project. I encourage you to try it, provide feedback, and adapt it to your own workflows. By leveraging Cursor's custom modes and visual process maps, the new Memory Bank system provides a powerful framework for disciplined, systematic development that scales with project complexity.
- Cursor Custom Modes Documentation
- Memory Bank Reference Files (in .cursor/rules/isolation_rules/)
- Mode-specific instruction files (van_instructions.md, plan_instructions.md, etc.)
- CREATIVE Mode and Claude's "Think" Tool
The previous Memory Bank implementation had several limitations:
- Limited Context Capacity: All rules and commands were loaded into a single context, reducing the available tokens for productive work
- Fixed Workflow: Little flexibility for adapting to different project complexities
- Redundant Rule Loading: Even simple tasks loaded the full ruleset, inefficient use of context
- No Visual Guidance: Difficult to understand the system's decision-making process
- Limited Platform Awareness: Platform-specific commands required manual adaptation
The new Memory Bank system addresses these limitations through:
Instead of loading all rules upfront, the system now:
- Loads only the rules relevant to the current development phase
- Uses visual maps to determine which rules to load at what time
- Dynamically adjusts rule complexity based on task requirements
- Preserves valuable context space for productive work
graph TD
subgraph "Old System"
OldMain[All Rules Loaded at Start]
end
subgraph "New System"
Entry[Entry Point]
Core[Core Rules]
Phase1[Phase 1 Rules]
Phase2[Phase 2 Rules]
Phase3[Phase 3 Rules]
Entry --> Core
Core --> Phase1
Core --> Phase2
Core --> Phase3
end
style OldMain fill:#ffcccc,stroke:#ff9999,color:black
style Entry fill:#ccffcc,stroke:#99ff99,color:black
style Core fill:#ccffcc,stroke:#99ff99,color:black
style Phase1 fill:#ccffcc,stroke:#99ff99,color:black
style Phase2 fill:#ccffcc,stroke:#99ff99,color:black
style Phase3 fill:#ccffcc,stroke:#99ff99,color:black
Before: All 25+ rules were loaded at initialization, consuming approximately 70% of the available context.
After: Only 3-7 rules are loaded at any given time, reducing context usage to approximately 15-20%.
The graph-based structure is a fundamental efficiency enabler in the new system:
- Optimized Path Navigation: The system uses directed graphs to navigate complex decision trees with minimal overhead
- Contextual Relationships: Graph structures explicitly model relationships between development phases and components, enabling smarter transitions
- Resource Optimization: Each node in the graph loads only the resources needed for that specific step
- Parallel Processing Potential: The graph structure makes it easier to identify components that can be addressed in parallel
graph TD
Start[Entry Point] --> A[Decision Node]
A -->|Condition 1| B[Process B]
A -->|Condition 2| C[Process C]
B --> D[Next Step]
C --> D
style Start fill:#f9d77e,stroke:#d9b95c,color:black
style A fill:#a8d5ff,stroke:#88b5e0,color:black
style B fill:#c5e8b7,stroke:#a5c897,color:black
style C fill:#ffcccc,stroke:#ff9999,color:black
style D fill:#d9b3ff,stroke:#b366ff,color:black
Before: Linear execution paths with redundant rule evaluations.
After: Optimized traversal through decision points with clear conditionals and merge points.
Each mode now has its own visual process map that:
- Clearly illustrates the workflow for that specific development phase
- Provides explicit decision points and conditional branches
- Adapts to project complexity levels
- Offers visual checkpoints to track progress
graph TD
Start[Start] --> Assess[Assess Project]
Assess --> Complexity{Complexity Level?}
Complexity -->|Simple| SimplePath[Simple Path]
Complexity -->|Complex| ComplexPath[Complex Path]
style Start fill:#c5e8b7,stroke:#a5c897,color:black
style Assess fill:#a8d5ff,stroke:#88b5e0,color:black
style Complexity fill:#f9d77e,stroke:#d9b95c,color:black
style SimplePath fill:#f4b8c4,stroke:#d498a4,color:black
style ComplexPath fill:#f4b8c4,stroke:#d498a4,color:black
The system now includes:
- Automated Platform Detection: Automatically adapts commands for Windows, MacOS, or Linux
- File Structure Verification: Validates project structure before proceeding
- QA Checkpoints: Dedicated technical validation phase with specific validation criteria
- More Accurate Command Generation: Platform-specific commands with higher success rates