Why does Cline forget my coding style?

Cline forgets your coding style because every new task starts with a fresh conversation, and style rules live either in your Custom Instructions or in a hand-maintained memory-bank/ or .clinerules file inside one workspace. Anything you only told the agent in chat is gone. The fix is to store style as queryable memory the agent loads automatically on every task.

Cline is a VS Code coding agent that runs in plan/act mode and is scoped to the current workspace. Three design choices push your style rules out of the model's working memory:

1. Conversations are task-local. Every New Task opens a clean window. Style rules you typed mid-chat — "use Tailwind utility classes, not styled-components" — only existed in that conversation. The next task does not see them.

2. Custom Instructions are global, not project-specific. Cline's Custom Instructions field in settings applies the same rules to every workspace. Useful for "always write tests", awkward for "this repo uses Vitest, that one uses Jest". You can split rules into .clinerules files per workspace, but you have to remember to write them and keep them current.

3. The Memory Bank does not auto-capture style decisions. The community memory-bank/ pattern includes a systemPatterns.md file, but updates are manual. If you decided in chat to prefer Result<T, E> over throwing, that decision lives in the closed task transcript, not in your Memory Bank.

The result: style is enforced for the length of a conversation, then forgotten.

The cost of style drift is bigger than it looks:

• Inconsistent diffs. Half the new files use named exports, half use default. Half use the cn() helper, half import clsx directly. Code reviewers spend their time on style nits instead of logic.
• Re-litigated decisions. "We agreed last week to drop barrel exports" is something Cline cheerfully proposes again because the rule was never written down where the agent looks.
• Onboarding friction. A teammate spinning up Cline in the same repo inherits none of your style understanding unless you committed it to .clinerules or the Memory Bank.

The fix is not "write a stricter Custom Instructions" — it is to keep style rules as project memory that loads on every task.

Cline gives you three ways to persist rules. None survives a workspace switch without manual upkeep.

Custom Instructions is a single global text field in Cline's settings. It applies to every project, which makes per-repo style rules messy. You end up either bloating the field with every project's quirks or writing generic rules that the agent overrides with reasonable defaults.

`.clinerules` files let you check repo-specific rules into source control. This is closer to what you want, but the file is static markdown — there is no automatic capture, no versioning beyond git, and no way to add a rule "from inside a task" without manually editing the file.

Memory Bank (community pattern) stores conventions in systemPatterns.md and techContext.md. Same trade-off as .clinerules: useful, manual, and stuck inside one repo. The open-source codebase and convention docs live at github.com/cline/cline, if you want to see how the extension reads these files.

The deeper issue is that style is a project asset, not a chat asset. You probably switch between Cline, Cursor, and Claude Code depending on the task. You run Cline on a laptop and a desktop. None of these share .clinerules, and the Memory Bank only travels if you remember to commit it.

Coding style needs to live above the editor, or it drifts the moment you leave the editor.

MemoryLake is a cross-model memory layer Cline reads from on every task. Instead of editing .clinerules by hand, you store style decisions as Memories in the project and let every new task open with them already loaded.

• Style as queryable memory. "We use named exports, Tailwind, and Result types" lives as structured Memories, not buried in a markdown file. Cline retrieves the relevant rules per file you touch, not a giant style dump.
• Same rules across machines, teammates, and editors. The project's style memory is the same whether you open Cline on your laptop, your teammate opens it on theirs, or you swap to Cursor or Claude Code for a quick task.
• 10,000× the retrieval reach of raw prompting. MemoryLake's retrieval engine reads from billions of tokens of project memory and feeds Cline only the style rules that matter for the file in front of it.

MemoryLake scored 94.03% on the LoCoMo long-context benchmark, the top published result as of 2026, with millisecond retrieval and AES-256 end-to-end encryption.

1. Create a project and load your context. Sign in to MemoryLake, open Project Management, click Create Project, and name it "Cline — Acme web style". Upload your existing .clinerules, style guide, ESLint config, and ADRs through the Document Drive. Add explicit style rules — "named exports only", "Tailwind utility classes" — as Memories in the Memories tab.
2. Generate an MCP Server endpoint. Open the MCP Servers tab inside your project, click Add MCP Server, name it "Cline style memory", and click Generate. MemoryLake returns an API key ID, secret, and endpoint URL. Copy the Bearer token immediately — it is shown only once.
3. Connect Cline through VS Code MCP settings. Open Cline's MCP Servers panel in VS Code, click Add Server, paste the MemoryLake endpoint URL, and add the Bearer token in the auth header. Reload the window. Every new task now opens with your style rules retrieved per file, no copy-paste required.