Switching clients or models should not mean rewriting your skills

The Thursday standup is where it happens. Fifteen minutes in, after the sprint board has been walked, your lead says the sentence you've been half-expecting: "We're standardizing on Cursor. Migration starts Monday."

Your stomach drops. And the thing you notice, standing there with your coffee, is that your stomach did not drop because you're worried about the editor. You've used Cursor before; it's fine. It's good, even. Your stomach dropped because of everything that lives on the other side of that switch: six months of Claude Code. The prompts you tuned until they felt like an extension of your own judgment. The release checklist you built up one painful incident at a time — the version-bump order, the changelog rule, the "never deploy on Friday" line that has a specific scar attached to it. The code review ritual that finally made agent-generated PRs safe to merge in your repo. The test-naming conventions you wrote down once and reuse every single time.

All of it lives in files that belong to a tool. And moving means rewriting. So you open your mouth to argue, and then you close it, because you've had this argument with yourself three times this year already, and you've lost it every time. You talk yourself out of switching. Again.

The three times are worth inventorying, because they're identical in shape. First time: the new model came out, the benchmarks were genuinely better for your stack, and you spent twenty minutes imagining the migration — the prompt templates, the style rules tuned to the old model's quirks — and closed the tab. Second time: a colleague raved about a new client, and you didn't even download it, because "try it" in your head meant "migrate to it." Third time: this standup. Every one of those decisions was made by the same cost, and the cost was never the tool. It was the accumulated stuff. You weren't rejecting tools; you were rejecting migrations.

A friend of yours did the migration last quarter, and his retelling is burned into your brain. Not because it was dramatic — because it was so ordinary. "I started Friday night, thinking it'd take an evening," he said, nursing a coffee the following Monday like a man who'd seen things. "Two days. Config files, prompt files, the little conventions I'd forgotten I'd set. The worst part wasn't the volume, it was the quiet stuff — the rules I'd tuned against the old client's quirks, the formatting habits I'd picked up without noticing I had them." He shrugged. "And there was this one prompt I really loved. This review checklist that had saved me twice. After the move it just... didn't work the same. I still don't know which step I broke. I rewrote it from memory, and it's not the same thing, and I'll never get the original back."

He showed me the old prompt and the rewrite, side by side, and honestly — they were different. Same skeleton, different muscle memory. Small phrasings had shifted, one gate had drifted, the tone had softened in a way he couldn't put his finger on. "The weird part," he said, "is that I can't even tell you what's wrong. It just doesn't feel as sharp." That's what you lose when the storage layer is your memory: not the content, the fidelity. Memory is lossy, conventions drift, and there's no diff to show you what changed.

The coda to his story is the part that should haunt you a little: he didn't stop migrating because he decided it wasn't worth it. He stopped because there was nothing left to migrate to. "I've got the tool, I've got the prompts, I've got the process in my head," he said, "and honestly? The process in my head is the one I'm most worried about losing." He was right to worry. It's the one without a backup.

That's the real cost of switching, and it's why you're still on the tool you're on: not the learning curve, not the new shortcuts. It's the accumulated stuff. The workflows, the rules, the conventions you wrote once and reuse everywhere. That stuff should not be owned by the tool you happen to be using this quarter.

You've felt it from the model side too, which is the part nobody warns you about. Six weeks ago, a new model came out, and the benchmarks said it was better at exactly the kind of code you write. You spent an afternoon testing it on real tasks. And here's what happened: it was better — and your prompts were wrong for it. The style rules you'd tuned against the old model's habits — "be terse," "use bullet points," "ask before you refactor" — were a kind of software, and they had been compiled against a different runtime. Some of them made the new model worse. You didn't switch models that day, and the reason was not the model. It was the migration. Again. That's when the pattern stopped being a coincidence and started being a design problem: you keep paying a migration tax, on a schedule someone else sets, for stuff that was never supposed to move at all.

The part you can use right now:

npx skills add <owner/repo>

That command is the same in Claude Code, Cursor, Copilot, Windsurf and Cline. Here is why that one sentence is the whole argument.

Where the problem lives

Your prompts live wherever you put them. That sounds like a statement of the obvious, but follow it to the end: put your prompts in Cursor's rules files and they belong to Cursor. Put them in a model-specific prompt template and they belong to that model. Every upgrade, every switch, every model change orphans them — not because they're bad, but because they're stored in the layer that changes.

Do the inventory right now, in your head. Where does your release process actually live? Part of it is in project files. Part of it is in a client's config format. Part of it is in your head, pasted into every new session from memory. The model-specific tuning — the "be terse, no bullet points" style rules — lives in prompt templates that only one model reads the way you intend. Each of those locations is owned by something that will change without asking you. The client will ship a breaking update, or the team will standardize on something else, or the model will get a successor that reads your tuning differently. Every one of those events is a migration, and you are the one who pays for it, with your evenings.

And the worst storage location of all is the one you use most: your memory. The checklist you retype into every new session is stored in exactly one place, and that place has no version control, no backups, and no diff. Every retype is a copy, and every copy drifts a little — a step gets dropped here, an order flips there, a rule you added during an incident quietly vanishes two projects later. You think you're reusing your process. You're actually re-narrating it from memory, and memory is the one storage layer that's guaranteed to degrade.

And let's be clear about what should stay in the client layer, so the separation doesn't feel like a totalitarian purge: your keyboard shortcuts, your theme, your window layout — those are preferences, and preferences belong to the tool. Nobody needs to port a keybinding across platforms; that's not the asset. The asset is the process — the sequence, the gates, the judgment calls you've encoded over months of incidents. Preferences are cheap to recreate. Processes are expensive to lose. The layered setup exists to protect the expensive one.

And those are exactly the two layers that change fastest in this industry. Models turn over every few months; the front-runner client changes every year or two. Parking your assets in the two most volatile layers means paying a migration tax on a schedule someone else sets. You don't get to vote on when the tax comes due; you just get to pay it, every time — the way your friend paid it with a lost prompt he still mourns.

The strange part is that the tax is invisible until you pay it, which is why everyone talks themselves out of switching and nobody realizes they've been migrating all along — every time you retype the checklist, every time you re-tune a prompt against a model's new quirks, every time you re-discover a convention you'd forgotten you had. You've been migrating continuously, in small doses, without ever calling it that. The layered setup doesn't just make the big switch cheap; it makes the small ones stop.

Once you see the continuous migration, you can't unsee it. The retype is a migration. The re-tune is a migration. The "oh right, we also do X" discovery three projects in is a migration that ran without you. Add them up, and you've been spending the equivalent of a real migration every couple of months — just spread thin enough to never notice. That's the argument for the layered setup in its most uncomfortable form: you're already paying the tax. The question is only whether the money goes toward a tool's config format or toward something you keep.

The fix: three layers that swap independently

What you accumulate is three layers, and they should come apart:

• Brain: the model. Swap freely; your skills do not move.
• Skills: plain markdown files. Readable, diffable, versionable — and installable on all of those clients from the same source.
• Client: the agent. Pick whatever you like; the other two layers do not care.

The markdown part is what makes the separation hold. A skill is not a proprietary format — it is text. The release checklist you wrote for Claude Code installs into Cursor with the same command, and GitHub Copilot reads the same file. When you switch clients, you take your skills with you, not your tool. You are not migrating; you are re-pointing. The difference between those two words is the difference between a weekend and an hour.

And "re-pointing" has another property worth naming: it's reversible. A migration is a one-way operation — once your prompts live in the new client's format, getting them back is another migration. A skill file, by contrast, can be installed anywhere, including back where it came from. You can try the new client for a week, decide it's not for you, and leave with zero casualties, because nothing was ever converted. You only ever pointed. Pointing doesn't break anything.

Let me make it concrete, because "three layers" is the kind of diagram that sounds good in a talk and gets ignored on a Tuesday. Take your release process — the one you've been retyping into every new project. Right now it lives in a config file that one client reads, plus your memory. The layered version is one markdown file that says, in order: run the test suite and don't touch the version number until it's green; update the changelog before tagging, never after; tag, push, wait for CI; deploy only when CI is green, and never on Friday without the on-call acknowledging. That's a skill. It is a plain text file. It contains no client-specific syntax and no model-specific tuning. You can install it anywhere that accepts a SKILL.md, which is twenty-odd platforms, and it will behave the same everywhere, because it's just prose with a structure — and prose is the one format nothing can take away from you.

The versioning bonus deserves its own sentence, because it's the one nobody mentions. The moment your release process becomes a file, it becomes a diffable artifact. Next month, when you wonder "when did we stop doing the Friday check?" — the answer is in git, along with who changed it and why. The process you've been carrying in your head has never had a history; now it does. That alone is worth the forty minutes.

There's a moment you'll recognize the first time your process becomes a file: the drift gets caught. Last month, without meaning to, you'd stopped doing the rollback drill — it had quietly fallen out of the retyped checklist somewhere around project three, and nobody noticed, least of all you. With the process in a file, the drift shows up as a diff. You can see the day the step vanished, and you can decide deliberately whether it comes back. Your memory never gave you that choice; it just silently upgraded the process to a worse version.

The model layer works the same way. Once skills are decoupled from the client, switching models is just a brain swap — the LLM gateway (routed through OpenRouter today) sits between you and the model, so a model change does not touch your skills. What you know how to do stays put; only the thing doing the thinking changes. You've tuned those prompts against the way models actually behave — the terse style, the format gates, the stop-and-ask tripwires. The tuning that used to be written into every prompt template becomes, at most, one skill that describes how you want the work done — and if a new model doesn't need that skill's rules, you update one file instead of rewriting your whole setup. The next time a better model ships, the decision is "try it through the gateway and see," not "spend the weekend migrating."

One concrete version of the brain swap, since "gateway" can sound like infrastructure poetry: your team's standard model gets deprecated, or a new one is genuinely better for your stack, and the decision used to be a weekend project — retune the prompts, retest the flows, pray. With the skills on the outside of the model, the decision is an afternoon: point the gateway at the new model, run your real tasks, compare the outputs. Your process doesn't know or care which brain is doing the thinking. It was never coupled to the brain in the first place.

The honest trade-offs

Layering is not magic, and pretending otherwise is how people get burned. Three trade-offs, stated plainly:

• Platforms parse SKILL.md slightly differently. Most skills are portable, but when one leans on a client-specific capability — a tool integration that only exists in one product, say — thirty seconds checking which platform it targets is worth it. The format is shared; the edges are not identical. The fix is boring and reliable: write the skill to be portable, and if it can't be, say so in the description. "Adapted for X" is not a weakness; it's a warning label, and warning labels are how you don't get burned.

The practical version: most skills you'll ever need — checklists, procedures, formats — are pure text and portable by construction. It's only the exotic ones, the ones that reach into a client's private tooling, that need the label. So the rule is simple: when you install, glance at the target platforms listed on the skill's page; when you write, keep the portability by default and label the exceptions. Thirty seconds either way, and the entire class of surprise disappears.

• The gateway adds a hop. Model calls route through it, which means latency and cost are yours to weigh. It is the price of "swap models without changing anything else," not a free lunch. For most work the hop is invisible; for the pathological cases — massive outputs, high-frequency calls — you'll feel it, and you should know it's the cost of the property you're buying. If you're doing a million tiny calls a day, measure before you commit; if you're a human with a terminal, you will not notice.
• Layering does not fix bad skills. A poorly written skill is poorly written everywhere. Separation of layers solves migration, not quality. If your release checklist is two sentences of vibes — "be careful, check things, deploy well" — it will be two sentences of vibes in every client you install it into, and no architecture will save you from it. The layers buy you freedom to move; they don't buy you competence. You still have to write the good checklist.

One more honest note: layering has a learning curve, and it's front-loaded. The first skill you write is the hardest, because you're simultaneously learning the format and extracting a workflow you've never had to articulate before. The second is easier. The third is mechanical. Most people who bounce off this idea bounce off the first skill — so set the bar low: one workflow, forty minutes, done. The goal of the first skill is not to be brilliant; it's to exist.

One more honest note about what layering will not give you, so you don't look for it in the wrong place: it won't make your prompts better, it won't organize your repos, and it won't decide which workflows are worth extracting — that last one is judgment, and judgment is still yours. What it gives you is narrower and more valuable: the guarantee that when the world changes — and it will, quarterly, forever — the thing you've built doesn't have to be rebuilt. Everything else you still have to do yourself.

The last thing to make peace with: this idea doesn't require you to abandon the tool you like. The layered setup isn't an argument against clients — it's an argument against a tool owning you. You can love Cursor and still keep your skills in files. You can love a model and still route it through a gateway. The point was never to make you stop choosing; it was to make choosing cheap enough that you can do it on the merits.

One move you can make today

Do not wait for the big migration. The trap is thinking this is a project with a start date. It's not a project; it's a habit, and habits start with one small move.

Pick the workflow you retype at the start of every project — the release checklist, the review ritual, the test conventions. The one you paste into the session from memory because it's too important to get wrong and too boring to maintain. Write it as a SKILL.md. Then install it into the client you are not currently using, and run it there once, on a real task.

The reframe that makes it stick: a project is something you finish; a habit is something you keep. If you treat skill extraction as a one-time migration project, you'll never start it, because the big migration is exactly the thing you've been avoiding. If you treat it as a habit — one workflow this week, one the next — you've already started, and starting is the whole game.

Here's what that evening actually looks like, so you know what you're signing up for. You open your editor, and you write the checklist as a markdown file: a description that says when it fires — "run before every release" — and a body that says what to check, in order, with the gates. That's forty minutes, not a weekend. Then the command:

npx skills add <owner/repo>

in the client you haven't touched since you downloaded it, pointing at your skill. You run one real release through it. And here's the moment that makes the whole thing click: it works. The checklist that lived in your head and in one client's config now lives in a file, and the file works in a second client, and nothing about the file changed between the two.

The part that surprised you — the part that made it click — was the anti-climax. You expected a migration; you got an install. No config to port, no format to convert, no prompt to retune. The file you wrote in one client worked in the other because neither client owned it. That's the whole architecture, demonstrated in forty minutes: the skill sits between the layers, and the layers move around it.

The momentum is the part nobody tells you about. The first skill took forty minutes and a surprising amount of staring at the ceiling — you'd never had to articulate the release process before. The second skill, the review ritual, took twenty. By the third, you were extracting workflows the way you'd write tests: list the steps, name the gates, note where to stop and ask. It's a skill you develop, writing skills — and like every skill, it only develops with reps.

And here's the nicest part of the momentum: it compounds into the team. The day your lead asks "how do you do your releases?" — and they will, because your Monday took an hour instead of a week — you can answer with a file. Not an explanation, not a doc that will drift, a file. That's the difference between teaching someone a process and handing them one. The second one scales, and it scales without a migration.

If it works there too, you have verified the separation — and you now own an asset that no longer drifts with your tools. You'll also have discovered something about your own workflow: the thing you retype every project is exactly the thing that should have been a file all along. It was never the tool's job to remember it; it was yours, and now it doesn't have to be.

Next time the standup drops a migration bomb, the math is different. The editor is a preference, not an anchor. You'll say "sure" — not because you're enthusiastic, but because the sentence that used to follow ("and then I migrate everything") is gone from the calculation. Your skills come with you because they were never the tool's to begin with. And the next time a model ships with better benchmarks, you'll route it through the gateway and try it on a real task, and the decision will be about the model — not about the cost of the switch.

Your skills should belong to you, not to whatever client or model you are trying this month. Directory and gateway: qumge.com.

Monday, when the migration actually starts, here's what you'll do: install your skills into the new client, run one real task to confirm they behave, and be done before lunch. Your teammates will spend the week migrating; you'll spend it working. Not because you're faster — because you have nothing to move. The stuff that made you productive never lived in the tool. It just took you six months and one bad standup to notice.

Two Mondays from now, the next thing will happen: a new model ships, the benchmarks are good, and your lead floats "should we try it?" The old you would have done the arithmetic and declined — too much to move. The new you routes it through the gateway on Tuesday, runs the release checklist against it on a real task, and reports back on Thursday with evidence. Not because you love switching. Because the cost that used to decide the question for you is gone.

And if the migration never comes — if the team stays on the current client forever — the setup still pays for itself, because the second benefit is independent of switching: the stuff that lived in your head is now in a file, which means it has a version, a history, and a future. You didn't just make switching cheaper. You made your process durable. That was always the real asset.

So the next time the standup drops a sentence like "we're standardizing on X," let your stomach stay where it is. The tool is a preference. Your skills are a file. And the only migration left in the building is the one your teammates are about to start.

That's the whole difference, and it was one file away. One file, and the migration stops being your problem forever.

npx skills add <owner/repo>