Cline vs Roo Code: Which AI Coding Agent Has Better Rules Support?

Both Cline and Roo Code are VS Code AI coding agents built on top of the same open-source core. Both support project-level rules files. Both can be told “never touch this directory” or “always write tests before implementation.” But the way each agent interprets and applies those rules is different in ways that matter at production scale.

This is a technical comparison focused on the configuration layer — not a “which AI is smarter” debate.

The File System: Where Rules Live

Cline uses a single file or a flat directory:

.clinerules           # single-file mode
.clinerules/          # directory mode
  base.md
  testing.md
  frontend.md

In directory mode, Cline loads all files alphabetically and concatenates them into a single rules block. There is no hierarchy — every file is loaded every time.

Roo Code uses a more structured layout:

.roo/
  rules/              # global rules (all modes)
    base.md
    security.md
  rules-code/         # mode-specific: Code mode only
    typescript.md
  rules-architect/    # mode-specific: Architect mode only
    decisions.md
  rules-debug/        # mode-specific: Debug mode only
    diagnostics.md

The directory names follow the pattern rules-{mode}. Rules in rules/ apply everywhere. Rules in rules-{mode}/ apply only when that mode is active. This is the structural difference that matters most.

Mode-Specific Rules: The Roo Code Advantage

Cline is a single-mode agent. It has one behavior profile at a time. You can switch between presets, but there is no native concept of “architect mode” vs “code mode” at the rules level.

Roo Code ships with five built-in modes: Code, Architect, Ask, Debug, and Orchestrator. Each mode has a different system prompt, different tool permissions, and can have different rules files.

In practice, this means your Architect mode can require that every design decision references an ADR, while your Code mode stays focused on implementation details without cluttering the context with architectural governance rules.

# .roo/rules-architect/decisions.md

Every significant technical decision must include:
1. A reference to the relevant ADR (docs/adr/XXX.md)
2. The alternatives considered and why they were rejected
3. The estimated impact on the existing architecture

If no ADR exists for this decision, create one before proceeding.

# .roo/rules-code/typescript.md

- Use `satisfies` instead of `as` for type assertions
- Prefer `unknown` over `any`. If `any` is unavoidable, add a `// eslint-disable-next-line @typescript-eslint/no-explicit-any` comment with a reason
- Functional components only. No class components.
- Co-locate tests with source files (`foo.ts` → `foo.test.ts`)

These two files never conflict because they never appear in the same context at the same time.

Glob-Based Conditional Rules: Cline’s Answer

Cline doesn’t have modes, but it has per-file rules via YAML frontmatter:

---
globs:
  - "src/**/*.test.ts"
  - "tests/**/*.spec.ts"
---

These are test files. Follow these constraints:

- Do not import from `../src/internal` — only public exports
- Each test file must have a describe block named after the file's module
- Use `beforeEach` for setup, never `before` (Jest compatibility)
- Mock external HTTP calls with MSW, not jest.mock

When Cline opens a file matching those globs, it loads this rule set. When you switch to a non-test file, it drops those rules and loads whatever else applies.

This is powerful for monorepos where different packages have different standards. The Roo Code equivalent requires switching modes manually or adding mode-detection logic.

Context Budget and Token Overhead

Every line in your rules file costs tokens. This is true for both tools, but the loading strategy is different.

Cline loads all .clinerules content unconditionally (except glob-filtered files). A 1,000-line rules directory means 1,000 lines of context overhead on every single tool call.

Roo Code loads rules/ unconditionally but loads rules-{mode}/ only in the active mode. If you have 500 lines of global rules and 300 lines of mode-specific rules, you are paying for 800 lines maximum, not 1,000+.

Practical implication: if you are working on a project with many specialized contexts, Roo Code’s mode system lets you write richer rules without ballooning your context window. If you are on a single-mode workflow (most solo projects), the difference is negligible.

Custom Modes in Roo Code

Roo Code lets you define entirely custom modes beyond the five defaults. You configure them in .roomodes:

{
  "customModes": [
    {
      "slug": "review",
      "name": "Code Review",
      "roleDefinition": "You are a senior engineer reviewing code for correctness, security, and maintainability. You do not write new code — you only comment and suggest.",
      "groups": ["read"],
      "customInstructions": "Format feedback as a numbered list. Group by: Critical / Warning / Suggestion."
    }
  ]
}

Then add rules for it:

.roo/rules-review/
  review-checklist.md
  security-patterns.md

Cline has no equivalent. You can achieve something similar by maintaining multiple .clinerules files and manually swapping them, but that is a manual workflow, not a system.

MCP Server Permissions

Both tools support MCP servers. The difference is in how permissions are scoped.

Cline grants MCP access globally or per-project via cline_mcp_settings.json. There is no per-mode MCP scoping.

Roo Code’s custom mode configuration includes a groups key that controls which tool groups (and by extension, which MCP servers) are available in that mode. A review mode with groups: ["read"] literally cannot write files, run shell commands, or call write-enabled MCP tools — the capability is structurally absent, not just instructed away.

This is the more robust approach for teams where you want to guarantee that the AI cannot modify code while in review mode, not just hope it doesn’t.

Choosing Between Them

Use Cline if:

• You work in a single-mode, file-focused workflow
• You need glob-based conditional rules (Roo Code doesn’t have a direct equivalent)
• You want a simpler configuration surface

Use Roo Code if:

• You switch between design, implementation, and debugging contexts frequently
• You want mode-scoped MCP permissions (structural safety, not instructed safety)
• You are building a team workflow where different people operate in different modes
• You want to create specialized custom agents (reviewer, documenter, tester) within the same project

Both tools read from CLAUDE.md as well if you are also using Claude Code in the same project. The rule systems are additive — you can have .clinerules, .roo/rules/, and CLAUDE.md active simultaneously, though at that point you should audit for conflicts.

The Practical Recommendation

For solo developers, the difference rarely matters. Pick the agent you find more comfortable and write your rules.

For teams, Roo Code’s mode system earns its complexity. The ability to say “this mode cannot write code, only read it” is a meaningful safety property that .clinerules cannot replicate with instructions alone.

For monorepos with highly varied file types, Cline’s glob matching gives you precision that Roo Code’s mode system doesn’t directly offer.

The ideal setup for large teams: Roo Code for mode-scoped workflows, with a shared rules/ directory that holds universal standards, and mode-specific directories that hold role-specific behavior. Keep each rules file under 200 lines. Audit the context overhead quarterly.