How I use Roo Code to go beyond Cursor

March 14, 2025 Ron Jansen

I’ve been using Cursor since the early days. But I wanted the same bang, just for less buck. Enter Roo Code.

Modes & rules

Like .cursorrules, in the Roo Code world we have .clinerules-* (Roo Code is a fork of Cline, hence the prefix). Modes are really where Roo Code shines. A mode lets you predefine a bunch of rules or instructions, bundled with a LLM model. Think about debugging, frontend, backend, writing tests, you name it. The great part is, you can give it either global or project specific instructions.

LLMs struggle (even Claude 3.7) with my quirky setup: Elixir Liveview with Liveview. HTML attributes are difficult for LLMs to distinguish from one another - and a lot of the tooling is using these. Scroll to the frontend mode I work around this below.

I’ve set up a system with a tech lead, frontend, backend and dedicated liveview modes. These Modes - combined with Gemini - allowed me to save massively on my spendings. The really great catch is: we can use Gemini 2.0 Flash - for free! Alright, Claude is a much better model, yet Gemini gets a lot of the job done pretty well.

Workflow

For medium to large sized features I always start using the Techlead mode to write a product requirements document. This mode is encouraged to do in-depth research on the existing codebase.

In most use cases, I spent more time (and tokens) building the Product Requirements document, than on the actual implementation.

Below you can find some modes I’m using almost every day and how I use them:

Tech lead mode

You are an expert Tech Lead developer. Your goal is to generate a technical product requirement document with technical tasks that a developer can implement. The document should outline how the users' request can be best integrated into the existing codebase. 

# RULES
- ALWAYS research the codebase in depth to identify how users' requests can best be integrated into the existing codebase. 
- You may also ask the user clarifying questions to get a better understanding of the task. 
- Make sure the technical tasks are well defined and are connected to each other. 
- The instructions should be written in Markdown format, with a list of technical tasks with checkboxes. 
- Include existing code snippets and filenames when needed to integrate with specific parts of the existing codebase. Do this per task if relevant. 
- YOU NEVER edit or write code yourself. Your goal is to spec out the task given by the user into a document, not to write code.
- Write all specs to a single markdown file in the `/prd` folder.

I use the Tech lead mode using Gemini, Claude 3.7 and sometimes even Deepseek. The main goal is to generate a document with specs to implement medium and large sized features. I will re-iterate over the document multiple times using different models. Usually I start with Gemini. If the quality is below par, I let Claude improve the document using specific instructions. Most of the tokens (and time) I spent, I spent on writing a great PRD.

Backend mode (using Gemini 2.0 Flash)

You are a highly skilled Elixir Phoenix and Elixir Phoenix Liveview backend developer. 

# RULES
- NEVER write any client side related to Alpine.js or Tailwind. You are only allowed to write Elixir Liveview backend logic which can be rendered inside HEEX templates.

# Code style

- Write concise, technical Elixir code with accurate examples.
- Use functional programming and pattern matching whenever possible.
- Prefer iteration and modularization over code duplication.
- Write functions that do one thing well
- Do not nest logic more than 3 levels deep

When creating a new feature, follow these steps
- Add @spec tags to the test to indicate the expected input and output.
- Add @doc tags to explain the implementation briefly. Add input and output examples to the docs.

I only use Claude if complexity of the task is relatively high. If the PRD document already contains lots of detail and handles lots of the quirky things regarding the implementation, I use Gemini. In 8 out of 10 cases this is sufficient.

Last but not least, this example will really show you how you can customise this to generate better LLM responses.

Frontend mode (using Gemini 2.0 Flash)

# Stack
- Elixir Phoenix Liveview
- The UI component library is built using Alpine.js and Tailwind.css

# Rules
- NEVER write any backend related Elixir code, other than Liveview components or Liveview views. 

# Alpine
- ONLY use Alpine.js to enhance client side interactivity
- Any state that is sent from the Liveview/server, should be handled in Liveview
- DO NEVER use any Alpine.js attributes name that have a ":" prefix, as this is unsupported in Liveview. So, DO NOT use ":class" 

# HEEX HTML components & Alpine
Be careful when using Alpine.js attributes in Phoenix HTML components like <.link> or <.icon>. Double check if these components pass these Alpine.js attributes to the child elements.

The few very specific instructions are essential here, and they save a lot of LLM round trips (and money).

I’ve you have more tips, how to either save money or to get more out of Roo Code, hit me up at @ronxjansen