Turning a general model into one that knows your job

You watched someone do something impressive with an AI tool, tried the same tool on your own work, and got back something that reads like it was written for a different company. The output was competent and generic, and fixing it took about as long as writing it yourself would have. Nothing was broken. You were using a model that has never seen your clients, your file naming, your pricing rules or the three things you always check before anything goes out.

That gap is the whole job, and it does not close by finding a better tool. It closes when you write down the parts of your work that only you know, put them where the tool reads them every time, and add examples of finished work you were happy with. This guide is for someone who already has a task they repeat most weeks and wants that task to come back usable on the first attempt. It is not for anyone still looking for a first use, and it is not about fine-tuning or training a model, which is a different discipline with a different budget.

Capability arrives general, the work is always specific

In July 2026, Walden Robotics announced $300 million in funding at a $1.1 billion valuation for general-purpose robots [1]. The number is not the useful part. The useful part is what the company says about how it got there. Founded in January 2026, it reports that “Since February, Walden’s general-purpose robots have been doing useful work in production at a Toyota plant in North America, moving from first pilot to real work in under two months” [1]. Its chief executive, Russ Tedrake, described the method plainly: “Core advances in Physical AI have made disruptive change possible. But providing real value to customers and building a robust and scalable business requires a deep understanding and respect for how manufacturing is done today. The best way to make fast and positive progress is by working closely together with the real experts” [1].

The round’s investor list points the same way. Toyota Motor Corp, Toyota Invention Partners and Toyota Ventures all appear on it, alongside NVIDIA, Boeing and Menlo Ventures [1]. The customer and the backer are the same company.

Read that as a division of labour. The general capability came from the model. The two months came from being on a real line with the people who already knew the work. Nobody in that story expected the robot to infer the plant from first principles.

The software you rent runs on the same split, and the vendors say so in their own documentation. Anthropic’s prompting guidance tells you to “Think of Claude as a brilliant but new employee who lacks context on your norms and workflows. The more precisely you explain what you want, the better the result” [2]. A new hire who is good at the general skill and knows nothing about your norms is exactly what you have. You would not hand that person a one-line brief and then conclude they were the wrong hire.

Every tool has a place where instructions stay put

Retyping the same context at the start of every chat is work you only have to do once. Every tool worth using has somewhere to put standing instructions and leave them, and the shape of that place tells you how much to write.

In ChatGPT, updates to custom instructions are “applied immediately across all chats (including existing conversations)” on web, desktop, iOS and Android, with a limit of 1,500 characters on Free and Go plans and 5,000 characters on Plus, Pro, Enterprise, Business and Education plans [6]. There is “no API for custom instructions, as the Chat Completions API system messages should be used for a similar effect” [6]. In the Gemini app, a custom Gem is built from four parts the help page names as persona, task, context and format, with instructions to “Tell your Gem what role to play and how to respond” and to “Provide as much background as possible” [7]. In Cursor, project rules live in .cursor/rules as .mdc files, and “rule contents are included at the start of the model context”, with the guidance to “Keep rules under 500 lines” and split anything larger into separate rules [8]. In Claude, a Skill is a SKILL.md file with a name of at most 64 characters and a description of at most 1,024 characters that “must include both what the Skill does and when Claude should use it” [4].

Those limits are the useful part. A 500-line ceiling and a 5,000-character field are both telling you the same thing: this is a page of standing context, not a manual. Write the things that would be wrong if the tool guessed.

Show finished work instead of describing it

It is tempting to write instructions as adjectives. Concise, professional, friendly, on-brand. The model already has an opinion about all four, and it is not yours.

Anthropic’s documentation is direct about the alternative: “Examples are one of the most reliable ways to steer Claude’s output format, tone, and structure. A few well-crafted examples (known as few-shot or multishot prompting) improve accuracy and consistency” [3]. The recommendation is 3 to 5 examples, and they should be relevant enough to “Mirror your actual use case closely”, diverse enough to “Cover edge cases and vary enough that Claude doesn’t pick up unintended patterns”, and structured, wrapped in <example> tags so the model can tell them apart from the instructions [3].

You almost certainly have those examples already. Go into last month’s sent folder or your project files, find 3 pieces of the exact thing you keep asking for, and paste them in whole. Pick a straightforward one, an awkward one and one where the client pushed back, so the set covers the range rather than one lucky day. That is the part the documentation calls reliable, and it is the part you can supply without writing anything new [3].

Scope the instructions to the job, not to yourself

Account-level instructions apply to everything you do, which means they can only hold things that are true of all your work. The specific material belongs one level down, attached to the job.

ChatGPT projects exist for that. Project instructions “only apply inside the respective project and will override your global custom instructions”, and a project holds files: 5 on Free, 25 on Go and Plus, 40 on Edu, Pro, Business and Enterprise, with 10 uploading at a time [5]. Projects also have two memory settings, and the stricter one is worth knowing about. Under project-only memory, chats “cannot reference conversations outside the project, such as general ChatGPT conversations or conversations in another project”, and shared projects use it automatically without the option to switch [5]. That is the setting to pick when a client’s material should not leak sideways into unrelated work.

The practical arrangement is two layers. Account level gets who you are, what you sell and the handful of rules that never change. Project level gets the client, the format, the examples and the vocabulary. When something goes wrong, you then know which layer to edit, which is the part that keeps this maintainable after the first enthusiastic afternoon.

The corrections are the training

Walden says its robots “continuously learn and improve through real-world practice” [1]. Your chat tool does not. The model that produced a bad answer this morning will produce the same bad answer next Tuesday unless the correction goes somewhere it gets read again.

So change the habit. When you fix an output by hand, spend the extra 30 seconds asking why you had to, and put that answer in the instructions as a rule or in the examples as a case. Wrong tone means the example set is off. Missing a step means the instructions are incomplete. Inventing a fact means you did not supply it. Fold each correction back in as you make it, rather than rewording the prompt again next time.

Cursor makes the maintenance model explicit by keeping rules “version-controlled with your codebase” [8], which is worth copying even outside code. Instructions are a document that changes, and treating them as one means you can see what you changed and undo it. Anthropic’s test for whether a set of instructions is finished is a good one to run before you stop: “Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they’d be confused, Claude will be too” [2].

Keep the master copy in a file you own

The work you put into instructions is portable in principle and stubbornly non-portable in practice, so keep the source of truth outside any one product.

Anthropic is unusually clear about this for its own Skills: “Custom Skills do not sync across surfaces. Skills uploaded to one surface are not automatically available on others”, with skills uploaded to claude.ai needing separate upload to the API, API skills unavailable on claude.ai, and Claude Code skills filesystem-based and separate from both [4]. Google’s Gem instructions carry a smaller version of the same trap, since custom Gems can only be created in the Gemini web app and the help page warns twice that “After you preview the Gem, make sure to click Save. Using the preview window does not automatically save your Gem” [7].

Keep one plain text file per repeated job, holding the standing instructions and the examples, in your own storage. Paste from it into whichever tool you are using. When you move tools, change plans or lose access, you are copying a file rather than reconstructing six months of accumulated corrections from memory.

What still goes wrong

Instructions rot. The client changes, the format changes, you stop doing the thing the examples show, and nobody removes the line that no longer applies. A stale rule is worse than no rule, because the output looks deliberate and is quietly wrong. The only defence is a calendar reminder to reread the file every few months, and a bias towards deleting rather than adding when you do.

More context is also not automatically better. A long instruction set can hold two rules that contradict each other, and you will not see which one the tool followed. The vendors set ceilings of their own. Cursor advises keeping rules under 500 lines and splitting anything larger into separate rules [8], and ChatGPT caps custom instructions at 1,500 or 5,000 characters depending on plan [6]. If your instructions have grown past a page and results have got worse, cut before you add.

The last limit is the honest one. None of this fixes a task the model cannot do. If the work needs a fact the tool has no access to, a judgement call you would not delegate to a competent stranger, or accuracy nobody is going to check, better instructions will make the failure more fluent rather than less likely. The technique here narrows the gap between a general capability and your specific job. It does not create capability that was not there, and the tell that you have crossed that line is that the output keeps getting more confident while you keep having to verify more of it.