Roo Code — formerly Roo Cline, a fork of Cline — is an autonomous coding agent that I’ve been getting a lot of use from over the past few months. When I first tried it out, I struggled to get any real value from it. I retreated back to what I knew: writing code myself and occasionally copy-pasting snippets into AI chat applications for suggestions.
But as I browsed more online AI coding communities, I kept seeing positive testimonials about Roo Code’s capabilities. I decided to give it another chance—this time armed with advice I had gathered from the internet. Once I implemented a few key strategies and gained more experience with it, Roo Code really started to shine.
In this guide, I’ll walk you through how I’ve been able to effectively use Roo Code in my development workflow.
Setting Up Roo
Before getting started, here are some things you’ll need to use Roo Code.
VS Code installed on your computer
Roo Code extension installed in VS Code. For installation instructions, follow this guide.
Access to an LLM API, either running remotely or locally on your machine
If using a remote service like Anthropic (which I’ll be using for this guide), you’ll need an API key. I’ve been using Anthropic’s Claude 3.7 Sonnet model since I have access to it, and it’s provided me with the best results over other models by Anthropic and OpenAI, and I have yet to use any local models.
At least one service provider configured in Roo Code
See configuration instructions here.
Setting Up Project Memory
One of the biggest changes that took Roo Code to the next level for me was integrating a tool that allowed me to persist project context across tasks. This was initially what kept me away from Roo Code – I would constantly have to remind it of certain aspects of the project like coding standards, architecture decisions, and implementation details. Once I integrated a solution for this, it boosted Roo Code’s effectiveness dramatically.
I’ve been using Roo Code Memory Bank by GreatScottyMac. This tool creates a structured way for Roo to remember important details about your project between sessions, maintaining consistency in how it approaches your codebase. I recommend giving the README a thorough review as it provides valuable information about what the memory bank does and how to utilize it. If you want to get a closer look at the implementation details, check out the Developer Primer which shows the intricacies of how it all comes together.
To install Memory Bank, you need to copy the .clinerules-* and .roomodes files to the root of your project. The .clinerules-* files contain instructions that Roo Code follows in a given mode – for example, the .clinerules-architect file is used when you’re in architect mode. The .roomodes file allows you to create custom modes for use in Roo Code. At the time of writing, it only adds a “Test” mode. We’ll explore these rules and modes in more detail later.
Note: I’m intentionally keeping the setup instructions somewhat vague here as the author of Memory Bank has made significant changes in the short time I’ve been using this tool. The README currently says “Major Update Coming Soon!” which suggests these changes will continue, so check the repository for the most up-to-date installation instructions.
Initializing Memory Bank
Before initialization, you should create a projectBrief.md file in your project root. This file should contain initial information about your project such as technologies you would like to use, key features, a high level architecture description, coding standards, and anything else that would be useful for Roo to know to start your project. This is essential if you’re starting from scratch. While not absolutely necessary for ongoing projects, it’s still valuable to include.
Once you’ve completed the installation steps above, open Roo in “Architect” or “Code” mode and send the message “hello”. This should automatically initialize the memory files in a memory-bank directory in your project.
Here’s what each of the generated memory files does:
activeContext.md: Contains information about the current taskproductContext.md: Contains high-level project informationprogress.md: Documents completed work and upcoming tasksdecisionLog.md: Records choices and their rationale
For more detailed information about these files and how to use them effectively, refer to the Memory Bank documentation.
Note: As Roo sets up your memory bank, it will prompt you to approve every task that involves a write. This is configured out of the box that way. I recommend keeping it this way for reasons we will get into later.
Now that we’ve got our memory bank setup, we can actually start building the project.
General Workflow Strategy
When working with Roo Code and Memory Bank, following a consistent workflow helps maximize productivity while maintaining code quality. Here’s the approach I’ve found most effective:
Always Start in Architect Mode
I recommend always starting in Architect mode. When you do this, Roo will craft an implementation plan that can be referenced by you, but more importantly by future Roo tasks to maintain project context.
Tip: I do not recommend asking Roo to do anything you yourself don’t know how to do. This may be fine for small things like one-off scripts, or spike projects, but will fall apart if you have to build anything that should be maintained over a long period of time. The worse your code gets, the harder it is going to be for you to understand, and the harder it is going to become to ask Roo for help, until you have an unmaintainable mess. I try to use Roo as a tool to do what I would have done, only faster. It sometimes will do things that are more clever than I could have come up with on my own, but I usually am able to understand the result.
I’m building a todo application while working through this and I would like to setup my data access layer first with domain types that map to the database record types. To do this I’ll send the following message in architect mode:
I want to architect a plan to create the data access layer for this app, along side domain types.
In my project, Roo made a dataAccessArchitecture.md file and an implementationPlan file explaining how we should proceed. It also updated the relevant memory-bank files with relevant information to each file for the plan it made.
Keep The Scope Of Each Task Small
The implementation plan Roo made was solid. However, the plan that it made included more than just database code and domain types, it also included a plan to completely wire up the data access layer from the database to the frontend. While we will eventually need to do this, that is a lot of extra information for Roo to handle. If you’ve used AI for any tasks, you’ll know that the quality of responses provided by an LLM is inversely related to the size of the input to the LLM. For this reason, I recommend forcing Roo to keep the scope of every task you’re doing as small as possible.
Be As Specific As Possible
In order to trim the scope down, it is useful to be as specific as possible when beginning a task. This means telling Roo what you want it to do and what you don’t want it to do. For even better output, I also highly recommend adding examples for what you do and don’t want it to do.
Returning back to what we set out to do last, I’ve edited the input message to trim out the parts mentioning the data access layer and came out with this:
I want to create a plan to create our domain types for todos. Start by creating a `Todo` type with all of the relevant information for a todo. Do not create anything other than these types. That means no database code, UI code, or anything that is not generating domain types.
For more information on how to effectively communicate with Roo, checkout their docs on typing your requests.
Make Corrections
The plan that Roo created was much smaller in scope. Great! But it created a few things that were unnecessary for the task at hand. Namely it created filter and sort types.
I could do what I did in the last section and start from scratch with a new task and more specific instructions, but since the correction I need it to make is pretty small, I can just instruct it to change within the chat. There isn’t an explicit rule for when you should just correct Roo vs starting from scratch. I’ve found that you start to get a feel for when to do so with experience.
In this case, I did not approve the creation of the initial implementation plan. Instead I sent a new message in the same task:
Just start with the Todo type for now. Do not include tags, filters or sorts for now.
That pared down the scope of the implementation quite nicely! Now we can get started with implementation.
Switch To Code Mode
After you’re done architecting a plan, you can create a new task, switch it to “Code” and tell it to begin implementing the plan. I’ve found that in this case you can be fairly generic, as long as the memory bank has been updated correctly. For this I can say something as simple as:
Implement the plan that is described in the active context
Roo will then begin analyzing the relevant files, and once it has enough context will begin implementing the plan you made earlier. Pretty cool right?
Use Checkpoints to Course Correct
There have been times when I’ve used Roo where I’m not being as vigilant about what edits I’m approving. Before I know it, I have no idea what or why Roo is trying to do something. This is where checkpoints come in handy. Checkpoints allow you to rollback changes made by Roo Code. According to Roo’s docs a checkpoint is made whenever:
- A task is started.
- A file is created, modified, or deleted.
- A command is executed.
Say for instance, Roo was doing something completely bonkers in the last four or five edits it made. You can scroll back in the chat history and find “Checkpoint” entries. There are two buttons: one to view the diff of that action and another to rollback to that point of the code. If you press the second button, you’ll be presented with an option to “Restore Files” and an option to “Restore Files & Task”. I have yet to find a reason to use only “Restore Files”, so I always use “Restore Files & Task” in this case.
Manually Intervene When Necessary
Roo is able to see when there are syntax or linting errors in the code and go back and automatically fix them. This is great when Roo is smart enough to fix them, but really annoying when it is not.
For instance, I’ve found that when Roo tries to fix TypeScript errors that are related to using the any type, it really struggles to fix things on its own. I’ve had it happen multiple times where Roo will try to fix this type of issue multiple times on its own and never succeed in doing so.
Remember how I mentioned earlier how you should keep write approval on? This situation is why. If you auto-approve writes, Roo will get caught in a loop of trying to fix an issue that you could fix a lot faster. It also allows you to stop and review any changes that Roo is making before it makes them and course correct.
When Roo makes edits, it displays the edit it’s going to make in a diff view in VS Code. You are able to edit the diff before actually saving the changes. Once you save the changes in the chat, Roo will see the changes you made and keep note of them before moving on to the next task.
Stop And Takeover If Necessary
If you’re unable to steer Roo in the right direction, odds are it’s going to be easier to just do the job yourself. Roo isn’t perfect so there are going to be times where it fails. I’ve had a few experiences where I make multiple attempts to correct the path Roo is taking, only for me to realize it’s a fruitless effort, then make the change I wanted it to make in less time than I spent trying to get it to do what I want.
Again, I don’t have an explicit rule for when to give up. You start to get a feel for things as you get more experience with the tool. This goes in conjunction with my earlier tip of only having Roo do what you know how to do. If Roo gets in this state trying to do something that you don’t understand, you’ll run into a wall, or have to start over since you won’t know how to get past the relevant issue on your own.
Rinse and Repeat
Once you’ve completed a task that was planned by the architect mode, you can start a new task and tell Roo to continue implementing the plan. I find that it usually works to say something like:
Continue implementing the plan we have started in the active context
If you feel like being more specific, the end of the last task will usually include a recommendation on where to start next if needed. I recommend using that info to prompt the next task. For instance, in my todo app, it ended with the following text: “The next step would be to create database schema based on the defined domain types”. So I take that and start a new task with the prompt:
Implement the next task of creating the database schema based on the types that are created
Tools To Enhance Your Roo Experience
Now that we’ve gone over the general workflow let’s dig into tools you should use to get the most out of Roo:
Context Mentions
Roo allows you to pass in specific information about your project via context mentions. You do this by typing in “@” in the message input and an options menu appears. If you just start typing, you will fuzzy search for files and folders in your project to include. I use those the most, but there are other options available:
@/path/to/file.js:10-20to reference specific line ranges@terminalto share terminal output@git-changesto show uncommitted changes@open-tabsto reference currently open files
These context mentions help you provide Roo with the perfect amount of information needed for a task without overwhelming it.
MCP Servers
Roo also allows you to connect it to various MCP servers to augment its capabilities by connecting it to external data sources. I’ve gotten a lot of use out of the postgres mcp server which allows Roo to connect to my database and run queries with my approval. There are a lot of community made MCP servers out there. I recommend looking at awesome-mcp-servers on GitHub to get a sample of them.
Not only are there a plethora of community build MCP servers, you can actually ask Roo to build an MCP server for you! All you have to do is say “Build me a tool that does X” in the chat box and it will build one for you. I have yet to use this feature since my needs have been met by community MCP servers, but I recommend giving this a try.
Alternative Memory System (Handoffs)
While I have gotten a lot of benefit out of the memory bank system mentioned above it’s not the only option. There is another tool called handoff manager that attempts to solve the context retention problem a different way. Instead of having a set amount of monolithic files that are updated, you create handoff documents as you go along. These can then be referenced by your future tasks to complete work with more context. The benefit of this over the memory bank system is that you in theory should only be providing Roo with enough context to complete the current task and nothing more. I’ve not tried this but I’ve read positive testimonials in online communities related to Roo, so I recommend giving this a shot when you have a chance.
Conclusion
Roo Code has transformed from a tool I initially struggled with to an essential part of my development workflow. By following the workflow strategies outlined in this article, you can establish an effective human-AI collaboration that respects both the strengths and limitations of AI coding assistants.