Skill Engineering: getting results on real tasks

Why packaging matters

We worked with a marketing team who asked for help writing better briefs. The request made sense. The briefs were inconsistent, and the person writing them was starting from a blank chat window every time.

What solved it was turning the brief into a thing rather than a message. The product information came from one place rather than whatever someone had to hand. The brand guidance travelled with it rather than sitting in a document nobody opened. And the context reached the designer downstream, who had previously been working from a brief with none of the reasoning behind it.

Same person, same tools, better outcome, because the work stopped being improvised.

That is the argument for skills. Improvisation works for a task you do twice. For a task you do weekly, it means the quality of the output depends on how much attention the person had that morning.

Anyone can build one, and they should

This is within reach of someone with no technical background, and it is worth encouraging.

Watching a colleague in finance or marketing build something that works for their own job is often the moment AI stops being abstract for them. Not a demo, not a training session. A thing they made, that saves them twenty minutes, that they built themselves.

The value of that is not the twenty minutes. It is that they understand what these tools are good at from the inside, which makes every later conversation about AI in your organisation a better one.

So encourage it, and make time for it. Expect most of what gets built this way to be modest, and some of it to be abandoned.

Then the requirements change

This part is easier to plan for than to discover later.

The moment a skill is meant to be shared or scaled, what it needs changes.

It needs current data, rather than a copy someone pasted in last month. It needs to reach the systems where the real information lives, rather than relying on a person to fetch things first. It needs permissions, because not everyone should see everything. It needs a single live version, so two people running it get the same answer rather than two answers from two private copies. And it needs somebody to notice when it stops working.

At that point you are running a small piece of software. Without treating it that way, you tend to end up with several slightly different versions of the same logic in different people's private setups.

Where the line falls, and who decides

We give this split two plain names.

A self build is something a person can set up themselves with tools they already have. A supported build is anything that needs real engineering: handling customer data, connecting to systems, modelling, or guardrails to keep it safe.

People do not have to work out which is which. They log the idea, triage sorts it, and guessing wrong costs nothing. That is deliberate, because the alternative is someone deciding their idea is probably too complicated and never logging it at all.

Where the shared version lives

The scaling problem usually shows up first as a version problem. The good version lives in someone's notes, a few people have edited their own copy, and nobody can say which one is running.

That is what we built SkyLab for. It gives every prompt and skill a home with a structured editor, full version history, AI assisted authoring and review, and one live version you can call by name.

If your teams are already sharing prompts by copying them into Slack, that is the problem to solve, with SkyLab or with something else.

Part of the series that starts with The jargon is complicated. The capabilities underneath are simple. Next: Context Engineering, why the right information determines the outcome.