How to Migrate From Cline to Kilo Code Without Losing Context (2026)

Your memory-bank/ directory transfers untouched. projectbrief.md, productContext.md, activeContext.md, systemPatterns.md, techContext.md, and progress.md are ordinary Markdown files in your repository. Nothing about them is Cline-specific. Cline's docs describe them as "regular markdown files in your project that both you and Cline can access." Leave them exactly where they are.

Your AGENTS.md transfers, if you have one. Cline reads AGENTS.md and ~/.agents/AGENTS.md as the "standard format for cross-tool compatibility." Kilo Code reads AGENTS.md at the project root, falling back to AGENT.md, and its docs warn that "the filename must be uppercase (AGENTS.md), not lowercase." If you already had one, that is the one file that needs no thought.

Your .clinerules/ directory does not transfer as a discovered source. Kilo Code's documented instruction sources are AGENTS.md and AGENT.md at the project root, the instructions key in project and global kilo.jsonc, .kilo/rules/ files, and — for backward compatibility — .kilocode/rules/ directories and legacy .kilocoderules files. The CLI "also supports .claude/ and .agents/ directories for compatibility with other tools." .clinerules/ is not on that list.

This is the sharp edge, because .clinerules/memory-bank.md is where the Memory Bank instruction lives if you followed Cline's setup. Move to Kilo without addressing it and your memory-bank/ files sit in the repository, complete and current, and nothing reads them. Cline's own instruction text is explicit about why that is fatal to the pattern: "I MUST read ALL memory bank files at the start of EVERY task — this is not optional." Remove the instruction and the files become documentation nobody opens.

Your conditional rules do not transfer. Cline supports scoping via a paths array in YAML front matter, and evaluates it against real working context: "it gathers context from your current work (open files, visible tabs, mentioned paths, edited files), evaluates each rule's conditions, and activates matching rules." Kilo Code's instructions key takes file paths and glob patterns, but those globs select which files to load, not when to load them. The one conditional behavior Kilo does document is different in kind: per-directory AGENTS.md files are "dynamically loaded when the agent reads files in that directory — they are not pre-loaded at session start," and their contents get "injected into the conversation as <system-reminder> tags." That is useful, and it is directory-based rather than glob-based, so a rule scoped to **/*.test.ts across the tree has no direct equivalent.

Rule combination behaves differently. Cline "processes all .md and .txt files inside .clinerules/, combining them into a unified set of rules," with numeric prefixes as an optional ordering convention, and "workspace rules take precedence when they conflict with global rules." Kilo Code publishes an explicit priority list instead: a per-agent prompt in config is highest, then the project instructions key in kilo.jsonc, then AGENTS.md at the project root, then the global instructions key, with Skills loaded on demand. Note where root AGENTS.md sits — below the project instructions key, not above it.

Both tools leave the same thing out. Neither documents a store that accumulates what your team learned across projects and people. Cline's answer is a documentation methodology you maintain; Kilo's is AGENTS.md plus rule files you maintain. Memory Bank exists precisely because that gap is real — it is the reason assistants feel forgetful even when they are well configured — and it is worth remembering when you decide where its content should live.

Step 1: Re-attach the instruction, not the content

You have two clean ways to make Kilo run the Memory Bank pattern, and they are not equivalent.

The straightforward option is the instructions key in your project's kilo.jsonc. Point it at the rule file you already have — the same .clinerules/memory-bank.md, or a copy relocated to .kilo/rules/memory-bank.md if you would rather not keep a Cline-named directory around. Kilo's docs show instructions taking both explicit paths and globs, so a single entry covers a whole rules folder. This sits at priority two, above root AGENTS.md, which is the right place for an instruction that has to run before anything else.

The other option is to put the instruction text into AGENTS.md. That is what Kilo's deprecation note points toward, and it works. It also means the instruction is subject to Kilo's file protection, discussed in the next step, and it competes for space with the rest of your AGENTS.md.

Whichever you pick, adjust the command vocabulary. Cline's Memory Bank instruction is written around three phrases — "follow your custom instructions," "initialize memory bank," and "update memory bank." The first is the one that depends on a Cline concept. Rewrite it into a direct statement: read every file in memory-bank/ before starting any task. The other two are plain English instructions to the agent and carry over as-is.

Then verify by starting a fresh task and asking what guidance the agent loaded. You are looking for the memory-bank/ file list. Cline gave you a visible signal here — a "Conditional rules applied" notification — and Kilo's equivalent signal for per-directory files is the <system-reminder> injection, so ask rather than assume.

Step 2: Do not pour memory-bank content into AGENTS.md

Kilo's deprecation note gives a two-step migration for its own memory bank: "Examine the contents in .kilo/rules/memory-bank/ (or the legacy .kilocode/rules/memory-bank/)" and "move that content into your project's AGENTS.md file (or ask Kilo to do it for you)." That advice is correct for what it describes — Kilo's memory bank lived inside its rules directory, so consolidating it into AGENTS.md is a simplification.

Applied to Cline's Memory Bank, the same move breaks the thing that makes it work. Here is why, in Kilo's own words: "Both AGENTS.md and AGENT.md are write-protected files in Kilo Code," which means "the AI agent cannot modify these files without explicit user approval" and "you'll be prompted to confirm any changes to these files."

Memory Bank is not a static document. activeContext.md is the file Cline's docs say "updates most frequently" and advise updating "after each session"; progress.md tracks milestones. The whole pattern depends on the agent being able to write to those files when you say "update memory bank." Merge them into AGENTS.md and every one of those writes becomes an approval prompt — which either trains you to click through prompts on your project's configuration file, or trains you to stop running the update.

So keep the split: the instruction goes into an instruction source, and the content stays in memory-bank/*.md, which are ordinary project files with no special protection. That split is also better hygiene independent of Kilo. It keeps a file the agent rewrites constantly out of the file that defines your project's guardrails. If you do want a canonical AGENTS.md as well, migrating CLAUDE.md to AGENTS.md covers the shape of that file.

One more thing to expect and not worry about: Kilo notes that "legacy Memory Bank status indicators such as [Memory Bank: Active] and [Memory Bank: Missing] can still appear, but they are not guaranteed across all clients or modes." If you have been reading a badge to confirm the pattern is live, stop. Ask the agent what it loaded instead.

Memory Bank's insight is right: agents need a durable record, and a folder of Markdown is a completely reasonable first implementation. Its limits are also structural, and you probably know them already.

It is per repository, so knowledge that spans services has to be duplicated or lost. It is per tool in practice, because the instruction that activates it is tool-specific — which is the entire reason this migration has steps. It has no retrieval; every task reads all six files, whether or not they are relevant. And it belongs to whoever remembers to run "update memory bank," which is why it goes stale on teams and why context walks out the door with people, a problem we covered in keeping AI context when someone leaves.

MemoryLake is the same idea with those four limits removed: one store outside any repository or editor, readable over MCP or an API, retrievable rather than read wholesale, and shared across a team. Your memory-bank/ files are a good seed for it.

Step 1: Create an API key

Generate a key and make your first request in about thirty seconds. One key works from Kilo Code, from Cline if teammates are still on it, and from whatever comes next.

Step 2: Upload your first memories

Drop in the documents, images, and files you already have — starting with systemPatterns.md, techContext.md, and progress.md, which are usually the three that hold real decisions rather than restatements of the README.

Step 3: Connect your AI & agents

Give Claude, Codex, OpenClaw, and other agents access over MCP or the API. In Kilo Code, that turns "read all six files every task" into retrieving the two facts that matter for the task in front of you.

The mandatory full read goes away. Cline's instruction text insists on reading every memory bank file at the start of every task because there is no retrieval layer — it is the only way to guarantee the relevant file is included. With retrieval, that requirement stops being necessary, the same way it stops being necessary to have an agent re-read the codebase every session.

activeContext.md stops drifting. The file Cline flags as changing most often is the one most likely to be out of date, because updating it is a manual step at the end of a session you have already mentally left. Capturing a correction when you make it is a smaller action than reconstructing the session afterwards.

Tool moves stop touching your knowledge. This migration is fiddly because the activation instruction is tool-shaped. When the content lives outside, changing tools means writing one new instruction, not auditing what still gets read.

And the six-file structure becomes optional rather than load-bearing. It was a sensible schema for a folder that has to be read in full. Once retrieval exists, you can keep it, or just keep facts.

Confirm discovery before trusting it. .clinerules/ is not on Kilo's documented list. Start a task and ask what was loaded.

Keep write-heavy files out of AGENTS.md. It is write-protected by design, which is good for guardrails and wrong for a running log.

Use directory placement for scoping. Kilo's per-directory AGENTS.md files load lazily when the agent reads files there. That is the closest thing to Cline's conditional rules, and it works on directories rather than globs.

Mind the priority order. Project instructions in kilo.jsonc outrank root AGENTS.md. If two sources disagree, that is usually why.

Expect a reload. Kilo notes that "changes to AGENTS.md take effect in new tasks (reload may be required)." Do not debug a rule you edited mid-task.

Don't rely on status badges. The legacy Memory Bank indicators are explicitly "not guaranteed across all clients or modes."

This migration looks like it should be hostile — you are moving a Memory Bank into a tool that deprecated memory banks — and it is not. Kilo Code deprecated a feature wrapper, and Cline's own documentation says the methodology "works with any AI that can read docs." The files are fine.

Two things need care. Kilo's documented instruction sources do not include .clinerules/, so the rule that makes the pattern run has to be re-attached, ideally through the instructions key in kilo.jsonc where it outranks root AGENTS.md. And Kilo's deprecation advice about moving memory bank content into AGENTS.md should not be applied to Cline's version, because AGENTS.md is write-protected and the agent needs to write to these files constantly. Instruction in, content out.

Get those right and nothing is lost. Then the more interesting question is whether a per-repository folder read in full on every task is still the best home for what your team knows — or whether that belongs somewhere retrievable, shared, and indifferent to which editor you opened this morning.