Someone else's skill doesn't know your work: how to teach AI your own approach

You downloaded ready-made instructions for AI, yet you still have to rework the result to fit your work? Even a skill – a set of instructions for a particular type of task – from a repository with two thousand stars doesn't know your quality requirements.

The downloaded file may well be good. But you received the result without the reasoning that led to it. Its author spent weeks testing the instructions on their own tasks and built into them their ideas about the subject and about what counts as quality work. Those decisions stayed with the author. That is why the same tools produce different results for different people, and the more AI becomes part of work, the more visible this difference is.

It is more useful to build your own skill that gives the model your approach to the task. Below we look at what it consists of and how to build it step by step.

A recipe and a way of thinking

An ordinary skill is like a recipe: step one, step two, step three, done. The model carries it out the same way whatever you write. The result is predictable, and therefore average.

A next-level skill, known as a meta-skill, works differently. It tells the model less about what to do and more about how to think about the task before it starts. It has three layers, and few people get as far as the third.

Layer 1. When the skill switches on

The first question: in what situation should the skill be triggered at all?

Weak skills describe themselves vaguely: "helps with presentations", "writing assistant". Such a description fits everything and nothing in particular, and the model doesn't understand when to step in.

A good description names the files the skill works with, the user phrases that trigger it and – especially important – what it does not do. Not stepping in at the wrong moment matters as much as stepping in at the right one.

Layer 2. How to think about a class of tasks

The second layer sets the approach to a whole class of tasks: how the model should reason before it starts composing an answer.

As a result, the model approaches the task from an angle it would not have chosen on its own. That is how above-average work comes about.

Layer 3. Checking for the generic

How does a skill know it hasn't produced the obvious standard answer? Usually it doesn't: generate and send.

A meta-skill checks itself: "Does this look like what the model would have written with no instructions at all? If so, the result is rejected and a new attempt is needed." This is not about grammar or formatting but about difference: did the skill change the approach, or just package the default behaviour nicely?

When the three layers work together, the skill changes how AI handles the request before the work even begins.

First, describe the lazy version

The main tool for moving away from an average result is working backwards. Before you write the first line of instructions, answer the question: what would the lazy version of this work look like?

Describe in detail what the model will do without your intervention:

• which structure it will reach for first;
• which words it will use by default;
• which assumptions it will make without asking anything;
• what impression the finished text will leave.

Write down every predictable move. Now the task is to deliberately move away from each of them.

The mechanics are simple. The model's default behaviour is a statistical average: it produces the most likely continuation based on the data it was trained on. If you don't specify what must not be done, the result will drift towards the centre: without concrete constraints, the model returns to familiar phrasing and structures.

An example – a skill for writing texts. The lazy version asks the model to "write persuasively", uses words like "catchy" and "engaging" and builds every text on the "hook, main body, call to action" pattern. The reverse version is built differently:

• a list of 50-plus words that must not be used in any text – the ones that immediately show a machine wrote it;
• structures to avoid: lists of three, a rigid identical sequence, empty summarising sentences;
• examples of bad texts from the specific field;
• a check: the result must not look like a typical AI answer – not to hide anything, but to make sure the work genuinely differs from the baseline.

You are telling the model less about what to write and more about what not to write. It is precisely this constraint that forces it to look for a non-standard solution.

The list of prohibitions, the examples and the checks make the instructions longer. The next question is what to keep in context at all times and what to load only at the stage where it is needed.

The model's context is a limited resource

The context window – the amount of text the model holds in its head at one time – is not a bottomless notebook. Every line of instructions competes with your real materials and with the room the model needs for a good answer.

Overloading doesn't produce a visible error. Quality drops quietly: the middle falls out of long instructions, while the beginning and the end remain.

It helps to reveal instructions gradually, on three levels:

1. Always in context. The core workflow: what stage the task is at, what needs to be loaded, which rules are never overridden. Only the path, no more than 500 lines.
2. On request. Detailed knowledge needed by a particular stage: domain concepts, worked examples, step-by-step guides. They live in separate files, and the first level calls them at the right moment.
3. Check. Loaded right before the result is delivered: the list of prohibited moves, anti-examples, the "does this look like a default answer" check. It is deliberately loaded last – so that it is the freshest thing in the model's memory during the final pass.

The main file is a router, not a textbook: it tells the model where to find information rather than laying everything out at once. Each supporting file is self-contained and is called by an explicit condition – "read this before stage three", not "read this when needed". Vague conditions are simply ignored under load.

An expert should be a method, not a role

Many skills have a step like "evaluate the work through the eyes of expert X". The model then acts out a vague idea of how that person might reason, gives itself a score and moves on. It is self-review in fancy dress: guessing what the expert might say instead of applying their actual method.

A different route works: instead of "pretend to be expert X", build a profile of how they make decisions. For that you need not quotes and short posts but long-form reasoning: talks in which the person takes decisions apart step by step; essays in which they explain why they chose one approach and rejected another; interviews in which they argue with conventional wisdom.

From these materials you extract specific things:

• recurring ways of making decisions – not vocabulary, but real mental models;
• the order of priorities: what they look at first when assessing work;
• warning signs: what immediately makes them suspicious;
• the sequence of questions they ask before deciding.

All of this is packaged as a decision-making procedure the model can carry out, not as a character it plays. The difference between "what would this expert say about my work" and "take this architecture apart from scratch, reduce every part to its basic requirements and question every layer" is huge. The first gives you an impression. The second is a process that finds real problems.

Such profiles are built once and used across all skills. Over time they become a permanent part of the check.

How to build your own skill: seven stages

It is easiest to show this with a skill that helps create other skills.

1. Gather what you already know

Before writing instructions, collect your earlier prompts, workflows, procedures, and both good and failed results.

Describe how you solve the task by hand. What decisions do you make without thinking? This unconscious method is the most valuable part.

The skill should pass on your thinking, not general advice from blogs.

2. Answer four rounds of questions

You can ask the model to interview you like this:

I want to build a skill – a set of AI instructions for my work task.
Task: [describe what the skill should do]

Interview me in four rounds. Ask the questions one round at a time,
wait for my answers and only then move on to the next.

1. Scope: what should the skill do that AI cannot do without it?
   Who will use it?
2. Difference: what does AI usually get wrong in this task?
   What does the lazy version of the result look like? What must the skill do best of all?
3. Structure: are templates, several workflows
   or external tools needed?
4. Weak spots: what input data will break a simple version?
   What should the skill explicitly refuse to do?

Stop when you have enough information – this is a conversation, not a questionnaire.
At the end, list what you have understood about my method and what is still missing.

3. Find how you differ from the standard

Describe the typical version: what the model will do without the skill – the usual structure, the expected words, the ordinary sequence of actions. Challenge two or three assumptions that the standard approach accepts without checking. Write down your own way of solving the task: it will become the reference point for everything else.

4. Choose the structure

• one task and a little knowledge – a single file of up to 300 lines;
• one main process with examples – a main router file and supporting files;
• several modes or deep specialist knowledge – a full modular scheme: the router directs to separate files for processes, concepts, examples and templates.

If the main file has grown beyond 400 lines, split it. If there is more than one process, add a mode selection at the top.

5. Write the skill text

Start with the main file – it is the foundation. Then a few rules:

• each supporting file has an explicit loading condition: "read the anti-examples file before delivery", not "check the anti-examples if necessary";
• the most important constraints go at the beginning and at the end of the main file: the model takes in what it reads last more sharply;
• no hedging: "always" and "never" work, "try" and "consider" do not;
• each stage produces a visible result or a concrete decision; if nothing changes, the stage is not needed.

6. Check it through someone else's eyes

Check with specific methods, not a general impression:

• From scratch, from the basic requirements: is there anything here that doesn't deserve its place? Could the same be achieved with fewer parts?
• In practice: would a person use this every day, or does the skill look good on paper but get in the way at work?
• By the result: does the skill really change AI's behaviour, or does it just frame the default answer?

The skill is ready when it has survived an outside review. Your own sense that it is ready is not enough here.

7. Hand over the whole skill

The package includes:

• the full file tree and the contents of each file;
• an explanation of the structure: why it is built this way and what problem each part solves;
• the results of the stage 6 check;
• instructions: how to install it, when the skill is triggered, examples of input data and the expected result.

Borrow or design

The gap mentioned at the beginning is growing.

Some people collect ready-made skills and trade prompts in the hope that the right combination of other people's tools will make the work good by itself. Their results are interchangeable: under different packaging lies the same basic reasoning.

Others transfer real human thinking into their instructions and get what the model will not produce by default – however powerful it is. Their work differs in its very structure.

So look not only at the finished text but also at how the model works: to change the result, give it your own sequence of reasoning and checks.

To start: take one task you regularly give to AI and write its lazy version – how the model will answer without your instructions. Mark three moves in that answer that you are not happy with, and write down how you do this work yourself. That is the first sketch of your skill.

Read next:

• How to formulate the task itself for AI rather than looking for "the right prompt" – how to turn a description of a problem into a working task for AI;
• When the skill is ready and you want to hand AI a whole process – how to prepare a work process for an AI agent: ten checks.

If you want to turn your way of working into instructions for AI – for texts, analytics or automation – we will work through your task at a free 30-minute meeting with Simplit. Discuss your task