Blog · October 24, 2026 · Agentdex Editorial

Cline Example: The 2026 Guide for AI Coders and Indie Devs

Q: Where do Cline rules files go?

Workspace rules go in .clinerules/ or .cline/rules/ at the project root. Global rules go in your system's Cline Rules folder, such as ~/Documents/Cline/Rules on macOS and Linux. Workspace rules win when the two conflict.

Q: Do these examples work in Roo Code?

Roo Code shut down on May 15, 2026. If you used it, Cline is the project it was forked from and supports the same kind of workflow. See our Roo Code guide.

The fastest way to understand Cline (Agentdex profile) is to watch it handle real tasks. This guide walks through seven practical Cline examples, from a first Plan and Act session to rules files, Memory Bank, an MCP server, safe auto-approve settings and running Cline headless in a script. Every config snippet follows Cline's official documentation as of October 24, 2026. The prompts are examples to adapt, not recordings of our own sessions, and results will vary with your model and codebase. If you are new to Cline, start with our Cline guide for installation and pricing.

Key Takeaways

Plan first, then act. The most useful Cline habit is asking for a plan in Plan mode, correcting it, and only then switching to Act mode.
Rules files save repeated prompting. Put conventions in .clinerules/, and use paths frontmatter so a rule only loads for matching files.
Memory Bank keeps context between sessions through a set of Markdown files Cline reads at the start of each task.
MCP servers add tools. Local servers use command and args; remote servers need "type": "streamableHttp", or Cline falls back to legacy SSE.
Auto-approve with care. Approve read-only actions automatically, keep edits and commands manual, and note that the CLI's --auto-approve flag defaults to true.

Example 1: A first Plan and Act session

Open a project in VS Code, open the Cline panel and switch to Plan mode. In Plan mode Cline reads code and proposes an approach without changing anything.

Plan mode prompt:
Add a "forgot password" flow to this app. Look at how signup and login
work in src/auth/ first. Propose the files you would change, the new
routes and how you would test it. Do not write code yet.

Read the plan. Push back on anything you disagree with, for example: "Use the existing email helper in src/lib/email.ts instead of adding a new package." When the plan looks right, switch to Act mode and say "Go ahead with the plan." Cline then edits files and runs commands, asking for approval at each step unless you have auto-approved that action.

Why this works: most wasted tokens and bad diffs come from an agent starting in the wrong direction. A two-minute plan review prevents that.

Example 2: Pointing Cline at the right context

Cline works best when you tell it exactly where to look. Mention files and folders with @ in your prompt so it does not read the whole repository:

@/src/components/Cart.tsx the total is wrong when a discount code
is applied. Find the bug, fix it and add a test in
@/src/components/__tests__/Cart.test.tsx. Run npm test before you finish.

Three habits make prompts like this reliable: name the files, say what "done" means (a passing test), and give it the command to check its own work. If a session gets long, use the /newtask command to start a fresh task with a summary of the current one, or /smol to compress the conversation, so you are not paying for a huge context on every turn.

Example 3: A rules file for your project

Rules are Markdown files that Cline follows in every conversation. Put workspace rules in .clinerules/ (or .cline/rules/) at the project root and commit them so collaborators get the same behavior.

your-project/
├── .clinerules/
│   ├── 01-coding.md
│   ├── 02-testing.md
│   └── 03-frontend.md
└── src/

A simple, always-on rule (.clinerules/01-coding.md):

# Coding standards
- TypeScript only. No new JavaScript files.
- Use the existing API client in src/lib/api.ts for all HTTP calls.
- Never edit files in /legacy.
- Before finishing any task, run: npm run lint && npm test

A conditional rule that only loads when Cline works on matching files (.clinerules/03-frontend.md):

---
paths:
  - "src/components/**"
  - "src/hooks/**"
---
# React component guidelines
- Functional components with hooks only
- Move reusable logic into custom hooks
- One responsibility per component

Rules without frontmatter are always active. Cline also picks up .cursorrules, .windsurfrules and AGENTS.md, so rules you wrote for other tools carry over. Our guide to writing agent rules has more patterns.

Example 4: Memory Bank for longer projects

Cline does not remember past sessions on its own. Memory Bank is a documented pattern that fixes this with Markdown files in a memory-bank/ folder. The core files are:

File	What it holds
`projectbrief.md`	Core requirements and goals; the source of truth for scope
`productContext.md`	Why the project exists and how it should work for users
`activeContext.md`	Current focus, recent changes and next steps
`systemPatterns.md`	Architecture and key design decisions
`techContext.md`	Stack, setup and constraints
`progress.md`	What works, what is left and known issues

To set it up, copy the Memory Bank instructions from Cline's documentation into a rule file such as .clinerules/memory-bank.md, then use these prompts:

initialize memory bank      # creates the files for a new project
update memory bank          # reviews and updates every file
follow your custom instructions   # at the start of a new session

A good rhythm is to ask for "update memory bank" at the end of each working session, then start the next one fresh. It costs a few extra tokens per session and saves a lot of re-explaining.

Example 5: Adding an MCP server

The Model Context Protocol (MCP) lets Cline call external tools. You can browse servers in Cline's MCP Marketplace, or add one by hand: click the MCP Servers icon in the Cline panel, open Configure and click Configure MCP Servers to edit the settings JSON.

A local server runs as a process on your machine, defined with command and args. This entry adds the official filesystem reference server, limited to one folder:

{
  "mcpServers": {
    "project-files": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/your/docs"],
      "disabled": false,
      "autoApprove": []
    }
  }
}

A remote server is defined with a URL. Set the transport explicitly, because without "type" Cline defaults to the legacy SSE transport:

{
  "mcpServers": {
    "team-docs": {
      "type": "streamableHttp",
      "url": "https://example.com/mcp",
      "headers": { "Authorization": "Bearer YOUR_TOKEN" },
      "disabled": false,
      "autoApprove": []
    }
  }
}

In the terminal, the CLI does the same with cline mcp, or in one line:

cline mcp add files --yes -- npx -y @modelcontextprotocol/server-filesystem .

After adding a server, check that its tools appear in the MCP Servers panel and try one simple call, such as "list the files in my docs folder". Keep tokens in environment variables or headers, never in a file you commit.

Example 6: Safe auto-approve settings

Unless you change its auto-approve settings, Cline asks before it edits files, runs commands or calls MCP tools. Approving every step gets tiring, so a sensible middle ground is:

Action	Suggested setting
Read files in the project	Auto-approve
Read-only MCP tools you trust	Auto-approve by adding them to that server's `autoApprove` list
Edit files	Approve manually until you trust the workflow; checkpoints let you restore if needed
Terminal commands	Approve manually, especially installs, deletes and git pushes
YOLO mode (approve everything)	Only in throwaway or sandboxed projects

Cline's docs are blunt about YOLO mode: it auto-approves all file operations, terminal commands, browser actions, MCP tools and the switch from Plan to Act. Use it only where a mistake costs nothing. Whatever you choose, checkpoints let you compare Cline's changes or restore an earlier state if a task goes wrong.

Example 7: Cline in the terminal and in scripts

The Cline CLI runs the same agent without an editor. Install it with npm install -g cline (Node.js 20 or newer), sign in with cline auth, then:

# interactive session
cline

# plan first, in a headless run
cline -p "design a migration plan for moving sessions to Redis"

# pipe context in
git diff | cline "review these changes for potential regressions"

# chain tasks
git diff | cline "explain these changes" | cline "write a commit message"

# limit runtime
cline --timeout 600 "run the full test suite and summarize failures"

One important detail: in the CLI, --auto-approve defaults to true, so headless runs can change files and run commands without asking. Run them on a clean branch, review the result, and pass --auto-approve false when you want prompts. The CLI has no built-in command allow list; Cline's docs suggest a PreToolUse hook to block commands you do not want run.

Putting it together: a small feature, end to end

Your rules file states the stack and the test command (Example 3).
Memory Bank tells Cline where the project stands (Example 4).
In Plan mode, you ask for a plan for one feature and point at the relevant files (Examples 1 and 2).
In Act mode, Cline makes the change with file reads auto-approved and edits and commands approved by you (Example 6).
It runs the tests, you review the diff, and you ask it to "update memory bank" before closing.
Later, a headless git diff | cline "review..." gives you a second look before you merge (Example 7).

Cost and model tips for these examples

Cline is free; you pay for model usage through your own key, Cline credits, ClinePass ($9.99/month for more usage on selected open models) or a local model. Planning and debugging benefit from a strong model, while routine edits and commit messages work fine on a cheaper one. Each task's token use and cost show in the task history, so check it after your first few sessions. Our Cline pricing guide breaks down the options.

FAQ

Where does Cline store MCP settings?

In the VS Code extension, open the MCP Servers panel, go to Configure and click Configure MCP Servers to open the settings JSON. The CLI uses ~/.cline/data/settings/cline_mcp_settings.json, which you can override with the CLINE_MCP_SETTINGS_PATH environment variable.

Where do Cline rules files go?

Workspace rules go in .clinerules/ or .cline/rules/ at the project root. Global rules go in your system's Cline Rules folder, such as ~/Documents/Cline/Rules on macOS and Linux. Workspace rules win when the two conflict.

Do these examples work with local models?

Yes, with Ollama or LM Studio as the provider. Smaller local models can struggle with long agent tasks and tool calls, so keep tasks small and expect to guide them more.

Do I need an MCP server to get value from Cline?

No. Built-in file editing, terminal commands, browser use, rules and Memory Bank cover most day-to-day work. Add an MCP server when you have a specific recurring task that needs an outside tool or data source.

Do these examples work in Roo Code?

Roo Code (Agentdex profile) shut down on May 15, 2026. If you used it, Cline is the project it was forked from and supports the same kind of workflow. See our Roo Code guide.

Written by Agentdex Editorial. Agentdex is an independent directory reviewing AI coding tools; we are not affiliated with the companies mentioned. Prices and features are as of October 24, 2026, from official sources linked above. Always confirm on the vendor's site.