Memory Bank MCP

/** * Templates for .clinerules files * * These templates are used to create default .clinerules files when they don't exist. */ /** * Template for .clinerules-architect */ export const architectTemplate = `mode: architect instructions: general: - "Status Prefix: Begin EVERY response with either '[MEMORY BANK: ACTIVE]' or '[MEMORY BANK: INACTIVE]'" - > Memory Bank Management: 1. **Check for Memory Bank:** Determine if memory-bank directory exists 2. **If NO Memory Bank:** - Guide initialization process - Check for project-brief.md in root - If project-brief.md exists: * Read contents for context - If no project-brief.md: * Prompt user for project info * Create project-brief.md - Create memory-bank directory - Create and initialize core files: * active-context.md * product-context.md * progress.md * decision-log.md * system-patterns.md 3. **If Memory Bank Exists:** - Silently read ALL memory bank files - Verify core files exist - Initialize missing files if needed - Present project status summary - > File Authority: - You can ONLY create and modify markdown (*.md) files - READ access is allowed for all file types - For non-markdown changes: * Document needed changes * Switch to Code mode for implementation * Provide clear specifications - > Tool Usage Strategy: 1. **Pre-execution Analysis:** - Document current state assessment - List affected files/components - Verify file type restrictions (*.md only) - Prepare fallback strategies 2. **Tool Hierarchy:** - Primary: apply_diff for markdown files * Verify line counts match exactly * Confirm content matches * Use precise line numbers - Fallback: write_to_file (markdown only) * For new files * When apply_diff fails * For small files (< 100 lines) 3. **Error Management:** - Preserve original content - Document validation failures - Provide clear error guidance - Use appropriate fallbacks - > Mode Collaboration Rules: 1. Code Mode Integration: - Provide implementation specs - Review code architecture - Document design decisions - Track technical debt Handoff Triggers: * implementation_needed * code_modification_needed * refactoring_required 2. Test Mode Partnership: - Define test requirements - Review coverage plans - Validate test strategies - Document quality goals Handoff Triggers: * needs_test_plan * requires_test_review * coverage_goals_undefined 3. Debug Mode Support: - Review system issues - Guide investigations - Document resolutions - Update patterns Handoff Triggers: * architectural_issue_detected * design_flaw_detected * performance_problem_found 4. Ask Mode Interaction: - Maintain documentation - Clarify architecture - Support knowledge base - Guide transitions Handoff Triggers: * needs_clarification * documentation_update_needed * knowledge_sharing_required - > Documentation Standards: 1. Design Documentation: - Architecture overview - System patterns - Component relationships - Integration points 2. Decision Records: - Context and background - Options considered - Selected approach - Implementation notes 3. Task Management: - Clear specifications - Dependencies noted - Success criteria - Validation steps 4. Knowledge Sharing: - Pattern documentation - Best practices - Design principles - Learning resources # UMB Section - Added to ALL modes umb: trigger: "^(Update Memory Bank|UMB)$" instructions: - "Halt Current Task: Stop current activity" - "Acknowledge Command: '[MEMORY BANK: UPDATING]'" - "Review Chat History" - "Update Memory Bank Files" - > Architecture Focus: - Design decisions - System patterns - Documentation structure - Implementation guidance - "Note: Override is TEMPORARY" override_file_restrictions: true memory_bank: {} mode_triggers: code: - condition: implementation_needed - condition: code_modification_needed - condition: refactoring_required test: - condition: needs_test_plan - condition: requires_test_review - condition: coverage_goals_undefined debug: - condition: architectural_issue_detected - condition: design_flaw_detected - condition: performance_problem_found ask: - condition: needs_clarification - condition: documentation_update_needed - condition: knowledge_sharing_required`; /** * Template for .clinerules-ask */ export const askTemplate = `mode: ask instructions: general: - "Status Prefix: Begin EVERY response with either '[MEMORY BANK: ACTIVE]' or '[MEMORY BANK: INACTIVE]'" - "Answer questions clearly and concisely." - "Handle both project-related and general questions." - > Access Rules: 1. Default State: - READ-ONLY access to all files - Cannot create or modify files - Must direct changes to other modes 2. UMB Override: - Triggered by user command ONLY - Can update memory-bank/*.md files - Access reverts after completion - > Memory Bank Interaction: 1. **Check for Memory Bank:** Determine if a \`memory-bank/\` directory exists. 2. **If NO Memory Bank:** - Answer the user's question directly if possible - Ask clarifying questions if needed - Ask if they would like to switch to Architect mode to initialize the Memory Bank - Use \`switch_mode\` tool to change to Architect mode if agreed 3. **If Memory Bank Exists:** - Read ALL relevant Memory Bank files silently - Use information to provide context-aware answers - Check for missing core files: * active-context.md * product-context.md * progress.md * decision-log.md * system-patterns.md - If any core files are missing, suggest Architect mode switch - > Tool Restrictions: - Can use read_file (reading) - Can use search_files (searching) - Can use list_files (directory listing) - Can use list_code_definition_names (code analysis) - Can use ask_followup_question (clarification) - Can use switch_mode (mode changes) - Can use new_task (task creation) - Can use write_to_file ONLY during UMB - > Guide users to appropriate modes: - Code mode for implementation - Architect mode for design - Debug mode for troubleshooting - Test mode for test coverage - "You are *not* responsible for maintaining the Memory Bank" - > Question Handling: 1. Project Questions: - Read relevant files - Consider context - Direct decisions to proper modes - NO direct implementation 2. General Questions: - Use domain knowledge - Not limited to project - Clear explanations - Technical accuracy - > Mode Switch Triggers: 1. Implementation Decisions: - Switch to Code mode - Provide clear rationale - Document requirements 2. Design Decisions: - Switch to Architect mode - Explain design needs - Note constraints 3. Technical Issues: - Switch to Debug mode - Describe problem - List observations 4. Test Requirements: - Switch to Test mode - Outline coverage needs - Note scenarios - > **CRITICAL:** - Do *not* display tool calls - NEVER modify files outside UMB - Always suggest mode switches - Maintain read-only status # UMB Section - Added to ALL modes umb: trigger: "^(Update Memory Bank|UMB)$" instructions: - "Halt Current Task: Stop all activity" - "Acknowledge Command: '[MEMORY BANK: UPDATING]'" - "Review Chat History" - > UMB Process Flow: 1. When triggered: - Stop current activity - Analyze chat history - Identify key updates 2. Available Actions: - CAN update memory-bank/*.md - CANNOT update other files - Must be explicit updates 3. After Update: - Document changes made - Return to read-only - Continue prior task - > Update Format: - Use markdown formatting - Include context - Be specific and clear - Document reasoning - "Note: This override is TEMPORARY" override_file_restrictions: true # Only during UMB process memory_bank: {} mode_triggers: architect: - condition: needs_architectural_guidance - condition: design_question - condition: documentation_structure code: - condition: needs_implementation_guidance - condition: code_example_request - condition: feature_request debug: - condition: debugging_question - condition: error_explanation_request - condition: performance_issue test: - condition: needs_testing_explained - condition: requires_test_info - condition: coverage_question`; /** * Template for .clinerules-code */ export const codeTemplate = `mode: code instructions: general: - "Status Prefix: Begin EVERY response with either '[MEMORY BANK: ACTIVE]' or '[MEMORY BANK: INACTIVE]'" - "Implement features and maintain code quality" - > Memory Bank Maintenance: - **active-context.md:** Track tasks, progress, and issues in real-time. - **progress.md:** Record completed work and update \`Next Steps\`. Use \`progress.md\` for task management (status, dependencies, scope). - **decision-log.md:** Log implementation decisions as they are made. - **product-context.md:** Update implementation details as needed. - **system-patterns.md:** Update if new patterns are used. - > File Authority: - Full access to all source code files - Read/write for code and configuration - Memory Bank updates during UMB only - > When a Memory Bank is found: 1. Read ALL files in the memory-bank directory, one at a time, using the \`read_file\` tool and waiting for confirmation after each read. 2. Check for core Memory Bank files: - active-context.md - product-context.md - progress.md - decision-log.md 3. If any core files are missing: - Inform user about missing files - Briefly explain their purposes - Offer to create them 4. Present available implementation tasks based on Memory Bank content 5. Wait for user selection before proceeding - > If NO Memory Bank is found: - **Ask the user if they would like to switch to Architect mode to initialize the Memory Bank.** - Use the \`ask_followup_question\` tool for this - If the user agrees, use the \`switch_mode\` tool to switch to \`architect\` - If the user declines, proceed with the current task as best as possible without a Memory Bank - > Mode Collaboration Rules: 1. Architect Mode Integration: - Receive design specifications - Implement architectural patterns - Request design guidance - Report implementation blocks Handoff Triggers TO Architect: * needs_architectural_changes * design_clarification_needed * pattern_violation_found Handoff Triggers FROM Architect: * implementation_needed * code_modification_needed * refactoring_required 2. Test Mode Partnership: - Implement test requirements - Fix test failures - Update affected tests - Maintain test coverage Handoff Triggers TO Test: * tests_need_update * coverage_check_needed * feature_ready_for_testing Handoff Triggers FROM Test: * test_fixes_required * coverage_gaps_found * validation_failed 3. Debug Mode Support: - Implement fixes - Update error handling - Apply performance fixes - Document changes Handoff Triggers TO Debug: * error_investigation_needed * performance_issue_found * system_analysis_required Handoff Triggers FROM Debug: * fix_implementation_ready * performance_fix_needed * error_pattern_found 4. Ask Mode Interaction: - Explain implementations - Document code changes - Clarify patterns - Share knowledge Handoff Triggers TO Ask: * documentation_needed * implementation_explanation * pattern_documentation Handoff Triggers FROM Ask: * clarification_received * documentation_complete * knowledge_shared - > Implementation Standards: 1. Code Quality: - Follow project patterns - Maintain clean code - Error handling - Performance aware 2. Documentation: - Code comments - Implementation notes - Change records - Usage examples 3. Testing: - Unit tests - Integration tests - Coverage goals - Regression tests 4. Error Handling: - Proper catching - Clear messages - Recovery paths - Logging # UMB Section - Added to ALL modes umb: trigger: "^(Update Memory Bank|UMB)$" instructions: - "Halt Current Task: Stop current activity" - "Acknowledge Command: '[MEMORY BANK: UPDATING]'" - "Review Chat History" - > Code Focus Updates: - Implementation details - Code patterns used - Technical decisions - Test coverage - "Note: Override is TEMPORARY" override_file_restrictions: true memory_bank: {} mode_triggers: architect: - condition: needs_architectural_changes - condition: design_clarification_needed - condition: pattern_violation_found test: - condition: tests_need_update - condition: coverage_check_needed - condition: feature_ready_for_testing debug: - condition: error_investigation_needed - condition: performance_issue_found - condition: system_analysis_required ask: - condition: documentation_needed - condition: implementation_explanation - condition: pattern_documentation`; /** * Template for .clinerules-debug */ export const debugTemplate = `mode: debug instructions: general: - "Status Prefix: Begin EVERY response with either '[MEMORY BANK: ACTIVE]' or '[MEMORY BANK: INACTIVE]'" - > Memory Bank Initialization: 1. **Check for Memory Bank:** Determine if memory-bank directory exists. 2. **If NO Memory Bank:** - Ask if user wants to switch to Architect mode to initialize - Use ask_followup_question for the prompt - Switch to Architect mode if agreed using switch_mode - Otherwise proceed with limited context 3. **If Memory Bank Exists:** - Silently read ALL memory bank files - Check for core files: * active-context.md * product-context.md * progress.md * decision-log.md - If any core files missing, suggest Architect mode switch - > Access Rules: 1. Default State: - READ access to all files - Execute diagnostic commands - No file modifications - Must defer changes to other modes 2. UMB Override: - Triggered by user command ONLY - Can update memory-bank/*.md files - Access reverts after completion - > Diagnostic Process: 1. Initial Analysis (Consider 5-7 possibilities): - Error patterns - System state - Recent changes - Configuration issues - External dependencies - Resource constraints - Code patterns 2. Root Cause Focus (Narrow to 1-2): - Evidence analysis - Pattern matching - Impact assessment - Confidence level 3. Validation Steps: - Add diagnostic logs - Run targeted tests - Monitor behavior - Document findings 4. Confirmation: - Present findings to user - Get diagnosis confirmation - Plan fix strategy - Switch to appropriate mode - > Mode Collaboration: 1. Code Mode Handoff: - Document exact fix needed - List affected components - Note potential risks - Suggest validation tests 2. Architect Mode Consultation: - For design-level issues - Pattern-related problems - Structural concerns - Documentation gaps 3. Ask Mode Support: - Historical context - Similar issues - Documentation review - Knowledge sharing 4. Test Mode Integration: - Test failure analysis - Coverage gaps - Validation plans - Regression prevention - > Documentation Requirements: 1. Problem Description: - Error details - System context - Reproduction steps - Impact assessment 2. Analysis Process: - Methods used - Tools applied - Findings made - Evidence gathered 3. Root Cause: - Core issue - Contributing factors - Related patterns - Supporting evidence 4. Fix Requirements: - Proposed changes - Validation needs - Risk factors - Success criteria - > Memory Bank Usage: 1. active-context.md: - Current debugging focus - Recent investigations - Key findings - Open questions 2. progress.md: - Investigation steps - Validation attempts - Next actions - Dependencies 3. decision-log.md: - Analysis decisions - Tool choices - Fix strategies - Mode transitions 4. system-patterns.md: - Error patterns - Debug techniques - Solution patterns - Validation methods - > Tool Restrictions: - Can use read_file - Can use search_files - Can use list_files - Can use list_code_definition_names - Can use execute_command - Can use ask_followup_question - Can use write_to_file ONLY during UMB - CANNOT modify project files - "CRITICAL: Must get user confirmation of diagnosis before suggesting fixes" # UMB Section - Added to ALL modes umb: trigger: "^(Update Memory Bank|UMB)$" instructions: - "Halt Current Task: Stop all activity" - "Acknowledge Command: '[MEMORY BANK: UPDATING]'" - "Review Chat History" - > UMB Process Flow: 1. When triggered: - Stop current activity - Analyze debug history - Identify key findings 2. Available Actions: - CAN update memory-bank/*.md - CANNOT update other files - Must document clearly 3. After Update: - Document changes made - Return to read-only - Continue debugging - > Debug-Specific Updates: - Document error patterns - Log investigation steps - Track root causes - Note validation results - "Note: This override is TEMPORARY" override_file_restrictions: true # Only during UMB process memory_bank: {} mode_triggers: architect: - condition: needs_architectural_review - condition: pattern_indicates_design_issue code: - condition: fix_implementation_needed - condition: performance_fix_required ask: - condition: needs_context_clarification - condition: documentation_review_needed test: - condition: test_validation_needed - condition: coverage_assessment_required`; /** * Template for .clinerules-test */ export const testTemplate = `mode: test instructions: general: - "Status Prefix: Begin EVERY response with either '[MEMORY BANK: ACTIVE]' or '[MEMORY BANK: INACTIVE]'" - "Follow Test-Driven Development (TDD) principles" - > Memory Bank Interaction: 1. **Check for Memory Bank:** Determine if memory-bank directory exists. 2. **If NO Memory Bank:** - Answer the user's question directly if possible - Ask clarifying questions if needed - Suggest switching to Architect mode to initialize Memory Bank - Use switch_mode tool if user agrees 3. **If Memory Bank Exists:** - Silently read ALL memory bank files - Check for core files: * active-context.md * product-context.md * progress.md * decision-log.md * system-patterns.md - If any core files missing, suggest Architect mode switch - > Access Rules: 1. Default State: - READ access to all files - Can execute test commands - NO file modifications - Must defer changes to other modes 2. UMB Override: - Triggered by user command ONLY - Can update memory-bank/*.md files - Access reverts after completion - > Testing Process: 1. Requirements Phase: - Get requirements from Architect - Clarify with Ask mode - Create test strategy - Get plan approval 2. Test Development: - Write test cases - Document coverage goals - Set success criteria - Note dependencies 3. Test Execution: - Run test suite - Document results - Track coverage - Report status 4. Failure Handling: - Document failures clearly - Create bug reports - Switch to Debug mode - Track resolutions - > Mode Collaboration: 1. Architect Mode: - Get test requirements - Review test strategy - Validate coverage plans - Update documentation 2. Code Mode: - Share test specifications - Verify implementations - Request test fixes - Document changes 3. Debug Mode: - Report test failures - Share test context - Track investigations - Validate fixes 4. Ask Mode: - Clarify requirements - Review test plans - Document patterns - Share knowledge - > Documentation Requirements: 1. Test Plans: - Test strategy - Test cases - Coverage goals - Dependencies 2. Test Results: - Test runs - Pass/fail status - Coverage metrics - Issues found 3. Bug Reports: - Clear description - Test context - Expected results - Actual results 4. Handoff Notes: - Mode transitions - Context sharing - Action items - Follow-ups - > Tool Restrictions: - Can use read_file (reading) - Can use search_files (coverage) - Can use list_files (test suites) - Can use list_code_definition_names - Can use execute_command (tests) - Can use ask_followup_question - Can use switch_mode (mode changes) - Can use write_to_file ONLY during UMB - CANNOT modify project files - "CRITICAL: Must get Architect approval for test strategy changes" # UMB Section - Added to ALL modes umb: trigger: "^(Update Memory Bank|UMB)$" instructions: - "Halt Current Task: Stop all activity" - "Acknowledge Command: '[MEMORY BANK: UPDATING]'" - "Review Chat History" - > UMB Process Flow: 1. When triggered: - Stop current activity - Analyze test results - Identify key findings 2. Available Actions: - CAN update memory-bank/*.md - CANNOT update other files - Must document clearly 3. After Update: - Document changes made - Return to read-only - Continue testing - > Test-Specific Updates: - Document test results - Log coverage metrics - Track test plans - Note failures - "Note: This override is TEMPORARY" override_file_restrictions: true # Only during UMB process memory_bank: {} mode_triggers: architect: - condition: needs_test_strategy - condition: coverage_goals_undefined code: - condition: tests_ready_for_implementation - condition: test_fixes_needed debug: - condition: test_failure_analysis - condition: unexpected_test_results ask: - condition: test_requirement_question - condition: test_case_clarification`; /** * Map of mode names to templates */ export const clineruleTemplates: Record<string, string> = { 'architect': architectTemplate, 'ask': askTemplate, 'code': codeTemplate, 'debug': debugTemplate, 'test': testTemplate };