Rebuilding custom instructions somewhere else

Custom instructions are the part of a switch that people put off, because it feels like retyping something that already exists. It is worth doing properly once, for a reason that has nothing to do with this switch: instructions kept as a file you own stop being something you can lose.

Right now yours exist in exactly one place, phrased for one product, editable only through that product’s settings screen. That is the actual problem, and it is fixable in an afternoon.

Start by finding out what yours currently say

Before writing anything new, read the existing set — properly, not from memory. People are reliably wrong about their own instructions, because they were written in layers over months and the layers contradict each other.

Copy the text out into a scratch file. If the product splits instructions across more than one field — something about you, something about how responses should be formatted — copy each field separately and label which was which. That labelling matters, because the destination may split them differently or not at all.

If you no longer have access, check whether your export includes them. If it does not, you rebuild from what you can reconstruct, which is a reasonable outcome and another argument for keeping the file outside the product from now on.

Sort what you find into three piles

Almost every accumulated instruction set is a mix of three different things, and they migrate differently.

Facts about you. Your role, your field, the tools you use, the audience you write for, your locale and units. These are durable, portable, and the most useful thing in the set. They transfer verbatim.

Standing preferences about output. Length, tone, formatting, whether to use headings, whether to ask clarifying questions, whether to include caveats. Also portable, though phrasing may need adjusting.

Workarounds for one product’s habits. Instructions that exist purely to suppress something one assistant kept doing — “stop apologising”, “do not restate my question”, “never end with an offer to help further”. These are the largest pile in a mature instruction set and most of them should not be migrated at all.

Carrying workarounds across is how people end up convinced the new assistant is strange. You are correcting behaviour it may not have, in language it interprets differently, and the corrections interact with each other. Leave them out. Add them back individually if the new assistant actually does the thing.

Write it as a file, not as a settings field

The output of this exercise should be a plain-text or Markdown file you keep with your own documents. Something like assistant-instructions.md, in whatever folder you actually back up.

Structure it so a section can be lifted out on its own:

WHAT MOVES — an instruction set

  · Facts about you and your work
                    → transfers verbatim. Highest value,
                      lowest effort.

  · Output and formatting preferences
                    → transfers, may need rephrasing for
                      the destination's fields.

  · Workarounds for the old product's habits
                    → STAYS BEHIND deliberately. Do not
                      migrate; re-add only if the new
                      assistant earns them.

  · The instruction set as a settings field
                    → STAYS BEHIND. Keep the file; paste
                      into the field.

  · Clearing the field before you have copied
    it out
                    → IRREVERSIBLE. Read and save the
                      existing text first.

Keeping it as a file buys three things immediately. You can diff it when you change it, so you find out which edit made responses worse. You can keep more than one variant — a work set and a personal set — without retyping. And the next switch, whenever it comes, costs one paste.

Rewrite rather than paste

Two adjustments are usually needed, and both are quick.

Cut the negations you can state positively. Long lists of prohibitions are the least reliable part of an instruction set. “Write in plain sentences” does more work than four instructions about what not to do, and it survives being interpreted by a different model.

Cut anything you cannot remember wanting. If you find an instruction and cannot reconstruct why it is there, it was almost certainly a response to a specific annoyance that no longer applies. Delete it. You will notice within a week if it mattered.

The goal is a set short enough that you can read the whole thing and predict its effect. Most accumulated sets are two or three times longer than that and no more effective for it.

Then test it against something you actually do

Do not evaluate a new instruction set on a made-up task. Take a real piece of work you have done recently with the old assistant — an email you sent, a document you drafted, a problem you worked through — and run it again.

What you are checking is narrow: does the output need the same amount of correcting as before? Not whether it is better, which is a question about the assistant rather than the instructions, and not whether it sounds the same, which it will not.

Three real tasks is enough to find the gaps. Add instructions for what you find, one at a time, and note in the file what each one was for. That note is what stops the set silently accumulating cruft again.

Saved prompts get the same treatment

The prompts you reuse weekly deserve the same move: out of the product, into files.

A prompt you paste is more portable than a prompt saved in a feature, works identically in every assistant, and can be edited in a real editor. The saved-prompt features are more convenient by a small margin and lock the text into one account, which is the trade that just cost you an afternoon.

Keep them in one folder, one file per prompt, named for what it does rather than what it says. Half of them will turn out to be variations on the same three, which is worth discovering.

What you are actually buying

Not a smoother switch — the switch is nearly over by this point. What you get is that the most carefully tuned thing you own stops living inside a subscription.

The instruction set is the only artifact in this whole process that improves with age and cannot be regenerated. Everything else either exports or is lost; this is the one thing whose portability is entirely your decision. Making it a file is that decision.