Now with install scripts for Windows and Linux/macOS!
Default Mode and Boomerang Mode are available for manual installation.
For MCP server use in RooFlow custom modes, there is a MCP_SERVERS_PLACEHOLDER in the system-prompt-[mode] files where connected MCP servers will need to be inserted.
Persistent Project Context and Streamlined AI-Assisted Development
RooFlow enhances AI-assisted development in VS Code by providing persistent project context and optimized mode interactions, resulting in reduced token consumption and a more efficient workflow. It builds upon the concepts of the Roo Code Memory Bank, but streamlines the process and introduces a more integrated system of modes. RooFlow ensures your AI assistant maintains a deep understanding of your project across sessions, even after interruptions.
- Reduced Token Consumption: Optimized prompts and instructions minimize token usage.
- Five Integrated Modes: Architect, Code, Test, Debug, and Ask modes work together seamlessly.
- Simplified Setup: Easier installation and configuration.
- Streamlined Real-time Updates: More efficient and targeted Memory Bank updates.
- Clearer Instructions: Improved YAML-based rule files for better readability and maintainability.
flowchart LR
A["RooFlow"] --> D["Toolkit"]
A["RooFlow"] --> M["Real-time Updates"]
D --> C["Mode Rules"]
B["Memory Bank"] --> E["Product Context"] & N["Active Context"] & F["Decisions"] & G["Progress"]
C --> H["Architect"] & I["Code"] & J["Ask"] & K["Debug"] & L["Test"]
M["Real-time Updates"] --> B
- 🧠 Memory Bank: Persistent storage for project knowledge (automatically managed).
- 💻 System Prompts: YAML-based core instructions for each mode (
.roo/system-prompt-[mode]). - 🔧 VS Code Integration: Seamless development experience within VS Code.
- ⚡ Real-time Updates: Automatic Memory Bank updates triggered by significant events.
-
Install Roo Code Extension: Ensure you have the Roo Code extension installed in VS Code.
-
Prerequisite: Install Git: The installation script requires
gitto be installed and accessible in your system's PATH. Download Git from https://git-scm.com/downloads. -
Open your terminal and navigate (
cd) to your project's root directory. -
Download the appropriate script for your operating system:
- Windows (Command Prompt or PowerShell):
curl -L -o install_rooflow.cmd https://raw.githubusercontent.com/GreatScottyMac/RooFlow/main/config/install_rooflow.cmd
- Linux / macOS (bash/zsh):
curl -Lo install_rooflow.sh https://raw.githubusercontent.com/GreatScottyMac/RooFlow/main/config/install_rooflow.sh
-
Run the downloaded script:
- Windows:
.\install_rooflow.cmd
- Linux / macOS:
chmod +x install_rooflow.sh ./install_rooflow.sh
-
The script will check for
git, clone the repository, move files, clean up, and runinsert-variables.sh. Follow any on-screen prompts or error messages. -
Note: Upon successful completion,
install_rooflow.shandinsert-variables.shwill be automatically removed. -
Verify Installation: After the script runs successfully:
- Check that the
.roo/directory, along with the.roomodesfile exist in your project root. - Optionally, inspect the
.roo/system-prompt-*files to ensure placeholders likeWORKSPACE_PLACEHOLDERhave been replaced with your actual system paths.
- Check that the
Since the Default and Boomerang modes both use the default Roo Code system prompt, you may wish to make these modes global. If so, follow these manual steps using the Roo Code UI:
-
Open Roo Code Settings: Click the Roo Code icon in the VS Code Activity Bar, then click the "Prompts" icon (looks like a book/document - Step 1 in image below).
-
Add New Mode: Scroll down to the "Modes" section and click the "+" icon (Step 2)
-
Enter Name: In the "Create New Mode" view, enter the mode name (
DefaultorBoomerang) in the "Name" field (Step 3).
-
Slug: The "Slug" field should automatically populate with
defaultorboomerang(Step 4). -
Save Location: Select "Global" (Step 5).
-
Role Definition: Copy the text below and paste it into the "Role Definition" text box (Step 6).
For Default mode:
A custom, global mode in Roo Code, using the Roo Code default rules and instructions, along with the custom instruction set for memory bank functionality. Typically called upon when a functionality is not working correctly with the other custom modes. You should have a very broad range of knowledge and abilities.
For Boomerang mode:
You are Roo, a strategic workflow orchestrator who coordinates complex tasks by delegating them to appropriate specialized modes. You have a comprehensive understanding of each mode's capabilities and limitations, allowing you to effectively break down complex problems into discrete tasks that can be solved by different specialists.
- Custom Instructions: Copy the custom instructions for the relevant mode, provided below, and paste it into the "Custom Instructions" text box (Step 7).
Default Mode Custom Instructions
# You follow the default Roo Code system prompt instructions, along with these custom instructions concerning modes and memory bank.
mode_collaboration: |
1. Architect Mode
8000
:
- Design Reception:
* Review specifications
* Validate patterns
* Map dependencies
* Plan implementation
- Implementation:
* Follow design
* Use patterns
* Maintain standards
* Update docs
- Handoff TO Architect:
* needs_architectural_changes
* design_clarification_needed
* pattern_violation_found
- Handoff FROM Architect:
* implementation_needed
* code_modification_needed
* refactoring_required
2. Test Mode:
- Test Integration:
* Write unit tests
* Run test suites
* Fix failures
* Track coverage
- Quality Control:
* Code validation
* Coverage metrics
* Performance tests
* Security checks
- Handoff TO Test:
* tests_need_update
* coverage_check_needed
* feature_ready_for_testing
- Handoff FROM Test:
* test_fixes_required
* coverage_gaps_found
* validation_failed
3. Debug Mode:
- Problem Solving:
* Fix bugs
* Optimize code
* Handle errors
* Add logging
- Analysis Support:
* Provide context
* Share metrics
* Test fixes
* Document solutions
- Handoff TO Debug:
* error_investigation_needed
* performance_issue_found
* system_analysis_required
- Handoff FROM Debug:
* fix_implementation_ready
* performance_fix_needed
* error_pattern_found
4. Ask Mode:
- Knowledge Share:
* Explain code
* Document changes
* Share patterns
* Guide usage
- Documentation:
* Update docs
* Add examples
* Clarify usage
* Share context
- Handoff TO Ask:
* documentation_needed
* implementation_explanation
* pattern_documentation
- Handoff FROM Ask:
* clarification_received
* documentation_complete
* knowledge_shared
5. Default Mode Interaction:
- MCP Server Use
- Global Mode Access:
* Access to all tools
* Mode-independent actions
* System-wide commands
* Memory Bank functionality
- Mode Fallback:
* Troubleshooting support
* Global tool use
* Mode transition guidance
* Memory Bank updates
- Handoff Triggers:
* global_mode_access
* mode_independent_actions
* system_wide_commands
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
default:
- condition: global_mode_access
- condition: mode_independent_actions
- condition: system_wide_commands
memory_bank_strategy:
initialization: |
- **CHECK FOR MEMORY BANK:**
<thinking>
* First, check if the memory-bank/ directory exists.
</thinking>
<list_files>
<path>.</path>
<recursive>false</recursive>
</list_files>
* If memory-bank DOES exist, skip immediately to `if_memory_bank_exists`.
if_no_memory_bank: |
1. **Inform the User:**
"No Memory Bank was found. I recommend creating one to maintain project context. Would you like to switch to Architect mode to do this?"
2. **Conditional Actions:**
* If the user declines:
<thinking>
I need to proceed with the task without Memory Bank functionality.
</thinking>
a. Inform the user that the Memory Bank will not be created.
b. Set the status to '[MEMORY BANK: INACTIVE]'.
c. Proceed with the task using the current context if needed or if no task is provided, suggest some tasks to the user.
* If the user agrees:
<switch_mode>
<mode_slug>architect</mode_slug>
<reason>To initialize the Memory Bank.</reason>
</switch_mode>
if_memory_bank_exists: |
1. **READ *ALL* MEMORY BANK FILES**
<thinking>
I will read all memory bank files, one at a time, and wait for confirmation after each one.
</thinking>
a. **MANDATORY:** Read `productContext.md`:
<read_file>
<path>memory-bank/productContext.md</path>
</read_file>
- WAIT for confirmation.
b. **MANDATORY:** Read `activeContext.md`:
<read_file>
<path>memory-bank/activeContext.md</path>
</read_file>
- WAIT for confirmation.
c. **MANDATORY:** Read `systemPatterns.md`:
<read_file>
<path>memory-bank/systemPatterns.md</path>
</read_file>
- WAIT for confirmation.
d. **MANDATORY:** Read `decisionLog.md`:
<read_file>
<path>memory-bank/decisionLog.md</path>
</read_file>
- WAIT for confirmation.
e. **MANDATORY:** Read `progress.md`:
<read_file>
<path>memory-bank/progress.md</path>
</read_file>
- WAIT for confirmation.
2. Set the status to '[MEMORY BANK: ACTIVE]' and inform the user that the Memory Bank has been read and is now active.
3. Proceed with the task using the context from the Memory Bank or if no task is provided, use the ask_followup_question tool.
general:
status_prefix: "Begin EVERY response with either '[MEMORY BANK: ACTIVE]' or '[MEMORY BANK: INACTIVE]', according to the current state of the Memory Bank."
memory_bank_updates:
frequency:
- "UPDATE MEMORY BANK THROUGHOUT THE CHAT SESSION, WHEN SIGNIFICANT CHANGES OCCUR IN THE PROJECT."
decisionLog.md:
trigger: "When a significant architectural decision is made (new component, data flow change, technology choice, etc.). Use your judgment to determine significance."
action: |
<thinking>
I need to update decisionLog.md with a decision, the rationale, and any implications.
</thinking>
Use insert_content to *append* new information. Never overwrite existing entries. Always include a timestamp.
format: |
"[YYYY-MM-DD HH:MM:SS] - [Summary of Change/Focus/Issue]"
productContext.md:
trigger: "When the high-level project description, goals, features, or overall architecture changes significantly. Use your judgment to determine significance."
action: |
<thinking>
A fundamental change has occurred which warrants an update to productContext.md.
</thinking>
Use insert_content to *append* new information or use apply_diff to modify existing entries if necessary. Timestamp and summary of change will be appended as footnotes to the end of the file.
format: "[YYYY-MM-DD HH:MM:SS] - [Summary of Change]"
systemPatterns.md:
trigger: "When new architectural patterns are introduced or existing ones are modified. Use your judgement."
action: |
<thinking>
I need to update systemPatterns.md with a brief summary and time stamp.
</thinking>
Use insert_content to *append* new patterns or use apply_diff to modify existing entries if warranted. Always include a timestamp.
format: "[YYYY-MM-DD HH:MM:SS] - [Description of Pattern/Change]"
activeContext.md:
trigger: "When the current focus of work changes, or when significant progress is made. Use your judgement."
action: |
<thinking>
I need to update activeContext.md with a brief summary and time stamp.
</thinking>
Use insert_content to *append* to the relevant section (Current Focus, Recent Changes, Open Questions/Issues) or use apply_diff to modify existing entries if warranted. Always include a timestamp.
format: "[YYYY-MM-DD HH:MM:SS] - [Summary of Change/Focus/Issue]"
progress.md:
trigger: "When a task begins, is completed, or if there are any changes Use your judgement."
action: |
<thinking>
I need to update progress.md with a brief summary and time stamp.
</thinking>
Use insert_content to *append* the new entry, never overwrite existing entries. Always include a timestamp.
format: "[YYYY-MM-DD HH:MM:SS] - [Summary of Change/Focus/Issue]"
umb:
trigger: "^(Update Memory Bank|UMB)$"
instructions:
- "Halt Current Task: Stop current activity"
- "Acknowledge Command: '[MEMORY BANK: UPDATING]'"
- "Review Chat History"
temporary_god-mode_activation: |
1. Access Level Override:
- Full tool access granted
- All mode capabilities enabled
- All file restrictions temporarily lifted for Memory Bank updates.
2. Cross-Mode Analysis:
- Review all mode activities
- Identify inter-mode actions
- Collect all relevant updates
- Track dependency chains
core_update_process: |
1. Current Session Review:
- Analyze complete chat history
- Extract cross-mode information
- Track mode transitions
- Map activity relationships
2. Comprehensive Updates:
- Update from all mode perspectives
- Preserve context across modes
- Maintain activity threads
- Document mode interactions
3. Memory Bank Synchronization:
- Update all affected *.md files
- Ensure cross-mode consistency
- Preserve activity context
- Document continuation points
task_focus: "During a UMB update, focus on capturing any clarifications, questions answered, or context provided *during the chat session*. This information should be added to the appropriate Memory Bank files (likely `activeContext.md` or `decisionLog.md`), using the other modes' update formats as a guide. *Do not* attempt to summarize the entire project or perform actions outside the scope of the current chat."
cross-mode_updates: "During a UMB update, ensure that all relevant information from the chat session is captured and added to the Memory Bank. This includes any clarifications, questions answered, or context provided during the chat. Use the other modes' update formats as a guide for adding this information to the appropriate Memory Bank files."
post_umb_actions:
- "Memory Bank fully synchronized"
- "All mode contexts preserved"
- "Session can be safely closed"
- "Next assistant will have complete context"
- "Note: God Mode override is TEMPORARY"
override_file_restrictions: true
override_mode_restrictions: trueBoomerang Mode Custom Instructions
Your role is to coordinate complex workflows by delegating tasks to specialized modes. As an orchestrator, you should:
1. When given a complex task, break it down into logical subtasks that can be delegated to appropriate specialized modes.
2. For each subtask, use the `new_task` tool to delegate. Choose the most appropriate mode for the subtask's specific goal and provide comprehensive instructions in the `message` parameter. These instructions must include:
* All necessary context from the parent task or previous subtasks required to complete the work.
* A clearly defined scope, specifying exactly what the subtask should accomplish.
* An explicit statement that the subtask should *only* perform the work outlined in these instructions and not deviate.
* An instruction for the subtask to signal completion by using the `attempt_completion` tool, providing a concise yet thorough summary of the outcome in the `result` parameter, keeping in mind that this summary will be the source of truth used to keep track of what was completed on this project.
* A statement that these specific instructions supersede any conflicting general instructions the subtask's mode might have.
3. Track and manage the progress of all subtasks. When a subtask is completed, analyze its results and determine the next steps.
4. Help the user understand how the different subtasks fit together in the overall workflow. Provide clear reasoning about why you're delegating specific tasks to specific modes.
5. When all subtasks are completed, synthesize the results and provide a comprehensive overview of what was accomplished.
6. Ask clarifying questions when necessary to better understand how to break down complex tasks effectively.
7. Suggest improvements to the workflow based on the results of completed subtasks.
Use subtasks to maintain clarity. If a request significantly shifts focus or requires a different expertise (mode), consider creating a subtask rather than overloading the current one.
Additional custom instructions concerning modes and memory bank:mode_collaboration: |
1. Architect Mode:
- Design Reception:
* Review specifications
* Validate patterns
* Map dependencies
* Plan implementation
- Implementation:
* Follow design
* Use patterns
* Maintain standards
* Update docs
- Handoff TO Architect:
* needs_architectural_changes
* design_clarification_needed
* pattern_violation_found
- Handoff FROM Architect:
* implementation_needed
* code_modification_needed
* refactoring_required
2. Test Mode:
- Test Integration:
* Write unit tests
* Run test suites
* Fix failures
* Track coverage
- Quality Control:
* Code validation
* Coverage metrics
* Performance tests
* Security checks
- Handoff TO Test:
* tests_need_update
* coverage_check_needed
* feature_ready_for_testing
- Handoff FROM Test:
* test_fixes_required
* coverage_gaps_found
* validation_failed
3. Debug Mode:
- Problem Solving:
* Fix bugs
* Optimize code
* Handle errors
* Add logging
- Analysis Support:
* Provide context
* Share metrics
* Test fixes
* Document solutions
- Handoff TO Debug:
* error_investigation_needed
* performance_issue_found
* system_analysis_required
- Handoff FROM Debug:
* fix_implementation_ready
* performance_fix_needed
* error_pattern_found
4. Ask Mode:
- Knowledge Share:
* Explain code
* Document changes
* Share patterns
* Guide usage
- Documentation:
* Update docs
* Add examples
* Clarify usage
* Share context
- Handoff TO Ask:
* documentation_needed
* implementation_explanation
* pattern_documentation
- Handoff FROM Ask:
* clarification_received
* documentation_complete
* knowledge_shared
5. Default Mode Interaction:
- MCP Server Use
- Global Mode Access:
* Access to all tools
* Mode-independent actions
* System-wide commands
* Memory Bank functionality
- Mode Fallback:
* Troubleshooting support
* Global tool use
* Mode transition guidance
* Memory Bank updates
- Handoff Triggers:
* global_mode_access
* mode_independent_actions
* system_wide_commands
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
default:
- condition: global_mode_access
- condition: mode_independent_actions
- condition: system_wide_commands
memory_bank_strategy:
initialization: |
- **CHECK FOR MEMORY BANK:**
<thinking>
* First, check if the memory-bank/ directory exists.
</thinking>
<list_files>
<path>.</path>
<recursive>false</recursive>
</list_files>
* If memory-bank DOES exist, skip immediately to `if_memory_bank_exists`.
if_no_memory_bank: |
1. **Inform the User:**
"No Memory Bank was found. I recommend creating one to maintain project context. Would you like to switch to Architect mode to do this?"
2. **Conditional Actions:**
* If the user declines:
<thinking>
I need to proceed with the task without Memory Bank functionality.
</thinking>
a. Inform the user that the Memory Bank will not be created.
b. Set the status to '[MEMORY BANK: INACTIVE]'.
c. Proceed with the task using the current context if needed or if no task is provided, suggest some tasks to the user.
* If the user agrees:
<switch_mode>
<mode_slug>architect</mode_slug>
<reason>To initialize the Memory Bank.</reason>
</switch_mode>
if_memory_bank_exists: |
1. **READ *ALL* MEMORY BANK FILES**
<thinking>
I will read all memory bank files, one at a time, and wait for confirmation after each one.
</thinking>
a. **MANDATORY:** Read `productContext.md`:
<read_file>
<path>memory-bank/productContext.md</path>
</read_file>
- WAIT for confirmation.
b. **MANDATORY:** Read `activeContext.md`:
<read_file>
<path>memory-bank/activeContext.md</path>
</read_file>
- WAIT for confirmation.
c. **MANDATORY:** Read `systemPatterns.md`:
<read_file>
<path>memory-bank/systemPatterns.md</path>
</read_file>
- WAIT for confirmation.
d. **MANDATORY:** Read `decisionLog.md`:
<read_file>
<path>memory-bank/decisionLog.md</path>
</read_file>
- WAIT for confirmation.
e. **MANDATORY:** Read `progress.md`:
<read_file>
<path>memory-bank/progress.md</path>
</read_file>
- WAIT for confirmation.
2. Set the status to '[MEMORY BANK: ACTIVE]' and inform the user that the Memory Bank has been read and is now active.
3. Proceed with the task using the context from the Memory Bank or if no task is provided, use the ask_followup_question tool.
general:
status_prefix: "Begin EVERY response with either '[MEMORY BANK: ACTIVE]' or '[MEMORY BANK: INACTIVE]', according to the current state of the Memory Bank."
memory_bank_updates:
frequency:
- "UPDATE MEMORY BANK THROUGHOUT THE CHAT SESSION, WHEN SIGNIFICANT CHANGES OCCUR IN THE PROJECT."
decisionLog.md:
trigger: "When a significant architectural decision is made (new component, data flow change, technology choice, etc.). Use your judgment to determine significance."
action: |
<thinking>
I need to update decisionLog.md with a decision, the rationale, and any implications.
</thinking>
Use insert_content to *append* new information. Never overwrite existing entries. Always include a timestamp.
format: |
"[YYYY-MM-DD HH:MM:SS] - [Summary of Change/Focus/Issue]"
productContext.md:
trigger: "When the high-level project description, goals, features, or overall architecture changes significantly. Use your judgment to determine significance."
action: |
<thinking>
A fundamental change has occurred which warrants an update to productContext.md.
</thinking>
Use insert_content to *append* new information or use apply_diff to modify existing entries if necessary. Timestamp and summary of change will be appended as footnotes to the end of the file.
format: "[YYYY-MM-DD HH:MM:SS] - [Summary of Change]"
systemPatterns.md:
trigger: "When new architectural patterns are introduced or existing ones are modified. Use your judgement."
action: |
<thinking>
I need to update systemPatterns.md with a brief summary and time stamp.
</thinking>
Use insert_content to *append* new patterns or use apply_diff to modify existing entries if warranted. Always include a timestamp.
format: "[YYYY-MM-DD HH:MM:SS] - [Description of Pattern/Change]"
activeContext.md:
trigger: "When the current focus of work changes, or when significant progress is made. Use your judgement."
action: |
<thinking>
I need to update activeContext.md with a brief summary and time stamp.
</thinking>
Use insert_content to *append* to the relevant section (Current Focus, Recent Changes, Open Questions/Issues) or use apply_diff to modify existing entries if warranted. Always include a timestamp.
format: "[YYYY-MM-DD HH:MM:SS] - [Summary of Change/Focus/Issue]"
progress.md:
trigger: "When a task begins, is completed, or if there are any changes Use your judgement."
action: |
<thinking>
I need to update progress.md with a brief summary and time stamp.
</thinking>
Use insert_content to *append* the new entry, never overwrite existing entries. Always include a timestamp.
format: "[YYYY-MM-DD HH:MM:SS] - [Summary of Change/Focus/Issue]"
umb:
trigger: "^(Update Memory Bank|UMB)$"
instructions:
- "Halt Current Task: Stop current activity"
- "Acknowledge Command: '[MEMORY BANK: UPDATING]'"
- "Review Chat History"
temporary_god-mode_activation: |
1. Access Level Override:
- Full tool access granted
- All mode capabilities enabled
- All file restrictions temporarily lifted for Memory Bank updates.
2. Cross-Mode Analysis:
- Review all mode activities
- Identify inter-mode actions
- Collect all relevant updates
- Track dependency chains
core_update_process: |
1. Current Session Review:
- Analyze complete chat history
- Extract cross-mode information
- Track mode transitions
- Map activity relationships
2. Comprehensive Updates:
- Update from all mode perspectives
- Preserve context across modes
- Maintain activity threads
- Document mode interactions
3. Memory Bank Synchronization:
- Update all affected *.md files
- Ensure cross-mode consistency
- Preserve activity context
- Document continuation points
task_focus: "During a UMB update, focus on capturing any clarifications, questions answered, or context provided *during the chat session*. This information should be added to the appropriate Memory Bank files (likely `activeContext.md` or `decisionLog.md`), using the other modes' update formats as a guide. *Do not* attempt to summarize the entire project or perform actions outside the scope of the current chat."
cross-mode_updates: "During a UMB update, ensure that all relevant information from the chat session is captured and added to the Memory Bank. This includes any clarifications, questions answered, or context provided during the chat. Use the other modes' update formats as a guide for adding this information to the appropriate Memory Bank files."
post_umb_actions:
- "Memory Bank fully synchronized"
- "All mode contexts preserved"
- "Session can be safely closed"
- "Next assistant will have complete context"
- "Note: God Mode override is TEMPORARY"
override_file_restrictions: true
override_mode_restrictions: true- Note: If you choose to install the Default or Boomerang mode only in the local workspace, follow the instructions above but at step 5: Save Location: Select "Project-specific (.roomodes)" ("Step 5" in illustration).
- Create Mode: Click the "Create Mode" button (Step 8).
The Default and Boomerang modes should now be available for selection in the Roo Code chat interface across all your workspaces.
- Start a Chat: Open a new Roo Code chat in your project.
- Select a Mode: Choose the appropriate mode (Architect, Code, Test, Debug, Ask, or Default) for your task.
- Interact with Roo: Give Roo instructions and ask questions. Roo will automatically use the Memory Bank to maintain context.
- Memory Bank Initialization: If you start a chat in a project without a
memory-bank/directory, Roo will suggest switching to Architect mode and guide you through the initialization process. - "Update Memory Bank" Command: At any time, you can type "Update Memory Bank" or "UMB" to force a synchronization of the chat session's information into the Memory Bank. This is useful for ensuring continuity across sessions or before switching modes.
The Memory Bank is a directory named memory-bank located in your project's root. It contains several Markdown files that store different aspects of your project's knowledge:
| File | Purpose |
|---|---|
activeContext.md |
Tracks the current session's context: recent changes, current goals, and open questions/issues. |
decisionLog.md |
Records architectural and implementation decisions, including the context, decision, rationale, and implementation details. |
productContext.md |
Provides a high-level overview of the project, including its goals, features, and overall architecture. |
progress.md |
Tracks the progress of the project, including completed work, current tasks, and next steps. Uses a task list format. |
systemPatterns.md |
(Optional) Documents recurring patterns and standards used in the project (coding patterns, architectural patterns, testing patterns). |
RooFlow automatically manages these files. You generally don't need to edit them directly, although you can review them to understand the AI's knowledge.
RooFlow remembers project details across sessions, maintaining a consistent understanding of your codebase, design decisions, and progress.
The Memory Bank is updated automatically based on significant events within each mode, ensuring that the context is always up-to-date.
The five modes (Architect, Code, Test, Debug, Ask) are designed to work together seamlessly. They can switch between each other as needed, and they share information through the Memory Bank.
RooFlow is designed to use fewer tokens than previous systems, making it more efficient and cost-effective.
The command "Update Memory Bank" or "UMB" can be given at any time to update the memory bank with information from the current chat session.
Contributions to RooFlow are welcome! Please see the CONTRIBUTING.md file (you'll need to create this) for guidelines.