A quick warning before we start: this one is for people who use AI properly rather than occasionally. If you dip into ChatGPT once a fortnight to tidy up an email, none of this will change your life.
But if you are using it daily, and particularly if you have a folder of prompt templates you keep copying and pasting, three things have changed in the last year and they are worth an afternoon of your time.
Change one: nobody writes prompt templates any more
If you have a document full of prompts you paste in when you need them, that approach has been superseded.
The replacement is called a skill, and it is a much less complicated idea than the name suggests. A skill is a folder containing a markdown file with instructions, optionally alongside scripts or reference documents. The model reads it when it is relevant, and ignores it when it is not.
Anthropic shipped these for Claude Code in October 2025, then open-sourced the format that December as the Agent Skills specification. Within weeks OpenAI had adopted the same file format for Codex, and it has since been picked up by Cursor, Gemini CLI and GitHub Copilot.
Which means a skill you write once works more or less everywhere. That portability is the reason this stuck.
Why it beats a template folder:
You are not pasting anything. The model discovers the skill and loads it when the task matches, so you stop being the person who has to remember which prompt to use.
They are almost free. A skill sits in context as just its name and description, somewhere around a hundred tokens, and the full contents only load when needed. You can have fifty installed and pay almost nothing for the forty-nine you are not using.
And they are shareable. A skill is a file. You can put it in a repository, hand it to somebody, or version it like anything else.
The bit most people get wrong
Here is the practical detail that decides whether yours actually work.
The description field is everything.
Skills are not always on. They are discovered, and the model decides whether to load one based on its description. A vague description means the skill sits there never triggering, and you conclude the whole thing does not work.
Be specific and concrete about when it should be used. Not “helps with writing” but “use when drafting or editing customer-facing emails, proposals or quotes.” The description is not documentation for you. It is the trigger.
Change two: describe the destination, not the route
This is the one that will improve your output most, and it runs against how everybody learned to prompt.
The old approach was step by step. First do this, then do that, then format it like so. Rigid, sequential, controlling.
The new approach: write instructions the way you would brief a capable senior colleague.
You would not hand an experienced person a numbered list of keystrokes. You would tell them what you are trying to achieve, what success looks like, what constraints matter, and what context they need. Then you would let them work out how.
That is now the better way to write for a model, and the reason is straightforward. As these things get more capable, your prescribed steps become the limiting factor. You are forcing a competent thing to follow a route you worked out when you were less informed than it is about the problem in front of you.
So spend your effort on:
- What does finished look like? Describe it properly, in detail. This is where most of your words should go.
- What context does it need that it cannot infer?
- What are the hard constraints? Things that are non-negotiable rather than preferences.
- What does failure look like? Often more useful than describing success.
And spend less effort on: the order of operations, the exact process, and the intermediate steps.
There is a practical benefit beyond output quality. Instructions written as goals age far better. When a new model arrives, a goal-based skill usually just works better, whereas a step-based one has to be rewritten because the steps were designed around the previous model’s limitations.
When rigid steps are still right
I do not want to overstate this, because there are genuine exceptions.
If the process itself is the point, be prescriptive. Anything with a compliance requirement, a legally required disclosure, a fixed format somebody else specified, or a sequence where doing things out of order causes real damage. In those cases you want the steps followed exactly and you should say so.
The rule of thumb: be prescriptive about things that would be wrong if done differently, and descriptive about things that would merely be done differently.
Change three: for big work, write loops rather than prompts
The most advanced of the three, and only relevant if you are doing substantial work.
The old pattern was conversational. Prompt, wait, read the output, evaluate it, prompt again. You are the loop, and you are the slow part.
For anything genuinely large, a piece of software, a long analysis, a complex plan, that is the wrong shape. You end up babysitting.
The alternative is to write a specification rather than a prompt. A proper document describing what the finished thing must do, what constraints apply, and crucially how you would know it was complete. Then set the model running against that specification, checking its own work against it and continuing until it is met.
The model becomes the loop. You become the person who wrote the definition of done.
What makes this work or fail: it lives or dies on the specification, and specifically on whether “finished” is defined in a way something can actually check. Vague success criteria produce a loop that either stops too early or runs forever polishing.
If you cannot describe how you would recognise the finished thing, you are not ready to write the loop yet. Which is a useful discipline in itself, and honestly it is where most projects go wrong regardless of whether AI is involved.
Where I would start
If all of that sounds like a lot, do them in order and stop whenever it stops being useful.
Take your three most-used prompts and turn them into skills. Write the descriptions carefully. That alone removes the copy-and-paste habit.
Then rewrite one of them as a goal. Take whichever is most step-by-step, delete the steps, and replace them with a proper description of what good output looks like. Compare the results.
Leave the loops until you have something big enough to need them. Most people do not, and there is no prize for using the advanced technique on a small job.
The underlying shift
If there is one thing to take from all this, it is that the work has moved.
It used to be about phrasing. Finding the magic words, the clever framing, the prompt that unlocked better output. That was a real skill for a while and it is becoming much less important.
What matters now is being able to describe what you want clearly, in detail, including how you would know it was right. Which is not a prompting skill at all. It is the ability to specify, and it is the same thing that separates people who brief work well from people who get back something they did not want.
That skill was valuable before any of this existed. It is just that now it has a much larger multiplier attached to it.
Want to talk about how any of this applies to your business? Get in touch, or email hello@inkon.co.uk. I read every message myself.