How to Migrate From Cline to Zencoder Without Losing Context (2026)

Start with what a Memory Bank actually is, because the documentation is clearer about this than most people realize.

"Memory Bank is a documentation methodology that transforms Cline from a stateless assistant into a persistent development partner. Through structured markdown files, Cline can 'remember' your project details across sessions."

Note the word methodology. The setup instructions confirm it: you copy a block of custom instructions and "add them to a Cline Rules file, such as .clinerules/memory-bank.md." There is no toggle. The feature is a prompt convention that lives in a rules file, plus a folder of documents the convention tells the agent to read. If you set yours up by following setting up Cline's Memory Bank, the rules file you pasted that block into is the part you are about to lose, not the folder.

The folder itself is ordinary:

"Memory Bank files are regular markdown files in your project that both you and Cline can access. They're organized hierarchically to build a complete picture of your project."

Six files, each with a job: projectbrief.md as the foundation document, productContext.md for why the project exists, activeContext.md for current focus and recent changes, systemPatterns.md for architecture and design patterns, techContext.md for stack and constraints, and progress.md for what works and what is left. You drive it with phrases — the documentation lists "follow your custom instructions" to make Cline read the bank and continue where you left off, and "update memory bank" to trigger "a full documentation review and update."

So the migration splits cleanly in two. The documents transfer perfectly: they are markdown in your repo, and they stay markdown in your repo. The mechanism does not transfer at all, and here is why.

Zencoder's documentation describes context as assembled per message, from five sources: workspace analysis of your project's file structure and dependencies, the file currently open in your editor, matched skills, anything you attach with @ mentions, and context the agent gathers with its own tools during execution. That is a complete list of how context arrives, and none of the five is an always-loaded repository instruction file.

The durable, version-controlled surface Zencoder does have is skills:

"Skills are stored as SKILL.md files in .agents/skills/ and are version-controlled with your repo."

It reads them from three locations — <workspace>/.agents/skills/ for project skills, <user-home>/.agents/skills/ for user-level ones, and <workspace>/.claude/skills/ which the docs label "Claude-compatible skills." The legacy .zencoder/skills/ path is described as "deprecated but still supported."

And now the sentence that decides your migration plan:

"Skills are automatically selected by the agent based on task context. Manual skill selection is not currently supported."

A skill loads when the agent decides its description matches what you are doing. The docs are direct that the description is doing the work — it is "what the skill does — the agent uses this to decide when to load it" — and the guidance is to "write it as a clear trigger condition."

Put the two halves together. Cline's Memory Bank depends on an instruction that fires unconditionally at the start of every task. Zencoder's equivalent surface fires on a description match, and there is no manual override to force it. Copying memory-bank/ into a Zencoder project gives you six files nothing is obliged to open.

For completeness on the reverse check: Zencoder's documentation describes skills, per-message context assembly, and multi-repository search. It does not describe a conversational memory store that accumulates facts across sessions. Its own advice points the other way — "Long, multi-topic chats accumulate stale context. Start a new chat for each distinct task so the agent's context stays clean." That is good advice, and it means every task starts from the repository plus whatever the agent chooses to load.

Step 1: Split the bank into procedures and standing facts

Open the six files and re-sort their contents by shape rather than by filename, because the destination has one container and it is procedure-shaped.

Anything that reads like a sequence — how to run a release, how to add a migration, how the review checklist works — is a candidate skill. It has a natural trigger condition ("use this when adding a database migration"), so a description can reliably match it, and it will work well.

Anything that reads like a standing fact is the hard pile. systemPatterns.md describing why the event bus is shaped the way it is, techContext.md listing the constraint that rules out an obvious library, projectbrief.md explaining what the product is actually for — none of that has a trigger condition, because it is relevant to almost every task and specific to none. Writing a description that matches "always" is exactly what the mechanism is not for.

Then there is activeContext.md and progress.md, which are neither. They are a running log of where things stand. Those two are the reason the Memory Bank felt like memory rather than documentation, and they are the two with no destination whatsoever — this is the gap behind complaints like Cline forgetting task history, except now the loss is structural rather than a context-window problem.

Step 2: Write the procedure skills, and write their descriptions carefully

Create one folder per procedure under .agents/skills/, each with a SKILL.md carrying a name and a description. Spend your effort on the description, because it is the entire activation mechanism. "API helper skill" will not match; "use this skill when the user asks to create or modify API endpoints" will.

Two fields are worth knowing about. paths accepts glob patterns to scope a skill to specific files, which gets you closer to conditional loading than descriptions alone. And disable-model-invocation, set to true, stops the agent auto-selecting a skill — which, given that manual selection is not supported, effectively takes that skill out of play. Use it deliberately or not at all.

If your team also runs Claude-based tooling, note that Zencoder reads <workspace>/.claude/skills/ as well. One folder can serve both rather than maintaining two copies.

What you should not do is stuff the standing facts into a skill with a vague description and hope. That is how you end up with the failure mode in why agent skills aren't memory: a document that is technically present and never loaded when it matters.

The pile you could not place is the valuable one. Architecture reasons, rejected alternatives, the constraint that explains a weird module, where the project currently stands — that is the content that made your Memory Bank worth maintaining, and Zencoder's activation model gives it no reliable trigger.

MemoryLake holds that layer outside the editor and answers questions about it over MCP or the API. The agent does not have to guess from a description whether the content is relevant — it asks when a question comes up. Your procedure skills stay in .agents/skills/ where Zencoder loads them by task match, and the standing facts stay answerable regardless of what the agent decided to load this turn.

Step 1: Create an API key

Generate a key and make your first request in about thirty seconds. Do this before Step 1 above, so you have somewhere to put each fact as you sort the six files.

Step 2: Upload your first memories

Work through the unplaceable pile file by file. Architecture decisions from systemPatterns.md, constraints from techContext.md, product intent from projectbrief.md and productContext.md, and current state from activeContext.md and progress.md. Write each as a decision with its reason. Supporting documents go in the same place — turning project docs into AI memory covers doing this without rewriting everything.

Step 3: Connect your AI & agents

Give Zencoder, Claude, Codex, and your other agents access over MCP or the API. Every new chat — and Zencoder's own advice is to start a lot of them — begins able to answer why the project is the way it is.

The first change is that starting a fresh chat stops costing you anything. Zencoder recommends a new chat per task precisely because stale context hurts, and that recommendation is only comfortable when the durable knowledge is not in the chat to begin with.

The second is that your skills get better because they get narrower. Once standing facts have somewhere else to live, each skill can be one procedure with one sharp description, which is exactly the condition under which description matching works.

The third is that the log files stop being a loss. activeContext.md and progress.md had no destination in the new tool. Recorded as decisions with dates, they become the thing a new teammate reads instead of scrolling a chat history.

The fourth is that the next move is easier than this one. The reason this migration was awkward is that Cline's mechanism was a rule file and Zencoder's is a description match. A layer that neither owns does not care which mechanism the next tool picks — the same reason Cline forgetting project context and its equivalents in every other tool have the same underlying fix.

Treat descriptions as the feature. A skill's description is its entire activation mechanism. Write it as a trigger condition naming the situation, not as a label naming the topic.

One procedure per skill. Bundling three unrelated procedures gives you a description that matches none of them cleanly.

Keep paths in mind for file-scoped work. Glob scoping is the closest thing to conditional loading and it is more reliable than a broad description.

Do not set disable-model-invocation casually. With manual selection unsupported, disabling auto-selection removes the only route in.

Migrate off the legacy skills path. The docs describe .zencoder/skills/ as deprecated but supported, and recommend .agents/skills/ to stay aligned with the current standard.

Share one skills folder with Claude tooling. Zencoder reads .claude/skills/ too, so teams running both do not need duplicates.

Do not expect a skill to behave like an always-on rule. If something must be true on every task, a task-matched container is the wrong home for it.

Cline's Memory Bank is a folder of markdown plus a rule file that makes the agent read it. Zencoder version-controls skills in .agents/skills/, selects them automatically from their descriptions, and does not currently support manual selection — and its documented context sources are assembled per message rather than loaded from a standing instruction file. So the documents in your Memory Bank migrate perfectly and the guarantee that anything reads them does not.

Split the bank by shape before you move it. Procedures become skills with descriptions written as trigger conditions, and they will work well. Standing facts and running state need a home that answers questions instead of waiting to be matched. Do that split once and Zencoder's advice to start a fresh chat for every task becomes what it is meant to be — a way to keep context clean, not a way to start over.